Configuration Plans for SOA Suite 12C (Part 2)

This is the second of a three part blog covering how to replace URLs and other environment specific fields in a SOA composite. The three options I am discussing are:

  1. Composite specific configuration plan
  2. Shared configuration plan
  3. Global tokens

The shared configuration plan is a great approach (my preferred). You no longer need to generate and customize the configuration plan for every composite, instead you have generic plans you use by environment. So if you have a dev, test, and prod, you would have 3 configuration plans, one for each environment. These generic plans can also be less error prone, since they can be set up once and used by everybody. The shared configuration plan uses the search and replace capability to find and replace the hostnames in your composite.

Here is an example Shared Configuration Plan:

<?xml version=”1.0″ encoding=”UTF-8″?>
<SOAConfigPlan xmlns:jca=””

    <composite name=”*”>







        <reference name=”*”>

            <binding type=”ws”>

                <attribute name=”location”>









    <wsdlAndSchema name=”*”>








You will notice that in the imports, I am replacing the host to a badhost. The reason is we leverage MDS or relative pathing for XSDs and abstract WSDLs, so we would not be intentionally importing anything that would be referenced through our server. Occasionally, someone forgets to clean up an import, this helps remind them (they will fail).

There also may be other properties that you need to replace based on your organization, this includes endpointURI, oracle.webservices.auth.userid and oracle.webservices.auth.password as examples. To replace these, you can use the same pattern as above.

Another challenge with shared configuration plans in 12c is you may be testing locally on your desktop and not on a shared server. Which means the hostname you search for could be different for each developer. I recommend using localhost in this case during development so you can use the consistent hostname in the search as I did above.

You will typically save these shared configuration plans where you can access them when deploying. If you are deploying from JDeveloper, you will select the shared configuration plan as below, then follow the normal deployment steps.

Using Shared Configuration Files in FlexDeploy

To use a shared configuration plan, it works basically the same as it did in the last blog. In the SOA deploy workflow, we open the SOA deploy plugin call and set the input to the name of the configuration plan.

Other Useful Links

An 11g overview of shares configuration plans:

3 thoughts on “Configuration Plans for SOA Suite 12C (Part 2)”

  1. I have created a BPEL Config plan and using it for the deployments into other environments.

    I have few WSDL’s which are having the endpoint URI’s in different places under the same WSDL, when i use the config plan it is searching and replacing only few references in the WSDL.

    BEPL Config plan is doing the partial replace, I have tried all the options in the level , but nothing worked.

    — this EndPOint URI reference is successfully getting updated with the value defined in config plan, but :

    EndPoint URI — this reference is not getting updated.

  2. wsa:Address xmlns:wsa=”” EndPoint URI /wsa:Address

    soap:address location=”EndPoint URI”

    Above comments does’nt allowed tags, hence reposting.

  3. I do not follow. I assume you are using the search and replace with in your WSDL and it is only replacing some of the URLs. What version of SOA Suite are you using? Can can you give an example?

Leave a Comment

Your email address will not be published.

Scroll to Top