Home

 

Restore communities with remote applications

Ensure data consistency following the recovery of an IBM Lotus Connections feature or the Communities database.

In the event of a database disaster, for example if the Communities database or another Lotus Connections feature 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 features disabled. To recover a Lotus Connections feature that integrates with Communities after a database failure...

  1. After the database is restored to a backup, but before general access is restored, temporarily disable access to the Communities feature and any other integrating features 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:

    1. 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

    2. 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 by default:

      • AIX/usr/IBM/HTTPServer/conf

      • Linux/opt/IBM/HTTPServer/conf

      • Microsoft WindowsC:\IBM\HTTPServer\conf

      You must have an Allow element for every WebSphere Application Server in your deployment.

        <Location / > Order Deny,Allow Deny from all Allow from <your.ip.address> Allow from <ip.of.each.machine.in.deployment>
        </Location>
        

    3. Restart IBM HTTP Server.

  2. Temporarily stop the processing of past failed replay events. Do this by running the CommunitiesSchedulerService.pauseSchedulingTask("LifecycleRetryQueuedEvents") command. For more information about this command, see Managing scheduled tasks.

  3. Clear out the replay event queue (since these events might no longer be applicable to the current application state) by doing 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...

      CommunitiesQEventService.clearQueuedEventsByRemoteAppDefId("<remoteAppDefId>")

      where <remoteAppDefId> is one of the following:


      Lotus Connections features and their remote application definition IDs

      Feature remoteAppDefId
      Activities Activities
      Blogs Blog
      Files Files
      Wikis Wiki

    • 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:

      CommunitiesQEventService.clearQueuedEventsByResourceType("community")

    For more information about the CommunitiesQEventService commands, see Administering community queued events.

  4. Run the exportSyncedResourceInfo command listed in the following table for each affected feature. If Communities failed, then all the features 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.


    The exportSyncedResourceInfo commands

    Feature Command
    Activities ActivityService.exportSyncedResourceInfo (String filePath, String eventType)For example:

      ActivitiesService.exportSyncedResourceInfo("/temp-dir/activitiesOutput.xml", "community")
      

    Blogs BlogsAdminService.exportSyncedResourceInfo(String filePath, String eventType)For example:

      BlogsAdminService.exportSyncedResourceInfo("/temp-dir/blogsOutput.xml", "community")
      

    Files FilesLibraryService.exportSynchedResourceInfo(String filePath, String eventType)For example:

      FilesLibraryService.exportSyncedResourceInfo("/temp-dir/filesOutput.xml", "community")
      

    Wikis WikisLibraryService.exportSyncedResourceInfo (String filePath, String eventType)For example:

      WikisLibraryService.exportSyncedResourceInfo("/temp-dir/wikisOutput.xml", "community")
      

    For more information about the exportSyncedResourceInfo commands, see Comparing remote application data with the Communities database.

  5. Generate an HTML report for each remote application export from above by running the following wsadmin command against each XML file:

    CommunitiesRemoteAppService.generateSyncReport(syncedResourceInfoFilepath, outputDirPath)

    The output file created by the feature-specific exportSyncedResourceInfo commands used in the previous step is used as input for the generateSyncReport 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.

  6. Resume the processing of past failed events...

    CommunitiesSchedulerService.resumeSchedulingTask("LifecycleRetryQueuedEvents")

    For more information about this command, see Managing scheduled tasks

  7. Validate setup and re-enable the HTTP server for user access. Do this by removing the Location and ErrorDocument statements that you added in step 1.

  8. Contact the community owners for all the communities that are listed in the communityDifferences file. To ensure that the features 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.

  9. For each remote application listed in the orphanedRemoteApplications file, do one of the following:

    • If the data should be retained, use the CommunitiesRemoteAppService 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 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.


Recovering from a database failure


Next topic:

Comparing remote application data with the Communities database

 

Related tasks

Restore a Community Blogs widget

Generating a synchronization report

Manage scheduled tasks

Assigning orphaned remote applications to a community

Delete orphaned data


+

Search Tips   |   Advanced Search