Event notification

The process of conveying changed EIS data to the integration server is called event notification. Most of today's EISs either do not provide an event notification mechanism for external systems (such as an adapter) or have only rudimentary support for it. To enable automated integration, event notification is an absolute necessity. If the EIS does not provide event notification, the enterprise must either purchase an adapter from a business integration vendor that provides this feature, or it must spend the time, money and development resources (with deep application knowledge) necessary to develop this event notification mechanism for the EIS.

To an adapter, an EIS event is any operation that affects the data of an EIS entity associated with a business object definition. There are other types of events in an EIS - a mouse click is an event to an EIS's window system or forms interface. The adapter, however, is interested only in a pre-defined subset of the data-level events that create, update, delete, or otherwise affect the content of the EIS's data store. Some EISs can explicitly trap and report events, providing user-friendly event management. Other EISs, without a concept of discrete, reportable events, might silently update their databases when something happens.

Where an EIS provides a facility for events, the adapter's event detection mechanism generally leverages it to populate the event store. For such applications, setting up the connector's event-notification mechanism is a normal application setup task. For example, an EIS may allow the installation of a script that executes when a particular type of event occurs, and that the script can place a notification in an event store. This mechanism is frequently referred to as a user exit. Another EIS might have an internal workflow system that can register an event in the EIS and write to an event store when executed.

Essentially all IBM WebSphere Business Integration Adapters provide the event notification for the EIS for which the adapter is developed. This event notification mechanism is typically developed with the tools the EIS vendor provides and is certified by the EIS vendor for IBM WebSphere Business Integration Adapters. Many competitive adapter products do not provide this event detection mechanism for the EIS, and the enterprise must invest its own resources to solve this problem.

The ways in which application-specific components detect and retrieve events differ from one adapter to another. However, the way in which application-specific components send events to the adapter framework, and the way in which the adapter framework delivers those events to the integration broker, is standard across all adapters. The following describes general concepts regarding the event notification mechanism of most adapters, but does not describe the specific implementation of any particular adapter.

The event notification mechanism generally consists of the following elements:

The following figure shows an adapter and its supporting infrastructure detecting a change to the EIS data store and constructing a business object to convey the changed data to the integration server.

The event store provides a persistent mechanism, such as additional tables in the EIS data store, for logging the EIS's data changes. The data store provides an ordered list of operations that take place in the EIS. It might have the physical form of an application event queue, a database table, a directory on the file system, or an e-mail inbox.

The information in the event store generally includes the business object type, verb, the key identifying the changed data entity in the EIS data store, timestamp, and priority. The event store may also contain the complete data for the event itself. The event store is usually provided with the adapter as an artifact specific to the EIS development environment, and is readily imported into the system.

If an EIS does not provide native support for events, the event notification mechanism can utilize the EIS database. A table would be created for the adapter's event store, and database triggers would be installed on the EIS tables of interest to insert event records into the event table.

For example, you can set up a trigger on an "Employee" table that detects updates to the rows. When an update occurs, the trigger inserts information about the update into an event table. Each new row that appears in the event table represents an event notification.

An adapter's application-specific component identifies new EIS events through its event detection mechanism, the most common of which is polling for new events in the event store. The adapter framework generally initiates a poll call at periodic intervals. The polling method is specific to the application, based on the event notification mechanism that the connector uses.

Polling behavior is configurable, including poll frequency and the maximum number of events processed per poll call. The poll call asks the application-specific component to check for changes to the EIS's event store. The interface to the event store may be through the EIS APIs where possible, or it may be provided through database queries to retrieve new events directly from an event table.

If there has been a change since the last poll call, the application-specific component determines if a business object definition exists to represent the changed data. After detecting an event, the adapter's application-specific component:

Once the adapter framework receives the business object from the application-specific component, it delivers the event to the integration server.

Why use this process?

There are two arguments you might hear in objection to this technology for event notification:

  1. The event notification and event persistence are intrusive to the application.
  2. Why use polling when an application provides event notification?

This section explains why IBM architected its adapters this way and how this architecture benefits WebSphere Business Integration adapter customers.

Intrusiveness

If an EIS does provide an event notification mechanism, the WebSphere Business Integration Adapters typically leverage this mechanism. One example is the IBM WebSphere Business Integration adapter for mySAP.com, which can use the SAP internal workflow event notification mechanism. The adapter provides the link into this SAP internal event notification mechanism.

The information that is provided by the event notification mechanism (including the ID of the data that caused the event in the application, timestamp of the event, and the priority of the event,) is usually stored in the event table within the EIS.

The event table is created specifically for the adapter in the EIS. By storing the event in the additional event table, no events are lost - even when the adapter is down or the network connection between the adapter and the integration server is lost. If this persistence mechanism did not exist, application events could be lost and the result would be data inconsistencies across the enterprise.

Polling

The WebSphere Business Integration Adapter Framework provides the technology to bind specific methods within the adapter to the event detection mechanism of an application. This enables a "publish and subscribe" mechanism for application events within the adapter.

Most EISs do not provide robust error handling of their event notification mechanism, and sometimes the adapter will not leverage this direct link into the event notification mechanism of the application.

For example, suppose four external applications, including an adapter, subscribe to a specific EIS event, such as the creation or change of customer data. The event within the EIS occurs and gets published to all four subscribing applications, but the adapter is unavailable or an error occurs during the event submission to the adapter. Ideally, the event notification mechanism of the EIS would be intelligent enough to re-submit the events to any external application that has subscribed to it.

Furthermore, the EIS would take care of the error handling and persistence of the event until all subscribing applications have successfully processed it. This sophisticated event notification typically doesn't exist in today's EISs, since they were not built with integration in mind. Additionally, EISs that do provide this capability often require extensive configuration and development within the EIS accommodate the deployment. WebSphere Business Integration adapters provide this valuable capability in a simple and reliable way.

Copyright IBM Corp. 1997, 2004