Resubmission Feature

Resubmission feature which is part of the latest patch.

Introduction

Oracle AS B2B is a B2B Product with very rich protocol stack and is based on Standard based Scalable Architecture managed through Oracle Application server. This product has a rich Exception handling framework to capture the error/Exception at various stages in the Engine, and send the exception message to IP_IN_QUEUE with B2BERRORUSER. With the increased customer base over the recent past, resubmission of error/Exception message in B2B is the key feature identified to be supported. There have been many best practices used by several of our customer to get the Exception message and to resubmit the business message using the Workflow driven BPEL Process. This is just an initial pilot project undertaken to provide the Resubmission feature out of the box. It is expected to go for multiple enhancements depending on the customer drive and the acceptance.

Use Case Addressed

1. Basic Resubmission feature with Retry count and Interval for both inbound and outbound.
2. Notification to B2B Administrator.
3. Resubmission based on message ID, Agreement and Status.
4. Payload based resubmission. This is ideally for error/Exception based on payload.
5. Outbound resubmission using IP_OUT_QUEUE and inbound Resubmission through Event queue. This will get the inbound message goes through all the layer of B2B as if it has come from Trading Partner.
6. Deletion of duplication message and correlation of business message with appropriate Acknowledgement.
7. Support Stacking feature to handle the B2B Downtime and Resubmission after the same.
8. Variable Resubmission interval.

Outbound Scenario
B2Bresubmit Utility runs in two modes.

Auto Mode:
B2Bresubmit Utility runs in infinite listening mode to IP_IN_QUEUE with B2BERRORUSER. For every exception message, it gets the messageID and uses InstanceMessageUtil to obtain the From Party, To Party, DocType , Revision and the payload . It uses the above information to enque the message to IP_OUT_QUEUE to be picked up by B2B.

Depending on the configured Retry Count and Interval it resubmit the message and send a notification to the configured email ID once after exhausting all the attempt to resubmit the message. Email subject contain the messageID and the body contain Error Description.


Variable Resubmission Interval

Be default the Retry Interval is constant for all the retry effort during resubmission. However there is an option to define variable resubmission Interval for every resubmission. This will enable the B2BAdministrator enough time to debug and bring up the partner server in case of any issues.

If the value for ResubmitWithInterval is set to true, the utility will resubmit every message with interval mentioned for the property

oracle.tip.adapter.b2b.data.ReSubmit.ResubmitIntervals.


In this example,

First resubmission will happen after 1 minutes of first failure
Second resubmission will happen after 1 minutes of first resubmission

Also ensure that the value for oracle.tip.adapter.b2b.data.ReSubmit.ReSubmitCount is same as number of intervals mentioned.
Manual Mode
B2Bresubmit utility resubmits messages based on
1. Message ID,
2. Agreement ID and Status.

MessageId based
Once after B2BAdministrator gets the notification for a failed resubmission, he will extract the messageID from the email, Identify the root cause of the problem by referring b2b.log/Report, fix the problem and use Resubmission utility in manual mode to resubmit the message based on messageID.
Agreement name and message status

Ideally this feature is used in Bulk Resubmission after the Trading partner Downtime and is based on Agreement name, Status, Start time and End time.

The typical way to execute is as below.

Example:

java oracle.tip.adapter.b2b.data.ReSubmit "2008/01/28 16:00" "2008/01/28 16:15" Agreement Error

The time format is: yyyy/MM/dd HH24:MI

Inbound Scenario

Inbound Resubmission is pretty much the same as Outbound with both Auto and Manual mode, however the resubmission is based on the event queue, which will enable the resubmission messages to go through the respective exchange layer as if it has come from Trading Partner.

Resubmission Configuration

Complete List of configurations used for this utility

Turn off TPA Validation for Delivery channel Information

This feature is used for re-submission. Assuming the inbound essage has come through AS2/EBMS exchange plugin, which needs to be re-submitted through a File Delivery channel which is encapsulated using a Dummy Agreement. This may not be feasible as B2B performs TPA validation for delivery channel (checking if the delivery channel info on which message arrived is same as the delivery channel
info present in matching trading partner agreement).

In order to turn off this validation, there a tip.property
oracle.tip.adapter.b2b.tpa.validateTPA

If the value of this property is set to false in tip.properties, B2B will not
perform TPA validation

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