This section describes the behavior of the standard error-handling BP. If you want, you can create a custom error-handling BP and can sort and redirect errors in any way you prefer. Custom error-handlers are outside the scope of this document, and are discussed in the eXchange Integrator Developer’s Guide.
Errors that occur at the business protocol level, such as an error within the payload of a single message resulting in a negative acknowledgment (such as an X12 997), or errors within the enveloping layer that can be reported at the messaging level (such as an X12 TA1), are a normal part of B2B conversation, and are not considered faults. For information on linking the B2B host to a tracker application, see Connecting the B2B Host to Oracle and LDAP Externals.
System-level errors, and business errors that cannot be handled by message tracking, are considered faults; eXchange Integrator catches such faults and publishes the ExStdEvent — with the error information now contained inside the ExStdEvent — to a standard eXchange Integrator topic, EX_ERROR. If further processing is possible, the messages are finally published to the EX_PROCESSEDERRORS topic; otherwise, they are finally published to the EX_DEADLETTER topic.
When EX_ERROR contains a marshallable ExStdEvent message, the message is presumed to contain all necessary troubleshooting details, specified in a clear enough way to allow the fault to be diagnosed. In this case, the ExStdEvent is published to the EX_PROCESSEDERRORS topic.
When EX_ERROR contains an ExStdEvent message that cannot be unmarshaled, there is no way to determine the cause of the fault. In this case, the ExStdEvent is published to the EX_DEADLETTER topic.
For help in tracking down subtle or persistent errors, the integration server provides extensive log files whose reporting sensitivity can be tuned to various levels (ERROR, INFO, DEBUG). For more information, see the “Monitoring Logs” chapter in the eGate Integrator System Administration Guide.
Within each of the standard BPs that provides for error handling, at the lower right margin of the main scope is a Catch Named Exception activity, connecting it to a scope containing an instance of a B2B protocol process: ErrorHandlerSelector. See Figure 3–4.
If you open the ErrorHandlerSelector BP, you find that by default, it uses JMS for handling errors, mapping fields under the ErrorHandlerSelectorRequest’s errorEvent container to the handleError.Input’s ErrorHandler container. See Figure 3–5.
The purpose of the JMSErrorHandler B2B protocol process is to send error messages to JMS, using the ErrorEvent_ErrorEventType OTD. However, in place of JMS, you could substitute SMTP to e-mail the text of the error message or FTP to write it to a file on a remote server. To create an SMTP-based error handler, for example, you would follow these steps:
In the Error Management folder, create a new B2B protocol process and name it; for example, SMTPErrorHandler.
Open the properties of SMTPErrorHandler and do the following:
Drag activities onto the Protocol Designer canvas for SMTPErrorHandler and connect them.
Configure business rules in the same way as for JMSErrorHandler.
After you have created a new error handler, you can go back to ErrorHandlerSelector and replace JMSErrorHandler with the new error handler, for example, if you wanted AS2OutboundChannelManager to deliver error messages via SMTP instead of JMS.
In the same way, you can add or modify other components in the B2B Templates folder, making them part of the toolset used by eeXchange Integrator projects in this Repository.