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.

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.