Logic of assigning Conversation Id for polling BPEL process – SOA 11g

        Recently we ran into an issue where we were getting issues with Conversation ID in SOA .Since we are not directly involved in generating the Conversation ID it was something we had not expected.

So one of the learning’s that we got out of this issue was that the payload data was also being used to create the conversation Id’s.

In our case we were having a composite primary key which was a collection of 4 to 5 columns. There was a DB Adapter polling these records. The error message was thrown not from the process but from the SOA engine.

Error Message: 

0000000000004fd1,0] [APP: soa-infra] JCABinding=>  db_poll2 db_poll2Adapter Service db_poll2 was unable to perform delivery of inbound message to the composite default/ConvIdPollerTest!1.0*soa_15be5514-092f-44ce-b44d-95726a0486f1 due to: Exception [TOPLINK-4002] (Oracle TopLink - 11g Release 1 (11.1.1.6.0) (Build 111018)): oracle.toplink.exceptions.DatabaseException[[

Internal Exception: java.sql.BatchUpdateException: ORA-12899: value too large for column "DEV116_SOAINFRA"."COMPOSITE_INSTANCE"."CONVERSATION_ID" (actual: 125, maximum: 100)

Since it was to do with SOAINFRA tables we had a look at the SOAINFRA COMPOSITE_INSTANCE table. The CONVERSATION_IS column was of 100 char.

The issue was coming because the SOA engine used the primary key values from polled records and concatenated them to a unique Id to make the conversation ID.

Since there were records where the combined concatenated value was more than 100 chars those records where failing when SOA Engine tries to make an entry into COMPOSITE_INSTANCE table for

Instance tracking.

There is no straight forward solution as this is a product limitation. Solution was to have a workaround to find a key which is unique but not too lengthy J