Using IBM Business Process Manager in a headless solution
Christian Karasiewicz 270005XS4E Comments (2) Visits (6041)
This blog post contributed by Owen Cline, a member of the IBM Software Services for Websphere team based in San Diego, California.
What is headless BPM?
Headless business process management (BPM) is the concept of using only the IBM BPM Process Server to execute process flows without any user interface (UI) coach forms.
Why do it?
There are good architectural reasons why someone would consider a headless BPM solution. Consider these scenarios:
Headless BPM patterns
Use coaches in an external user interface
In this pattern, an external UI displays coaches in an iframe. This pattern is used if the user does not want to use the IBM BPM process portal but does want to use the coaches.
Use coaches programmatically
Using coaches programmatically means that you do nothing special in your BPM application. In this pattern you add user tasks with coaches as you normally would.
This allows you to have a coach UI in the BPM application in case some users will work with the coach forms from within the BPM process portal.
But, this pattern also allows you to progress through the BPM process application programmatically from an external UI or application.
This is because the BPM REST API allows you to claim a User Task (Assign Task), modify a User Task's output variables (Set Data) and, finally, complete the task (Finish Task).
Take this BPM process application, for example:
And here are the process application variables:
And, here is the headless BPM User Task:
And, here are the headless BPM User Task variables:
First, we start an instance of the headless BPM process application. And, the process instance blocks on the headless BPM User Task where the task ID is 207.
Next, using the BPM REST API Tester, we claim the task (Assign Task to Me, the admin user):
Next, we check the Process Inspector to verify that the headless BPM User Task is assigned now to the admin user:
Next, we will issue a Get Data command to check the value of the output variable. If there were more output variables, we could set all of them in one Get Data command. Notice that the output variable is NULL.
Next, we will issue a Set Data command to change the value of the output variable. If there were more output variables, we could set all of them in one Set Data command.
Next, we will issue a Finish Task command (and set the output variable).
After the Finish Task call, the task (and the process instance) completes.
Use external implementations
You can provide an external implementation for User and System Tasks. Think of them as breakpoints in your process flow. And, yes, they can have input and output variables that you can externally access and set using the BPM REST API commands seen above. The User and System Tasks are handled the same way that the User Task implemented with coaches was above. You still have to claim them (Assign Task), change the variables and then complete them (Finish Task).
This pattern is a common one for mobile-based UIs that connect to the BPM engine.
Here we create an external implementation:
And here we assign the newly created external implementation to a System Task (and it could have been a User Task with no coaches):
You can also use a hybrid solution where you have both a User Task with coaches and a User Task implemented as an external implementation. In front of them, you have a gateway to test a Boolean variable that routes to one of the two.
As I mentioned above, there can be good requirements where you will need to model headless BPM process applications.
You can use several patterns depending on your particular business requirements, like:
You can consider several patterns:
Have you tried a headless BPM solution? Let me know how it went or post your questions below.