Administering widgets and remote applications

You can extend your community to include various components or applications. These applications are contained within the community as widgets. You can administer widget lifecycle 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, Status Updates, Recent Updates, and Members widgets. The Bookmarks, Files, Status Updates, and Forums widgets are added by default, but can be removed or hidden. The Recent Updates and Members widgets are default widgets, and cannot be removed or hidden. In addition, community owners can optionally add the Activities, Blogs, IdeationBlog, Events, Feeds, Subcommunities, Media Gallery, Related Communities, and Wiki widgets. Of these widgets, the Activities, Blogs, IdeationBlog, Files, Forums, Status Updates, and Wiki widgets are affected by lifecycle 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® WebSphere® 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, Blogs, IdeationBlog, Files, Forums, Status Updates (News), and Wiki applications. Changes to these applications are not pulled into Communities. The changes that are pushed out to the widget servers include the following changes:
  • 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.

The widgets-config.xml 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.