This is the first of a three part blog covering how to replace URLs and other environment specific fields in a SOA composite.  The 3 options I will discuss are:

For each of these approaches to cleaning up environment specific fields, we will show how the Oracle capability works, then show how Flexagon’s FlexDeploy product supports each approach.  My example will be using CreateOrderService Composite that has a call to GetOrderDiscount composite.  I am running it on a local 12c Soa Server, and need to deploy it to a central 12C test server.  Although this Blog is written for SOA 12C, the capability is virtually identical to the 11G capability.  To see the required fix up in this composite, I open the composite.xml, see the local reference highlighted below:

We will clean up this URL using the 3 above techniques to show the strengths of each approach.  The blog today will cover composite specific configuration plans, in future blogs we will cover the shared configuration plan and global tokens.

Composite Specific Configuration Plan

With the composite specific configuration plan, we will generate a plan, and customize it specifically for the CreateOrderService composite.

Generating the Configuration Plan with JDeveloper

To generate the configuration plan in JDeveloper, right click on the composite.xml.  Select “Generate Config Plan” and give the plan a name.  This name is often specific to an environment because each environment will have its only values that you will need to set the URL to.  For example, the Dev URL might start with http://devsoa01:8001,   but in the QA environment being fronted by a load balancer, the URL is http://soaqa01:80.

Adjusting the Plan

Once the plan is generated, we can open the plan and adjust it for the environment we are going to deploy the composite to.  In this case, we need to adjust the location for the reference SOAP_GetOrderDiscount.  At times, you may need to handle environment specific content in your imports, services or other parts of the composite.xml.  You can also adjust other files like JCA files or WSDLs.   Note how specific this generated plan is, it has been generated specifically for the CreateOrderService composite.  The section of the generated plan requiring fix up is below:

After updating the location url, the Configuration plan looks like:

Deploying with the Configuration Plan with JDeveloper

Now we are ready to deploy the composite to the development environment.  When deploying from JDeveloper, select the checkbox indicating that we will use the config plan, then select the plan you would like to use.   Then proceed with the remaining deployment screens.  The Config plan you selected will perform the required fix up.

Using a Specific Plan with FlexDeploy

To use the configuration plan with Flexagon’s FlexDeploy, generate the plan as described above.  In the SOA deploy workflow, open the soaDeploy step and configure the configuration plan.  In the example below, I use the Environment Code (DEV in this case) and the project name (CreateOrderService in this case).  The plugin will then apply this plan when you deploy from FlexDeploy.

Using Workflow Properties in a Config Plan

FlexDeploy provides the ability to create user-defined workflow properties that can be set based on environment.  In this case, I defined a property named SOAURLPREFIX.   We now only need one configuration plan for the composite.  When using these workflow properties, I would change the name of the config plan to be CreateOrderService_configplan.xml (it is not specific to an environment anymore!).  This property replacement will handle mapping the URL for each environment.  Central administrators can manage the actual values in FlexDeploy instead of each developer setting the actual URL in the config plan, you just reference the property name.

I now update my config plan to use this property.  To reference a property in your config plan use ${{…}} to delimit the property name.  The updated config plan is below:

Then we can configure this property in FlexDeploy on the DEV environment for the SOA instance:

Useful link

Oracle 12C documentation:

https://docs.oracle.com/middleware/1213/soasuite/develop-soa/soa-composite-deploy-jdev.htm

Download the Datasheet

Greg Draheim

I am a Principal Architect with Flexagon focused on providing DevOps and CD solutions for microservices. Over the past 25 years, I have architected and implemented complex integration systems and recognize the value of automating both testing and deployment. I have also leveraged my integration expertise to assist in the design and implementation of FlexDeploy's integration plugins.

More posts by Greg Draheim
    

2 Comments

  • RAVISH KUMAR JHA says:

    Hello Greg,

    Thanks for the article. Its indeed very useful.

    One thing I have noticed though that config plan doesn’t work on Cloud adapter’s .jca files. E.g. Let’s say in .jca file for Salesforce adapter it using below property :

    If I want to replace “SFDC-XYZ-KEY” by “SFDC-ABC-KEY” using wsdlAndSchema/searchReplace then its not working and after deployed the value remains as same as what is mentioned in .jca file.

    Did you come cross this scenario ever and how did you get over it?

  • Greg Draheim says:

    It surprises me that config plan is not working on a jca file. A couple of options if you cannot get the config plan to replace a specific value is:

    1. With FlexDeploy, you can use workflow properties and replace ${{PROPERTYNAME}} in a jca file without using a configuration plan.

    2. If you are not using FlexDeploy, a simple script can expand the sar, replace values (using a tools like sed), and re-jar the sar file.

Leave a Reply

Your email address will not be published. Required fields are marked *