Open Editions

This post shows the necessary steps for the deployment of PAM/DM applications based on Kogito/Quarkus frameworks.

The focus of the post is on the ease of use of the "IBM BAMOE Kogito Operator" operator and how all operations can be performed via CLI in order to easily create a DevOps pipeline.

The applications used in this demo are present on the github repository at the links

only DM
https://github.com/marcoantonioni/MyKogitoDemoDm

BPMN and DM
https://github.com/marcoantonioni/MyKogitoDemoPam


The steps presented are as follows

1. Check operator presence and create namespace
2. Pull secret
3. OperatorGroup with specific target namespace
4. Subscription
5. KogitoBuild for DM application
6. KogitoRuntime for DM application
7. Tests DM
8. KogitoBuild for BPM application
9. KogitoRuntime for BPM application
10. Tests BPM
11. Conclusions


Prerequisites

- OpenShift cluster connected to the internet
- Credentials to access the Red Hat image registry
- A namespace in which to deploy operator and demo applications

Optional tool: jq


1. Check operator presence and create namespace

We use the IBM-supplied Kogito operator (bamoe-kogito-operator) found in the "Red Hat Operators" catalog.

To verify the presence of the operator we use the command

oc get packagemanifests bamoe-kogito-operator -n openshift-marketplace


If you want to use OpenShift console go to Operators menu and search for "businessautomation" the select the IBM distribution


Let's create the namespace where we will deploy operator and applications

TNS=my-demo-kogito-operator

oc new-project ${TNS}


2. Pull secret

We now create the secret to access the Red Hat image registry, and associate it with the builder and default with the 'pull' option

REGISTRY_URL=registry.redhat.io
REGISTRY_USER=<...your-user-id...>
REGISTRY_PWD=<...your-password...>

oc create -n ${TNS} secret docker-registry my-pull-secret --docker-server=${REGISTRY_URL} --docker-username=${REGISTRY_USER} --docker-password=${REGISTRY_PWD}
oc secrets -n ${TNS} link builder my-pull-secret --for=pull
oc secrets -n ${TNS} link default my-pull-secret --for=pull

We are now ready to configure the operator.


3. OperatorGroup with specific target namespace

We set the name of the operator group, we reuse the environment variables previously set.
We create the CR that defines the OperatorGroup

OG_NAME=my-kogito-operator

echo "
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  generateName: my-kogito-operator-
  name: ${OG_NAME}
  namespace: ${TNS}
spec:
  targetNamespaces:
  - ${TNS}
" | oc apply -f -


We verify the presence of the resource

oc get operatorgroups.operators.coreos.com -o yaml


4. Subscription

We set the operator name and the reference version, we reuse the environment variables previously set.
We create the CR that defines the Subscription to the operator.
If you have web access to the OpenShift cluster console go to "Operators> Installed Operators" and you will soon see the new operator called "IBM BAMOE Kogito Operator"





OPERATOR_NAME=bamoe-kogito-operator
CSV_VER="8.0.1-1"

echo "
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: ${OPERATOR_NAME}
  namespace: ${TNS}
spec:
  channel: 8.x
  installPlanApproval: Automatic
  name: bamoe-kogito-operator
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  startingCSV: bamoe-kogito-operator.${CSV_VER}
" | oc apply -f -


We verify the presence of the resource

oc get subscriptions.operators.coreos.com -o yaml


For further information and to check further new versions, refer to the links

IBM Business Automation Manager Open Editions 8.0 download document
https://www.ibm.com/support/pages/node/6596913

IBM Business Automation Manager 8 - Kogito Operator
ibm-bamoe/bamoe-kogito-rhel8-operator
https://catalog.redhat.com/software/containers/ibm-bamoe/bamoe-kogito-rhel8-operator/62d668813273d8696f48a10e?_ga=2.95087518.360948437.1667402606-142034002.1667402606


5. KogitoBuild for DM application

Now let's create the build configuration (KogitoBuild) which will automatically create the containerized image of our application.
The resources necessary for the build phase will be automatically created by the operator.
If you have web access to the OpenShift cluster console go to "Operators> Installed Operators> Kogito Build" and you will soon see the new build configuration named "my-kogito-demo-dm"


APP_NAME=my-kogito-demo-dm

echo "
kind: KogitoBuild
apiVersion: rhpam.kiegroup.org/v1
metadata:
  name: ${APP_NAME}
  namespace: ${TNS}
spec:
  gitSource:
    uri: 'https://github.com/marcoantonioni/MyKogitoDemoDm'
  type: RemoteSource
" | oc apply -f -

oc get kogitobuilds.rhpam.kiegroup.org -o yaml

oc get bc
oc get build
oc get is






and finally the builder log



oc get is ${APP_NAME} -o yaml
oc get pod | grep ${APP_NAME}-builder

# log of builder pod
oc logs -f $(oc get pod | grep ${APP_NAME}-builder | awk '{print $1}')


Wait for the creation of the "builder" image.
It may take a few minutes to complete the creation of the image

The containerized image of our application is now available

oc get ImageStream ${APP_NAME}
oc get ImageStreamTag ${APP_NAME}:latest


6. KogitoRuntime for DM application

Let's now create the runtime configuration of our Quarkus based application
If you have web access to the OpenShift cluster console go to "Operators> Installed Operators> Kogito Runtime" and you will soon see the new runtime configuration named "my-kogito-demo-dm"

echo "
apiVersion: rhpam.kiegroup.org/v1
kind: KogitoRuntime
metadata:
  name: ${APP_NAME}
  namespace: ${TNS}
spec:
  replicas: 1
  image: >-
    image-registry.openshift-image-registry.svc:5000/${TNS}/${APP_NAME}
  runtime: quarkus
" | oc apply -f -

oc get kogitoruntimes.rhpam.kiegroup.org -o yaml







The runtime configuration automatically creates also the 'Service' resource and the 'Route' resource





We store the url to access the service


URL=$(oc get route ${APP_NAME} -o jsonpath='{.spec.host}')



7. Tests DM

In a different shell set env var to follow the logs using 'oc logs' command

APP_NAME=my-kogito-demo-dm
oc logs -f $(oc get pod | grep Running | grep ${APP_NAME} | awk '{print $1}')

Then run the following commands

# health checks
curl -X GET ${URL}/q/health -H 'accept: application/json'
curl -X GET ${URL}/q/health/live -H 'accept: application/json'
curl -X GET ${URL}/q/health/ready -H 'accept: application/json'
curl -X GET ${URL}/q/health/group -H 'accept: application/json'
curl -X GET ${URL}/q/health/group/* -H 'accept: application/json'
curl -X GET ${URL}/q/health/well -H 'accept: application/json'
curl -X GET ${URL}/q/health/started -H 'accept: application/json'

# ping
curl -s -w"\n" -X GET ${URL}/ping

# set the service name (in this example the DMN rule service)
SERVICE_NAME=ValidateRequest

# get the rule model
curl -s -X GET -H 'accept: application/xml' ${URL}/${SERVICE_NAME}

# run a request with requestor values that will be accepted
curl -s -X POST ${URL}/${SERVICE_NAME} -H 'accept: application/json' -H 'Content-Type: application/json' -d '{ "RequestData": { "requestorName": "Marco", "requestorAge": 50, "amount": 10000 } }' | jq .

# run a request with requestor values that will be rejected
curl -s -X POST ${URL}/${SERVICE_NAME} -H 'accept: application/json' -H 'Content-Type: application/json' -d '{ "RequestData": { "requestorName": "baby", "requestorAge": 10, "amount": 10000 } }' | jq .


8. KogitoBuild for BPM application

Now let's create the build configuration (KogitoBuild) which will automatically create the containerized image of our application.
The resources necessary for the build phase will be automatically created by the operator.
If you have web access to the OpenShift cluster console go to "Operators> Installed Operators> Kogito Build" and you will soon see the new build configuration named "my-kogito-demo-pam"


APP_NAME=my-kogito-demo-pam

echo "
kind: KogitoBuild
apiVersion: rhpam.kiegroup.org/v1
metadata:
  name: ${APP_NAME}
  namespace: ${TNS}
spec:
  gitSource:
    uri: 'https://github.com/marcoantonioni/MyKogitoDemoPam'
  type: RemoteSource
" | oc apply -f -

oc get kogitobuilds.rhpam.kiegroup.org -o yaml

oc get bc
oc get build
oc get is

oc get is ${APP_NAME} -o yaml
oc get pod | grep ${APP_NAME}-builder

# log of builder pod
oc logs -f $(oc get pod | grep ${APP_NAME}-builder | awk '{print $1}')


Wait for the creation of the "builder" image.
It may take a few minutes to complete the creation of the image

The containerized image of our application is now available


oc get ImageStream ${APP_NAME}
oc get ImageStreamTag ${APP_NAME}:latest


9. KogitoRuntime for BPM application

Let's now create the runtime configuration of our Quarkus based application
If you have web access to the OpenShift cluster console go to "Operators> Installed Operators> Kogito Runtime" and you will soon see the new runtime configuration named "my-kogito-demo-pam"


echo "
apiVersion: rhpam.kiegroup.org/v1
kind: KogitoRuntime
metadata:
  name: ${APP_NAME}
  namespace: ${TNS}
spec:
  replicas: 1
  image: >-
    image-registry.openshift-image-registry.svc:5000/${TNS}/${APP_NAME}
  runtime: quarkus
" | oc apply -f -

oc get kogitoruntimes.rhpam.kiegroup.org -o yaml


The runtime configuration automatically creates also the 'Service' resource and the 'Route' resource


URL=$(oc get route ${APP_NAME} -o jsonpath='{.spec.host}')



10. Tests BPM


In a different shell set env var to follow the logs using 'oc logs' command

APP_NAME=my-kogito-demo-pam
oc logs -f $(oc get pod | grep Running | grep ${APP_NAME} | awk '{print $1}')

Then run the following commands

# health checks
curl -X GET ${URL}/q/health -H 'accept: application/json'
curl -X GET ${URL}/q/health/live -H 'accept: application/json'
curl -X GET ${URL}/q/health/ready -H 'accept: application/json'
curl -X GET ${URL}/q/health/group -H 'accept: application/json'
curl -X GET ${URL}/q/health/group/* -H 'accept: application/json'
curl -X GET ${URL}/q/health/well -H 'accept: application/json'
curl -X GET ${URL}/q/health/started -H 'accept: application/json'

# ping
curl -s -w"\n" -X GET ${URL}/ping


Now we start two process instances, the first will end automatically because the requested amount and the applicant's age meet the criteria of the rule for automatic acceptance; the second instance will stop waiting for the human task (also in this case we will simulate the interaction with a call from tool curl)

Set the name of the process we will interact with

SERVICE_NAME=RequestProcess


Let's start the two instances

curl -s -X POST -H 'accept: application/json' -H 'Content-Type: application/json' ${URL}/${SERVICE_NAME} -d '{ "amount": 70000, "requestorAge": 58, "requestorName": "Marco" }' | jq .



then the second instance

curl -s -X POST -H 'accept: application/json' -H 'Content-Type: application/json' ${URL}/${SERVICE_NAME} -d '{ "amount": 6000, "requestorAge": 12, "requestorName": "Baby" }' | jq .


The process instance is routed to human task step.
Let's read the list of active processes.

curl -s -X GET -H 'accept: application/json' -H 'Content-Type: application/json' ${URL}/${SERVICE_NAME} | jq .


Let's read the list of active tasks for the ongoing process

Set the process ID env var then query for the running task

PROC_INST_ID="<...your-process-instance-id...>"

curl -s -X GET -H 'accept: application/json' -H 'Content-Type: application/json' ${URL}/${SERVICE_NAME}/${PROC_INST_ID}/tasks | jq .


Set the task NAME and the task instance ID env var then complete the running task


TASK_NAME="VerifyRequest"
TASK_INST_ID="<...your-process-instance-id...>"
TASK_PHASE="complete"
curl -s -X POST -H 'accept: application/json' -H 'Content-Type: application/json' "${URL}/${SERVICE_NAME}/${PROC_INST_ID}/${TASK_NAME}/${TASK_INST_ID}?phase=${TASK_PHASE}" -d '{ "validated": true }' | jq .


The process instance is now completed



Query for running instances

curl -s -X GET -H 'accept: application/json' -H 'Content-Type: application/json' ${URL}/${SERVICE_NAME} | jq .


11. Conclusions

All very simple and intuitive, with the necessary parameterization of each single CR it is possible to create DevOps pipelines that help you simplify repetitive activities.


References

IBM Process Automation Manager Open Editions Documentation

https://www.ibm.com/docs/en/ibamoe

 

IBM Business Automation Manager Open Editions Software Support Lifecycle Addendum

https://www.ibm.com/support/pages/node/6596913

 

KieGroup

https://github.com/kiegroup/kogito-operator/releases

https://raw.githubusercontent.com/kiegroup/kogito-images/main/kogito-imagestream.yaml

 

Kogito

https://kogito.kie.org/

https://kogito.kie.org/get-started/

 

Quarkus

https://quarkus.io

https://quarkus.io/get-started/

Previous posts related to this topic

Setup IBM Process Automation Manager Open Edition (PAM/DM) using docker images
https://community.ibm.com/community/user/automation/blogs/marco-antonioni/2022/09/24/setup-ibm-process-automation-manager-open-edition

Setup IBM Process Automation Manager Open Edition (PAM/DM) in OpenShift
https://community.ibm.com/community/user/automation/blogs/marco-antonioni/2022/09/28/setup-ibm-process-automation-manager-open-edition

Use OpenShift CLI to setup IBM PAM Open Editions
https://community.ibm.com/community/user/automation/blogs/marco-antonioni/2022/10/09/use-openshift-cli-to-setup-ibm-pam-open-editions

Deploy IBM PAM/DM applications built with Kogito and Quarkus on OpenShift
https://community.ibm.com/community/user/automation/blogs/marco-antonioni/2022/10/16/deploy-ibm-pamdm-applications-built-with-kogito-an

One shot installation of IBM Business Automation Manager Open Editions on your laptop
https://community.ibm.com/community/user/automation/blogs/marco-antonioni/2022/10/18/one-shot-installation-of-ibm-business-automation-m

How to apply fixes to IBM Business Automation Manager Open Editions
https://community.ibm.com/community/user/automation/blogs/marco-antonioni/2022/10/30/how-to-apply-fixes-to-ibm-business-automation-mana