Implementing event detection

For most connectors, the application must be configured to implement the event detection mechanism. A system administrator does this as part of the connector installation. Once the application has been configured, it can detect entity changes and write event records to the event store. The information is then picked up by the connector and processed. In this way, an event notification mechanism is implemented in both the application and the connector.

This section provides the following information about event detection:

Event detection mechanisms

Events can be triggered by user actions in the application, by batch processes that add or modify application data, or by database administrator actions. When an event detection mechanism is set up in an application and an application event associated with a business object occurs, the application must detect the event and write it to the event store.

Event detection mechanisms are application dependent. Some applications provide an event detection mechanism for use by clients such as connectors. The event detection mechanism may include an event store and a defined way of inserting information about application changes into the event store. For example, one type of implementation uses an event message box, where the application sends a message every time it processes an event in which the connector is interested. The connector's application-specific component periodically polls the message box for new event messages.

Other applications have no built-in event detection mechanism but have other ways of providing information on changes to application entities. If an application does not provide an event detection mechanism, you must use whatever mechanism is available to extract information on entity changes for the connector. For example, you may be able to implement database triggers, use user exits to call out to a program that writes to an event store, or extract information on application changes from flat files.

Note:
Although the way in which events are generated can vary significantly from application to application, certain aspects of an event notification mechanism should be consistent across all types of applications. For example, all types of event detection mechanisms should create event records that have similar contents.

Three common ways in which events are detected and written to an event store are discussed in the following sections:

Form events

Some form-based applications provide form events that are executed when a special user action occurs. To set up event detection in this way, you must create a script that executes when a particular type of event occurs. When a user opens a form and performs an action that has an associated script, the script places event records in the event store.

In most cases, form events are integrated in application business processes and therefore support application business logic. However, only application events that are triggered by user actions are detected; if the application database is updated directly in other ways, such as by a batch process, these events are not detected.

Figure 51 shows a form-based event detection mechanism. When a user enters a new customer on the Customer form and clicks OK, a script generates an event record and places it in the event store.

Figure 51. Form-based event detection

Workflow

Some applications use an internal workflow system to keep track of their business processes. You may be able to use the workflow system to generate events for event detection.

For example, you may be able to define a workflow process that inserts an entry in an event store when a particular operation occurs. Alternatively, the event detection mechanism might be able to intercept information from a workflow process and use the information to place an event record in the event store. In designing a workflow-based event detection mechanism, you need to determine at what point in the workflow an event record should be written to the event store and then use the available application mechanism to generate the event record.

Using a workflow system for event detection ensures that event detection is integrated into an application business process. The workflow system can also detect application events that are generated automatically without user involvement.

Figure 52 shows a workflow-based event detection mechanism. When a particular operation occurs, the workflow process is started. The event detection mechanism receives the information about the event and writes a record to the event store. The workflow process continues with other tasks.

Figure 52. Workflow-based event detection

Database triggers

If the application has no built-in method for detecting events and the database that the application is running on provides database triggers, you may be able to implement row-level triggers to detect changes to application tables. The triggers are inserted in application tables that correspond to business object definitions supported by the connector.

With this mechanism, you also need to set up an event table in the application database to store the event records that the triggers generate. Whenever an application entity is created, updated, or deleted, a trigger inserts a row into the event table. Each row represents one event record, and the event table queues the events for processing by the connector.

Figure 53 shows a user action that updates an application Customer table. When the Customer table is updated, a trigger on the table executes and writes an event record to the event table in the application database.

Figure 53. Event detection using database triggers

If you use database triggers, keep the following in mind:

Event detection: standard behavior

An application event detection mechanism should take the following steps:

Once event records are in the event store, the event store queues events for pickup by the connector's poll method. The event store should be internal to the application. If the application terminates unexpectedly, the event store can be restored to its preceding state when the application is restored, and the connector application-specific code can then pick up queued events.

The event detection mechanism should ensure data integrity between an application event and the event record written to the event store. For example, generation of an event record should not take place until all required data transactions for the event have completed successfully.

Subsequent sections provide the following information about issues to handle in the event detection mechanism:

Filtering the event store for duplicate event records

The event detection mechanism can be implemented so that duplicate events are not saved in the event store. This behavior can minimize the amount of processing that the integration broker has to perform. As an example, if an application updates a particular Address object several times between connector polls, all the events might be stored in the event store, and the connector will then create business objects for all events and send them to InterChange Server. To prevent this, the event detection mechanism can filter the events such that only a single Update event is stored.

Before storing a new event as a record in the event store, the event detection mechanism can query the event store for existing events that match the new event. The event detection mechanism should not generate a record for a new event in these cases:

Case 1 The business object name, verb, key, status, and ConnectorId (if applicable) in a new event match those of another unprocessed event in the event store.
Case 2 The business object name, key, and status for a new event match an unprocessed event in the event table; in addition, the verb for the new event is Update, and the verb for the unprocessed event is Create.
Case 3 The business object name, key, and status for a new event match an unprocessed event in the event table; in addition, the verb in the unprocessed event in the event table is Create, and the verb in the new event is Delete. In this case, remove the Create record from the event store.
Note:
If event detection is implemented with stored procedures and triggers, the stored procedures can perform the query before inserting records for new events.

Future event processing

The event detection mechanism can be set up to specify a date and time in the future to process an event. To implement this feature, you may need to set up an additional event store for these events. Event records in the future event store should include a date that identifies when they will be processed.

This feature is required for applications with records that include effective dates. As an example, suppose that an existing employee will receive a promotion in a month and that, at that time, he will receive a raise. Because the paperwork for his increased compensation is completed prior to the date of his promotion, the change to his status generates an event with an effective date, which is stored in the future event table.

Copyright IBM Corp. 1997, 2003