Skip to content

Assigning orphaned remote applications to a community

Use the CommunitiesRemoteAppService.assignRemoteApp command to assign remote applications that have been orphaned following a database failure to a new community or reinsert the widget into an existing community.

To use administrative commands, you must use the wsadmin client. See Starting the wsadmin client for details.

To assign orphaned remote applications to a community, you must first run the CommunitiesRemoteAppService.generateSyncReports command. This command generates an <remoteAppDefId>_orphanedRemoteApplications.html file that contains a list of orphaned remote applications, along with each application's objectIdentifyingId and oldCommunityUuuid. These two values are needed as input to the command for assigning orphaned remote applications to a community, CommunitiesRemoteAppService.assignRemoteApp. For more information about using the generateSyncReports command, see Generating a synchronization report.

You can use the CommunitiesRemoteAppService commands when recovering from an incomplete database restore. If, after the restore process, you find that orphaned remote applications remain, use the assignRemoteApp wsadmin command to assign these applications to new communities or find their previously associated community and add their widget again with the existing data.

Note: You cannot assign an orphaned widget to a community that already contains that type of widget. For example, if you have an orphaned Activities widget, when you use the assignRemoteApp wsadmin command to assign it to a community, that community must not have an Activities widget already added to it. If the community already contains an Activities widget, the command will fail with an exception in the SystemOut.log file. The same is true for the other types of widgets that you can add to a community, that is, the Blogs, Files, Forums, IdeationBlog, Status Updates, and Wiki widgets. By default all new communities contain the Files, Forums, and Status Updates widgets. If the user is reassigning orphaned Files, Forums, or SU widgets to this new community, you must remove those widgets from the new community before you issue this command.

  1. To assign an orphaned widget to a new community or existing community, complete the following steps.
  2. Start the wsadmin client from the following directory of the system on which you installed the Deployment Manager:

    [app\_server\_root](../plan/i_ovr_r_directory_conventions.md)\profiles\dm\_profile\_root\bin
    
    app\_server\_root\profiles\dm\_profile\_root\bin
    

    where app_server_root 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 will not execute correctly.

  3. Start the Communities Jython script interpreter using the following command:

    execfile("communitiesAdmin.py")
    

    If prompted to specify a service to connect to, type 1 to pick the first node in the list. Most commands can run on any node. If the command writes or reads information to or from a file using a local file path, you must pick the node where the file is stored.

  4. Use the following command to assign orphaned widgets to new communities.

    Repeat the command for each orphaned remote application.

    CommunitiesRemoteAppService.assignRemoteApp("remoteAppDefId", "objectIdentifyingId", "oldCommunityUuid", "newCommunityUuid", "uiLocation")

    The command takes the following parameters:

    Parameter Description
    remoteAppDefId The remote application's identifier: Activities, Blog, Files, Forum, IdeationBlog, StatusUpdates, or Wiki.
    objectIdentifyingId Provided as part of the synchronization report generated by the generateSyncReports command. For more information about the generateSyncReports command, see Generating a synchronization report.This ID is specific to the remote application and is used to uniquely identify the orphaned resource.

| |oldCommunityUuid|Provided as part of the synchronization report generated by the generateSyncReports command. For more information about the generateSyncReports command, see Generating a synchronization report.This ID is a character string often found in the URL of a community page, for example, 6dd8815a-890e-4742-8261-e98e51362bb0. This ID represents that of the community that the orphaned resource was previously associated with.

| |newCommunityUuid|This ID represents the new community to which to assign the orphaned remote application. If the old community still exists but is missing the remote application's widget, you can provide the same value as the oldCommunityUuid. If the old community is gone, you can create a new community and provide its ID as this value. After creating a new community, look in the URL for the following pattern (/html/communityview?communityUuid=6dd8815a-890e-4742-8261-e98e51362bb0). Its ID can be extracted form the communityUuid parameter value following the equal sign.| |uiLocation|With the exception of the Status Updates widget, the remote applications only support col2 as a user interface location; this value must always be used. col2 is a string and must always be enclosed in quotation marks: "col2".For the Status Updates widget, col2statusposts must be used. col2statusposts is a string and must always be enclosed in quotation marks: "col2statusposts".

|

For example:

```
CommunitiesRemoteAppService.assignRemoteApp("Forum", "b307369e-7e60-403b-b850-206a28d6c19e", "b307369e-7e60-403b-b850-206a28d6c19e", "a307376f-3g20-523c-a320-921c28d6c19e", "col2")
```

The command returns the following output to the wsadmin console when the assignment completes successfully:

```
Assignment succeeded
```

Parent topic:Recovering from a database failure