Restore communities with remote applications 

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

Before you begin

To use wsadmin commands, use the IBM WAS wsadmin client. See Starting the wsadmin client for details.

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.

Note: 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...

  1. 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 WAS 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 directory by default:

      • AIX : /usr/IBM/HTTPServer/conf

      • Linux™: /opt/IBM/HTTPServer/conf

      • Microsoft™ Windows™: C:\IBM\HTTPServer\conf

        You must have an Allow element for every WAS in your deployment.

        <Location / >
        Order Deny,Allow
        Deny from all
        Allow from <your.ip.address>
        Allow from <>

    3. Restart IBM HTTP Server.

  2. 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 Manage Communities scheduled tasks.

  3. Clear out the replay event queue (since these events might no longer be applicable to the current application state)...

    1. Start the wsadmin client from the dmgr host:


      • From the dmgr host:

      • Do one of the following:

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


        2. where <remoteAppDefId> is one of the following:

            Table 1. IBM Connections applications and their remote application definition IDs
            Application remoteAppDefId
            Activities Activities
            Blogs Blog
            Files Files
            Forums Forum
            Ideation Blog IdeationBlog
            Wikis Wiki

        3. 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 Administer community queued events.

  4. Run the exportSyncedResourceInfo command listed in the following table for each affected application.

      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.

      Note: Before running the exportSyncedResourceInfo command, initialize the application's wsadmin environment by running the appropriate execfile("<application_name>") command.

      Table 2. The exportSyncedResourceInfo commands

      Application Command
      Activities ActivityService.exportSyncedResourceInfo(String filePath, String eventType)

      For example:

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

      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, specify a value of IdeationBlog.

      For example, to export content for a blog:

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


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

      To export content for an Ideation Blog:

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

      Files FilesLibraryService.exportSyncedResourceInfo(String filePath, String eventType)

      For example:

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

      Forums ForumsService.exportSyncedResourceInfo(String filePath, String eventType)

      For example:

        ForumsService.exportSyncedResourceInfo("/temp-dir/forumsOutput.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.generateSyncReports("syncedResourceInfoFilepath", "outputDirPath")

      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.

  6. Resume the processing of past failed events using the following command:


      For more information about this command, see Manage scheduled tasks

  7. Validate set-up 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 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.

  9. 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:


      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.

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

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

    • 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 Delete orphaned data.

Parent topic

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 Communities scheduled tasks
Assigning orphaned remote applications to a community
Delete orphaned data