Saturday, 1 June 2013

OSB :: Route - Publish and Service Callout

Many of us sometime gets confused as what is the basic difference between Route , Publish and Service Call out in an OSB proxy flow.
People who are new to SOA buzz world they will find it difficult to fathom these actions and people who knows Oracle SOA suite may also get confused.
In this post i will try to explain the differences between these actions.

Service Callout: As we know there are mainly 3 types of MEPs (Message Exchange Pattern) which we follow in our day to day development to interact between end applications.
1) Synchronous interaction 2) Asynchronous interaction 3) One way interaction

Synchronous interaction is basically to communicate with end point and wait for its reply to process the response.
Service Call out is exactly meant for that. If you use Service Call out in any of Request or response pipeline proxy service will wait for the reply from the end application.
So when ever you are thinking to interact with synchronous process you can opt for Service call out. But this is not the only action which you can use when interacting with synchronous process.

Publish: As mentioned earlier there can be three types of interactions between application. For asynchronous interaction OSB does not provide specifically any action and it also does not suite its architecture. So if yo are thinking to implement asynchronous service interaction better to choose Bpel(Oracle SOA) instead of OSB, though you can implement asynchronous interaction in OSB but it is not straight forward like Bpel.
Apart from asynchronous interaction there is another interaction named one way interaction.
OSB provide an action for this type of interaction named Publish. Publish action only sends the request and never ever waits for any response(default behavior if required one can use routing option to change its behavior)  from the back end service even if any exception happens you can not catch it using publish action because it doesn't block the request thread and doesn't wait for reply.

So far we cam to know about Service call out and publish action now we will discuss the most important action in a OSB proxy flow for integrating with different application, action is called route.

Route: Route action has some special feature in a proxy flow. if you are using route in your proxy flow then route will be the last action in the flow and you can not add any other action after route action. It is route action where context is switched, what i meant to say about context switching is switching between request context to response context, that means in route action request body will be mapped to response body and similarly for all the context variables (body , fault etc).
Now inside a route you can use a routing option and you can communicate with back end applications using this routing option. you can interact with both Synchronous and oneway process using routing option.
More over it has a feature which makes the processing/interaction happen within the same transnational boundary (unless configured separately) by doing this it ensures that the response comes back from the back end application without having any dependency on the process type (Synchronous/oneway).

There is one action called routing option which is very useful for managing threads/transaction for the interaction.

Thursday, 27 September 2012

Traversing Oracle SOA MDS


While developing in Oracle SOA Suite most of us come across a common challenge on how to fetch artifacts from MDS.
MDS is a out of the box governance provided by Oracle, whenever we install Oracle SOA suite MDS gets automatically created and this MDS is used mainly at runtime.
Sometimes we may require to access this artifacts directly from MDS using mds apis provided by oracle. The challange of using the MDS api provided by oracle is that the api exposed by oracle does not provide the flexibility to use them as per user's requirement.

In this blog i will provide the java code base which helped me to traverse the MDS package and fetch the required documents.

ref : http://java.net/projects/mds-explorer

MDS Runtime Dependencies and MDS Runtime library required to run the code.

Friday, 6 July 2012

Transient and Durable Process

Most of us who are working in Oracle SOA has came across a common question many times,
what is transient and durable process in SOA.

As we know oracle soa uses dehydration store to store all the details of a process which has been executed, may it be a successful execution or may it be a failure each and every details are stored in the the soa dehydration store.
A process will be called a Transient process whose state  is not stored in soa dehydration store or in tern we can say it is an in-memory execution. Any process which are not stored in the dehydration store we can call it a Transient process.

A process will be called a durable process which has its state stored in the soa dehydration store. By default all the BPEL process are durable process and its instances are stored in the dehydration tables.

Oracle SOA gives us flexibility to make any process transient forcefully by setting few properties.
These properties are bpel.config.inMemoryOptimization and bpel.config.completionPersistPolicy.
By setting these properties in tandem we can forcefully make a durable process transient.


Though there is some catch in this. As we know oracle SOA BPEL engine executes a process depending upon its message exchange pattern, if the process is synchronous then dehydration happens at the end of the execution or else if the process is asynchronous then the dehydration happens wherever the process encounters a dehydration point/activity ( wait , receive , pick , onAlarm , dehydrate).
We can make a synchronous process transient by setting above properties in the composite.xml provided the synchronous process does not have any dehydration points within its flow or else these properties won't work.

below is a snap of how to set these properties in the composite xml
<component name="BPELProcess" version="1.1">
   <property name="bpel.config.inMemoryOptimization" type="xs:string" many="false">true</property>
   <property name="bpel.config.completionPersistPolicy" type="xs:string" many="false">off</property>
</component>



Once these properties are set as shown above we will not be able to see the audit trail of this process from the em as the process is a transient process.