Sunday, March 11, 2012

Accessing Remote JMS


As explained in my previous post: http://oraclefusion1011.blogspot.com/2011/01/foriegn-jms.html
we can use Foreign JMS or Message Bridge to access remote JMS.

There is another simple way of using the remote CF JNDI to access remote JMS, here are the steps :

Server 1: This host the JMS
- Create JMS Module : MyVendorModule
- Create JMS Queue : jms/Queue/Vendor_Que
- Create Connection Factory : com.myorg.jms.VendorQueConnectionFactory


Server 2: The consumer Server
Create outbound connection pool in JMS Adapter :

eis/VendorInput/Queue , with following important properties :

ConnectionFactoryLocation : com.myorg.jms.VendorQueConnectionFactory

FactoryProperties :
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://server1:8001

for clustered env

FactoryProperties :
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://server1:8001,server2:8002

or

FactoryProperties :
java.naming.factory.initial=weblogic.jndi.WLInitialContextFactory;java.naming.provider.url=t3://server1,server2:8001

If ports are same



This option works well with SOA - Bpel , however Message bridge and Remote JMS provides more usability with heterogeneous code/Tech need to access remote JMS

Cheers !!

Bpel Dehydration and recovery


There are number of docs that explains dehydration and instance recovery. But is that really works in case server crashes or for some network failure.
Here are few test run based on some of closely related activities wait,checkpoint,dehydrate, sleep(inside java).

Wait : This causes bpel instance to get dehydrated and following activities will be executed in a different thread.
Invoke -> wait 1 -> invoke -> wait 2 -> assign -> finish
Here is what the thread display in audittrail inside java :
Thread before wait is : 130
Thread after wait 1   is : 238
Thread after wait  2 is  : 239

Checkpoint:This has similar behaviour as wait
Invoke -> chk 1 -> invoke -> chk 2 -> assign -> finish
Thread before checkpoint 1 is : 16
Thread after checkpoint 1 is : 232
Thread after checkpoint 2 is : 233

wait/checkpoint/dehydrate : All behaves same

Sleep: inside java embedd
Most people think this will cause dehydration , however this doesnt
Invoke -> sleep 1 -> invoke -> sleep 2 -> assign -> finish

Thread before sleep 1 is : 129
Thread after sleep  1 is : 129
Thread after sleep  2 is : 129

If you query the cube instance table for these activities you will find that except sleep all other updates the table with status "INITIATED" after dehydration. For sleep the row gets updated just once with status "COMPLETED"

That seems good , now lets see if the bpel actually do the recovery as per the documentation the saved instance will be recovered and re-executed from the last dehydration point.

Flow :
Invoke1 -> dehydrate ->server crash -> invoke 2
Here is what happened :
- Invoke 1 completed
- Instance gets dehydrated
- server crash
- DB store the state with : initiated
- Server started
- Instance gets recovered , state changed to running and completed from the dehydration point
- DB store the state with : completed

That looks good , there are couple of settings one must be careful with while expecting auto recovery.

these are listed here : Configuring Automatic Recovery for Oracle BPEL Process Manager
http://docs.oracle.com/cd/E17904_01/integration.1111/e10226/bp_config.htm

Tables to look out for in soa database :
CUBE_INSTANCE
CUBE_SCOPE
INVOKE_MESSAGE

Cheers !!

Thursday, March 8, 2012

WS Atomic Transactions using SDO


ADF bc based SDO works well for data fetch and data transformation , however applications interacting using WS interface and needs Transaction support with SDO need to understand :
Web Services Atomic Transaction &
Web Services Coordination (WS-Coordination)

These specifications define an extensible framework for coordinating distributed activities among a set of participants. As per oracle doc :



Coordinator : 
Manages the transactional state (coordination context) and enables Web services and clients to register as participants.

Activation Service :
 Enables the application to activate a transaction and create a coordination context for an activity. Once created, the coordination context is passed with the transaction flow.

Registration Service Enables an application to register as a participant.

Application Protocol X, Y : Supported coordination protocols, such as WS-AtomicTransaction.

 How to enable these while using SDO :
1. In the ServiceImpl.java class of service interface add following to the class and methods
@Transactional(
version=Transactional.Version.[WSAT10|WSAT11|WSAT12|DEFAULT],
value=Transactional.TransactionFowType.[MANDATORY|SUPPORTS|NEVER]
)


This will enable SDO to participate in JTA transaction 

2. For this to support the domain should  have been created with WebLogic Advanced Web Services for JAX-WS Extension , Or need to extend the domain for this.

This option will create following resources :
WseeJaxwsJmsModule : JMS Module
WseeJaxwsFileStore_server_designator : File store
WseeJaxwsJmsServer_server_designator : JMS server
WseeJaxwsJmsServeruniqueID : JMS subdeployment
weblogic.wsee.jaxws.mdb.DispatchPolicy : Work Manager
ReliableWseeJaxwsSAFAgent_server_name  : SAF service agent
WseeBufferedRequestQueue_server_designator : JMS queue
WseeBufferedRequestErrorQueue_server_designator : JMS queue
WseeBufferedResponseQueue_server_designator : JMS queue
WseeBufferedResponseErrorQueue_server_designator :JMS queue
WseeStore : Logical store


Cheers !!