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:
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″?>
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: