A connector whose application provides triggering events must learn about those events and send the associated data to the integration broker. Figure 14 illustrates a connector's interactions with respect to event notification.
Figure 14. Event
notification in a connector.
The ways in which application-specific components detect and retrieve events differ from one connector to another. However, the way in which application-specific components send events to the connector framework, and the way in which the connector framework deliver those events to the integration broker, is standard across all connectors.
The following subsections describe general concepts regarding the operation of most connectors, including:
This discussion is not intended to describe the specific implementation of any particular connector.
To a connector, an application event is any operation that affects the data of an application entity that is associated with a WebSphere Business Integration adapters business object definition. There are other types of events in applications; for example, a mouse click is an event to an application's window system or forms interface. The connector, 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 application's data store.
Some applications explicitly trap and report events, providing user-friendly event management and configurable event text. Other applications, without a concept of discrete, reportable events, might silently update their databases when something happens. WebSphere Business Integration adapters provide connectors for both types of applications.
For most connectors, some application configuration is needed to set up an event- notification mechanism for the connector's use. An event-notification mechanism maintains an ordered list of operations that take place in the application. It might have the physical form of an application event queue, an e-mail inbox, or a database table.
What types of event-notification mechanisms do connectors use? The next sections illustrate some general approaches.
If an application is event-based, it probably has an event-notification interface for use by client applications such as connectors. The application might also permit you to configure the text of the event report. For such applications, setting up the connector's event-notification mechanism is a normal application setup task.
For example, imagine that an application lets you install a script that executes when a particular type of event occurs and that the script can place a notification in an event inbox. To install the connector for that application, you create a user account for the connector, write or obtain scripts for handling the events you want to track, install the scripts, specify the type of event that triggers each script, and create the inbox. When you are done, the application-specific component periodically retrieves the inbox contents to check for new events.
Figure 15 illustrates an application configuration that includes an event inbox.
Figure 15. Example:
Using an event inbox for event notification.
Another application might have an internal workflow system that can generate mail messages or write to an event queue when a particular operation occurs. Figure 16 illustrates an application that has its own business object repository where business objects and events are defined. In the figure, Customer is a business object and Create, Delete, and Update are the types of events associated with it.
When a business object event such as Customer.Update takes place, the event is sent to the workflow system, which places an entry in an event table in the application database.
Figure 16. Example:
Using application workflow for event notification.
The preferred method for a connector to interact with application events is through the application's API, which provides a framework that enforces the application's data model and logic. However, some application APIs do not provide native support for event notification.
One way that a connector can receive event notifications from such an application is to interact with the application database. 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 a table, created when you deploy the connector. Each new row that appears in the event table represents an event notification. The connector can use SQL queries to retrieve new events from the table.
Figure 17 illustrates this approach.
Figure 17. Example:
Using the database for event notification.
In Figure 17, the application database has a trigger on the creation of records in the Employee Table. Each time the application inserts a new record, the trigger creates a row in the event table. The row contains the key values of the new employee record (last name and employee ID), the system time, and the event type, Create.
A connector's application-specific component learns about application events through its event-notification mechanism, the most common of which is polling for new events in the event store. The polling method is specific to the application, based on the event- notification mechanism that the connector uses.
Polling is configurable. When you use the Connector Configurator tool to configure a connector, you can:
For most connectors, you can also specify the number of events to be processed per poll call.
An application-specific component need only poll an application if another application is interested in that application's events. If a particular application is not the source of events, you can stop the application-specific component from polling by setting its polling frequency to "no" using the Connector Configurator. To learn more about the Connector Configurator, refer to either of the Connector Development Guides or to the adapter user guide for the adapter you are deploying.
After detecting an event, the connector's application-specific component:
When an application-specific component retrieves an event, it must determine which business object definition and verb represent the event.
The application-specific component uses the event text to associate the event with a business object definition and verb, as Table 4 shows.
Table 4. Event text and business object formation
Type of data in the application event | Examples | Use |
---|---|---|
Application entity type | Customer, Part, Item | Determining the associated business object definition |
Operation that occurred | Create, Update, Delete | Determining the active verb of the business object |
For example, a connector can associate the following event text with an Employee.Create business object:
1997.10.19.12:50.22 employee created lname="como" id="101961"
From left to right, the event text consists of:
Note that this example is simple; other types of event text might require more processing by the application-specific component.
If the connector's been configured to support the business object definition for the event, the application-specific component builds a business object, uses a key value to retrieve application data, and fills in the business object with the application data. Business object construction and deconstruction describes the process of building a business object.
The application-specific component sends the business object to the connector framework without needing to know the identity of the application that will receive the information carried in the business object.
Application event archives are useful for troubleshooting and record-keeping. An event archive contains status information about each event, such as:
If an application provides an event archiving feature, the connector generally uses it. A connector for an application that does not support event archiving might have its own event archive. For example, if a connector's event-notification mechanism is like the database mechanism illustrated in Figure 17, a database trigger could copy deleted events to an archive table. that you create when you deploy the connector.
Guaranteed event delivery ensures that critical events, such as financial transactions, are processed correctly, regardless of any service interruptions that might occur. This feature enables the connector framework to guarantee that each event is detected and transmitted only once from the source connector's event store to the destination connector's request queue.
Without guaranteed event delivery, a small window of possible failure exists between the time that the connector detects an event and the time all necessary processing has completed. If a failure occurs in this window, the event has been sent but its event record remains in the event store. When the connector restarts, it finds this event record still in the event store and treats it as a new event, causing the event to be sent twice.
For more information about guaranteed event delivery and to learn how to enable it for the adapter you are deploying, refer to the adapter's user guide.