OSB 11g Split-Join

Oracle Service Bus’s Split-Join feature lets you split a service payload, such as an order, into individual messages for concurrent processing. Concurrent processing, as opposed to sequential processing, greatly improves service performance. Split-Join achieves this task by splitting an input message payload into sub messages (split), routing them concurrently to their destinations, and aggregating the responses into one overall return message (join).
This process of payload splitting and response aggregation is called a Split-Join pattern.

Split-Joins are particularly useful for optimizing overall response times in scenarios where payloads delivered by faster systems are being directed to responding services on slower systems. Without Split-Join, individual messages in a payload are normally resolved in sequential order by the recipient, which can take a long time if the responding system is slow.

(The overall response time is the sum of the individual response times for each message.) With Split-Join, multiple messages are processed simultaneously, which reduces burden on the responding system and greatly enhances response times. (The overall response time is roughly that of the longest individual message’s response time plus some minor system overhead.)

For split join hands on refer the below blog post:
http://biemond.blogspot.com/2008/11/split-join-in-oracle-service-bus.html

XA and non XA datasource

An XA transaction is a "global transaction" that may span multiple resources.
A non-XA transaction always involves just one resource.

An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction.

Non-XA transactions have no transaction coordinator, and a single resource is doing all its transaction work itself (this is sometimes called local transactions).

Example of non-XA - a Servlet or EJB or plain old JDBC in a Java application talking to a single database.

XA gets involved when you want to work with multiple resources - 2 or more databases, a database and a JMS connection, all of those plus maybe a JCA resource - all in a single transaction.

In this scenario, you'll have an app server like Websphere or Weblogic or JBoss acting as the Transaction Manager, and your various resources (Oracle, Sybase, IBM MQ JMS, SAP, whatever) acting as transaction resources.

Your code can then update/delete/publish/whatever across the many resources. When you say "commit", the results are commited across all of the resources. When you say "rollback", _everything_ is rolled back across all resources.

The Transaction Manager coordinates all of this through a protocol called Two Phase Commit (2PC). This protocol also has to be supported by the individual resources.

In terms of datasources, an XA datasource is a data source that can participate in an XA global transaction. A non-XA datasource generally can't participate in a global transaction.

OSB 11G - HTTP redirects

HTTP redirects -Solves Issues redirecting the requests

Select this check box to specify that HTTP redirects (which are requests with a response code 3xx) should be automatically followed. A re-direct occurs when you send an outbound request to the URL of a business service, and that service returns a response code (for example, 302) that says the URL is no longer valid and this request needs to be sent to another URL. If the Follow HTTP Redirects check box is selected, Oracle Service Bus automatically re-sends the request to the new URL without any action on your part. Deselect this check box if you do not want the HTTP redirects to be automatically followed.

MaxMessageSizeExceededException Errors Caused By Large Payloads

If you provide a large payload (for example, 12 MB) to your deployed SOA composite application, then click View XML Document in the audit trail to view the payload, you can encounter MaxMessageSizeExceededException errors. This error can be resolved by setting the following JVM parameter.

Open the following file:

On UNIX operating systems, open $MIDDLEWARE_HOME/user_projects/domains/domain_name/bin/setDomainEnv.sh.

Add the weblogic.MaxMessageSize property with the following value:
EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES}
-Dweblogic.MaxMessageSize=20000000"
export EXTRA_JAVA_PROPERTIES

Restart the server

Unable to display Flowtrace

1. Go to servers--->protocols--->general--->max message size--->changed the value (admin and the soa servers)

2. Go to servers--->configuration--->server start--->arguments---> Dweblogic.MaxMessageSize=50000000

3.Restarted admin,managed servers

Unable to display Flowtrace due to the below exceptions:

"weblogic.socket.MaxMessageSizeExceededException" "weblogic.rmi.extensions.RequestTimeoutException"

Use ALTER TABLESPACE ADD DATAFILE statement to add one or more files to the tablespace indicated.

SOA 11g java.lang.OutOfMemoryError

11G is running java 1.6 which is already 64-bit enabled. So, all you need to do to resolve 'out of memory' errors is increase java start up parameters in setSOADomainEnv.sh script to required values, for example change from
DEFAULT_MEM_ARGS="-Xms768m -Xmx1536m"and PORT_MEM_ARGS="-Xms768m -Xmx1536m"toDEFAULT_MEM_ARGS="-Xms768m -Xmx3072m"and PORT_MEM_ARGS="-Xms768m -Xmx3072m" If after JDK upgrade you are still getting 'out of memory' errors or if upgrade is not possible then you need to perform SOA capacity planning, setup SOA cluster and start adding nodes to your cluster based on estimated load.

The above is applicable to JRockit as well.

Managed SOA Servers starting in Admin Mode

Managed Servers will fail to be up and running and will start in Admin Mode for several reasons.

Few of which are due to problems in Datasource:

1)Invalid Credentials
2)Corrupted Datasource (Datasource which gave exceptions during creation)

Struck Thread Error in SOA11g

Struck Thread Error

Patch Number: 12573835 (Patch applicable for 11.1.1.5)

Problem Details:

Encountered the problem where Admin/Managed Server resulted in Warning mode . The immediate logs reflected Struck Thread Error.

Cookie: JSESSIONID=rkBvTKqd98lT1Hvh52cvhLJrlqLvTG5FZ1vf7Lw2Th17gfjQh8QT!-1380073465; ADMINCONSOLESESSION=QQn0TKRG11p1vKnwFRyFnnSQr6d4Gz1NnLFkGvKlRcSM1n4rnLCc!-1380073465

]", which is more than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace:
Thread-184 "[STUCK] ExecuteThread:


Patch 12797505 (Patch applicable for 11.1.1.5)

Problem Details:
Corruption of wsdl manager cache based on Note 1340218.1

Patch 12337493 (Patch applicable for 11.1.1.5) based on Note 1344909.1 WLS10.3.4

Problem Details:
Hangs with Stuck Thread:Blocked trying to get lock

SET COMPOSITE PROCESS STATE CONFIGURATION - SOA11g

To have the composite state display the actual state, perform the following:

i. Log in to Fusion Middleware Control (e.g., http://host:7001/em)

ii. Right-click on "soa-infra" and navigate to "SOA Administration --> Common Properties"

iii. Set Audit Level as “Development”

iv. Check 'Capture Composite Instance State'

v. Click "Apply"

Increase EJB timeout seting in SOA11g

* Stop the managed servers
* Log into Oracle WebLogic Administration Console.
* Click Deployments.
* Expand soa-infra -> EJBs.
* Following EJBs need to be updated:

BPELActivityManagerBean
BPELDeliveryBean
BPELDispatcherBean
BPELEngineBean
BPELFinderBean
BPELInstanceManagerBean
BPELProcessManagerBean
BPELSensorValuesBean
BPELServerManagerBean

* You can change the parameter in the Configuration tab for the Transaction Timeout setting.
* Click Save.
* Save the Plan.xml to some known location - Ensure no other file is named Plan.xml
* Update soa-infra deployment.
* Start SOA Managed Server.

EXCEPTION NOT HANDLED BY THE COLLAXA CUBE SYSTEM - ORA-01438

Applies to:

Oracle SOA Platform - Version: 11.1.1.3.0 and later [Release: 11gR1 and later ]
Information in this document applies to any platform.

Symptoms

The following exception is continuously logged in the SOA logs impacting performance of SOA composites
Error while invoking bean "cube delivery": Exception not handled by the Collaxa Cube system.[[
an unhandled exception has been thrown in the Collaxa Cube systemr; exception reported is: "ORABPEL-00000

Exception not handled by the Collaxa Cube system.
an unhandled exception has been thrown in the Collaxa Cube systemr; exception reported is: "java.sql.SQLDataException: ORA-01438: value larger than specified precision allowed for this column

at oracle.jdbc.driver.SQLStateMapping.newSQLException(SQLStateMapping.java:83)
at oracle.jdbc.driver.DatabaseError.newSQLException(DatabaseError.java:135)
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:210)

Cause

Issue caused by Bug 12621337 - ora-01438 on live_instances column

Solution

Bug 12621337 is still open and scheduled to be fixed in future release.Meanwhile, the following explanation and workaround is documented in the bug
The problem is with the precision of the column composite_instance.live_instances currently defined to be number(3) which can at the most hold a value up to 999. There is no explicit limitation on this column and so, the right way to handle this is to increase the precision of this column to accommodate more instance.

The workaround is to modify composite_instance.live_instances column precision to be number(38) in the soainfra schema.

1. Stop SOA domain
2. Login to SOA infra repository database as sysdba
3. Modify composite_instance table
For example:
ALTER TABLE
soa11g_soainfra.composite_instance
MODIFY
(
live_instances NUMBER(38)
)
;

4. Restart SOA domain

Could not reserve enough space for object heap on JDEV11g

Increase the JVM arg value in ant-sca-compile.xml available at (jdeveloper\bin\ant-sca-compile.xml )

JVMARG value="-Xms512m"