D Exception Handling

D.1 Inbound Messages

This section describes the following inbound message types:

• Request or Response Messages

• Acknowledgment Messages

• Exception Messages

D.2 Outbound Messages

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.

D.3 Inbound Exception Handling Scenarios

Table D-1 describes 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.

D.4 Exception Payload Definition

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>