Regardless of whether the application provides is an event store in a table, inbox, or other location, the connector must poll periodically to retrieve event information. The connector's poll method, pollForEvents(), polls the event store, retrieves event records, and processes events. To process an event, the poll method determines whether the event has subscribers, creates a new business object containing application data that encapsulates the event, and sends the business object to the connector framework.
This section provides the following information on how to implement the pollForEvents() method:
The pollForEvents() method typically uses a basic logic for event processing. Figure 55 shows a flow chart of the poll method's basic logic.
For an implementation of this basic polling logic, see Implementing an event-notification mechanism.
This section provides information on the following polling issues:
Once a connector has processed an event, it can archive the event. Archiving processed or unsubscribed events ensures that events are not lost. Archiving usually involves the following steps:
The archive store serves the same basic purpose as an event store: it saves archive records in a persistent cache until the connector can process them. An archive record contains the same basic information as an event record.
The archive record should be updated with one of the event-status values in Table 49.
Status | Description |
---|---|
Success | The event was detected, and the connector created a business object for the event and sent the business object to the connector framework. |
Unsubscribed | The event was detected, but there were no subscriptions for the event, so the event was not sent to the connector framework and on to the integration broker. |
Error | The event was detected, but the connector encountered an error when trying to process the event. The error occurred either in the process of building a business object for the event or in sending the business object to connector framework. |
This section provides the following information about event archiving:
If the application provides archiving services, you can use those; otherwise, an archive store is usually implemented using the same mechanism as the event store:
Archiving can have performance impact in the form of the archive store and moving the event records into this store. Therefore, you might want to design event archiving to be configurable at install time, so that a system administrator can control whether events are archived. To make archiving configurable, you can create a connector-specific configuration property that specifies whether the connector archives unsubscribed events. IBM suggests a name of ArchiveProcessed for this configuration property. If the configuration property specifies no archiving, the connector application-specific component can delete or ignore the event. If the connector is performance-constrained or the event volume is extremely high, archiving events is not required.
A connector performs archiving as part of the event processing in its poll method, pollForEvents(). Once a connector has processed an event, the connector must move the event to an archive store whether or not the event was successfully delivered to the connector framework. Events that have no subscriptions are also moved to the archive. Archiving processed or unsubscribed events ensures that events are not lost.
Your poll method should consider archiving an event when any of the following conditions occur:
Java connectors must be thread safe. The connector framework can use multiple threads to perform event delivery (execution of the pollForEvents() method) and request processing (execution of the doVerbFor() method).
Event priority enables the connector poll method to handle situations where the number of events in the event store exceeds the maximum number of events the connector retrieves in a single poll. In this type of polling implementation, the poll method polls and processes events in order of priority. Event priority is defined as an integer value in the range 0 - n, with 0 as the highest priority.
To process events by event priority, the following tasks must be implemented in the event notification mechanism:
The following example SQL SELECT statement shows how a connector might select event records based on event priority. The SELECT statement sorts the events by priority, and the connector processes each event in turn.
SELECT event_id, object_name, object_verb, object_key FROM event_table WHERE event_status = 0 ORDER BY event_priority
The logic for a poll method is then the same as discussed in Basic logic for pollForEvents().
The event detection and retrieval mechanisms can be implemented so that multiple connectors can poll the same event store. Each connector can be configured to process certain events, create specific business objects and pass those business objects to InterChange Server. This can streamline the processing of certain types of events and increase the transfer of data out of an application.
To implement event distribution so that multiple connectors can poll the event store, do the following:
This might be done per application entity. For example, the event detection mechanism might specify that all Customer events be picked up by the connector that has the connectorId field set to 4.