Asynchronously reported conditions

Typically, problems reported asynchronously are run-time conditions, such as the failure of the SonicMQ Broker or the failure of communication between the Progress OpenEdge JMS Adapter and the JMS-provider Broker. Another example is the failure to send an automatic reply (the message handler is set with a reply message, but the JMS-provider fails to send the reply).

The error condition is reported in a TextMessage, with several possible CHAR message properties in the message header: exception, errorCode, linkedException–1, linkedException–2… linkedException–n (where n is a number of additional exceptions linked to the main exception). Use the getPropertyNames function to get a list of properties in the error message header. For an example, see "Messaging Examples" in the OpenEdge Development: Messaging and ESB guide.

The application should handle problems of this type programmatically by creating a Message Consumer object and passing it to the setErrorHandler procedure in the Session object. If an application does not set an error handler, a default error handler displays the error message and the properties in alert boxes.

Note: An application must call the beginSession procedure before creating the error-handling Message Consumer object and calling the setErrorHandler procedure.