Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 17 Next »

Configuration plans are used to automatically cleanup environment specific information in a composite.xml file during deployment.  Information that can be changed includes URL hosts and retry values, to name a few items. Configuration plans can utilize property replacement to utilize FlexDeploy properties.  Utilizing FlexDeploy properties allows configuration plans to become re-usable.

The configuration plans that were saved to the ./artifacts/configPlans, during the build step, will be copied to the ./temp directory. Configuring the Deploy Config Plan input can be either an absolute path to a global configuration plan or a relative path to one of the copied configuration plans based on the ./temp directory.

Configuration plan can be specified using SOA Deploy Config Plan project property and/or Deploy Config Plan plugin input. The plugin input will take precedence over the project property.

There are two approaches to Configuration Plans:

  1. Composite specific

    A composite specific configuration plan is created directly in the composite project using the JDev wizard.  Right click on the composite.xml file and select "Generate Config Plan".  Provide the plan a name and it is recommended that you add the FlexDeploy environment code in the name.  When a configuration plan is generated the file will contain most of the composite.xml content, there will be many lines that contain static content and will change infrequently.  Removing all static content from the file will keep the configuration plan easier to update.  If static content is changed in the composite.xml file but the configuration plan is unchanged, the configuration plan will overwrite the composite.xml changes on deployment.  This approach will require a configuration plan for each environment for each composite since the goal is to cleanup host names as we progress through environments.  The two blocks below show examples of what a configuration plan would look like for a DEV (hard code the host name) and QA (utilizing FlexDeploy property replacement) environment

    DEV Configuration Plan
    <?xml version="1.0" encoding="UTF-8"?>
    <SOAConfigPlan xmlns:jca="http://platform.integration.oracle/blocks/adapter/fw/metadata" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" xmlns:edl="http://schemas.oracle.com/events/edl" xmlns="http://schemas.oracle.com/soa/configplan">
       <composite name="testcall">
          <reference name="test">
             <!--Add search and replace rules for the binding properties-->
             <binding type="ws">
                <attribute name="location">
                   <replace>http://DEV_HOST_NAME:8001/soa-infra/services/default/test/test_client_ep?WSDL</replace>
                </attribute>
             </binding>
          </reference>
       </composite>
       <wsdlAndSchema name="Schemas/testcall.xsd|WSDLs/testcall.wsdl">
          <searchReplace>
             <search/>
             <replace/>
          </searchReplace>
       </wsdlAndSchema>
    </SOAConfigPlan>
    
    
    
    QA Configuration Plan
    <?xml version="1.0" encoding="UTF-8"?>
    <SOAConfigPlan xmlns:jca="http://platform.integration.oracle/blocks/adapter/fw/metadata" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" xmlns:edl="http://schemas.oracle.com/events/edl" xmlns="http://schemas.oracle.com/soa/configplan">
       <composite name="testcall">
          <reference name="test">
             <!--Add search and replace rules for the binding properties-->
             <binding type="ws">
                <attribute name="location">
                   <replace>http://${{FDSOA_SERVER_HOST}}:8001/soa-infra/services/default/test/test_client_ep?WSDL</replace>
                </attribute>
             </binding>
          </reference>
       </composite>
       <wsdlAndSchema name="Schemas/testcall.xsd|WSDLs/testcall.wsdl">
          <searchReplace>
             <search/>
             <replace/>
          </searchReplace>
       </wsdlAndSchema>
    </SOAConfigPlan>

    On the soaDeploy operation used in the deployment workflow, change the FDSOA_INP_DEPLOY_CFG_PLAN input to a groovy expression similar to:

    "./" + FD_ENVIRONMENT_CODE + "*_cfgplan.xml".  

    This will allow the workflow to remain re-usable across all composite deployments even though the configuration plans are specific to a composite.


  2. Shared (recommended method)

    A shared configuration plan provides the same functionality as a composite specific configuration plan but with the added benefit of not needing to remember to generate a configuration plan for new composites or new environments.  The shared configuration plan will be managed seperately from the composites and deployed independently to a common location on the servers.  With a shared configuration plan, utilizing FlexDeploy property replacement is a must.  Shared configuration files can be either environment specific or global across all environments due to the use of property replacement.

    You will notice that in the import section of the conguration plan, any host name is being replaced with a string "change to mds ref".  The reason is that when leveraging MDS or relative paths for XSDs or abstract WSDLs, there should be no references to the server.  When a developer forgets to clean up the composite correctly, this helps to remind them because the deploy will fail with a message that includes the string above.

    There may be other properties that need to be replaced based on your organization, which include endpointURI, oracle.webservices.auth.userid and oracle.webservices.auth.password, as examples.  These can be replaced utilizing the same pattern as above.

    Shared Configuration Plan
    <?xml version="1.0" encoding="UTF-8"?>
    <SOAConfigPlan xmlns:jca="http://platform.integration.oracle/blocks/adapter/fw/metadata" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" xmlns:edl="http://schemas.oracle.com/events/edl" xmlns="http://schemas.oracle.com/soa/configplan">
       <composite name="*">
          <import>
             <searchReplace>
    		    <search>localhost</search>
    			<replace>change to mds ref</replace>
    		 </searchReplace>
           </import>
    	  
    	  <reference name="*">
             <!--Add search and replace rules for the binding properties-->
             <binding type="ws">
                <attribute name="location">
    			    <searchReplace>
    				   <search>localhost</search>
    				   <replace>${{FDSOA_SERVER_HOST}}</replace>
    				</searchReplace>
                </attribute>
             </binding>
          </reference>
       </composite>
    </SOAConfigPlan>


    On the soaDeploy operation used in the deployment workflow, change the FDSOA_INP_DEPLOY_CFG_PLAN input to a groovy expression similar to following if the shared plan is environment specific:

    "/shared/location/" + FD_ENVIRONMENT_CODE + "*_cfgplan.xml"

    If the shared plan is global, use an expression like: 

    "/shared/location/acme_cfgplan.xml"

    This will allow the workflow to remain re-usable across all composite deployments even though the configuration plans are specific to a composite.

  • No labels