Asynchronously reported conditions
- Last Updated: February 11, 2026
- 1 minute read
- OpenEdge
- Version 13.0
- Documentation
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.