8 Generating Deployment Plans and Deploying Artifacts

8.1 Introduction

AIA Project Lifecycle Workbench contains the integration specific details of the PIP or direct integrations, like the business tasks involved and the service components involved in each business task. Project Lifecycle Workbench supports only Oracle SOA artifacts which are created using FMW technologies such as BPEL or Mediator. These are called native artifacts and they are supported by AIA Foundation Pack tools such as Project Lifecycle Workbench, Harvester, Deployment Generator, and AID. When a composite is harvested, the annotation details of the composite are stored in the lifecycle database. The Bill of Material (BOM) of a PIP can be exported as BOM.xml using the Generate BOM feature in AIA Lifecycle Workbench. The existing artifacts can be modified and new natively supported artifacts can be added using AIA Lifecycle Workbench and a BOM.xml file can be generated.

The BOM.xml file consists of a list of artifacts that constitute a project and their ensuing annotations. Deployment Plan Generator reads the annotations and other information in BOM.xml file as input and generates deployment plan for the selected services. The deployment plan is used to perform the required configurations and deploy the services to the Fusion Middleware server using AID.

Figure 8-1 illustrates the flow for extending and deploying native artifacts.

Figure 8-1 Extending and Deploying Native Artifacts

You may need to deploy artifact types that are not supported by the Project Lifecycle Workbench and AIA Harvester. For instance, your integration may require the use of Java Web Services or interaction with third party services. In such cases, the deployment of those artifacts is supported by invoking custom scripts such as Shell scripts or ANT scripts from the Deployment plan. AID supports deployment of these supplementary artifacts. However, you must modify and add new non-native artifacts outside AIA Lifecycle Workbench.

Figure 8-2 illustrates the flow for extending and deploying non-native artifacts.

Figure 8-2 Extending and Deploying Non-native Artifacts

The following files are used in the deployment plan generation and deployment of AIA artifacts:

• <PIP_Name>DP.xml: This deployment plan file orchestrates the deployment of natively supported services and the configuration required for those services. Oracle AIA delivered PIPs usually have their deployment plans under AIA_HOME/PIPS/<pip name>/DeploymentPlans. Oracle AIA Foundation Pack customers are also advised to save their Deployment plans under the corresponding folder in the AIA_HOME/PIPS/ folder.

• <PIP_Name>SupplementaryDP.xml: Supplementary Deployment Plan contains configuration required for deployment of non native services. A PIP installation may or may not constitute the deployment of non-native artifacts. If it does, then the corresponding PIP supplies a Supplementary deployment plan at AIA_HOME/PIPS/<pip name>/DeploymentPlans.

• <PIP_Name>HS.xml:HS is a Harvester Settings file that harvests the deployed services to OER for a PIP project from the SOA run time. When a PIP is installed, the file can be located in AIA_HOME/PIPS/<pip name>/HarvesterSettings folder.

For more information about the Harvester settings file, see Chapter 5, "Harvesting Oracle AIA Content"

You can also generate deployment plans for ODI and include them in your deployment plans. For information on generating a deployment plan for ODI refer to Chapter 9, "Generating a Deployment Plan for ODI"

8.2 Extending Deployment Plans

Oracle AIA Foundation Pack provides a comprehensive mechanism to extend the Oracle shipped deployment plans. Most often, integration scenarios require modifications to AIA-shipped integrations or PIPs before they are deployed to customer environments. The modifications include changes to PIP functionality, and they often manifest on the changes to PIP deployment configurations. This section discusses how to modify or extend both native and non-native artifacts that are shipped with Oracle AIA.

8.3 Generating Deployment Plans

This section discusses the input required for Deployment Plan Generator, the process for generating the deployment plan, and the output generated

8.4 Generating Conditional Deployment Plans

You can set conditions to your deployment plans for the following scenarios:

• Choose artifacts to be deployed depending on the version of participating application.

• Define conditional logics depending on deployments and sequences for two different projects. For example, project A may lay out certain artifacts which must be conditionally kept or removed while deploying project B.

You must define the conditions in a deployment policy file. The deployment policy file supports all the artifact types in configurations and deployments except the adapter types (JmsAdapter, DbAdapter, AqAdapter, OracleAppsAdapter). However, for composites you must define an additional condition.

The deployment policy file is passed as an additional input to AID through -DDeploymentPolicyFile variable. When AID begins execution, it checks if -DDeploymentPolicyFile variable is passed as a command line input. When it finds the variable, AID creates a copy of the original deployment plan with the name <Original_DP_Name>-Conditional.xml. AID checks whether there are changes required to the original deployment plan based on inputs from the deployment policy file, picks up the modified deployment plan and executes them during installation.

You must create the deployment policy file manually. The sample deployment plan shown in Example 8-1 will help you understand deployment policy file.

<DeploymentPlan component="AIADemo" version="3.0">
       <PreInstallScript>
       </PreInstallScript>
       <Configurations>
              <Datasource name="FODDS" jndiLocation="jdbc/fodDS" wlserver="fp"
                          
database="participatingapplications.AIADemo.db.aiademoparticipatingapp" 
action="create"
                          xa-enabled="true"/>
              <JMSResource wlserver="fp" jmsResourceType="ConnectionFactory"
                           jmsResourceName="AIADemoCF"
                           jmsresourcejndi="jms/aia/AIADemoCF"
                           action="create" jmsModuleName="AIAJMSModule"
                           jmsSubDeploymentName="AIASubDeployment"/>
      </Configurations>
       <Deployments>
              <Application name="WebServices_WebLogicFusionOrderDemo_
CreditCardAuthorization"
                           filelocation="${AIA_
HOME}/samples/AIADemo/Services/CreditCardAuthorization/deploy/WebServices_
WebLogicFusionOrderDemo_CreditCardAuthorization.war"
                           wlserver="fp" failonerror="true" action="deploy"/>
              <Composite compositeName="AIADemoUpdateSalesOrderEBS"
                         compositedir="${AIA_
HOME}/samples/AIADemo/EBS/AIADemoUpdateSalesOrderEBS"
                         revision="1.0" wlserver="fp" action="deploy"/>
              <Composite 
compositeName="AIADemoSyncCustomerPartyListCRMProvDBAdapter"
                         compositedir="${AIA_
HOME}/samples/AIADemo/Adapters/AIADemoSyncCustomerPartyListCRMProvDBAdapter"
                         revision="1.0" wlserver="fp" action="deploy"/>
       </Deployments>
</DeploymentPlan>

If this is your deployment plan file, you must create a deployment policy file as illustrated in Example 8-2.

<DeploymentPlan component="AIADemo" version="3.0">
<Conditions component="AIADemo" version="3.0">
   <if>
      <equals arg1="${pip.foo.boo}" arg2="11.5.7"/>
      <then>
          <UpdateDP artifacttype="Datasource" name="FODDS" action="no-action" />
          <UpdateDP artifacttype="JMSResource" name="AIADemoCF" 
action="no-action" />
          <UpdateDP artifacttype="Composite" name="AIADemoUpdateSalesOrderEBS" 
action="no-action" />
      </then>
   </if>
</Conditions>
</DeploymentPlan>

When AID executes the policy file, the contents between <Conditions> tag will be written to a temporary build file and executed. Ensure that the contents inside conditions are valid ant tasks. A policy file can have only one conditions tag and all the conditions should be written inside this tag.

8.5 Deploying Artifacts

The deployment of the artifacts is done by AID. AID takes the deployment plan and AIAInstallProperties.xml file as input. Based on the tags specified in the deployment plan, AID configures and deploys the artifacts onto the server.

AID supports three types of deployment plans:

• Main Deployment Plan

• Supplementary Deployment Plan

• Custom Deployment Plan

Main Deployment Plan is autogenerated by the Deployment Plan Generator whereas Supplementary Deployment Plan and Custom Deployment Plan are handcoded. Support to add custom deployment tags to the main deployment plan is available through Pre-Install and Post-Install sections in the Deployment plan. However, the problem with using these sections is that the deployment plan may not be upgrade-safe. To mitigate the issue, supplementary and custom deployment plans are introduced. The supplementary deployment plan is used mostly by the internal PIP development team. You will use custom deployment plan to meet the requirement of non-native artifact deployment plan.

The execution sequence of deployment plans followed by AID is Main Deployment Plan -> Supplementary Deployment Plan -> Custom Deployment Plan. Here Supplementary Deployment Plan and Custom Deployment Plan are optional.

The following sections show the deployment commands for various deployment scenarios.

ant -f <AIA_HOME>\Infrastructure\Install\AID\AIAInstallDriver.xml 
-DPropertiesFile=<AIA_HOME>\aia_instances\<AIA_Instance_
name>\config\AIAInstallProperties.xml  -DDeploymentPlan=<AIA_HOME>\pips\<PIP_
name>\DeploymentPlans\<PIP_name>DP.xml  -DSupplementaryDeploymentPlan =<AIA_
HOME>\pips\<PIP_name>\DeploymentPlans\<PIP_name>SupplementaryDP.xml  
-DDeploymentPolicyFile=<AIA_HOME>\pips\<PIP_name>\DeploymentPlans\<PIP_
name>ConditionalPolicy.xml

ant -f <AIA_HOME>\Infrastructure\Install\AID\AIAInstallDriver.xml 
-DPropertiesFile=<AIA_HOME>\aia_instances\<AIA_Instance_
name>\config\AIAInstallProperties.xml  -DDeploymentPlan=<AIA_HOME>\pips\<PIP_
name>\DeploymentPlans\<PIP_name>CustomDP.xml  -DSupplementaryDeploymentPlan 
=<AIA_HOME>\pips\<PIP_name>\DeploymentPlans\<PIP_name>SupplementaryDP.xml  
-DDeploymentPolicyFile=<AIA_HOME>\pips\<PIP_name>\DeploymentPlans\<PIP_
name>ConditionalPolicy.xml

ant -f <AIA_HOME>\Infrastructure\Install\AID\AIAInstallDriver.xml 
-DPropertiesFile=<AIA_HOME>\aia_instances\<AIA_Instance_
name>\config\AIAInstallProperties.xml  -DDeploymentPlan=<AIA_HOME>\pips\<PIP_
name>\DeploymentPlans\<PIP_name>DP.xml  -DSupplementaryDeploymentPlan =<AIA_
HOME>\pips\<PIP_name>\DeploymentPlans\<PIP_name>CustomSupplementaryDP.xml  
-DDeploymentPolicyFile=<AIA_HOME>\pips\<PIP_name>\DeploymentPlans\<PIP_
name>ConditionalPolicy.xml

ant -f <AIA_HOME>\Infrastructure\Install\AID\AIAInstallDriver.xml 
-DPropertiesFile=<AIA_HOME>\aia_instances\<AIA_Instance_
name>\config\AIAInstallProperties.xml  -DDeploymentPlan=<AIA_HOME>\pips\<PIP_
name>\DeploymentPlans\<PIP_name>CustomDP.xml  -DSupplementaryDeploymentPlan 
=<AIA_HOME>\pips\<PIP_name>\DeploymentPlans\<PIP_name>SupplementaryDP.xml  
-DDeploymentPolicyFile=<AIA_HOME>\pips\<PIP_name>\DeploymentPlans\<PIP_
name>ConditionalPolicy.xml -l <AIA_HOME>\pips\<PIP_
name>\DeploymentPlans\<PIPDeploymentPlanName>.log

ant -f <AIA_HOME>\Infrastructure\Install\AID\AIAInstallDriver.xml 
-DPropertiesFile=<AIA_HOME>\aia_instances\<AIA_Instance_
name>\config\AIAInstallProperties.xml  -DDeploymentPlan=<AIA_HOME>\pips\<PIP_
name>\DeploymentPlans\<PIP_name>DP.xml  -DSupplementaryDeploymentPlan =<AIA_
HOME>\pips\<PIP_name>\DeploymentPlans\<PIP_name>SupplementaryDP.xml 
-DCustomDeploymentPlan=<AIA_HOME>\pips\<PIP_name>\DeploymentPlans\<PIP_
name>CustomDP.xml> -DDeploymentPolicyFile=<AIA_HOME>\pips\<PIP_
name>\DeploymentPlans\<PIP_name>ConditionalPolicy.xml

8.6 Undeploying Services

The undeployment plan is generated at the same location as the deployment plan with the name <PIP_Name>UndeployDP.xml. The undeployment plan is generated only for native artifacts modified through the Project Lifecycle Workbench. This contains undeploy tasks for all the services deployed and the configurations done as part of Deployment Plan. The undeployment plan is executed using the AID.

The undeployment command is similar to the deployment plan command except for the Deployment Plan input argument and an additional argument “Uninstall”.

For example, if you have used the following command to deploy modified native artifacts:

ant -f <AIA_HOME>\Infrastructure\Install\AID\AIAInstallDriver.xml 
-DPropertiesFile=<AIA_HOME>\aia_instances\<AIA_Instance_
name>\config\AIAInstallProperties.xml  -DDeploymentPlan=<AIA_HOME>\pips\<PIP_
name>\DeploymentPlans\<PIP_name>DP.xml  -DSupplementaryDeploymentPlan =<AIA_
HOME>\pips\<PIP_name>\DeploymentPlans\<PIP_name>SupplementaryDP.xml  
-DDeploymentPolicyFile=<AIA_HOME>\pips\<PIP_name>\DeploymentPlans\<PIP_
name>ConditionalPolicy.xml

then the undeployment command will be:

ant -f <AIA_HOME>\Infrastructure\Install\AID\AIAInstallDriver.xml 
-DPropertiesFile=<AIA_HOME>\aia_instances\<AIA_Instance_
name>\config\AIAInstallProperties.xml Uninstall -DDeploymentPlan=<AIA_
HOME>\pips\<PIP_name>\DeploymentPlans\<PIP_name>UndeployDP.xml

However, for non-native artifacts you must generate the undeployment plan manually. You must take a copy of the supplementary deployment plan and name it <PIP_Name>UndeploySupplementaryDP.xml or <PIP_Name>UndeployCustomSupplementaryDP.xml depending on the supplementary deployment plan name. In the new deployment plan change the action attributes of all the tasks from “deploy” to “undeploy” or from “create” to “delete”.