Configuration plans for Oracle SOA Composites

Deployments of SOA composite(s) onto a SOA server environment is one of the challenging task for a SOA Developer/Admin, more so when certain composite or components parameters will need to be set differently from one server environment to another.  For instance, a composite with DB Adapter poller component deployed on a multi-node server(Clustered environment) will need to have a singleton property set to true to ensure that only one instance of adapter is triggered for a transaction. However, the singleton property may not hold good in a single node environment. The values of such properties and many such changes can be handled using the configuration plan during deployment of composites.


Unlike Java applications, SOA composite applications do not rely on property files to maintain environment specific configuration. Many SOA projects may include references to other external services, for example, http://payment-processing-server-dev:7777/proc/servlet/createCustomer. As you can see from this URL, the developer is referencing some external development server as identified by the hostname payment-processing-server-dev. This URL is hardcoded within the code and ultimately included within the deployable SAR. Prior to deploying this code to the test environment, the administrator must find a way to ensure that the test URL is referenced instead (which may have a different host, port, and protocol) as shown by https://payment-processing-server-test:7778/proc/servlet/createCustomer.


The configuration plan is applied to the composite during deployment. In this post, let's look at the way to generate a configuration plan, explain different section of a configuration plan and few of the ways the plan can be applied during composite deployments. Normally, the case is a developer's environment will not have any configuration plan and the default values specified in the project files are taken into account during composite deployment (It's true in the projects that I  had worked until now). The configuration plan is applied during composite deployment in server environment higher up to the development like test and production environments and values of the development environment can be over-ridden to environment specific values. Note that the configuration plan can also be defined at the SOA application level in which case it is applied to all projects within that application. In this post, to keep it simpler let's look at the plan being defined at the project level.


Generate a Configuration Plan
In order to create a configuration plan in JDeveloper, right click on the composite.xml file of the project and then select the Generate Config Plan option. 

Key in a meaningful value to your configuration plan file name and then click on Ok (I generally suffix the plan name with the environment name, that way one will know to which environment is the configuration plan will need to be applied as in my case I had a different config plan for stage and production environments).

Configuration Plan Explained
The configuration plan of the project so generated will contain changes to be done at two levels - composite.xml file, and the other to the WSDL and schema files defined in the project.

The composite section in turn contains different sub sections - import, component, service and reference sub sections. Key in the appropriate values to search and replace the URL/properties of sub sections to suit to your deployment environment.

The wsdlAndSchema section by default points to all the wsdl, schema and jca files in the project where a search and replace rules are mentioned. Change them with appropriate search and replace strings

Additionally, you can validate the configuration plan for valid tags and its syntax using the Validate Config Plan option of the menu popped up when you right click on the composite.xml file.

Applying Configuration plan during composite deployment

Configuration plan can be applied to the composite during deployment onto the server. Two such ways are mentioned below:
1. Using JDeveloper in the deployment wizard, while deploying to SAR file or to application server as shown below: 

2. In the Weblogic EM console, while deploying the Service Archive (SAR) file onto the server partition

Once deployed, you can validate if the properties specific to deployment environment mentioned in the configuration plan applied to the composites in the EM console.



                                                                                                     By DeepthiReddy