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 > Lotus Domino > Overview of WebSphere Adapter for Lotus Domino > Technical overview > Inbound processing
Event store
The event store is a persistent cache where event records are saved until the polling adapter can process them. To keep a track of inbound events as they make their way through the system, the adapter uses an event store.
Each time you create, update, or delete an event record in the Lotus Domino server, it is referred to as an event. The adapter updates the status of the event in an event store, when ever a business object is created, updated, or deleted. For recovery purposes, the status of each event is continually updated by the adapter until the events are delivered to a configured endpoint in the IBM BPM or WebSphere Enterprise Service Bus.
For example, an update to the document in the Lotus Domino server triggers the adapter to record the event in the event table. The event record stores information associated with the event such as the event status. The adapter can show the status of an event as 0 for unhandled events, 1 for processed events, or -1 for the failed events. The adapter retrieves this event and the update to the document. The event store implementation by the adapter ensures that data is correctly retrieved from the Lotus Domino server. The adapter then processes the event and delivers the event to the configured endpoint.
Each event store created by the adapter is associated with a particular module; however the same event store can be used by multiple modules. If you want multiple modules to use the same event store, you must set the EventTypeFilter property to a different event type for each module using the event store. You can configure the EventTypeFilter property in the ActivationSpec instance for each module.
During inbound processing, the adapter polls the event business components from the event store at regular intervals. Each time it polls, a number of events are processed by the adapter. Events are processed in ascending order of priority and ascending order of the event time stamp. In each poll cycle, new events are picked up. The adapter retrieves the value set in the EventID field of the event table and loads the business object that corresponds to it. The business object is created from the retrieved information and is delivered to the endpoints.
If you set the activation specification property AssuredOnceDelivery to true, a transaction ID (XID) value is set for each event in the event store. After the event is retrieved for processing, the XID value for the event is updated in the event store. The updated value is displayed in the XID column in the event business component. The event is then delivered to its corresponding endpoint, and the status is updated to show that the event has been successfully delivered. If the application is stopped or the event is not processed completely, the XID column is filled with a value. This process ensures that the event is reprocessed and sent to the endpoint. After the connection is reestablished or the adapter starts again, the adapter checks for events in the event store that have a value in the XID column. The adapter processes these events first and then polls the other events during the poll cycles.
The adapter can either process all the events or process events filtered by business object type. You set the filter through the activation specification property, EventTypeFilter. The property contains a comma-delimited list of business object types. Only the types specified in the property are processed. If the EventTypeFilter property is not set, then all events are processed. If the FilterFutureEvents property is set to true, the adapter filters events based on the time stamp. The adapter compares the system time in each poll cycle to the time stamp on each event. If an event is set to occur in the future, it is not processed until that time.
After an event is successfully posted and delivered to the endpoint, the entry is deleted from the event store. Failed events (posting and delivery to the endpoint is unsuccessful), remain in the event store and are marked -1. This feature prevents duplicate processing of the events.
Event store structure for Domino business objects and business components
The event business component stores information about the event. The information stored is used by the resource adapter during event subscription to build the corresponding business object and send it to the registered endpoints. The information that is stored, as well as the structure of the event store used by the adapter, is shown in the following table.
Event store structure Field Description Example Pick Fields The fields which the user is interested in. This field is not configurable. If ID Event ID The ID of the event row. Automatically generated unique ID in Domino (for example: 1-XYZ) Event type The type of event. Create, Update, or Delete Database path The database path of the document. test/doc.nsf Form The Form is an instance of the document on which the event occurs. Response UNID Universal ID of the document Status The event status that is initially set to the value for a new event and updated by the adapter as it processes the event. The status can have one of the following values:
- 0: Identifies a new event.
- 1: Identifies an event that has been delivered to an endpoint.
- -1: An error occurred while processing the event.
This column cannot be null.
0 Event timestamp The time stamp for the event. The format is in mm/dd/yyyy hh:mm:ss. 02/24/2007 11:37:56 Connector ID The ID set for the Domino adapter to filter events. This field is mapped to the AdapterInstanceFilter property of the activation specification properties. Domino001 XID The transaction ID. It ensures the assured once delivery of the events. None