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.
Before you begin
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.
About this task
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.
Procedure
To assign an orphaned widget to a new community or existing
community, complete the following steps.
- Start the wsadmin client from the following
directory of the system on which you installed the Deployment Manager:
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.
- 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.
- 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:
Table 1. Parameters for
the CommunitiesRemoteAppService.assignRemoteApp command
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