Plan.xml Not Getting Updated Across Nodes In SOA 11g Cluster

Recently came across an issue in SOA 11g cluster environment related to Plan.xml.

After creating a data source in Weblogic Admin console, when you update the DB adapter from deployments section, at the "Save Deployment Plan Assistant" screen the data gets stored in the Plan.xml (MW_HOME/ORACLE_SOA1/soa/connectors directory). In a SOA 11g Cluster (lets say 2 node env.) this Plan.xml file gets created on both the nodes first time. However any subsequent updates on the adapter like creation of new datasources or updation to existing ones dont get saved to both nodes. Only the Plan.xml on node where admin server runs gets updated.

This would cause datasource errors/missing JNDI name errors when the environment is load balanced and requests are routed to the 2nd node.

This is more of a cluster configuration issue. The Plan.xml should be kept in a location that is shared storage for all cluster nodes. If this hasn't been done while setting up the cluster then every time adapter updation happens, the Plan.xml only gets updated on Admin server node. In that case the solution is to manually copy the Plan.xml from admin server node to other nodes and restart the managed servers.

Using DVMs in SOA 11g

DVM(Domain Value Maps) are static mappings between a source and target system which can be used in transformations. In SOA 10g, DVMs (.xml) could be imported into the ESB Console and during design time accessed via the lookupDVM XPath functions. I would like to cover the usage of DVMs in SOA 11g and how they can be extended/updated at runtime using SOA Composer.

Within Jdeveloper Right Click on your SOA Composite project and create a new DVM table

You can the use this DVM inside your XSL transformation using the lookupDVM function and finally deploy the code.

Modifying the DVM is equally easier. Just login to the SOA Composer (http://hostname:port/soa/composer)

You can edit the DVM after selecting it and once changes are done Save it and the Commit it. It should commit the changes to the MDS repository and make them available at runtime.