Deleting Orphaned data

If you have a page for which users have Priveleged user rights then then can customize/ personalize that page. When any of the user does that the portal server will create a private page and store that information in customization database domain(The actual page layout is stored in the RELEASE database domain). Now when you delete that page the main page would get deleted from RELEASE database domain( either immediately or at the time of schedule cleanup) but the personalized page that is stored in the CUSTOMIZATION domain wont be deleted. This page would be included in your database backup. You can delete the private page from the CUSTOMIZATION database domain by following these steps.

• First create a Private demo page like this. Make sure to assign Privileged User role to All Authenticated Portal Users.
  
  


• Now login with some other user except wpsadmin and customize the Private page by say rearranging the portlets on Private page. Also create com.wpcertification.privatepage.child as child page of the private page.
  
  


• Go to the Portal Admin Console and delete the Private page.


• Now create Full Export of the portal that includes Orphan data by executing this XMLAccess command
  
C:\WebSphere\PortalServer\bin>xmlaccess -user wasadmin -password wasadmin -url h
ttp://localhost:10040/wps/config -in c:\WebSphere\PortalServer\doc\xml-samples\E
xportIncludingOrphanedData.xml -out c:\temp\ExportIncludingOrphanDataResult.xml

  If you open the ExportIncludingOrphanDataResult.xml you will notice that it does not have com.wpcertification.privatepage but it does have the com.wpcertification.privatepage.child with value of parentref attribute equal to orphan like this
  
<web-app action="update" objectid="ORPHANED_DATA_CONTAINER_OID">
<portlet-app action="update" objectid="ORPHANED_DATA_CONTAINER_OID"/>
</web-app>
<content-node action="update" active="true" allportletsallowed="true" content-parentref="orphaned" create-type="explicit" domain="cust" objectid="6_6RUKKSU31OL4D0IG4BACKN00K5" ordinal="100" type="page" uniquename="com.wpcertification.privatepage.child">
<supported-markup markup="html" update="set"/>
<localedata locale="en">
<title>Child of test private page</title>
</localedata>
<parameter name="com.ibm.portal.IgnoreAccessControlInCaches" type="string" update="set"><![CDATA[false]]></parameter>
<parameter name="com.ibm.portal.bookmarkable" type="string" update="set"><![CDATA[Yes]]></parameter>
<parameter name="com.ibm.portal.remote-cache-expiry" type="string" update="set"><![CDATA[0]]></parameter>
<parameter name="com.ibm.portal.remote-cache-scope" type="string" update="set"><![CDATA[NON-SHARED]]></parameter>
<access-control auth-level="default" externalized="false" owner="uid=sunil,o=defaultwimfilebasedrealm" private="true"/>
</content-node>

  


• Now find the candidates for deletion by executing the following command
  
slcheckertool.bat --find-candidates -s c:\temp\ExportIncludingOrphanDataResult.xml -d c:\temp\findcandidate.xml -domain cust

  This will create an .xml file containing all the orphaned resources. In my case com.wpcertification.privatepage.child is the only child resource that it is able to find so it will create an xml file with one resource element the oid of this element is equal to the oid of the private child page and the value of type is content-node since it is a content node. If you had any other orphan data you would see additional nodes here.
  
<orphaned-resource-candidates export-origin="IBM WebSphere Portal/6.1.0.1 build wp6101_115_01 exported on Sat May 09 11:59:40 PDT 2009 from sunpatil-wxp/192.168.2.103">
<resource oid="6_6RUKKSU31OL4D0IG4BACKN00K5" type="content-node"/>
</orphaned-resource-candidates>

  


• Next step would be to identify the orphan data, this step is more useful if you have multiple lines of production. In that case you would have entered set of files that are generated by find-candidates command from each production line. This command would look through all of them and create one candidate file. This is the command that you will have to execute
  
slcheckertool.bat --identify-orphans -s c:\temp\findcandidate.xml -d c:\temp\identifycandidates.xml

  This file will generate an output file like this
  
<orphaned-resources>
<export-origins>
<export-origin value="IBM WebSphere Portal/6.1.0.1 build wp6101_115_01 exported on Sat May 09 11:59:40 PDT 2009 from sunpatil-wxp/192.168.2.103"/>
</export-origins>
<resource oid="6_6RUKKSU31OL4D0IG4BACKN00K5" type="content-node"/>
</orphaned-resources>

  


• Next step is to use slcchecker tool to generate an xmlaccess file that can be used to actually delete the orphan data. Execute this command to do that
  
slcheckertool.bat --delete-orphans -s c:\temp\identifycandidates.xml -d c:\temp\deleteorphans.xml

  It will produce an xmlaccess output file like this
  
<?xml version="1.0" encoding="UTF-8"?>
<!--
This is a generated file. Do not edit!

ATTENTION: Assure that all production lines were considered creating this file before xmlaccess is invoked with this file.

For the generation of this file the following full exports were used:
IBM WebSphere Portal/6.1.0.1 build wp6101_115_01 exported on Sat May 09 11:59:40 PDT 2009 from sunpatil-wxp/192.168.2.103

-->
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="SLChecker_1.0.xsd">
<portal action="remove-orphaned-data">
<content-node action="delete" objectid="6_6RUKKSU31OL4D0IG4BACKN00K5"/>
</portal>
</request>

  


• Now last step is to execute xmlaccess script to actually delete the orphan data. Execute this command to do that
  
xmlaccess.bat -user wasadmin -password wasadmin -url http://localhost:10040/wps/config -in c:\temp\deleteorphans.xml -out c:\temp\
deleteorphanresult.xml

  

Delayed cleanup of deleted portal pages

When you delete a page the portal server also deletes all its derived pages and dependent resources. This information is stored in the database so deleting all the resource might take long time. As administrator you have two choices for when the actual deletion should happen

• Immediately: That means as soon as you delete the portal page all its dependent resources get deleted immediately


• Delayed deletion: If you choose this option then that means when you delete the page it does not actually get deleted instead portal will only mark the page and its dependent resources as deleted and make sure that users are not able to access these deleted pages but the actual deletion is done by the ResourceCleanup task which runs on every Saturday at 8 PM by default.

You can configure delayed cleanup of resources by setting value of scheduler.cleanup.enabled property to true in the DataStoreService. If you dont want delayed cleanup set it to false.

Now if you set the delayed cleanup then you might face one problem. Lets say you deleted a page then if you try to recreate that page immediately you might get DuplicateKey exception because that page is not actually deleted. In that case you can execute XMLAccess task using Task.xml file which is available in PortalServer/doc/xml-samples directory as input file.

xmlaccess.bat -in c:\WebSphere\PortalServer\doc\xml-samples\Task.xml -out c:\temp\taskresult.xml -url http://localhost:10040/wps/config -user wasadmin -password wasadmin

When you run the cleanup task, the XML configuration interface only schedules the task to be run in WebSphere Application Server and returns. This does not necessarily mean that IBM WebSphere Application Server runs the task immediately. To determine when a task started and ended, check the portal log SystemOut.log for the EJPDE0002I and EJPDE0003I messages.

[5/9/09 11:29:27:319 PDT] 00000027 SchedulerTask I com.ibm.wps.datastore.ejb.cleanup.SchedulerTaskNotificationSinkBean handleEvent() EJPDE0005I: Task WPS_RUN_ONCE_TASK_com.ibm.portal.datastore.task.ResourceCleanup with ID 4957 was started.
[5/9/09 11:29:28:069 PDT] 00000027 SchedulerTask I com.ibm.wps.datastore.ejb.cleanup.SchedulerTaskNotificationSinkBean handleEvent() EJPDE0007I: Task WPS_RUN_ONCE_TASK_com.ibm.portal.datastore.task.ResourceCleanup with ID 4957 has finished.
[5/9/09 11:29:28:100 PDT] 00000027 SchedulerTask I com.ibm.wps.datastore.ejb.cleanup.SchedulerTaskNotificationSinkBean handleEvent() EJPDE0006I: RUN ONCE Task WPS_RUN_ONCE_TASK_com.ibm.portal.datastore.task.ResourceCleanup with ID 4957 has completed.


These messages confirm that the cleanup task has successfully completed. After you have confirmed this, you can run the XML script for re-creating a page with the same object ID as it had before the deletion.

If you want to change the schedule of when ResourceCleanup task runs then you can use XMLAccess and use the sample Task.xml file to figure out how to schedule a task.