Wednesday, March 8, 2017

SOA Suite 11g to SOA Suite 12c Migration Experience !!!

In this post, I am going to list of some of the problems which I could remember; I have faced during SOA Suite 11g to SOA Suite 12c migration for one the recent project which I have completed.

Problem1: 'jca.retry.count’ error

While running some of the composite, transaction was getting rolled back with below error message –
Cannot parse JCA binding retry property 'jca.retry.count', value '0' due to: Value of JCA binding retry property
'jca.retry.count' must be a positive number: Cannot parse JCA binding retry property 'jca.retry.count', value '0' due to:
Value of JCA binding retry property 'jca.retry.count' must be a positive number</summary>
,detail=<detail>oracle.fabric.common.FabricException: javax.resource.ResourceException: Cannot parse JCA binding
retry property 'jca.retry.count', value '0' due to: Value of JCA binding retry property 'jca.retry.count' must be a positive
number: Cannot parse JCA binding retry property 'jca.retry.count', value '0' due to: Value of JCA binding retry property
'jca.retry.count' must be a positive number
at oracle.integration.platform.blocks.event.jms2.EdnBus12c.publish(

Solution 1:

This error was coming because ‘0’ was set for “NumberofRetry” located at this path
We have modified soainfrastructure>>
SOA Administration>> common properties>> More SOA Advance Configuration Properties >> Application
Defined Beans >>>>EDNConfig>>edn
I believe some internal changes been made for EDN delivery retry mechanism. Earlier as part of 11g, we were able to set “NumberOfRetry=0” but when we carried forward same value for SOA Suite 12c then composite start failing JCA error as listed above.
To fix this error we just change “NumberOfRetry =1” or any positive number up to 5.
Note: Setting number of “NumberOfRetry” =1 does not retry failed JCA transaction automatically.
Refer this document for detailed understanding about different value of NumberOfRetry and its impact.

Problem 2: ORA01400: cannot insert NULL into ("TST01_SOAINFRA"."AUDIT_DETAILS"."CI_PARTITION_DATE")

While running composite in test environment, we were getting below error message.
cannot insert NULL into ("TST01_SOAINFRA"."AUDIT_DETAILS"
Internal Exception: java.sql.SQLIntegrityConstraintViolationException: ORA01400:
Error Code: 1400
SCA_PARTITION_ID) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?)
bind => [9 parameters bound]
Query: InsertObjectQuery(AuditDetails flowId:
componentId: 1415333
detailId: 1055735
docRef: null
binUsize: 0
binCsize: 0
partitionDate: null)

Solution 2:

This error was related to “CI_PARTITION_DATE” column value inside “AUDIT_DETAILS” table. This error was coming specific to TEST environment. Later we find out this was related to “Audit Level” configuration which we can set at this PATH SOA-Infra>>SOA-Infrastructure>>SOA Administration>> Common Properties >> Audit Level to “Development” value.
This “Audit Level” property has two possible values a) Production and b) Development. In both cases, it does different level of logging. It’s obvious to understand that when we use “Audit Level = Development” , it does more extensive logging using “Audit_Details” table and was throwing above error.

The temporary fix of this error to change “Audit Level = Off/Production”, in this case error won’t get generated. 

The permanent fix we got from Oracle after raising the SR. Oracle advised to install PATCH 24794863 which fixed this issue permanently.   

Problem 3: Composite aka BPEL Code fixes

“bpel.config.inMemoryOptimization” and “bpel.config.transaction” properties were causing unexpected behavior while BPEL execution.

Solution 3:

The existing BPEL code where utilizing above 2 properties, but in 12c SOA Suite environment the BPEL containing above properties were causing issues while BPEL execution, transaction were getting stuck and were getting rolledback as well.
Later, after digging around a lot we came to know that these property were causing the issue, though these property are well supported in 12c as per Oracle comment.
Since these property does not have any significant impact on BPEL execution, to fix this problem we simply removed these properties from composite.xml.

Read below links, in case need detail understanding about these two properties behavior.

Problem 4: Non-blocking Invoke Issue

This issue also related to some of composite aka BPEL process. BPEL 11g offer execution of parallel flow using “nonBlockingInvoke” BPEL Partner link property. However, existing composite having parallel flow was getting stuck while execution. Audit trail was showing only first branch execution, later it didn’t do anything, Instance just get stuck.

Solution 4:  

In 11g threading model was having three different threading configuration Dispatcher Invoke, Dispatcher Engine, and Dispatcher System Threads respectively wherein we can specify how much treads count each category of threads required.
However, In SOA12c weblogic has changed its threading model completely. Now, instead of just 3 threading category, we have many work manager created to control thread count for various purpose. One of the work manager  default_dspNonBlock” also been created to handle parallel flow execution. This work manager has min constraint “default_dspNonBlock_minThreads_1” defined having default value 1, as result only thread can execute despite having parallel flow activity inside BPEL code.
To fix this problem we need to increase the count of min thread constraint “default_dspNonBlock_minThreads_1” default value to some higher value e.g. 5