Identification of Document - Custom Over EBMS

Identification of Document - Custom Over EBMS

Inbound : Ideally Custom Document Plugin identify the document based on Xpath Expression and value. In the EBXML world the identification is based on action name of the incoming document. To provide this flexibility oracle B2B tries to Identify the document, based on the Xpath expression if present, else identify based on the incoming action name.

Outbound : Along with the typical Identification of Agreement based on From, To , DocType and Revision, it can also be Identified based on From,To and Action_Name where the Action_Name has to be mapped against the business Action Name.

actionName=ACTION:

By setting the above AQ (ACTION_NAME for jms) property, TPA identification can be done using business action instead of document type and revision. This is typical use case in ebms

Example :
from = Acme
to = GlobalChips
payload = Acme_850.xml
actionName=ACTION:Process_850

Correllation of Business Message in EBMS Exchange

Correllation of Business Message in EBMS Exchange is done using

a. RefToMessageId
b. ConversationId

It is possible to correllate a business message such as ORDER with its response message such as ORDRSP and it is also allowed to correllate as many number of related messages as long as they carry appropriate RefToMessageID and ConversationID.

Back end application such as BPEL can make use of the AQ/JMS header replyToMsgID for setting the correllation information. Format of the replyToMsgID is as follows.

replyToMsgID : RefToMessageId : ConversationId


Example to correllate ORDER and ORDRSP

Let us consider two EBMS setup one for ACME and another for GlobalChips. Following are the sequence of activities which is of interest.

1. Enque an order message to ACME with the value of replyToMsgID as

replyToMsgID = : 999999999

B2B in the Acme side generates its own message id and use 999999999 as Conversation ID.

EBMS header of the business message sent to GlobalChips

a. Do not have RefToMessageID as this is the 1st message
b. MessageID contain the messageID (e.g Acme@222222222) of the ORDER message
c. ConversationID contain 999999999

2. GlobalChips gets the ORDER message (msgid= 444444444) and sends an Acknowledgement with the EBMS header as follows.

a. MsgID of the ACK message
b. RefToMessageID as copied from ORDER message from ACME i.e Acme@222222222
c. ConversationID contain 99999999

3. GlobalChips Enque an ORDRSP message with the value of

replyToMsgID = 444444444 : 999999999

where 444444444 is the messageID of the ORDER message. EBMS header of the ORDRSP

a. MsgID of the ORDRSP message
b. RefToMessageID as copied from ORDER message from ACME i.e Acme@222222222
c. ConversationID contain 99999999


4. Acme to send the Acknowledgement.

As a prerequisite it is required to set the following tip.properties to avail the correllation feature in EBMS Exchange.

oracle.tip.adapter.b2b.ebms.deliverConvId = true
oracle.tip.adapter.b2b.ebms.TreatMsgWithReplyToMsgIDAsReq = true

Please send a mail to ramesh.anantharamaiah@oracle.com for sending the export of the configuration.

How to handle Host/Trading partner with Multiple Idenfier

Lets consider an organization which has multiple business units with different Trading Partner Identification of same Type.

e.g Host has multiple DUNS number as identification with value 111111111 and 222222222.


This feature provides a capability to handle Multiple DUNS eventhough it is not part of the agreement, but still present as part of the Trading partner Idenfitification.

Outbound:
For outbound messages, instead of setting the AQ header 'From' as Name Identification set it as DUNS:value

e.g DUNS:111111111 and the same is applicable to 'To' attribute in the AQ header.

In this case, B2B will use the identification type and value
for Agreement Identification and also for populating the exchange headers.

Inbound:

As part of the Trading partner Identification B2B compares the Exchange identifier with various Identification value of the same exchange Identifier type.

For e.g For an incoming document with Trading partner DUNS: 333333333, it compares with all the DUNS number of the Trading Partner. If any one of the DUNS number matches it identifies the appropriate Trading partner. The identified trading partner name is used for Agreement identification.

Added a new Exchange Parameter for EBMS Exchange:SendPartyTypeAndValue and the value for this parameter could be true/false. Default value is false. If the value is true, b2b will enqueue partyid:value to FROM/TO Trading partner.

For specifying a different seperator than : , set the following property.

oracle.tip.adapter.b2b.partyTypeAndValueSeparator=;

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