Oracle B2B handles exceptions for inbound and outbound messages. This appendix describes the exception handling, error messages, and structures for Oracle B2B.
The appendix includes the following sections:
Note:
Oracle B2B does not support the various error codes specified by the ebMS 2.0 specification. For exception messages, Oracle B2B sets the error code to "Unknown". The expected error codes are:
ValueNotRecognized
NotSupported
Inconsistent
OtherXml
DeliveryFailure
TimeToLiveExpired
SecurityFailure
MimeProblem
Unknown
This section describes inbound message types.
For an incoming request, response, or functional acknowledgment message that results in an exception, the following actions occur when you use the default error handling settings:
An exception message is sent to the application.
The exception message is enqueued to IP_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.
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.
Inbound message content-type must be one of the following for AS1 messages to be retrieved from the email server and processed properly:
application/xml
enveloped
pkcs7-mime
ipart/report
multipart/signed
application/edi
For example, given this scenario:
Sender: Acme admin@slc05hzo.us.mydomain.com Receiver: GlobalChips joe@slc05hzo.us.mydomain.com Outbound channel: joe@slc05hzo.us.mydomain.com Listening channel is listening on admin@slc05hzo.us.mydomain.com
If an inbound payload is sent by sending email to admin@slc05hzo.us.mydomain.com with the payload as attachment, the reports show the following error message.
The error info was as follows, see "Inbound failed.jpg": Error Code: B2B-51566 Error Description: Machine Info: (slc05hzo) Description: Parse stream error
For an incoming acknowledgment message that results in an exception, the following actions occur when you use the default error handling settings:
An exception message is sent to the application.
The exception message is enqueued to IP_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 when you use the default error handling settings:
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 IP_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.
Exceptions can be delivered to default queues (B2B_IN_QUEUE
or IP_IN_QUEUE
) or custom JMS queues configured for exception messages. See Using a Custom Exception Queue for Error Message Delivery for more information.
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.
When you use the default error handling settings, the exception message is enqueued to IP_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 IP_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.
The data inside the <b2bMessageId>
tag of the exception message contains non-parsable characters and so, it is provided in the CDATA section so that it does not get parsed removing the chances of getting XML parsing errors.
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. However, if a transmission failure occurs, then the wire message table does have an entry.
The error reports are updated to show only business messages; a business message is always created in the inbound and outbound directions.
You can configure B2B to use a JMS queue by setting the Use JMS Queue as default parameter to true on the Configuration tab.
The default settings, as described in Inbound Messages and Outbound Messages, use an AQ queue, IP_IN_QUEUE
, as the exception queue. The JMS queue, B2B_IN_QUEUE
, becomes the default exception queue unless you have configured a custom JMS exception queue and selected it as the value for the Exception Queue parameter (see Using a Custom Exception Queue for Error Message Delivery.) In general, B2B sends inbound messages to B2B_IN_QUEUE
and polls on B2B_OUT_QUEUE
for outbound messages.
Because JMS queues cannot use b2berroruser as the consumer, a JMS message property is used to filter exception messages for error handling. Specifically, when the MSG_TYPE
value equals 3 (MSG_TYPE='3'
), all exception messages are received by the JMS receiver. (For successful messages, MSG_TYPE='1'
.) All JMS message properties are of type string
.
See Table 17-1 for more information on the Use JMS Queue as default parameter.
This section contains the steps to create a custom JMS exception queue.
To create custom JMS exception queues, perform these steps:
If B2B fails to deliver an exception message to the selected custom exception queue, then the exception message is sent to the default internal delivery channel.
See Table 17-1 for more information on the Exception Queue parameter.
This section describes inbound exception handling scenarios.
Table K-1 Inbound Exception Handling Scenarios
If an exception occurs because. . . | Then Oracle B2B does. . . |
---|---|
The identification of the exchange fails or the exchange is not supported |
|
Message unpacking fails |
|
Incoming message decoding fails |
|
The message is duplicated |
|
Document identification fails |
|
Incoming trading partner agreement processing fails |
|
Incoming document processing fails |
|
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 all message types except acknowledgments.
This section shows the definition for the exception payload, ipException.xsd
.
Example K-1 Exception Payload Definition
<?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>
This section describes AS4–based message errors, including SOAP faults and ebMS errors.
SOAP Fault
The receiving partner reports errors from message processing as SOAP faults to the sender. The error message is sent to the sending MSH using the same connection. Also, the backend application is notified of the errors.
ebMS Error
The error codes shown inGUID-D1D15D0F-BB34-4DC7-9383-5341EC905950.htm#XBBUG-GUID-55F481A0-E24A-4D7F-A207-415A6834A9CB__GUID-836D7758-9F0C-4D47-8EB1-7022C6B6E4A5 extend the set of ebMS V3 error codes to support the AS4 additional features.
Table K-2 ebMS V3 Error Codes
Error Code | Short Description | Description or Semantics |
---|---|---|
EBMS:0301 |
MissingReceipt |
A receipt has not been received for a message that was previously sent by the MSH generating this error. |
EBMS:0302 |
InvalidReceipt |
A receipt has been received for a message that was previously sent by the MSH generating this error, but the content does not match the message content; for example, some part has not been acknowledged, or the digest associated does not match the signature digest, for NRR. |
EBMS:0303 |
Decompression-Failure |
An error occurred during the decompression. |