Database Reference
In-Depth Information
Prod: cfgplan_prod.xml
The cfgplan_test.xml configuration plan should replace all devel-
opment environment settings with the test equivalent. The cfg-
plan_qa.xml should, similarly, replace all development environment
settings with the QA equivalent. The cfgplan_prod.xml should do the
same.
Thus, the code will always maintain development environment specific
settings, and it is the configuration plan that will ensure that these settings
are replaced appropriately when the code is deployed to the target envir-
onment.
3.
Every time a new environment-specific setting is used, the administrator
should ensure that it is added to each of the configuration plans.
4.
The administrator should always attach a configuration plan to every deploy-
ment.
Using configuration plans
In this example, we will exemplify the usage of configuration plans in a real world
use case.
We have a simple HelloWorld BPEL project already deployed to both our
development and test servers. On our development server, this is accessible
at the URL http://soa11gdev:8001/soa-infra/services/default/
HelloWorldBPEL/helloworld_client_ep?WSDL .
On our test server, it is accessible here, with only the hostname having changed.
The URL is http://soa11gtest:8001/soa-infra/services/de-
fault/HelloWorldBPEL/helloworld_client_ep?WSDL .
When developing a Mediator composite that calls this BPEL service in our devel-
opment environment, it will naturally invoke the development URL (accessible at
http://soa11gdev:8001) . When deploying this to the test server, this Me-
Search WWH ::




Custom Search