Error handling

All error messages generated by the adapter are stored in a message file named FrontArena.txt. The name of the file is determined by the LogFileName standard connector configuration property. Each error has an error number followed by the error message:

Message number
Message text

The adapter handles specific errors as described in the following sections.

Application timeout

The error message BON_APPRESPONSETIMEOUT is returned when:

Unsubscribed business object

If the adapter retrieves a message that is associated with an unsubscribed business object, the adapter delivers a message to the queue specified by the UnsubscribedQueue property.

Note:
If the UnsubscribedQueue is not defined, unsubscribed messages will be discarded.

Data handler conversion

If the data handler fails to convert a message to a business object, or if a processing error occurs that is specific to the business object (as opposed to WebSphere MQ), the message is delivered to the queue specified by ErrorQueue. If the ErrorQueue is not defined, messages that cannot be processed due to errors will be discarded.

If the data handler fails to convert a business object to a message, BON_FAIL is returned.

Event message to a business object conversion fails

In this case, the message being processed is forwarded to the adapter's ErrorQueue, if a valid queue is specified in the adapter's application configuration property. Otherwise, the event message is simply discarded.

Apart from a corrupted event message, a missing entry for the <object>_<verb> entry in the static conversion meta-object of the adapter can be responsible for this failure. If the error was detected by the data handler, details about the failure can be found in the adapter's log file.

Recommended action: Any message in the error queue requires analysis because it is usually a symptom of a wrong configuration. For example, when the wrong application sends messages to the input queue, or there are errors in the meta-object definition, or the wrong version of message is compared to adapter.

Communication between the adapter and the InterChange Server fails or the adapter crashes

In this case, the adapter creates a log file entry and shuts down. The event message being processed remains in the adapter's InProgressQueue. All messages in the InProgressQueue have not been processed by the server and are reprocessed automatically, when the adapter is restarted.

Recommended action: None.

Missing subscription

Events that no collaboration has subscribed to are stored in the UnsubscribedQueue if this queue is defined in the adapter configuration. Otherwise, they are simply discarded.

Recommended action: If a "sleeping" collaboration was a potential reason for this situation, move the messages to the back to the adapter's input queue to enforce reprocessing after having started the collaboration. Remove the messages with wrong business object-verb combinations (for example, messages without a destination within the integration scenario) from the UnsubscribedQueue and stop the source of these messages.

Problem with event related queues

If one of the event related queues is not operational, the adapter writes a message into the log file and shuts down.

Recommended action: Any termination of the adapter must be analyzed carefully, taking the adapter's log file into consideration.

Duplicate delivery of events

Double, or multiple, delivery of events is very unlikely though not impossible. There is a small gap between the bridge putting an event message onto the adapter's event queue and removing it from FRONT ARENA's AMB. If the bridge crashes between these two neighboring instructions, the event message is re-delivered as soon as the bridge comes up again. The gap cannot be closed by the bridge because FRONT ARENA does not provide any hooks for an external transaction coordinator.

Recommended action: If the bridge delivers an event twice, the adapter is not able to detect this since it does not maintain a history of processed events. The handling of duplicate events must be done in the collaboration in conjunction with the relationship table. FRONT ARENA assigns a unique key to each object created in the system. If the system, and more accuratly, the AMBA, is configured correspondingly, this key is part of the event message that indicates the creation, modification, or deletion of the object. In conjunction with the create or update time, which is also part of the event message, this piece of information can be used to verify whether the event message had been received before.

Example: For TRADE objects, the message field, trdnbr, contains the unique internal FRONT ARENA key, and update_time contains the timestamp indicating when the object was created, updated, or deleted.

Copyright IBM Corp. 1997, 2004