Oracle B2B handles exceptions for inbound and outbound messages. This appendix describes the exception handling, error messages, and structures for Oracle B2B.
This appendix contains the following topics:
This section describes the following inbound message types:
For an incoming request or response message that results in an exception, the following actions occur:
An exception message is sent to the application.
The exception message is enqueued to B2B_IN_QUEUE and has the recipient name b2berroruser. The enqueued exception is based on ipException.xsd and contains information such as the error message (errorText has a short description and errorDescription has a longer description) and the error code.
An exception message is sent to the trading partner, if mandated by the exchange specification.
The exception message is sent back to the trading partner only if there is enough information to identify the outgoing trading partner agreement. For this purpose, the flag B2BHeader.sendException is used. The flag is set to true when enough information is extracted from the incoming message to send the exception message to the trading partner.
Oracle B2B catches exceptions thrown by exchange or document layers.
If the B2Bheader.sendException flag is set to true, the outgoing trading partner agreement is processed and an exception message is sent to the trading partner.
For an incoming acknowledgment message that results in an exception, the following actions occur:
An exception message is sent to the application.
The exception message is enqueued to B2B_IN_QUEUE and has the recipient name b2berroruser. The enqueued exception is based on ipException.xsd and contains information such as error text and error code.
No exception message is sent back to the trading partner.
For an incoming exception message, the following actions occur:
The original message is updated so that it is in an errored state. The incoming exception is processed and delivered to the application normally.
If the incoming exception message itself results in an exception, an exception message is sent to the application.
The exception message is enqueued to B2B_IN_QUEUE and has the recipient name b2berroruser. The enqueued exception is based on ipException.xsd and contains information such as error text and error code. No exception message is sent back to the trading partner in this case.
B2B errors cannot be delivered on other queues that you may configure (for example, an AQ or JMS queue).
If the following types of failure occur while an incoming message is processing, then the receiving trading partner sends a negative acknowledgment to the sender.
Decryption fails
Verification fails
Agreement is not found
Document identification fails
Document validation fails (and so on)
The negative acknowledgment message has the reference for the original (request) message details to correlate at the sender side.
If an exception occurs while an outbound message is being sent (for example, if the trading partner identification fails), then an exception message is sent to the application. The exception message is enqueued to B2B_IN_QUEUE and has the recipient name b2berroruser. The enqueued exception is based on ipException.xsd and contains information such as error text and error code.
If an exception occurs during Oracle B2B startup, then an exception message is enqueued to B2B_IN_QUEUE and has the recipient name b2berroruser. The enqueued exception is based on ipException.xsd and contains information such as error text and error code. The correlation ID is not populated in this case.
Note the following:
When the exception message is sent back to the application, the document type is Exception instead of the original message document type.
When the exception message is sent back to the application, inReplyToMessageId is populated with the correlation ID value.
For inbound exception handling, a business message is always created and populated with the available information. It also points to the corresponding wire message. The wire message is updated so that it is in an errored state. For the outbound direction, only the business message is updated, because the wire message does not exist.
The error reports are updated to show only business messages; a business message is always created in the inbound and outbound directions.
Table D-1 describes inbound exception handling scenarios.
Table D-1 Inbound Exception Handling Scenarios
Note the following:
The exception is sent back to the trading partner only for RosettaNet exchanges. For other exchanges, a failure is reported as mandated in the respective specifications. For example, for an ebMS exchange, an acknowledgment is sent along with the error list that is defined. For an AS2 exchange, the acknowledgment is sent indicating an error, without exception details.
An exception is sent back to the trading partner for request messages only.
No exception is sent back to the trading partner for response, acknowledgment, and functional acknowledgment messages.
The exception payload, ipException.xsd, is defined as follows:
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://integration.oracle.com/B2B/Exception" targetNamespace="http://integration.oracle.com/B2B/Exception">
<xs:element name="Exception">
<!--xs:complexType name="Exception"-->
<xs:complexType>
<xs:sequence>
<xs:element ref="correlationId"/>
<xs:element ref="b2bMessageId"/>
<xs:element ref="errorCode"/>
<xs:element ref="errorText"/>
<xs:element ref="errorDescription"/>
<xs:element ref="errorSeverity"/>
<xs:element ref="errorDetails" minOccurs="0" />
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="correlationId" type="xs:string"/>
<xs:element name="b2bMessageId" type="xs:string"/>
<xs:element name="errorCode" type="xs:string"/>
<xs:element name="errorText" type="xs:string"/>
<xs:element name="errorDescription" type="xs:string"/>
<xs:element name="errorSeverity" type="xs:string"/>
<xs:element name="errorDetails">
<xs:complexType>
<xs:sequence>
<xs:element ref="parameter" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="parameter">
<xs:complexType>
<xs:attribute name="name" type="xs:string" use="required" />
<xs:attribute name="value" type="xs:string" use="required" />
</xs:complexType>
</xs:element>
</xs:schema>