Oracle Apps Adapter in SOA 11g vs Apps Adapter in SOA 10 g

Once migrating our integrations from oracle Soa 10 g to 11g we faced issue while calling oracle APIs using Oracle apps adapter. Everything looks fine at OEBS side. Because integration from SOA 10g was still working perfect and when we try to execute migrated interface from SOA 11g fails...

We had checked the JCA settings several times. Responsibility and user were correctly assigned as the same values were working fine for 10g.

After investigating a lot we decided to debug the Apps Adapter jar file deployed on SOA 11g as it's version was different on SOA 10g. We got a solution from there as there were few SQL queries this apps adapter calls before executing the Apis and our user don't had access to query those tables.

In my next post I wi try to share the details of it.

But it's quite strange that this information or clue for such problem was not available or I was not able to find it over the Internet nor at oracle support.

Apps Adapter Fails due to invalid Apps Context

While calling API from Oracle SOA 11g using OracleApps Adapter. BPEL Process which was calling API of OEBS fails and give error that  Invalid Apps Context.

Fault Thrown by SOA Component

2012-11-29T07:54:53.629+01:00] [soa_server1] [ERROR] [] [oracle.soa.bpel.engine.dispatch] [tid: orabpel.invoke.pool-4.thread-17] [userId: <anonymous>] [ecid: 75f494dcfdf9a2f6:12e9d78e:13b46f8f54b:-8000-00000000000078df,1:23847] [APP: soa-infra] failed to handle message[[
com.oracle.bpel.client.BPELFault: faultName: {{http://schemas.oracle.com/bpel/extension}bindingFault}
messageType: {{http://schemas.oracle.com/bpel/extension}RuntimeFaultMessage}
parts: {{
summary=<summary>Exception occured when binding was invoked.
Exception occured during invocation of JCA binding: "JCA Binding execute of Reference operation 'APPS_AP_VENDOR_SITES_PKG_INSERT_NEW' failed due to: Apps Context Error.
Error occurred while setting up Apps Context.
Context parameters should be valid.
Contact oracle support if error is not fixable.
".
The invoked JCA adapter raised a resource exception.
Please examine the above error message carefully to determine a resolution.
</summary>
,detail=<detail>ORA-00942: table or view does not exist
</detail>
,code=<code>EBzA-057</code>}

Solution

 There could be more then one causes of the above problem.

1. User and responsibility in JCA file is not properly defined.

<jca:binding />
<operation name="APPS_AP_VENDOR_SITES_PKG_INSERT_NEW">
<jca:operation
IRepInternalName="PLSQL:AP_VENDOR_SITES_PKG:INSERT_ROW"
SchemaName="SYS_USER"
PackageName="AP_VENDOR_SITES_PKG"
ProcedureName="INSERT_ROW"
InteractionSpec="oracle.tip.adapter.apps.AppsStoredProcedureInteractionSpec"
Username="sysadmin"
Responsibility="System Administrator" >
</jca:operation>

 
2. User mentioned in JCA properties do not have access\correct responsibility assigned in OEBS setup

Following properties should be correctly mentioned in JCA file as well as in OEBS setup.

Username="sysadmin"
Responsibility="System Administrator" 


3. User in jdbc datasource doesn't have enough rights to execute the API.

In my case problem was with the datasource user which was configured in WLS console doen't had enough rights. I provide with super user or apps user to access or execute the Apps Adapter from SOA plateform and my problem was resolved.

I hope this solution helps.

DB Adapter Singleton behaviour in High Availability Environment

There was a problem which one can face in high availability environment (clustered) . 

We had one Integration between Oracle Ebiz and third party system in which we get data from Oracle Ebiz and send them to third party application. This integration was running fine till the time our server environment upgraded for high availability means clustered ones...

We had two clustered which were configured to be synchronous to idealised HA situation. But this causes one design issue in that Integration. 

The issue starts coming in our DB Adapter that now the DB Adapter starting polling Staging table(OEBS)  in parallel with the initialised interval. Cluster1 and Cluster2 starts initiating DB Adapter instances in parallel and if we increase the clusters form 2 to 3. The same way three instances of pooling components started. Which leads to a situation in which if we increase the clusters in future from 2 to 50 then in parallel 50 instances of pooling component will be created in parallel and will hit the third party application in parallel. This could be a problem for a target system if it doesn't supports parallel processing.

The solution to this problem was that we need a concept of singleton pattern in our pooling component / DB Adapter.

There's a property of Inbound endpoint lifecycle support within Adapters called Singleton.
To enable this feature for high availability environment for a given inbound adapter endpoint, one must add the singleton JCA service binding property in the composite.xml within the <binding.jca> element and set it to a value of true as shows.

Singleton Property in composite.xml

    <binding.jca config="bindin_file.jca">
        <property name="singleton">true</property>
    </binding.jca> 

This was our finding to the problem we faced in clustered environment.

I hope this helps others as well.