6 Performing Post-deployment Tasks

This chapter describes the tasks you perform after deploying AIA cloud native.

Integrating Applications with AIA Cloud Native

This section describes procedures for integrating the following cloud native applications with AIA cloud native:

Note:

Before proceeding with integrating these applications, ensure that all web user interfaces of these applications are available for integration.
See Application Integration Architecture Compatibility Matrix for supported and recommended versions of these applications.

Deploying Custom Components

This section describes how to deploy custom components.

You can deploy the following:

Deploying Custom AIA Artifacts

The deployment of the artifacts is done by AIA Installation Driver (AID). AID takes the deployment plan and the 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 the following deployment plans:
  • Main Deployment Plan
  • Supplementary Deployment Plan
  • Custom Deployment Plan

Main Deployment Plan is auto-generated 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 by the internal Pre-Built Integration development team. Use custom deployment plan to meet the requirement of non-native artifact deployment plan.

The running sequence of deployment plans followed by AID is as follows:
  1. Main Deployment Plan
  2. (Optional) Supplementary Deployment Plan
  3. (Optional) Custom Deployment Plan

Note:

To facilitate durability across upgrades and patch updates, place the custom modified files in a directory path different from AIA-shipped PIP_Name DP.xml and PIP_Name SupplementaryDP.xml.

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

Deploying AIA Shipped Native Artifacts and Non-native Artifacts

This scenario does not involve any customizations. The following command takes the main deployment plan and the supplementary deployment plan which are shipped with the Pre-Built Integration installer as input.

Run this command inside the domain admin pod:
source $COMMS_AIA_HOME/comms_home/bin/commsenv.sh
ant -f $SOA_HOME/aiafp/Install/AID/AIAInstallDriver.xml \
-DPropertiesFile=$VOLUME_DIR/domains/$DOMAIN_NAME/soa/aia/bin/AIAInstallProperties.xml \
-DDeploymentPlan=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameDP.xml  \
-DSupplementaryDeploymentPlan=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameSupplementaryDP.xml  \
-DDeploymentPolicyFile=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameConditionalPolicy.xml
Deploying Modified AIA-shipped Artifacts

This section describes how to deploy modified AIA-shipped native and non-native artifacts.

Deploying Modified Native Artifacts and Original Non-native Artifacts

For modified native artifacts scenario, re-harvest the modified artifacts and regenerate the deployment plan, and name it as PIP_Name CustomDP.xml. Pass this as the main deployment plan, instead of the shipped deployment plan.

Run the following AID command inside the domain admin pod:
source $COMMS_AIA_HOME/comms_home/bin/commsenv.sh
ant -f $SOA_HOME/aiafp/Install/AID/AIAInstallDriver.xml \
-DPropertiesFile=$VOLUME_DIR/domains/$DOMAIN_NAME/soa/aia/bin/AIAInstallProperties.xml \
-DDeploymentPlan=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameCustomDP.xml  \
-DSupplementaryDeploymentPlan=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameSupplementaryDP.xml  \
-DDeploymentPolicyFile=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameConditionalPolicy.xml

Deploying Original Native Artifacts and Modified Non-native Artifacts

For the original native artifacts and modified non-native artifacts scenario, copy the contents of the shipped supplementary DP to a new file and name it as PIP_Name CustomSupplementaryDP.xml. Modify this file with the customizations. This is passed as the supplementary deployment plan, instead of the shipped supplementary DP.

Run the following AID command inside the domain admin pod:
source $COMMS_AIA_HOME/comms_home/bin/commsenv.sh
ant -f $SOA_HOME/aiafp/Install/AID/AIAInstallDriver.xml \
-DPropertiesFile=$VOLUME_DIR/domains/$DOMAIN_NAME/soa/aia/bin/AIAInstallProperties.xml \
-DDeploymentPlan=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameDP.xml  \
-DSupplementaryDeploymentPlan=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameCustomSupplementaryDP.xml  \
-DDeploymentPolicyFile=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameConditionalPolicy.xml
Deploying New or Custom Built Artifacts

This section discusses how to deploy newly added native and non-native artifacts.

Deploying Newly-added Native Artifacts and Original Non-native Artifacts

If you are introducing new native artifacts, harvest the new artifacts and regenerate the deployment plan for the new artifacts along with the shipped ones, and name it PIP_Name CustomDP.xml. Pass this as the main deployment plan, instead of the shipped deployment plan.

Run the following AID command inside the domain admin pod:

source $COMMS_AIA_HOME/comms_home/bin/commsenv.sh
ant -f $SOA_HOME/aiafp/Install/AID/AIAInstallDriver.xml \
-DPropertiesFile=$VOLUME_DIR/domains/$DOMAIN_NAME/soa/aia/bin/AIAInstallProperties.xml \
-DDeploymentPlan=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameCustomDP.xml  \
-DSupplementaryDeploymentPlan=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameSupplementaryDP.xml  \
-DDeploymentPolicyFile=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameConditionalPolicy.xml \
-l $COMMS_HOME/pips/PIP_name/DeploymentPlans/PIPDeploymentPlanName.log

Deploying Newly Added Non-native Artifacts

For new non-native artifacts scenario, add customizations to PIP_Name CustomDP.xml, which is an empty deployment plan shipped with the Pre-Built Integration. This custom plan is in the same location as the main plan. Pass this as Custom Deployment Plan to AID.

Run the following AID command inside the domain admin pod:
source $COMMS_AIA_HOME/comms_home/bin/commsenv.sh
ant -f $SOA_HOME/aiafp/Install/AID/AIAInstallDriver.xml \
-DPropertiesFile=$VOLUME_DIR/domains/$DOMAIN_NAME/soa/aia/bin/AIAInstallProperties.xml \
-DDeploymentPlan=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameDP.xml  \
-DSupplementaryDeploymentPlan=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameSupplementaryDP.xml  \
-DCustomDeploymentPlan=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameCustomDP.xml> \
-DDeploymentPolicyFile=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameConditionalPolicy.xml

The AIAInstallProperties.xml file contain the details of the AIA environment and is located at: $VOLUME_DIR/domains/$DOMAIN_NAME/soa/aia/bin/AIAInstallProperties.xml.

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 the Deployment Plan. The undeployment plan is run using the AID.

The undeployment command is similar to the deployment plan command except for the input argument and an additional argument "Uninstall". You run this command inside the domain admin pod.

For example, if you have used the following command to deploy modified native artifacts:
source $COMMS_AIA_HOME/comms_home/bin/commsenv.sh
ant -f $SOA_HOME/aiafp/Install/AID/AIAInstallDriver.xml \
-DPropertiesFile=$VOLUME_DIR/domains/$DOMAIN_NAME/soa/aia/bin/AIAInstallProperties.xml \
-DDeploymentPlan=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameDP.xml  \
-DSupplementaryDeploymentPlan=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameSupplementaryDP.xml  \
-DDeploymentPolicyFile=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameConditionalPolicy.xml
Then, the undeployment command would be:
source $COMMS_AIA_HOME/comms_home/bin/commsenv.sh
ant -f $SOA_HOME/aiafp/Install/AID/AIAInstallDriver.xml \
-DPropertiesFile=$VOLUME_DIR/domains/$DOMAIN_NAME/soa/aia/bin/AIAInstallProperties.xml Uninstall \
-DDeploymentPlan=$COMMS_HOME/pips/PIP_name/DeploymentPlans/PIP_nameUndeployDP.xml
However, for non-native artifacts, generate the undeployment plan manually:
  1. Copy the supplementary deployment plan and name it as PIP_Name UndeploySupplementaryDP.xml or PIP_Name UndeployCustomSupplementaryDP.xml, depending on the supplementary deployment plan name.
  2. In the new deployment plan, change the action attributes of all the tasks from "deploy" to "undeploy" or from "create" to "delete".

Installing SSL Certificates

To install SSL certificates:

Note:

This procedure automates the process of importing certificates to kss-based keystore. If you wish to use jks-based keystore, set it up manually.
  1. Create keystore credentials by running the following commands:

    Note:

    Ensure that certificates are available in the $AIA_DIR/oc-cn-aia-comms/helm-charts/aia-comms-chart/charts/aia-comms-certs/certificates directory and that proper management policies are used to store the private keys. 
    cd $AIA_DIR/oc-cn-aia-comms/scripts/  
./create-keystore-secret.sh -h
usage: ./create-keystore-secret.sh -k keystore -c custTrust -i custIdentity [-d domainUID] [-n namespace] [-h]
  -k  pasword for  KeyStore, must be specified.
  -c  password for  Cust Trust, must be specified.
  -i  password for Cust Identity , must be specified.
  -d domainUID, optional. The default value is soainfra. If specified, the secret will be labeled with the domainUID unless the given value is an empty string.
  -n namespace, optional. Use the soans namespace if not specified
  -h Help
  2. Run the following command, which creates a Kubernetes secret:
    kubectl -n soa_namespace create secret generic secret_name --from-file=certificates
  3. Update values in the following files:
    • oc-cn-aia-comms/helm-charts/aia-comms-chart/values.yaml
    • oc-cn-aia-comms/helm-charts/aia-comms-chart/charts/aia-comms-certs/values.yaml
    The values to be updated are:
    • name: The Keystore name on which the operation is to be performed. For example, custTrust or CustIdentity.
    • identityKeyStoreName: The Keystore name of the Identity Keystore. For example, custIdentity.
    • trustKeyStoreName: The Keystore name of Custom Trust Keystore. For example, custTrust.
    • type: The type of the certificate which is to be imported, updated, and deleted. For example, TrustedCertificate.
    • For each Siebel certificate and OSM certificate to be imported, specify the following:
      • fileName: The certificate filename which is to be imported. This should be available in the aia-comms-chart/charts/aia-comms-certs/certificates directory.
      • alias: The alias name.
      • operation: The supported operation types are: import, delete, and update. Leave this value empty or commented in case no operation is required to be performed on either OSM certificate or Siebel certificate.

      Note:

      The helm chart execution supports adding, updating, and deleting the certificate. The mandatory fields are:
      • import: alias, fileName, operation
      • delete: alias, operation
      • update: alias, fileName (the file name of the new certificate to be updated), operation
  4. After the aia-comms-ssl-certificate-job completes, restart the domain to import, update, or delete the OSM certificate, Siebel certificate, or both certificates as specified in the values.yaml file of the chart.
    cd $AIA_DIR/oc-cn-aia-comms/helm-charts
 helm install aia-comms-certs\    
    aia-comms-chart/charts/aia-comms-certs/ \ 
    --namespace namespace \     
    --values ./aia-comms-chart/values.yaml \    
    --values ./aia-comms-chart/charts/aia-comms-certs/values.yaml
  5. Restart the domain.

Updating Files in AIA MDS

To update multiple files at once in AIA MDS:

  1. Update the following values.yaml files as per your requirement:

    $AIA_DIR/oc-cn-aia-comms/helm-charts/aia-comms-chart/values.yaml

    $AIA_DIR/oc-cn-aia-comms/helm-charts/aia-comms-chart/charts/aia-comms-update-mds/values.yaml

    See Global Parameters for details about the parameters.

    Table 6-1 Parameters in the values.yaml

    Parameter Description Example
    fileList List of files with their full paths in MDS.

    Note: This is the destination path where files need to be uploaded in MDS and not a source path where files are present in AIA PV → /u01/shared/mds. 

    soa/configuration/default/AIAConfigurationProperties.xml
    apps/AIAMetaData/config/AIAInstallProperties.xml
  2. Upload the files to AIA PV:
    kubectl cp File_to_be_Uploaded_in_MDS SOA_Admin_Pod:/u01/shared/mds/-n SOA_Namespace
  3. Run the following command:
    $ cd $AIA_DIR/oc-cn-aia-comms/helm-charts/
$ helm install aia-comms-update-mds \
     aia-comms-chart/charts/aia-comms-update-mds/ \
     --namespace namespace \
     --values ./aia-comms-chart/values.yaml \
     --values ./aia-comms-chart/charts/aia-comms-update-mds/values.yaml
  4. Wait till the aia-comms-update-mds-job completes.
  5. Restart the domain.

    This validates the path in MDS.

Validating the AIA Cloud Native Deployment

To validate your AIA cloud native deployment:
  1. Verify the logs:
    1. Run the following command:
      kubectl exec -it admin_server -n namepspace –- bash

cd $ORACLE_HOME/user_projects/domains/domain_name
    2. Verify there are no errors in the log files.

    Note:

    If you want to verify the PIP deployment log, refer to the below log files within the admin server pod:
    • /u01/shared/logs/runconfig.log
    • /u01/shared/logs/setupo2c.log
    As these logs contain sensitive information, delete them once the validation is complete.
  2. Verify the deployment of composites for Siebel CRM, OSM, and BRM. See "Verifying Composite Deployment" in the AIA Installation Guide for details. To generate a diagnostic report, see "Generating a Diagnostic Report."
  3. Test the order flow to check connectivity between Siebel, OSM, and BRM.