Cloud Pak for Business Automation

 View Only

CP4BA Workflow Process Service (WfPS) deep dive part 2 - PFS federation

By Marco Antonioni posted Fri January 12, 2024 03:05 AM

  

Introduction

In this second post I want to present a federated topology composed by various instances of 'Workflow Process Service' runtime.
This configuration is preparatory to the final topology (described in the next post, 'CP4BA Workflow Process Service (WfPS) deep dive part 3' which will be published soon).
The capability that creates the technological bridge enabling the federation is 'Process Federation Server'.
As usual, the final part of this post provides an example for the complete implementation of the topology described.

Process Federation Server (PFS) overview

Process Federation Server enables task workers to perform all their work from a single Business UI (Responsive Portal or Workplace).
Tasks and instances can be federated across BAW and WfPS deployments (also running different product versions).
PFS only provides the data, no UI, it provides federated REST APIs for external Business UI (may be a custom UI).
Data exposed via REST APIs: Task Lists, Process Instances Lists, Dashboards, Launchable Entities, Saved Searches.
PFS requires an 'Elasticsearch' engine as supporting component.
For detailed information about PFS see Reference section.

Benefits of use

The use of the PFS and workflow runtimes in a containerized environment allows you to delegate all the detailed configurations to the respective operators which allow complete collaboration between the various components.
For example, in terms of configurations, when the WfPS operator manages an WfPS instance that has the 'capabilities.federate.enable: true' tag, it independently creates a 'FederatedSystem' type resource; this type of resource is monitored by the PFS operator who is thus informed of the presence of a new runtime to be federated and exposed to clients as available system using its REST APIs.
Your IT team doesn't have to do anything except monitor the operational status of your systems. This is a concrete example of savings of time and resources.

Scenario topology

The scenario described is made of a PFS runtime and two WfPS runtimes (same namespace is a must).
This restricted scenario is useful in the case of a customized UI portal integrated via REST API towards PFS/WfPS.
It is preparatory to the complete topology described in the scenario of 'part 3' of this series.

Demo time, deployment of PFS and WfPS runtimes

Now let's move on to the most interesting part, the deployment of one PFS and two WfPS runtimes
 

Configure and deploy the PFS instance

To install an instance of PFS you can follow the example instructions in the 'Create process federation server' section of the README page at the link https://github.com/marcoantonioni/cp4ba-process-federation-server.
When the PFS deployment is ready you may deploy the two WfPS instances.
 

Configure and deploy the WfPS instances

To install a pair of WfPS runtimes you can follow the instructions on the README page of the link https://github.com/marcoantonioni/cp4ba-wfps (you can use wfps1.properties and wfps2.properties configuration files). 
Remember to modify the namespaces of the various configuration files in order to have the three components in same location. 
Update also WFPS_FEDERATE=true, with value of 'true' the WfPS operator automatically federate the runtime to PFS running in same namespace.
 

Installations verification

To verify the status of PFS and WfPS installations you may use OCP console in browser or from command line
 
oc get pfs pfs-demo -n [your-namespace] -o jsonpath='{.status}' | jq .
 
oc get wfps wfps-1 -n [your-namespace] -o jsonpath='{.status}' | jq .
 
To list names of federated servers use commands from 'scripts' folder of 'cp4ba-process-federation-server' repository
 
./pfs-show-federated.sh -c ../configs/pfs1.properties
 
To list all details of federated servers you can query against PFS server using command
 
./pfs-show-federated.sh -c ../configs/pfs1.properties -d
 
Install the demo applications in WfPS runtimes using 'wfps-install-application.sh' script in repo https://github.com/marcoantonioni/cp4ba-wfps.
 
When installed and after few seconds you can query against PFS server the list federated contents using the following commands
 
# only tasks
./pfs-show-contents.sh -c ../configs/pfs1.properties -t
 
# only processes
./pfs-show-contents.sh -c ../configs/pfs1.properties -p
 
# only launchable entities
./pfs-show-contents.sh -c ../configs/pfs1.properties -l
 
# all
./pfs-show-contents.sh -c ../configs/pfs1.properties -a

Next steps

 
In the next and final post 'CP4BA Workflow Process Service (WfPS) deep dive part 3' I will guide you on how to install a 'production' type CP4BA deployment within which we will see the complete deployment scenario with PFS, WfPS and BAW running the ProcessPortal for federated systems.
Stay tuned.
 

References

 
Planning for a CP4BA Process Federation Server production deployment
 
Installing a CP4BA Process Federation Server production deployment
 
Administering and operating IBM Process Federation Server Containers
 
My GitHub repositories (see cp4ba- prefix)

0 comments
20 views

Permalink