For event notification, the adapter detects events written to the FRONT ARENA AMB . For each newly created or modified object, an event notification message is published on the AMB under a predefined topic that contains the type of the affected object. Event processing is asynchronous, FRONT ARENA messages are put on the queue without waiting for a response.
AMB client applications can subscribe to all messages published under certain topics. This way, they become aware of changes in the FRONT ARENA system. Based on this mechanism, other financial market applications can be kept in synchrony with FRONT ARENA in a scenario where the FRONT ARENA system is the master application, for example. The bridge component of the Adapter for FRONT ARENA acts as an AMB client application. It does not use the information received from FRONT ARENA by itself, but passes it on to a third party by way of the WebSphere MQ queue. The types of events subscribed to, and forwarded, by the bridge depend on its configuration. These settings must be consistent with the corresponding FRONT ARENA configuration parameters, and more precisely, the corresponding FRONT ARENA AMBA parameters.
The adapter uses the pollForEvents() method to poll the queue for messages at regular intervals. When the adapter finds a message, it retrieves it from the queue and examines it to determine its format. If the format has been defined in the adapter's static meta-object, the adapter passes both the message body and a new instance of the business object associated with the format to the FRONT ARENA data handler. The data handler is expected to populate the business object. If the format is not defined in the static meta-object, the adapter passes only the message body to the data handler; the data handler is expected to determine, create, and populate the correct business object for the message. See "Error handling" for event failure scenarios.
The adapter processes messages by first opening a transactional session to the input queue. The adapter then moves all messages to an in-progress queue. The message is held in the in-progress queue until processing is complete. If the adapter shuts down unexpectedly during processing, the message remains in the in-progress queue instead of being reinstated to the original input queue.
Upon initialization, the adapter 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.
With the fail on startup option, if the adapter 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.
With the reprocessing option, if the adapter 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 adapter begins processing messages from the input queue.
With the ignore option, if the adapter finds any messages in the in-progress queue during initialization, the adapter ignores them, but does not shut down.
With the log error option, if the adapter finds any messages in the in-progress queue during initialization, it logs an error but does not shut down.
If the connector property, ArchiveQueue, is specified and identifies a valid queue, the adapter places copies of all successfully processed messages in the archive queue. If ArchiveQueue is undefined, messages are discarded after processing. For more information on archiving unsubscribed or erroneous messages, see Error handling.