This section contains the following information about event processing:
An application can support one of the following types of delete operations:
It may be tempting to implement delete event processing in a manner that is consistent with the application. For example, when an application entity is deleted, a connector poll method for an application that supports physical deletes might publish a business object with the Delete verb. A connector poll method for an application that supports logical deletes might publish a business object with the Update verb and the status value changed to inactive.
Problems can arise with this approach when a source application and a destination application support different delete models. Suppose that the source application supports logical delete and the destination application supports physical delete. Assume that an enterprise is synchronizing between the source and destination applications. If the source connector sends a change in status (in other words, a delete event) as a business object with the Update verb, the destination connector might be unable to determine that the business object actually represents a delete event.
Therefore, event publishing must be designed so that source connectors for both types of applications can publish delete events in such a way that destination connectors can handle the events appropriately. The Delete verb in an event notification business object should represent an event where data was deleted, whether the delete operation was a physical or logical delete. This ensures that destination connectors will be correctly informed about a delete event.
This section provides the following information on how to implement event processing for delete events:
The event detection mechanism for both logical and physical delete connectors should set the verb in the event record to Delete:
In other words, it must differentiate update events for modified entities from update events for logically deleted entities. For logically deleted entities, the event detection mechanism should set the verb in the event record to Delete even if the event in the application was an Update event that updated a status column.
The poll method for both logical and physical delete connectors should generate a business object with the Delete verb:
For hierarchical business objects, the connector should not send deleted children. The connector can constrain queries to not include entities with status of inactive, or child business objects with a status of inactive can be removed in mapping.
WebSphere InterChange Server |
---|
Mapping between the application-specific business object and the generic business object should map the verb as Delete. This ensures that the correct information about an event is sent to the collaboration, which may perform special processing based on the verb. |
Follow these recommendations for relationship tables:
The guaranteed-event-delivery feature enables the connector framework to guarantee that events are never sent twice between the connector's event store and the integration broker.
Without use of the guaranteed-event-delivery feature, a small window of possible failure exists between the time that the connector publishes an event (when the connector calls the gotApplEvent() method within its pollForEvents() method) and the time it updates the event store by deleting the event record (or perhaps updating it with an "event posted" status). If a failure occurs in this window, the event has been sent but its event record remains in the event store with a "ready for poll" status. When the connector restarts, it finds this event record still in the event store and sends it, resulting in the event being sent twice.
You can provide the guaranteed-event-delivery feature to a JMS-enabled connector in one of the following ways:
If the JMS-enabled connector uses JMS queues to implement its event store, the connector framework can act as a "container" and manage the JMS event store (the JMS source queue). One of the roles of JMS is to ensure that once a transactional queue session starts, the messages are cached there until a commit is issued; if a failure occurs or a rollback is issued, the messages are discarded. Therefore, in a single JMS transaction, the connector framework can remove a message from a source queue and place it on the destination queue. This container-managed-events feature of guaranteed event delivery enables the connector framework to guarantee that events are never sent twice between the JMS event store and the destination's JMS queue.
This section provides the following information about use of the guaranteed-event-delivery feature for a JMS-enabled connector that has a JMS event store:
To enable the guaranteed-event-delivery feature for a JMS-enabled connector
that has a JMS event store, set the connector configuration properties shown
in Table 43..
Table 43. Guaranteed-event-delivery connector properties for a connector with a JMS event store
In addition to configuring the connector, you must also configure the data
handler that converts between the event in the JMS store and a business
object. This data-handler information consists of the connector
configuration properties that Table 44 summarizes.
Table 44. Data-handler properties for guaranteed event delivery
End users that configure a connector that has a JMS event store to use guaranteed event delivery must be instructed to set the connector properties as described in Table 43 and Table 44.. To set these connector configuration properties, use the Connector Configurator tool. Connector Configurator displays the connector properties in Table 43 on its Standard Properties tab. It displays the connector properties in Table 44 on its Data Handler tab.
For information on Connector Configurator, see Appendix B, Connector Configurator.Appendix B, "Connector Configurator," on page 527.
If a connector uses guaranteed event delivery by setting ContainedManagedEvents to JMS, it behaves slightly differently from a connector that does not use this feature. To provide container-managed events, the connector framework takes the following steps to poll the event store:
The event store is implemented as a JMS source queue. The JMS message contains an event record. The name of the JMS source queue is obtained from the SourceQueue connector configuration property.
The connector framework calls the data handler that has been configured with the properties in Table 44..
WebSphere InterChange Server |
---|
The message sent to the JMS destination queue is the business object. |
Other integration brokers |
---|
The message sent to the JMS destination queue is an XML message. |
When the JMS transaction commits, the message is written to the JMS destination queue and removed from the JMS source queue in the same transaction.
The connector framework can use duplicate event elimination to ensure that duplicate events do not occur. This feature is usually enabled for JMS-enabled connectors that use a non-JMS solution to implement an event store (such as a JDBC event table, Email mailbox, or flat files). This duplicate-event-elimination feature of guaranteed event delivery enables the connector framework to guarantee that events are never sent twice between the event store and the destination's JMS queue.
This section provides the following information about use of the guaranteed-event-delivery feature with a JMS-enabled connector that has a non-JMS event store:
To enable the guaranteed-event-delivery feature for a JMS-enabled connector
that has a non-JMS event store, you must set the connector configuration
properties shown in Table 45..
Table 45. Guaranteed-event-delivery connector properties for a connector with a non-JMS event store
End users that configure a connector to use guaranteed event delivery must be instructed to set the connector properties as described in Table 45.. To set these connector configuration properties, use the Connector Configurator tool. It displays these connector properties on its Standard Properties tab. For information on Connector Configurator, see Appendix B, Connector Configurator.Appendix B, "Connector Configurator," on page 527.
If a connector uses guaranteed event delivery by setting DuplicateEventElimination to true, it behaves slightly differently from a connector that does not use this feature. To provide the duplicate event elimination, the connector framework uses a JMS monitor queue to track a business object. The name of the JMS monitor queue is obtained from the MonitorQueue connector configuration property.
After the connector framework receives the business object from the application-specific component (through a call to gotApplEvent() in the pollForEvents() method), it must determine if the current business object (received from gotApplEvents()) represents a duplicate event. To make this determination, the connector framework retrieves the business object from the JMS monitor queue and compares its ObjectEventId with the ObjectEventId of the current business object:
For a JMS-enabled connector to support duplicate event elimination, you must make sure that the connector's pollForEvents() method includes the following steps:
The application generates this event identifier to uniquely identify the event record in the event store. If the connector goes down after the event has been sent to the integration broker but before this event record's status can be changed, this event record remains in the event store with an In-Progress status. When the connector comes back up, it should recover any In-Progress events. When the connector resumes polling, it generates a business object for the event record that still remains in the event store. However, because both the business object that was already sent and the new one have the same event record as their ObjectEventIds, the connector framework can recognize the new business object as a duplicate and not send it to the integration broker.
A C++ connector can use the setAttrValue() method of the BusinessObject class to assign the event identifier to the ObjectEventId attribute, as follows:
pBusObj->setAttrValue("ObjectEventId", strngEventId, BOATTRTYPE::STRING);
Unless the connector changes any In-Progress events to Ready-for-Poll status when it starts up, the polling method does not pick up the event record for reprocessing.