IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Services and service-related functions > Access external services with adapters > Configure and using adapters > IBM WebSphere Adapters > Adapter Toolkit > Implementing code from the IBM WebSphere Adapter Toolkit > Inbound event notification

Use the IBM WebSphere Foundation Classes for inbound event notification

Although not required, use of the IBM WebSphere Foundation Classes is strongly recommended for adapters that need to provide event notification.

Using the Foundation Classes can dramatically simplify the often complicated implementation of event retrieval and publication. The Foundation Classes can automatically track endpoints (the consumers of events) for the adapter, control the polling for and delivery of events, handle recovery of events if the adapter unexpectedly terminates, and assure once-and-only-once event delivery. This allows developers to provide greater quality of service (QoS) in less time and also ensure that behavior across adapters is consistent.

In order to employ the Foundation Classes for event-notification, the adapter and EIS application must meet requirements described in the following sections.


Event Store Requirements

  1. Event data must be persistent. Once detected in the event store, an event should remain available there until deleted by the adapter regardless of connection failure or time elapsed.

  2. The event store must allow the adapter to both identify and change the state of event records in the event store.


Adapter Requirements

To manage application-specific events, the Foundation Classes require that you provide application-specific logic, if any. To do this, you must:

  1. Ensure that any subclass of com.ibm.j2ca.base.WBIResourceAdapter implements interface com.ibm.j2ca.WBIPollableResourceAdapter. This interface allows the Foundation Classes to acquire an EventStore implementation that specifically reflects the EIS application.
  2. Provide an implementation of the com.ibm.j2ca.extensions.eventmanagement.EventStore interface. This interface allows the Foundation Classes to manage events in the store without requiring specific knowledge of how and where the event store is implemented.
  3. Extend WBIActivationSpecForXid to include the base polling properties.

    There is an alternate ActivationSpec, called WBIActivationSpecForPooling, that contains two additional properties; Minimum connections, and MaximumConnections. These properties are used by the event manager to establish a connection pool of EventStoreWithXid instances. Each instance of EventStoreWithXid is treated as a "connection".

    If the user sets MaximumConnections to a value greater than 1, and the delivery type is set to a value other than "ORDERED", multiple threads will be used in delivery, and each delivery thread can potentially be assigned a discrete connection.

    If you decide to use WBIActivationSpecForPooling, keep in mind that "createEventStore" can be called multiple times on your adapter, so be sure to handle this appropriately.


Application Requirements

In many cases–and even when your adapter does not implement the Foundation Classes–an application must also be configured or modified before the adapter can use the event-notification mechanism.

Modifications to the application might include setting up a user account in the application, creating an event store and event table in the application database, inserting stored procedures in the database, or setting up an inbox.

If the application generates event records, you might need to configure their text. You might also need to configure the adapter to use the event-notification mechanism.

For example, a system administrator might need to set adapter-specific configuration properties to the names of the event store and event table.

Inbound event notification