Oracle SOA/BPEL/OSB- High Availability and Scalability DB adpater - SOA Suite 11G/12C

The Oracle Database Adapter supports two high availability setups.

• Active-Active setup
• Active Passive setup

In an active-active setup, distributed polling techniques can be used for inbound Database Adapters to ensure that the same data is not retrieved more than once.

Singleton behavior within an active-passive setup allows a high performance multi threaded inbound Oracle Database Adapter instance running in an active-passive setup, to follow a fan out pattern and invoke multiple composite instances across a cluster.

The Oracle Database Adapter also supports the high availability feature when there is a database failure or restart. The DB adapter picks up again without any message loss.

Distributed Polling 

Often in production environments,servers runs in clustered mode i.e more than one managed server running under one cluster.Generally if we don't implement distributed functionality then say for e.g we have 5 severs in clustered environment.Then in clustered environment in case of polling DB adapter it is quite possible that all 5 nodes try to poll the same record at same time,which will result in 5 concurrent instances with same data.Clearly,we do not want that at all.

When we select Distributed polling while configuring DB adapter, it automatically uses the syntax SELECT FOR UPDATE SKIP LOCKED that means the same row cannot be processed multiple times.

Singleton

As mentioned under distributed polling,there may be times where it is best to improve performance on a single node, and then optionally do fan-out to multiple nodes in a cluster. Relying on concurrency control features of the database such as locking can be great, but these are often designed more for preserving data integrity than for high performance scalability.The JCA Binding Component supports active fail over of inbound Adapter Services.To enable this fail over feature for a given inbound adapter endpoint, you 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 shown below:

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

Only one node of the cluster will poll for the record. If the active node goes down then other node of the cluster will active node and started polling for the record.   

Oracle SOA/BPEL- Unit Test Cases tutorial for SOA Composites

Unit testing is very critical part of development process. In SOA there is no straight forward process to perform unit test. You have to deploy the composite on SOA server and through EM console you can unit test it. Some time EM console takes time to open which is very frustrating.

So, we should SOAP UI tool for unit testing . We can do unit and load  testing from Soap UI for same composite. I came through very helpful blog for the same.

http://learn-oraclesoa.blogspot.co.uk/2013/07/unit-test-cases-tutorial-for-soa.html

Oracle SOA 11g/12C - BPEL Transaction Handling Part 2

Please check my previous post (SOA 11g/12C - BPEL Transaction Handling Part 1)on this topic.


Now we will test other scenario of  BPEL  transactions

2. Second scenario

Master BPEL Process

bpel.config.transaction=requiresNew

ChildBPEL Process 

bpel.config.transaction=required


In this case ChildBPEL process will participate in client's transaction (MasterBPEL process).  

If The ChildBPEL Process	Then The MasterBPEL Process
Replies with a fault (that is, it uses <reply>).	Gets the fault and can catch it. The BPELCaller owns the transaction. Therefore, if it catches it, the transaction is committed. If the BPELCaller does not handle it, a global rollback occurs.
Throws a fault (that is, it uses <throw>).	Gets the fault and can catch it.
Throws (that is, it uses <throw>) abpelx:rollback fault.	Gets its transaction rolled back; there is no way to catch it. This fault cannot be handled.

We will test last one when ChildBPEL process throws roll back error. In this case transaction in MasterBPEL process will be rolled back even if it catches this exception beacuse both processes are part of same transaction. So, roll back will happen for both the processes.
Transaction settings





MasterBPEL process with CatchAll block

 
ChildBPEL Process with RollBack exception

Database table with 2 records. We will try to insert third record in this scenario.

 

 Test data on EM



 

 Error on EM console




Audit trail






Employee table - no new record inserted due to global roll back.



 In other cases, if ChildBPM process throws error other than rollback and MasterBPEL process catch the exception then MasterBPEL process's transaction will be comitted. You will see new record in database table.



Source:

http://docs.oracle.com/middleware/1213/soasuite/develop-soa/bpel-transaction-semantics.htm#SOASE85818