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

SOA-INFRA in Warning state due to BPM MDB’s - MDB application soa-infra is NOT connected to messaging system

One of the customers had the following issue where MDB’s where showing MDB application soa-infra is NOT connected to messaging system in one of their SOA environment. CubeActionMDB, BAMActionMDB, PeopleQueryMDB are added as part of the BPM suite.

These MDB’s are internally used by BPM.
Cube Action MDB:: A message driven bean (MDB) is used to trigger aggregation and persistence of the analytical data to the BPM cube schema stored in the SOA Service Infrastructure database.
BAM Action MDB::  A message driven bean (MDB) is used to publish analytical data towards the BAM adapter installed as part of the SOA Service Infrastructure.

Issue

The issue is caused by missing BPM Topics and connection factories.

This causes the MDB deployments in soa-infra to fail causing the soa-infra application to go into a warning state.

Create missing BPM Topics and connection factories.
Create a topic with the below JNDI names and target those to the SOASubDeployment (please make sure SOASubDeployment is targeted to one JMS Server on SOA Server).
1. jms/bpm/PeopleQueryTopic
2. jms/bpm/MeasurementTopic

Create the below connection factories (All are XA enabled connection factories) and target them into a SOA server (where soa-infra application is targeted to).
1. jms.bpm.PeopleQueryConnectionFactory
2. jms.bpm.CubeCommandXAConnectionFactory
3. jms.bpm.BAMCommandXAConnectionFactory

After the above changes, restart the SOA Servers and check the application deployment status.

Reference:

1.      1.  amis-blog-on-soa-infra-on-warning-after-upgrade

2.      2.  Oracle support:-- SOA-INFRA Application Deployment Display Status Shows Warning Instead of Active Status in a New SOA Suite Domain [ID 1159547.1]

SOA-INFRA startup issue

One of the issues which I got involved last week was more related to server administration. The client had a SOA11g environment with Weblogic 10.3.4, SOA 11.1.1.4 & AIA 11.1.1.4. The servers were running fine, but due to some environment issue the soa-infra crashed. As part of the admin process they restarted the SOA managed server. The SOA managed server in Weblogic came up but the soa-infra fails to start with the following error.

Error Snippet @server log

<Apr 21, 2011 12:10:10 AM PDT> <Error> <HTTP> <BEA-101216> <Servlet: "FabricInit" failed to preload on startup in Web application: "/soa-infra".

oracle.fabric.common.FabricException: Error in getting XML input stream: oramds:/deployed-composites/spe/GEOReqABCSImpl_rev1.0/SCA-INF/classes/META-INF/adf-config.xml: oracle.mds.exception.MDSException: MDS-00054: The file to be loaded oramds:/deployed-composites/spe/GEOReqABCSImpl_rev1.0/SCA-INF/classes/META-INF/adf-config.xml does not exist.

                at oracle.fabric.common.metadata.MetadataManagerImpl.getInputStreamFromAbsoluteURL(MetadataManagerImpl.java:280)

                at oracle.integration.platform.common.MDSMetadataManagerImpl.getInputStreamFromAbsoluteURL(MDSMetadataManagerImpl.java:555)

Analysis

 From the log files and stack trace it was pretty evident that one process was holding up the entire soa-infra. The composite process was having a reference to the MDS store and it was missing the adf-config file from the deployed composites folder. The adf-config file usually gets copied to SCA-INF classes folder during the compilation and packaging of the sar (service archive)file.

During deployment, a composite is targeted to a managed server which stores the composite meta-data in the MDS .During startup or on receiving the deployment notification a managed server loads the composite from the MDS.

Below picture gives you the order in which managed server manages soa-infra.

Since the issue is related to the single process, solution was to either provide the adf-config.xml  to the process or un-deploy the process . I am listing the easiest work around that is available so as to resolve the issue.

Workarounds

In 11g there is a deployed-composites.xml in MDS store which has entries related to the composite processes that are deployed to the current soa-infra.

1. Editing the deployed-composites.xml to remove entries of the composite which is causing the issue.

Since the GEOReqABCSImpl is preventing the soa-infra from starting up, remove the  entries  w.r.t GEOReqABCSImpl process from deployed-composites.xml, After that  you should be able to bring up soa-infra.  For similar issue,have a look at the this blog -- ReynoldsBlog

How to edit the deployed compsites.xml

You can export the whole of MDS from the EM console and then edit the appropriate content and import it back.
From the entry exporting the whole soa-infra MDS partition by using EM->SOA->soa-infra->Administration->MDS Configuration.  Exporting via EM is probably the easiest because it then prepares you to fix the problem later.

2.   2.  Use sca_undeployComposite in WLST to remove the composite which is causing the error.

How to use Wlst @ gettingStartedCustomWLSTCommands

This WLST command works in offline mode, so no need for soa-infra to be up and running for undeploying the processes, which makes it ideal option for resolving the issue.

Once you apply any of the above listed workaround, you can restart the managed server or bring up the soa-infra .The soa-infra will be up and running. Special thanks to Antony Reynolds who had helped us with this issue.