Hi there “Process Automation” fans,

Welcome to a new installment of “Process Automation” tips.

An interesting question passed by a LinkedIn connection. It’s related to the cloning of service containers in an organization. Normally, I would search my own blog content for an answer, but I came to the conclusion this feature never passed our content stream. Reading the documentation it’s also one topic overlooked, but we put this straight in this post. Let’s find out the magic behind the ANT-task cloneservicecontainers…

Let’s get right into it…

A note upfront as “cloning” service containers is NOT from one organization to another organization (what some expect!); It’s within the same organization for a second platform instance/node! Building a similar service container in another organization, you simply use createservicecontainer which you can clone again!

cloneservicecontainers and createservicecontainer are part of Command Line Interface (CLI) automation with ANT tasks; read about it here.

In the past, we already played with these ANT-tasks:

• deployapplicationpackage and undeployapplicationpackage
• createservicegroup and deleteservicegroup
• createconnectionpoint and deleteconnectionpoint
• createservicecontainer and deleteservicecontainer
• createdatabaseconfiguration and deletedatabaseconfiguration

However, there is one missing in action: cloneservicecontainers!

I have my VM up and running where we first need to prepare our ANT-environment. It’s a simple RHEL command: sudo yum install -y ant

To check if all is fine, run ant -version with an output like this: Apache Ant(TM) version 1.10.5 compiled on December 13 2018

Next, we’ll need to prepare our VM with some variables, so the anttasks.jar (see below) is “aware” of our OPA environment:

1
2
3
4
5
6

export CORDYS_HOME=/opt/opentext/ProcessAutomationCE/defaultInst
export PATH=$PATH:$CORDYS_HOME/bin
export CLASSPATH=$CLASSPATH:/opt/opentext/ProcessAutomationCE/defaultInst/cordyscp.jar
export JAVACMD=/opt/jdk-21.0.1/bin/java
export JAVA_HOME=/opt/jdk-21.0.1
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/jdk-21.0.1/lib/server:/opt/opentext/ProcessAutomationCE/defaultInst/lib

ANT works with a (default) build.xml file. You see its content below, and we can inject it with a properties file for variables within the ANT-build. Run vi ~/test.properties and provide these properties:

1
2
3
4
5

cordys.server=opa.mydomain.com
cordys.port=8080
cloneservicecontainers.containerNameSuffix=_node2
cloneservicecontainers.sourceNodeName=opa
cloneservicecontainers.targetNodeName=opa

Adjust the properties to your own needs!

Now we can create a new build file via vi ~/build.xml with this content part:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

<project basedir="." default="info" name="Test-Antscripts">
    <!-- Run tests based on these properties -->
    <property file="test.properties"/>
    <!-- Add the task definition to include the custom tasks -->
    <property environment="env"/>
    <property name="bop.install.dir" value="${env.CORDYS_HOME}"/>
    <path id="anttask.classpath">
            <pathelement location="${bop.install.dir}/components/anttasks/anttasks.jar"/>
    </path>
    <taskdef resource="com/cordys/deployment/ant/taskdef.xml">
            <classpath refid="anttask.classpath"/>
    </taskdef>
    <!-- call the tests -->
    <target name = "info">
        <echo>${bop.install.dir}/components/anttasks/anttasks.jar</echo>
        <echo>Java/JVM version: ${ant.java.version}</echo>
        <echo>Java/JVM detail version: ${java.version}</echo>
        <echo>PORT: ${cordys.port}</echo>
        <echo>SERVER: ${cordys.server}</echo>
    </target>
    <target name="testCloneserviceContainers">
        <cloneservicecontainers containerNameSuffix="${cloneservicecontainers.containerNameSuffix}" sourceNodeName="${cloneservicecontainers.sourceNodeName}" targetNodeName="${cloneservicecontainers.targetNodeName}">
            <searchCriteria>
                <!--Use asterisk for wildcards; include/exclude are repeating-->
                <organizations>
                    <include>opa_tips</include>
                    <exclude>system</exclude>
                    <exclude>whatever*</exclude>
                </organizations>
                <!--Remove <serviceGroups> to clone all services within the groups; below we define what to include/exclude-->
                <serviceGroups>
                    <include>sg_appserver</include>
                    <exclude>Collaborative Workspace</exclude>
                    <exclude>Log*</exclude>
                </serviceGroups>
            </searchCriteria>
        </cloneservicecontainers>
    </target>
</project>

It’s no rocket science; just read it to understand its content and adjust where applicable for your environment (ask your questions in the comments below)

Once ready, save the content, move into the home directory with cd ~, and run ant. It will run the (default) target name ‘info’. ant info gives the exact same output! Next is calling our other target with ant testCloneserviceContainers to clone a service container. If you don’t have the included organization opa_tips and don’t have the included service group sg_appserver nothing will happen!

However, if you create a new service container in the ‘System Resource Manager’ artifact with this input in organization opa_tips (in my case)…

• Application connector: Application Server Connector
• Service group name: sg_appserver
  • Mark all the web service interfaces!
• Service container name: sc_appserver
  • With an automatic startup
  • Assigned to the OS process (recommendation by OpenText PS)

…and rerun the ANT-task, you should be fine with this end result:

Is this a valid scenario? Well, nope! But if you have a second OPA node, you can update the targetNodeName with the correct second node name in the properties file!

That’s a clony “DONE” where we nailed our final ANT-task target name to the wall with a fascinating outcome. You see that the complex can be made easy with some simple steps and a little guidance. We are now prepared for further automation of the OPA platform with ANT tasks to clone services for new nodes. We can continue life now, and we’ll pick it up next week in another great post about a relevant OpenText Process Automation Tips topic. Cheers!

Don’t forget to subscribe to get updates on the activities happening on this site. Have you noticed the quiz where you find out if you are also “The Process Automation guy”?