Ensure data consistency following the recovery of an IBM
® Connections application or the Communities database.
Before you begin
To use wsadmin commands, you must use the IBM WebSphere
® Application Server wsadmin client. See Starting the wsadmin client
About this task
In the event of a database disaster, for example if the Communities database or another IBM
Connections application database fails, in addition to restoring the failed database, you need to ensure that data is correctly synchronized between the Communities database and the remote application databases. Your disaster recovery plan should start with restoring the failed database to a backup, with access to Communities and any integrated applications disabled.
This procedure is only needed if the databases that you restored from backup (for example, the Activities, Blogs, Files, Forums, or Wikis databases) are different from the Communities database backup. In other words, you only need to perform the steps below if, after you restored the application databases, any of the widget databases are older or newer than the Communities database.
To recover an IBM
Connections application that integrates with Communities after a database failure, complete the following steps.
- After the database is restored to a backup, but before general access is restored, temporarily disable access to the Communities application and any other integrating applications impacted by the failure. This must be done only at the IBM HTTP Server because the IBM WebSphere Application Server must be running to keep wsadmin commands available for the remaining recovery steps. Below is a suggested approach to accomplish this:
- Create an HTML document notifying users of the server maintenance window.
The maintenance page can inform users that the product is temporarily unavailable due to scheduled maintenance work. Point to the maintenance page using the following ErrorDocument statements:
- ErrorDocument 401 /upgrading.htm
- ErrorDocument 403 /upgrading.htm
- Add the following element to the IBM HTTP Server configuration file, httpd.conf, to block all unauthorized IP addresses from the server and send the user to the upgrading.htm page. The httpd.conf file is stored in the following directory by default:
- AIX®: /usr/IBM/HTTPServer/conf
- Linux®: /opt/IBM/HTTPServer/conf
- Microsoft® Windows®: C:\IBM\HTTPServer\conf
Restart IBM HTTP Server.
You must have an Allow element for every WebSphere
Application Server in your deployment.
<Location / >
Deny from all
Allow from <your.ip.address>
Allow from <ip.of.each.machine.in.deployment>
Temporarily stop the processing of past failed replay events. Do this by running the CommunitiesScheduler.pauseSchedulingTask("LifecycleRetryQueuedEvents") command. For more information about this command, see Managing Communities scheduled tasks.
Clear out the replay event queue (since these events might no longer be applicable to the current application state) by doing the following:
Run the exportSyncedResourceInfo command listed in the following table for each affected application.
- Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:
is the WebSphere
Application Server installation directory and <dm_profile_root>
is the Deployment Manager profile directory, typically dmgr01.
You must start the client from this directory or subsequent commands that you enter do not execute correctly.
- Start the Communities Jython script interpreter using the following command:
- Do one of the following:
- If the Communities application did not fail and only one or many of the remote applications had a data loss failure, clear only the affected queue or queues by using the following command:
- where <remoteAppDefId> is one of the following:
Table 1. IBM Connections applications and their remote application definition IDs
- If the Communities application had a data loss failure, clear the replay event queue for all remote applications by using the following command on the Communities admin console:
For more information about the CommunitiesQEventService commands, see Administering community queued events.
Generate an HTML report for each remote application export from above by running the following wsadmin command against each XML file:
If Communities failed, then all the applications are affected. Each service will generate an XML file depicting its current state of associated remote applications. This report is to be used in the next step for validation against the current state of the Communities database.
Before running the exportSyncedResourceInfo command, you must initialize the application's wsadmin environment by running the appropriate execfile("<application_name>Admin.py")
Table 2. The exportSyncedResourceInfo commands
|Activities||ActivityService.exportSyncedResourceInfo(String filePath, String eventType)|
|Blogs||BlogsAdminService.exportSyncedResourceInfo(String FullFilePath, String ContainerType, String BlogType)|
Note: The BlogType parameter is optional when you are exporting content for a blog. When you are exporting content for a blog, you can optionally specify Blog as the value for this parameter. For an Ideation Blog, you must specify a value of IdeationBlog.
For example, to export content for a blog:
To export content for an Ideation Blog:
BlogsAdminService.exportSyncedResourceInfo("/temp-dir/blogsOutput.xml", "community", "Blog")
BlogsAdminService.exportSyncedResourceInfo("/temp-dir/IdeationblogsOutput.xml", "community", "IdeationBlog")
|Files||FilesLibraryService.exportSyncedResourceInfo(String filePath, String eventType)|
|Forums||ForumsService.exportSyncedResourceInfo(String filePath, String eventType)|
|Wikis||WikisLibraryService.exportSyncedResourceInfo (String filePath, String eventType)|
For more information about the exportSyncedResourceInfo commands, see Comparing remote application data with the Communities database
Resume the processing of past failed events using the following command:
The output file created by the application-specific exportSyncedResourceInfo commands used in the previous step is used as input for the generateSyncReports command. This command generates two files, communityDifferences and orphanedRemoteApplications, in a localized HTML format. For more information about this command, see Generating a synchronization report.
Validate set-up and re-enable the HTTP server for user access.
For more information about this command, see Managing scheduled tasks
Do this by removing the Location and ErrorDocument statements that you added in step 1.
Contact the community owners for all the communities that are listed in the communityDifferences file. To ensure that the applications are synchronized, community owners can toggle the community privacy settings after any required data scrubbing has been completed. Community owners can temporarily modify the community settings. For example, they can set a community's access to restricted, save it, change the access back to public, and then save it again to alert all remote applications that the community's content should be publicly visible.
To ensure that data is correctly synchronized when files have been shared with communities from the Files application, and those communities do not contain the Files widget, use the following command:
To ensure that data is correctly synchronized when communities have been added to activities as activity members, use the following command:
If the name or the access level of a community has changed, the command updates the Files data store to reflect those changes. If the community no longer exists, the shared files still exist in the Files application. The file owners still own and have full access to that content even though it is no longer shared.
For each remote application listed in the orphanedRemoteApplications file, do one of the following:
If the name or the access level of the community has changed, the command updates the Activities data store to reflect those changes. If the community no longer exists, the membership of the activity is changed, removing the community.
Parent topic: Recovering from a database failure
Next topic: Comparing remote application data with the Communities database
Restoring a Community Blogs widget
Generating a synchronization report
Managing Communities scheduled tasks
Assigning orphaned remote applications to a community
Deleting orphaned data
- If the data should be retained, use the CommunitiesRemoteAppService.assignRemoteApp command to assign the application to a relevant community. This might be the same community as before if only the widget is missing from the community. It might be a new community if the entire community and its membership was lost on data recovery. For more information about the CommunitiesRemoteAppService.assignRemoteApp command, see Assigning orphaned remote applications to a community.
- Delete orphaned data from the remote application by running the commands described in Deleting orphaned data.