WebSphere Business Integration Adapters: An Adapter Development and WebSphere Business Integration Solution

136 WebSphere Business Integration Adapters

8.5.3 Setting the verb during mapping

If you use 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 might perform special processing based on the verb.

Follow these recommendations for relationship tables:

 For delete events for a logical delete application, leave relationship entries in

the relationship table.

 For delete events for a physical delete application, delete relationship entries

from the relationship table.

8.6 Guaranteed event delivery

The guaranteed event delivery feature enables the Adapter Framework to

guarantee that events are never sent twice between the connector’s event store

and the integration broker.

Without the 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:

 With the c

ontainer managed events feature: If the connector uses a JMS

event store (implemented as a JMS source queue), the Adapter Framework

acts as a container and manages the JMS event store.

Important: This feature is available only for JMS-enabled connectors, that is,

those connectors that use Java Messaging Service (JMS) to handle queues

for their message transport. A JMS-enabled connector always has its

DeliveryTransport connector property set to JMS. When the connector starts,

it uses the JMS transport; all subsequent communication between the

connector and the integration broker occurs through this transport. The JMS

transport ensures that the messages are eventually delivered to their

destination.

Chapter 8. Asynchronous event processing and notification 137

 With the d

uplicate event elimination feature: The Adapter Framework can

use a JMS monitor queue to ensure that no duplicate events occur. This

feature is usually used for a connector that uses a non-JMS event store (for

example, implemented as a JDBC table, inbox, or flat files).

8.6.1 Container-managed events

If the JMS-enabled connector uses JMS queues to implement its event store, the

Adapter 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 Adapter 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

Adapter Framework to guarantee that events are never sent twice between the

JMS event store and the destination’s JMS queue.

Enabling the feature for connectors with JMS event stores

To enable the guaranteed event delivery feature for a JMS-enabled connector

that has a JMS event store, set the connector configuration properties, as shown

in Table 8-21.

Table 8-21 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) that the

Adapter Framework polls and from which it retrieves

events for processing

The source queue and other JMS queues should be part

of the same queue manager. If the connector’s application

generates events that are stored in a different queue

manager, you must define a remote queue definition on

the remote queue manager. WebSphere MQ can then

transfer the events from the remote queue to the queue

manager that the JMS-enabled connector uses for

transmission to the integration broker.