You can configure the guaranteed-event-delivery feature for 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). In a single JMS transaction, the connector can remove a message from a source queue and place it on the destination 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 to values shown in Table 12.
Table 12. Guaranteed-event-delivery connector properties for a connector with a JMS event store
Connector property | Value |
---|---|
DeliveryTransport |
JMS |
ContainerManagedEvents |
JMS |
PollQuantity |
The number of events to processing in a single poll of the event store |
SourceQueue |
Name of the JMS source queue (event store) which the connector framework polls and from which it retrieves events for processing
|
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 13 summarizes.
Table 13. Data-handler properties for guaranteed event delivery
Data-handler property | Value | Required? |
---|---|---|
MimeType |
The MIME type that the data handler handles. This MIME type identifies which data handler to call. | Yes |
DHClass |
The full name of the Java class that implements the data handler | Yes |
DataHandlerConfigMOName |
The name of the top-level meta-object that associates MIME types and their data handlers | Optional |
If you configure a connector that has a JMS event store to use guaranteed event delivery, you must set the connector properties as described in Table 12 and Table 13. To set these connector configuration properties, use the Connector Configurator tool. Connector Configurator displays the connector properties in Table 12 on its Standard Properties tab. It displays the connector properties in Table 13 on its Data Handler tab.
For information on Connector Configurator, see Appendix B, Connector Configurator.
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 13.
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.
If the JMS-enabled connector uses a non-JMS solution to implement its event store (such as a JDBC event table, Email mailbox, or flat files), the connector framework can use duplicate event elimination to ensure that duplicate events do not occur. 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 to values shown in Table 14.
Table 14. Guaranteed-event-delivery connector properties for a connector with a non-JMS event store
Connector property | Value |
---|---|
DeliveryTransport |
JMS |
DuplicateEventElimination |
true |
MonitorQueue |
Name of the JMS monitor queue, in which the connector framework stores the ObjectEventId of processed business objects |
If you configure a connector to use guaranteed event delivery, you must set the connector properties as described in Table 14. 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.
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.
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.