Blog

Among the core components of WebCenter Interaction (WCI) is its “notification engine.”  Users get notified via email or RSS feeds when information stored in the portal is updated. Typically, we subscribe to specific pieces of information we are interested in: e.g. collab projects, documents, discussion threads, tasks, etc. and then decide on the notification frequency: e.g. immediate, hourly, daily, or weekly summary email alerts.

I’ve often subscribed to pieces of information in WCI only to realize that my inbox gets flooded with notifications alerting me that content was updated.  The notification service is, by design, rightfully doing what it is expected to do: send alerts when content is updated.  However, often enough, upon receiving a notification and reading the document that was updated, thus triggering the alert, I realize that the updates were inconsequential in substance.  The updates might have been grammatical or syntactical edits and the notification service performed its due diligence and generated an alert in my inbox or RSS.  Along came Subscriber.  The idea is simple: the content owners decide when an alert gets sent out to the content item's subscribers, that is when the content update is worthy of sending a notification.

The Subscription process is simple:

• A “Subscribe / Unsubscribe” portlet is anchored on communities with content that is of interest to internal and external users.
• The content manager associates the community to specific portal group(s).
• The user decides if s/he wishes to subscribe to the content.
• If the user subscribers, s/he gets added to the portal group(s) that is/are associated to the community.
• If the content manager updates the content on that page/community and decides to alert its subscribers, s/he can then launch the eAlert application through a link accessible to content managers.
• Upon launching eAlerts, the application will retrieve the portal group(s) that is/are related to that business area and the content manager will select the group(s) to whom s/he will send the eAlert.
• Upon selecting the group(s) from the list and submitting the request, the group members will receive a custom notification message with a link to the content that has been updated.
• The notification triggers an asynchronous job and when all alerts are sent out, the content manager will receive a confirmation.
• If the user decides that the content on the page is no longer of interest to him/her; an “Unsubscribe” is then due.  Unsubscribe removes that user from the group related to that community.

As illustrated, the process is semi-automated; that is the alert is triggered by flesh and blood that distinguishes between a trivial syntactical edit and a genuine update that the Redskins have won the Super Bowl :-)

Thanks.

Hani