SOA Composite is in Running State and Reinitiates

 Problem:

The SOA Composite remains in running state for ever.
 Also it gets reinitiated by itself all over again

 Solution:

 This is because the process fails to identify the point of dehydration and tries to replay it all over again.
 There are several scenarios in which this can occur.
 Always ensure that long running while loops are avoided.
 Ensure that the audit doesn't have too much to be dumped on the Dehydration DB.
 If its not an issue , set the audit level to Production mode to achieve a better performance.

SOA11g DBAdapter - Package Body has been invalidated

 Problem:

 SOA via dbadapter calls a parent API.
 This Parent API can inturn call child APIs.
 The child API was recompiled and is in a valid state at the database layer.
 
 The DB Adapter fails with the following message:

 ORA-04061: existing state of package body "APPS.XYZ" has been invalidated
 ORA-04065: not executed, altered or dropped package body "APPS.XYZ"
 ORA-06508: PL/SQL: could not find program unit being called: "APPS.XYZ"

 Solution:

 This is a caching issue.
 Either recompile the package again at the database side or bounce the SOA Managed server.

SOA11g Datasource has been suspended.

Problem:
 Pool xyz_db_ds is Suspended, cannot allocate resources to applications

Summary:
This happens when the database has no more free connections, the datasource connection pool keeps requesting them, and weblogic suspends it.

Solution:
To resolve this exception, ask your DBA to give you a report about you database load, or, if you have a sysdba account, just run these commands:

Run these commands

--see current sessions/processes:
select count(*) from v$process;
select count(*) from v$session;

--see database configuration:
select *  from v$parameter where name in ('sessions','processes','transactions');

Increase the connections or correctly dimension your datasource connection pool to match the free sessions

sql> alter system set processes=500 scope=spfile sid='*';
sql> alter system set sessions=555 scope=spfile sid='*';
sql> alter system set transactions=610 scope=spfile sid='*';
sql> shutdown immediate
sql> restart

Finally , on the weblogic server reset this  datasource.

References:
http://egherardini.wordpress.com/2011/04/27/oracle-soa-suite-11g-datasource-has-been-suspended/

DB Adapter: Interaction processing error

Exception:

Exception occured when binding was invoked.Exception occured during invocation of JCA binding: "JCA Binding execute of Reference operation 'DEMO_TEST' failed due to: Interaction processing error.Error while processing the execution of the APPS.ABC.DEMO API interaction.An error occurred while processing the interaction for invoking the APPS.ABC.DEMO API. Cause: java.lang.NullPointerException.Check to ensure that the XML containing parameter data matches the parameter definitions in the XSD. This exception is considered not retriable, likely due to a modelling mistake.". The invoked JCA adapter raised a resource exception.Please examine the above error message carefully to determine a resolution.

Solution:

Undeploy the composite and Redeploy it again

ORACLE initialization or shutdown in progress

Exception:

java.sql.SQLException: ORA-01033: ORACLE initialization or shutdown in progress Error Code: 1033 [Caused by: ORA-01033: ORACLE initialization or shutdown in progress ] Check to ensure that the XML containing parameter data matches the parameter definitions in the XSD.
Contact oracle support if error is not fixable.

Cause:

This is not a JCA adapter problem. Please verify the stability of target database.

No more data to read from socket

Exception:

The invoked JCA adapter raised a resource exception.
Please examine the above error message carefully to determine a resolution.

,detail=No more data to read from socket ,code=17410}

Cause:

Occurs if application that uses DB connection from the DataSource which has been already been timed out.The application is not aware of this and still tries to use it to connect to the database.


Soultion:


Option1:
Reset the datasource

Option2:
Bounce Managed Servers

Option3:
Delete the datasource , bounce managed server and create the datasource again.

Could not instantiate InteractionSpec oracle.tip.adapter.db.DBStoredProcedureInteractionSpec



Exception:

Exception occured during invocation of JCA binding: "Could not instantiate InteractionSpec oracle.tip.adapter.db.DBStoredProcedureInteractionSpec due to: ". The invoked JCA adapter raised a resource exception.Please examine the above error message carefully to determine a resolution

Cause:

The issue was caused by known Unpublished Bug 11924578
Bug 11924578 - ADAPTERS USE OF HASHMAP CAN LEAD TO DEADLOCKS
Additional Information: Bug 11924578 exists in versions 11.1.1.3, 11.1.1.4 and 11.1.1.5


Solution:

To implement the solution:

For Non-Clustered environments, patches for the following three bugs have to be applied Bug 13360039 , Bug 12573835 and Bug 13394139
Note: Patch for Bug 11924578 is included in Patch for Bug 13360039
For Clustered environments, in addition to the above 3 patches, patch for bug 12797505 is also required

Failed to read wsdl file at: caused by:java.net.ConnectException: java.net.ConnectException: Connection refused


Solution:
Telnet to the external server to check whether the Connection to the server is established properly

Unable to undeploy Composite from SOA 11g partition



[undeployComposite] INFO: Received HTTP response from the server, response code=500


[undeployComposite] ---->response code=500, error:There was an error undeploying composite on ETH_SOA1: Cannot find revision in undeploy : ETH_INPUT_SERVICES_EMR613/ETH_EMR613_FileReceiverProcess_Composite!1.0..




Cause
Bug 13360039 - SOA11G COMPOSITE UNDEPLOYMENT FAILS WHEN THE PATCH 11924578 APPLIED.


Solution
Please follow below steps to download Patch:13360039:
1) Login to MyOracle support portal.


2) Search for patch number 13360039


3) Download the patch and follow the Readme to apply the patch in your test environment.

Could not reserve enough space for object heap Could not create the Java virtual machine

Open user_projects\domains\base_domain\bin\setSOADomainEnv.cmd file


Change From : set JAVA_OPTIONS=%JAVA_OPTIONS% set DEFAULT_MEM_ARGS=-Xms512m -Xmx1024m set PORT_MEM_ARGS=-Xms768m -Xmx1536m

To: set JAVA_OPTIONS=%JAVA_OPTIONS% set DEFAULT_MEM_ARGS=-Xms512m -Xmx768m set PORT_MEM_ARGS=-Xms768m -Xmx1536m

Save the file and then re-run startWebLogic.cmd

Oracle SOA 11g - Changing the service endpoint URL dynamically through EM console

To change the default endpoint location of the service through the EM console, please follow the below steps:

1. In EM console click on the Composite
2. Scroll down to Service and References section
3. Click on Reference link and properties tab
4. Change Endpoint Address to the desired location and click apply

The new request will be send to the new endpoint location configured through the EM console. 

The new endpoint configuration can be removed to send the request to the default endpoint location configured in the WSDL.

SOA11g File Adapter - Write Permissions

File Adapter by default writes with (-rw-r----- 1 oracle dba ) permissions.
Modify the UMASK permissions (To required permission level) on startWebLogic.sh file and bounce the managed servers to get it reflected.

Change the Endpoint URI of OSB Business Service dynamically

In the Proxy Service,user Routing Options in Request of ServiceCallout/Route to change the URI dynamically.

Routing Options to override the following default configurations:

URI:
Quality of Service:
Mode:
Retry Interval:
Retry Count:
Priority:

Tuning the Oracle SOA infrastructure

Tuning the Oracle SOA infrastructure involves the following:

JVM Memory
JVM Garbage Collection
Datasources
Threads
EJB
Database
Tuning JVM Memory

The JVM Memory settings are extremely important for Oracle SOA 11g. Set the minimum heap size to 2048MB and the maximum heap size to 4096MB or more depending on the availability of your physical resources on which the SOA platform is installed.
Also, setting the PermSize and the MaxPermSize is extremely important. Make sure that the PermSize is set to at least 512MB and the MaxPerSize is at least 1024.

Example:
-Xms2048M -Xmx4096M -XX:PermSize=512M -XX:MaxPermSize=1024M

Setting JVM Garbage Collection

If your SOA Suite is running on a single CPU machine, then setting the garbage collection to parallel will not improve the performance. However, if your SOA Suite is installed on a virtual machine with a multi-core CPU running on a VMWare ESX host, then setting this option will improve your system’s performance significantly.

Example parameters for a multi-core CPU or virtualized environment server:
-XX:-UseParallelGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+CMSIncrementalMode -XX:+CMSIncrementalPacing

Tuning SOA Suite 11g DataSources

Configuring and optimizing your back-end connections for SOA Suite is essential for the overall system performance. Oracle recommends that you run a series of load tests against your database to adequately measure performance needs and properly define the associated parameters.

Oracle recommends to tune the below Oracle SOA 11g DataSources:

BAMDataSource
EDNDataSource
EDNLocalTxDataSource
mds-soa
SOADataSource
SOALocalTxDataSource

The following parameters settings showed improved performance over the default when set for each of the above datasources. These are set using the Weblogic Administrative Console:

Initial Capacity=0
Maximum Capacity=100
Capacity Increment=1
Statement Cache Type=LRU
Statement Cache Size=0
Test Connections On Reserve=TRUE
Test Frequency=180
Seconds to Trust an Idle Pool Connection=30
Shrink Frequency=300
Connection Creation Retry Frequency=30
Inactive Connection Timeout=30
Maximum Waiting for Connection=2147483647
Connection Reserve Timeout=30
Statement Timeout=-1
oracle.net.CONNECT_TIMEOUT=100000
Set XA Transaction Timeout=TRUE
XA Transaction Timeout=0
XA Retry Duration=300
XA Retry Interval=60

Threads

Oracle advises against modifying the default threading model for the Oracle SOA 11g Suite. This is because Weblogic uses an automated mechanism for tuning its execution of threads. WebLogic Server prioritizes the requests and allocates threads based on an execution model that takes into consideration the managed servers parameters and actual run-time statistics.
On the other hand, you may tune the threads of the BPEL engine itself. This can be achieved through the Weblogic Enterprise Manager. The threads will use a database connection from the pool.

Setting the following parameters according to Oracle’s best practices for the BPEL engine through EM will allow for an improved thread execution and handling:

dspInvokeThread=10
dspEngineThreads=15
dspSystemThreads=2
synMaxWaitTime=150

EJB

The soa-infra application includes all the EJB objects required for Oracle SOA 11g Suite. Each of these EJB objects has a pre-defined timeout setting. By default, this setting is 300 seconds. Time-out errors could occur in the case of long running processes that could slow down the overall SOA system. Therefore you should not just count on tuning the soa-infra application, you should design and implement efficient and optimal composites.
To change the timeout of the EJB’s, you will need to go through steps described below:
Log in to the Weblogic Administrative Console.
Undeploy the soa-infra application and activate the changes.
Redeploy soa-infra application with configuration file (Plan.xml) from $ORACLE_HOME/soa/applications/soa-infra-wls.ear with all the new EJB time-out settings. Make sure to copy the application to all servers.
Activate changes
Start soa-infra application to server all requests.

Please note the following timeout settings showed improved performance over the default:

TransactionDescriptor_transTimeoutSeconds_BPELEngineBean=1800
TransactionDescriptor_transTimeoutSeconds_BPELDeliveryBean=1800
TransactionDescriptor_transTimeoutSeconds_BPELActivityManagerBean=1800
TransactionDescriptor_transTimeoutSeconds_BPELServerManagerBean=1800
TransactionDescriptor_transTimeoutSeconds_BPELProcessManagerBean=1800
TransactionDescriptor_transTimeoutSeconds_BPELInstanceManagerBean=1800
TransactionDescriptor_transTimeoutSeconds_BPELFinderBean=1800
TransactionDescriptor_transTimeoutSeconds_BPELDispatcherBean=1800
TransactionDescriptor_transTimeoutSeconds_BPELSensorValuesBean=1800

In addition, verify that the global transaction timeout on all the managed servers is larger than the timeout of the EJB. If using the above settings, make sure to set the global transaction time-out, JTA, to 3600 through the Weblogic Administrative Console.

Database

Ensure first that you have followed the appropriate database configuration required for Oracle SOA 11g Suite as documented in the Oracle SOA 11g Administrative Guide (Download from oracle.com). Most importantly, make sure that the database is configured to create adequate processes and sessions to support the infrastructure. The database must be tuned so that it has enough memory for caching, PGA, and SGA.
In addition, cleaning the SOA composite instances from the back-end is also important as part of the Oracle SOA 11g system maintenance. Deleting thousands of instances with the Delete with Options button on the Instances page of a SOA composite application in Oracle Enterprise Manager takes time and may result in a transaction timeout and data inconsistency. Instead, Oracle recommends using the “purge_soainfra_oracle.sql” PL/SQL script for instance and rejected message deletion. The script can be located under: “SOA_HOME\rcu\integration\soainfra\sql\purge”. The PL/SQL procedures in this script are populated into the database when you run the Repository Creation Utility during Oracle SOA Suite schema creation.
For detailed instructions on how to use and manipulate the purging scripts to maintain the Oracle SOA suite, refer to Section 8.11 in the Oracle Fusion Middleware – Administrator’s Guide for Oracle SOA Suite and Oracle Business Process Management Suite.

The link for the administrative guide is provided below:
http://download.oracle.com/docs/cd/E14571_01/integration.1111/e10226.pdf