Generating a synchronization report

Use the CommunitiesRemoteAppService.generateSyncReports command to generate HTML reports that help to identify data inconsistencies between communities and their remote applications.

Before you begin

You must export synchronized resource information by following the steps in the topic, Comparing remote application data with the Communities database.

To use wsadmin commands, you must use the IBM® WebSphere® Application Server wsadmin client. See Starting the wsadmin client for details.

About this task

The CommunitiesRemoteAppService.generateSyncReports command generates two HTML reports that can help you to identify data inconsistencies between communities and their remote applications, communityDifferences.html and orphanedRemoteApplications.html. The communityDifferences.html report lists the differences in the information that is recorded in different application databases. For example, the Communities database might record that the privacy level of a community is set to public, but the Blogs application might record the community type as restricted. The orphanedRemoteApplications.html file lists the remote applications for which there is either no associated community or whose associated community is missing the orphaned data widget.

The Wikis_communityDifferences.html reports might indicate that there are differences for community moderation fields. In IBM® Connections 4.0, these differences have no impact on the operation of Wikis and do not require immediate attention. It is recommended, however, that these differences are addressed since they might be meaningful in a future release.

Procedure

To generate a synchronization report, complete the following steps.
  1. Verify that you completed Comparing remote application data with the Communities database and then continue to the next step.
  2. Run the following command to generate the report:

    CommunitiesRemoteAppService.generateSyncReports(String syncedResourceInfoFilepath, String outputDirPath)

    Where:
    • syncedResourceInfoFilepath is the full path and file name of the output XML file that was generated by using the exportSyncedResource command. (For more information about this command, see Comparing remote application data with the Communities database.) Use forward slashes as the path separator. For example, c:/temp-dir/activitiesOutput.xml on Microsoft Windows or /opt/temp-dir/blogsOutput.xml on Linux or AIX®.
    • outputDirPath is the full path to the subdirectory where you want to create the two output files that are generated from this command. You must use forward slashes; not backslashes as the path separator. For example, c:/temp-dir on Microsoft Windows or /opt/temp-dir on Linux or AIX®.
    For example:
    CommunitiesRemoteAppService.generateSyncReports("c:/temp-dir/activitiesOutput.xml", "c:/temp-dir")
    Using the sample command previously shown, the two output files, Activities_communityDifferences.html and Activities_orphanedRemoteApplications.html, are created in the c:/temp-dir subdirectory.
  3. Repeat step 3 for each remote application where you want to restore data.
    Note: Potentially, you might need to run the command seven times, once for each remote application (Activities, Blogs, Files, Forums, Ideation Blogs, Status Updates, and Wikis) that is integrated with Communities.
  4. Check the application_orphanedRemoteApplications.html files. To keep the data identified in those files, follow the steps in the topic Assigning orphaned data to a new community. To delete the data, follow the steps in the topic Deleting orphaned data.
  5. Check the application_communityDifferences.html files. Contact the community owners for all the communities that are listed in the file. To ensure that the applications are synchronized, community owners can toggle the community privacy settings after any required data scrubbing is 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.
    Note: For Community Trash, some of the Communities that are listed in the application_communityDifferences.html file with "visibility" differences could be caused by a Community that is deleted and is now placed in Trash. Communities in the Trash are changed to have "private" as the visibility type. If so, synchronize the Community and the external widget by restoring the Community from the Trash temporarily. This action restores the Community's original visibility. You can then delete the Community again. Both Communities and the external widget now have the same visibility and both are now in Trash.