You can extend your community to include various components or applications. These applications are contained within the community as widgets. You can administer widget life-cycle events to ensure that changes are synchronized between the Communities server and the servers hosting the widgets.
Communities has several widgets that are automatically added when the community is first created. These widgets include the Bookmarks, Files, Forums, and Members widgets. The Bookmarks, Files, and Forums widgets are opened by default, but can be removed or hidden. The Members widget is a default widget, and it cannot be removed or hidden. In addition, community owners can optionally add the Activities, Blog, Feeds, Subcommunities, and Wiki widgets. Of these widgets, the Activities, Blog, Files, Forums, and Wiki widgets are affected by life-cycle events.
When you create a community and add a widget to it, such as the Activities widget, any activities added to the community are owned by the community. Only members of the community can access those activities and, if the community's membership changes, or if the community is deleted, then the Activities widget must be updated with those changes. Provided that the Communities server and the widget (Activities, in this example) server are both up and running, these changes are applied to the widget immediately.
However, if the widget server is down for some reason, the changes need to be synchronized when the server is back up and fully running again. If an event cannot be pushed out to the widget server, the event is queued in a Communities database table, LC_EVENT_REPLAY. The IBM
® Application Server scheduler attempts to push queued events to the widget server's event handler on a scheduled basis until it is successful. When multiple events are queued for a single widget, the events are tried in consecutive order, with the oldest events tried first. You can use the CommunitiesQEventService commands to manually administer queued events when there is a problem with the WebSphere
Application Server scheduler and you don't want to wait for the next scheduled retry task to run. For more information about these commands, see Administering community queued events
Changes are only pushed from Communities to the Activities, Blog, Files, Forums, and Wiki widgets; changes to these applications are not pulled into Communities. The changes that are pushed out to the widget servers include the following:
- Membership changes. For example, when users are added, removed, or when membership roles are changed.
- Community privacy setting changes. For example, when a community is changed from public to private and vice versa.
- Widget addition or removal. For example, when the activities, blog, files, and wiki widgets are added to or removed from a community.
- Updates to community information. For example, changes to the community name, description, or tags.
- Community deletion.
file contains a section for each of the widgets available in Communities. Each widget section contains configuration settings for the widget's life cycle and lists the events that correspond to the widget. For more information about this file, see Using the widgets-config.xml file for Communities
Using the widgets-config.xml file for CommunitiesParent topic: Administering Communities
Working with remote applications
Managing Communities scheduled tasks
files contains configuration settings for each of the widgets supported by Communities and Profiles. To update settings in the file, you must check the file out and, after making changes, you must check the file back during the same wsadmin session as the checkout for the changes to take effect.
Adding custom widgets to Communities
Extend the functionality of the Communities application by adding custom widgets. To make the widgets available for use in Communities, you need to configure the widgets in the widget definition file, widgets-config.xml
Specifying different system users for widget life-cycle events
Specify a system user to manage widget life-cycle events that overrides the default authentication alias created at installation time.
Administering community queued events
Use the CommunitiesQEventService commands to administer the life-cycle events that occur within a community.
Configuring the widget life-cycle retry schedule
Communities uses the IBM WebSphere
Application Server scheduler to run a scheduled task that processes events in the widget life-cycle event queue. You can configure the frequency with which this task runs by editing settings in the communities-config.xml
Recovering from a database failure
When Communities or another IBM
Connections application experiences a database failure that involves restoring to a backup without replaying the transaction log to the point of failure, you can follow a number of steps to ensure a consistent data state for communities and their associated remote applications.