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-