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

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

Typical EDI Errors and Solutions

Typical EDI Errors

1. Unable to identify the Document

Make sure the document protocol parameters defined in the document definition matches the corresponding data in the inbound document.

2. Agreement Identification which involves Document Identification and TP Identification

For e.g. trading partner agreement not found for the given input values: From party [NAME-ROLE] "GlobalChips-Seller", To party [NAME-ROLE] "GlobalChips-Buyer", Collaboration name "3A4"; also verify agreement effectiveToDate

Check: Make sure to verify Trading Partner Name, Trading Partner Parameters (Optional), Document Type Name, Document Type Revision ,Trading Partner Id, Delivery Channel

3. Document Validation Error

Check: 1. Make sure Document Revision Protocol Parameters i.e Transaction Envelope has valid values.

Proper ECS file is used for Validation. Make sure you have not used xsd instead of ecs file.

4. Connection Issues
Transport error: [IPT_HttpSendConnectionRefused] HTTP connection is refused. Connection refused: connect

Check : Make sure the information about delivery channel is correct and also the end point is active. This can be done by pinging the end points.

5. Duplicate Delivery channel
Check : Make sure you have not used the host ip address for configuring the Trading partner Delivery channel.