Oracle B2B – b2b.rowLockingForCorrelation

Introduction 

In cases where the latency between the outbound EDI document and the subsequent inbound acknowledgment is very low, a race condition will likely occur when B2B tries to update the document state in the B2B_Business_Message table. The result is the status of the original EDI document remains in either a MSG_WAIT_FA or MSG_WAIT_ACK state indefinitely if no retry value has been set, or it evolves to a state of MSG_ERROR after the retry interval and all the retry attempts have expired.

Problem Description:

In these cases, no exceptions occur so you won’t find the problem by searching log files. The problem tends to manifest itself as one of the two following conditions:

Condition 1: The original EDI document (such as a HL7, X12, or EDIACT), when configured to handle a Functional Acknowledgment, remains in a state of MSG_WAIT_FA after the functional acknowledgement has in fact been received and is itself in a MSG_COMPLETE state.

If the retry interval and retry attempts parameters for the FA are set to values greater than zero in the B2B trading partner agreement or the SSHI endpoint configuration, the state of the original EDI document will eventually evolve to MSG_ERROR while the FA will be shown as MSG_COMPLETE

Condition 2: The original EDI document (such as a HL7, X12, or EDIACT) remains in a state of MSG_WAIT_ACK after the MDN has in fact been received and is itself in a MSG_COMPLETE state.

If the retry interval and retry attempts parameters for acknowledgments in the transport protocol section of the delivery channel or endpoint configuration is set to values greater than zero in the B2B trading partner agreement or the SSHI endpoint configuration, the state of the original EDI document will evolve to MSG_ERROR while the MDN will be shown as MSG_COMPLETE

Problem Resolution:

To avoid these conditions, add the following property to the b2b properties section of Enterprise Manager for SOA Suite:

b2b.rowLockForCorrelation = true

This property applies row level locking to the B2B_Business_Message table forcing the ACK to wait for the initial write to complete before attempting to update the row itself. You may observe some slow down in the average transaction time due to the fact that B2B will be using row level locking, But the impact should only be minor.

Comments:

Post a Comment:
  • HTML Syntax: NOT allowed
About


This is the blog for the Oracle FMW Architects team fondly known as the A-Team. The A-Team is the central, technical, outbound team as part of the FMW Development organization working with Oracle's largest and most important customers. We support Oracle Sales, Consulting and Support when deep technical and architectural help is needed from Oracle Development.
Primarily this blog is tailored for SOA issues (BPEL, OSB, BPM, Adapters, CEP, B2B, JCAP)that are encountered by our team. Expect real solutions to customer problems, encountered during customer engagements.
We will highlight best practices, workarounds, architectural discussions, and discuss topics that are relevant in the SOA technical space today.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today