I’m taking a detour from IBM BAW/BPM for a bit and wanted to jot down some lessons learned while working on a Proof-of-Concept with Red Hat Process Automation Manager (RHPAM), which is also kind of just JBoss jBPM, but then also this Kogito KIE (“Knowledge Is Everything”) product…yeah, welcome to Open Source. We’ll call it RjK for this post.
For the most part, RjK is a full Business Process Management/Process Automation/Workflow solution. It offers design/authoring functionality in a web-based environment under the label “Business Central” (BC). In Business Central you can author process flows, rule assets, data models (like Business Objects), forms (like Coaches), and a few other asset types I haven’t used yet. RjK is much more Java than anything in the IBM BPM/BAW world: the Data Model asset is essentially a Java class file; the process assets are full BPMN-compliant XML files, etc. RjK covers process, rules (pretty much the Drools product), and then this OptaPlanner feature that I haven’t looked at yet but seems like a cool way to create optimization solutions for things like “the best way to plan delivery trips” or “solving a Sudoku puzzle”. There are a ton of open source resources for RjK: examples in GitHub, posts on Stack Overflow, Medium.com posts, etc. All three products offer documentation and some of it is copy/paste from each other, but looking at examples is usually the best place to start. RHPAM is Red Hat’s “hardened” version of jBPM with some Kogito/KIE functionality included. I think this means customers can pay for support and consulting for almost the latest version of jBPM/Kogito, but with a stamp of approval from Red Hat that the version is safe(r). From what I can tell, Kogito is the migration path for what was previously called jBPM. Kogito is putting a more cloud-friendly spin on the offering with things like Quarkus, Kubernetes, and GraalVM…way outside of my comfort zone, but still neat to tech-drop like that.
RjK applications are built into kJAR files which can run under the umbrella of a KIE server, or kJARs can be setup to run all by themselves, or even embedded in another application. There are a ton of API options for RjK, all the way from Business Central to KIE to the individual objects that actually execute the process and rules assets (REST APIs, Java APIs, other APIs I’m sure I don’t understand). It’s very compartmentalized and much more “micro-services” than IBM BPM.
This PoC is setting up one Business Central instance on a Kubernetes pod and then one KIE Server instance on a different Kubernetes pod. There is a shared Persistent Storage Volume (PSV) for the two pods: it is being used for the Maven Repo mentioned below. The PoC is essentially trying to mimic IBM BPM by using Business Central as a Process Center-type environment and KIE Server as a Process Server environment. Projects are deployed from Business Central to the KIE Server instance which is running other projects/containers at the same time. Business Central is connected to KIE Server so BC can manage and start instances and interact with tasks.
I’m also messing around with Spring, Apache Camel, Kafka, and Mongo for some supplemental functionality. I need to scrub the code and get it into GitHub and I’ll share some learning notes on those capabilities next.
Again, these are just raw notes from some setup and configuration work. Hopefully more to come:
- Connect Business Central (BC) to KIE/Process Server
- This older 7.0 article mentions a specific login-module that needs to be enabled on BC to authenticate to KIE, but the 7.12 page doesn’t mention it:
<login-module code="org.kie.security.jaas.KieLoginModule" flag="optional" module="deployment.business-central.war"/> - We had to add that element to the BC standalone*.xml in order to get BC Workbench to see process data on KIE
- This older 7.0 article mentions a specific login-module that needs to be enabled on BC to authenticate to KIE, but the 7.12 page doesn’t mention it:
- Asset Path – The way BC and KIE store assets (aka code) can be a little confusing…and obviously I’m not 100% sure all of this is correct.
- BC uses an internal Git repository (.niogit) in a hidden directory to store and manage design-time assets (versioning, branching, etc.)
- There is a lot of read/write to this repo so it needs to be local to BC
- BC then uses Maven to pull from code niogit and push assets to a Maven Repository
- This repository can be local to BC only or external
- A local BC Maven Repo (local as in on the file system where BC is running) is accessible by the BC/maven2 REST endpoint, which has a special security configuration (we could not get this to work)
- NOTE: this might work if we add the login-module above to KIE standalone…but we’ll wait and try this later
- The external repo can be over HTTP (like Artifactory)
- Or a shared file location
- We chose to point BC maven to a Persistent Volume (PV) that KIE Maven could also reach
- A local BC Maven Repo (local as in on the file system where BC is running) is accessible by the BC/maven2 REST endpoint, which has a special security configuration (we could not get this to work)
- This repository can be local to BC only or external
- At PAM Project deployment, BC sends container information to KIE (?) along with the build to the Maven Repo
- Totally not sure about how this really works…KIE has a configuration reference to BC’s controller, so I’m not sure if KIE is pinging BC to get deployment info…or if BC pushes or signals KIE is some way…
- KIE goes to the same Maven repo to pull down the assets (the KJAR and pom) and build (via Maven) the actual container that will run while keeping the build locally in its own Repo…? Again, not sure at all how this is working but this PoC has .niogit on BC’s filesystem, a Repo for BC and a Repo for Maven and it’s working.
- BC uses an internal Git repository (.niogit) in a hidden directory to store and manage design-time assets (versioning, branching, etc.)
- Events – It looks like there are three different event scenarios for PAM:
- Automatic Event Emitters
- This a feature where jBPM will automatically send/publish a Process, Task, or Case event to Kafka using the built-in jbpm.event.emitters feature. This feature has to be enabled and configured in standalone-*.xml. See notes here.
- Custom Event Emitter
- This is where an activity in a BPMN flow is built to send/publish an event in a specific scenario in the process. This option requires a WorkitemHandler to be configured. Here.
- Basic Event Processing
- This is how to configure KIE to consume and produce Kafka events using the built-in Kafka server functionality. This only works with an app deployed to a full KIE Server that is already configured to deal with Kafka. This configuration setup is slightly different than the Automatic Event Emitters.
- See here.
- NOTE: if you’re setting up a Receive Message Event (Consume) in a BPMN asset, the event payload has to match the Message Start Event data mapping exactly. And needs to be JSON in the form (“data”:{—-JSON of Input Variable name:value—–}}. You can’t just use a string.
- Automatic Event Emitters
- Signals vs Messages
- I’m not really sure if this is correct based on the documentation, but apparently Messages are universal, which means you can’t target a specific Process Instance with a Message Event. Using the REST API or the Kafka connection to a Message Topic will fire the message on all active instances…? This might be unique to the scenario of setting up a central KIE server to run multiple containers/deployment units.
- Signals use a specific Process Instance ID and can target only that instance.
- Signals
- When firing a signal via the REST API, the payload/body has to include the class name of the output variable defined for the Signal. So if a Signal is mapped to an output variable like this: {“MyObject”:{“myName”:”Sue Smith”,”myAge”:25}}, that JSON has to be in the Body of the REST API call to fire the Signal, where “MyObject” is the class name of the Data Model for the Output variable. Using the name of the Output Variable doesn’t seem to work.
Some helpful links:
Thaxton's Nerd Notes 