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:
- You have a BPM workflow that is a batch workflow (or micro flow) and doesn't require any human tasks. In this case, the BPM process application is started externally. It runs through its activities, and finally the process application completes.
- You already have an existing UI layer that it likes. For example, the client has a portal developed that it will continue to use.
- You have a technical challenge, like the client wants to embed an existing UI page (a JavaServer page [JSP], for example) in an iFrame in a coach. One issue with doing that is that the "look and file" between the coach and the embedded page will be different. Another issue can arise if there is a requirement to signal the coach when the user completes data entry in the embedded page.
- Your UI developers only know a particular technology like .Net, JSP or JavaServer Faces (JSF) and they don't plan on learning how to develop coaches.
- You need to provide a mobile app that you host from IBM Worklight that is the UI to your BPM process application.
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 need to use and existing application.
- You are developing a mobile app for IBM Worklight for your BPM application.
- There is some reason why the client doesn't want to use coaches.
You can consider several patterns:
- Use coaches but programmatically complete them.
- Use external implementations of User or System Tasks.
- Use both in a hybrid BPM process implementation.
Have you tried a headless BPM solution? Let me know how it went or post your questions below.