Event handling

The connector polls the application's output queue to detect events written to the input queue via a database trigger. You install a database trigger for each MFG/PRO application that you want to configure for connector event processing. You install triggers using the DataSync module supplied by QAD. For further information, see QAD documentation (External Interface Guide -- Data Synchronization). An event occurs when an MFG/PRO application generates MQ messages and stores them on the input queue.

Retrieval

The connector uses the pollForEvents() method to poll the input queue at regular intervals for messages. When the connector finds a message, it retrieves it from the input queue. The connector passes the message to the configured data handler; the data handler is expected to create and populate a business object and specify a verb. See "Error handling" for event failure scenarios.

The connector processes messages by first opening a transactional session to the input queue. This transactional approach allows for a small chance that a business object could be delivered to a collaboration twice due to the connector successfully submitting the business object but failing to commit the transaction in the queue. To avoid this problem, the connector moves all messages to an in-progress queue. There, the message is held until processing is complete. If the connector shuts down unexpectedly during processing, the message remains in the in-progress queue instead of being reinstated to the original input queue.

Note:
Transactional sessions with a JMS service provider require that every requested action on a queue be performed and committed before events are removed from the queue. Accordingly, when the connector retrieves a message from the queue, it does not commit to the retrieval until three things occur: 1) The message has been converted to a business object; 2) the business object is delivered to an integration broker by the gotApplEvents() method, and 3) a return value is received.

Recovery

Upon initialization, the connector checks the in-progress queue for messages that have not been completely processed, presumably due to a connector shutdown. The connector configuration property InDoubtEvents allows you to specify one of four options for handling recovery of such messages: fail on startup, reprocess, ignore, or log error.

Fail on startup

With the fail on startup option, if the connector finds messages in the in-progress queue during initialization, it logs an error and immediately shuts down. It is the responsibility of the user or system administrator to examine the message and take appropriate action, either to delete these messages entirely or move them to a different queue.

Reprocess

With the reprocessing option, if the connector finds any messages in the in-progress queue during initialization, it processes these messages first during subsequent polls. When all messages in the in-progress queue have been processed, the connector begins processing messages from the input queue.

Ignore

With the ignore option, if the connector finds any messages in the in-progress queue during initialization, the connector ignores them, but does not shut down.

Log Error

With the log error option, if the connector finds any messages in the in-progress queue during initialization, it logs an error but does not shut down.

Copyright IBM Corp. 1997, 2004