Resubmission Feature in B2B - Error Exception Handling

Resubmission Feature in B2B


There are various Best practices suggested to re-submit the failed messages in B2B. Following is one approach.

1. Outbound Flow

The exception handling and resubmission mechanism can be split it into three different activities.

I. Get the Exception Message details: Query IP_IN_QUEUE using consumer name as B2BERRORUSER.
II. Get the Business message details: Query the b2b_instancemessage view for a specific b2bmessageID for which exception occurred.
III. Resubmit the Business message to IP_OUT_QUEUE with appropriate AQ header information such as From, To, Doc Type, Revision etc.

For any Error/Exception during outbound message processing, B2B sends an exception message whose Document type is “Exception” to the IP_IN_QUQUE with error user as B2BERRORUSER. The exception message enqueued will be based on the ipException.xsd available in the $midtier/ip/lib.

To accomplish the 1st step BPEL Process can be created with an inbound AQ Adapter to listen on to the IP_IN_QUEUE with Consumer Name as B2BERRORUSER to dequeue the exception message sent by B2B Exception handling Mechanism. Exception message contains the message details such as b2bmessageID, Error Text, Error code etc. The status of the business message and wire message is updated with Error.

As part of 2nd step, using the B2BmessageID available in the exception message, it is required to query b2b_InstanceMessage view in the b2b schema to get the following information.

a. Payload (PAYLOAD)
b. From Party (SENDERNAME)
c. To Party (RECEIVERNAME)
d. Document Type (DOCUMENTTYPE)
e. Document Revision (DOCUMENTPROTOCOL)
f. Business Action (BUSINESSACTION)

Ideally, the above database call to the b2b schema is accomplished by configuring the DBAdapter in the same BPEL Process.

As part of the 3rd and final step enqueue the payload obtained in second step to IP_OUT_QUEUE by setting appropriate AQ headers such as From Party, To Party, Doc Type and Revision. This is done by, outbound AQ adapter configured in the Enqueue mode.
Note: In this approach, IP_IN_QUEUE, IP_OUT_QUEUE and b2b_instancemessage view are in b2b schema.

Retry Count: As a best Practice it is advised to introduce a concept called Submission Retry count based on one of the column in the tip_businessmessage_rt table such as NOTM. For every re-submission, increment the Retry count for a specific b2bMessageID for a pre-configured Retry count. An email notification can be sent to the B2B Administrator once the maximum Retry count is reached.

2. Inbound Flow

The above Exception handling mechanism applies to inbound as well. Instead of resubmitting the message through IP_OUT_QUEUE, it is required to configure a listening inbound File end point and drop the file, with appropriate naming convention. B2B picks it up and process in the inbound direction as if it has come from the Trading partner.

Note: As this approach uses file protocol for inbound processing, the exchange specific features may not be available.

Reference: http://www.oracle.com/technology/products/integration/b2b/pdf/B2B_TN_007_Exception_Handling.pdf