Administer widgets and remote applications

We can extend the community to include various components or applications. These applications are contained within the community as widgets. We 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...

• Bookmarks
• Files
• Forums
• Status Updates
• Recent Updates
• Members widgets

The Bookmarks, Files, Status Updates, and Forums widgets are added by default. Can be removed or hidden. The Recent Update and Members widgets are default widgets, and cannot be removed or hidden.

In addition, community owners can optionally add widgets...

• Activities
• Blogs
• IdeationBlog
• Events
• Feeds
• Subcommunities
• Media Gallery
• Related Communities
• Wiki

The Activities, Blogs, IdeationBlog, Files, Forums, Status Updates, and Wiki widgets are affected by lifecycle events.

When creating 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 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. We can use the CommunitiesQEventService commands to manually administer queued events when there is a problem with the WAS scheduler and you don't want to wait for the next scheduled retry task to run.

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. When users are added, removed, or when membership roles are changed.
• Community privacy setting changes. When a community is changed from public to private and vice versa.
• Widget addition or removal. 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.

See

• Use widgets-config.xml for Communities
• Add custom widgets to Communities
• Specify different system users for widget life-cycle events
• Administer community queued events
• Configure the widget life-cycle retry schedule
• Recover from a database failure

Parent topic:
Administer Communities

Related:
Scheduling tasks
Manage Communities scheduled tasks