Last week I showed some of the new dynamic process capabilities of Flowable V6 at the bpmNEXT conference and I thought it might be nice to give a taste of that demo here. The demo scenario was that we’re organizing a tour for the Flow Pistols and like any well designed processes, it can’t always cope with what the real world throws at it. I showed Flowabe 6 running within the edoras one Case Management platform, with a case representing the overall tour and a process to run for each gig that needed arranging in the tour.
The process is quite simple: gather some details about the gig, and if the expected audience is above a certain size, then organize stadium-scale sound and light equipment; otherwise, just arrange transport for the band’s own gear. The process diagram is:
Instead of just allowing random dynamic actions anywhere in the process, we can tag user tasks as being able to allow the user to insert dynamic tasks or processes at that point. I’m going to tag two of the tasks as allowing either dynamic tasks or processes.
Once the process is deployed, I create a case for the tour and kick it off with a gig in Paris. The case view allows me to start any appropriate processes associated with the case.
If I click the Start process action on the right-hand side, I can pick from the available processes for the case and get its start form – in the Arrange a gig process, this is just a dropdown to select the region for the event.
Once the process is started, the first task appears, requesting the gig details.
We can complete the details needed here, including the expected size of the audience. We’re expecting a relatively small crowd in Paris, only about 4000.
Because it’s going to be a small gig, we’ll be taking the band’s own equipment and the process takes us to the task to arrange transport for the kit, getting details of the vehicle carrying it. Notice the additional actions to add dynamic tasks or sub processes.
Inject a parallel task in a live instance
Now, imagine I had got to this point in the process, when I heard from the company that usually transports the gear, saying that because of Brexit, the French government was insisting on UK commercial transport taking out an additional insurance. Luckily, we already have forms we use for non-EU countries, so we can just reuse one of those. Of course, I could just create an ad hoc task that’s linked to the case (or as a child of a user task), but in this case, I really do need it as an independent task that can be done in parallel to booking the transport. Also, I do need both tasks to be completed before the process continues. What I really want is to magically change this instance to a process more like the following:
This is exactly what I can get with dynamic tasks. If I click the Add dynamic task, I get a form to define the task. I can give the task a name and select its form. It could have been configured to more specific, predefined tasks, but I’m keeping it simple.
Now, I have two tasks in my list:
I can now complete the insurance task and booking transport task to allow the process to continue, eventually to completion.
Inject a complete process into a live instance
Well, that was fun, but not exhilarating. Let’s arrange a gig in the US. I’ll start the Arrange a gig process again and this time take a different path. If I arrange a gig for New York and say I’m expecting a crowd of 15,000, then we go down the path needing stadium equipment to be booked.
Just at this point, I see that there has been a presidential tweet early this morning saying that some planned energy tax legislation is being brought forward, effective from today! Luckily, I had been planning for the tax, so already had someone define the process that modeled it. What do I do? Try and create a new process model that includes this, deploy it and them migrate active instances to it? If I had enough time to learn the intricacies of BPMN models and migrations (plus some developers ready to handle the cases where it just doesn’t seem to want to play nice), then I might. Alternatively, I can just click the Add a sub process action.
I can give a name to use and then select the USA Energy Levy process. This time, the entire process will be inserted in parallel to the current task and started, so, as you’d expect, an additional user task has been opened.
Before we continue, let’s take a peek inside the engine to see what’s going on. By starting the Flowable Admin app, I can inspect all kinds of interesting things about the engine, but I’m just going to look at that active process instance.
If I click the Show process diagram action, I can see the familiar Arrange a gig process, but with one difference – the Book light and sound systems task isn’t a user task.
If I click on it, I zoom down a level and can see a parallel gateway with the open task and a sub process.
If I then click on the subprocess, I can see the energy levy process and its open task.
Back in the case view, I can complete the tasks for the energy tax, giving details about the consumption of the equipment.
Sadly, because we’re using low energy gear, we end up on the path that gets hit by the tax.
And it looks like we have to pay an additional tax, because being concerned about global-warning means we’re probably communists.
Of course, demos like that can look amazing, but you never know how hard it was to do behind the scenes, and what corners were cut. So, here’s the code that was used to insert a subprocess into a running instance:
DynamicEmbeddedSubProcessBuilder subProcessBuilder = new DynamicEmbeddedSubProcessBuilder()
Inject a process into an injected process in a live instance
Yes, I did just say that. If you can inject a process into a running process instance, why not inject a process into that injected process as well? Sounds twisted, but think again about dealing with the real world – you never know what you might have to deal with at any time. Also, think about it in the context of having many process snippets that can be used as needed by the user or by a smart subsystem. Then think about a chatbot that follows a process snippet when the user asks something, and while following that path, the user suddenly has something else come to mind that makes their conversation take a diversion. The user journey could be created using process injection. Here’s an injected process to update the Accounts Payable system in the injected process that used the new tax for the first time – see the path in the top of the view.
Where does it go from here?
As we got a hint of when looking under the covers, we can visualize, audit and even reuse these one-off instance variations. Existing analytics can continue to be used, and there’s an exciting potential to use Machine Learning to recognize the cases when exceptions should be considered for a case in hand.
This was just intended to illustrate something we can do now with Flowable 6. As we move forward, we will continue to add features that exploit the dynamic manipulation of process state in user-friendly ways. When looking at other BPM engines, see if they currently can do this. A big thank you to the guys who put in the hours to make the magic happen for the demo – I was the dancing monkey.