Event notification

Many (but not all) connectors engage in a publish-and-subscribe interaction with collaborations and use event-notification to trigger events in those collaborations. A connector whose application provides triggering events for InterChange Server collaborations must learn about those events and send the associated data to the subscribing collaboration. The following figure illustrates a connector's interactions with respect to event notification.



Figure 29. Event notification in a connector

The ways in which connector agents detect and retrieve events differ from one connector to another. However, the way in which connector agents send events to connector controllers, and the way in which connector controllers deliver those events to collaborations, 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.

Setting up the application's event-notification mechanism

To a connector, an application event is any operation that affects the data of an application entity that is associated with a 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 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.

For most connectors, an implementor needs to perform some application configuration to set up an event notification mechanism for the connector's use. An event notification mechanism is an ordered list of operations that take place in the application. It might have the physical form of an application event queue, an email inbox, or a database table.

What types of event notification mechanisms do connectors use? The next sections illustrate some general approaches.

When applications have event support

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 implementors 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 connector agent periodically retrieves the inbox contents to check for new events.

The following figure illustrates an application configuration that includes an event inbox.



Figure 30. Example Using an event inbox for event notification

Another application might have an internal workflow system that can generate email messages or write to an event queue when a particular operation occurs. Figure 31 illustrates an application that has a business object repository where business objects and events are defined. In the figure, Customer is an application 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 31. Example: Using application workflow for event notification


When applications lack event support

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, an implementor 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 special table. Each new row that appears in this table of events represents an event notification. The connector can use SQL queries to retrieve new events from the table.

Figure 32 illustrates this approach.

Figure 32. Example: Using the database for event notification


In Figure 32, 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.

Detecting an event

A connector agent learns about application events by polling for new events in the event notification mechanism. The polling method is completely application-specific, based on the event notification mechanism that the connector uses.

Polling is configurable. When you use System Manager to configure a connector, you can:

A connector agent need not poll an application if collaborations are not interested in the application's events. If a particular application participates in collaborations but is not the source of events, you can stop the connector agent from polling by setting its polling frequency to "no."

Processing an event

After detecting an event, the connector agent:

Associating an application event with a business object definition

When a connector agent retrieves an event, it must determine whether any collaboration has subscribed to the event. However, because collaborations subscribe to events in the form business-object-type.verb, the connector must first determine which business object definition and verb represent the event.

The connector agent uses the event text to associate the event with a business object definition and verb, as Table 6 shows.

Table 6. 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"

The event text contains:

Although this example is simple, other types of event text might require more processing by the connector agent.

Checking for subscriptions

After the connector agent associates an event with a business object definition and verb, it checks its internal list of subscriptions to find out whether any collaboration is interested in the event. The list of subscriptions is always current because the connector controller updates the connector agent whenever subscriptions change.

If the event does not match any current subscription, the connector agent logs a warning message and discards the event.

Building a business object

If there is a subscription for an event, the connector agent builds a business object, uses the key values to retrieve application data, and fills in the business object. "Business object construction and deconstruction" describes and illustrates the process of building a business object.

Sending the business object to the connector controller

A connector agent sends a business object to the connector controller by means of the transport in use (messaging or CORBA). The connector agent knows only that there is a subscription for the business object but does not know which collaboration or collaborations are the subscribers; the connector controller takes care of delivery to the collaborations.

Archiving events

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 32, a database trigger could copy deleted events to an archive table.

Copyright IBM Corp. 1997, 2004