Introducing CMMN in Action: Part Two
Blog: Flowable Blog
We’ve been following through an example CMMN model as a way to introduce some of the ways to use CMMN to describe case management automation. In the previous post, we’d started and then completed the first task, Capture claim details, in the first stage, Receive claim. Doing that had just enabled the process task Need additional information for the user to start manually if needed. What we’re going to do in this post is explore how dependencies between elements in the case can be modeled.
Before we go further, it’s useful to point out that the manually activated process task can be run multiple times, as indicated by the repitiion marker #, so any time more information is needed, the process can be run again as a new process instance. There’s options that allow you to control if multiple instances of the process task can be run at the same time, or if it’s a blocking task, meaning only one instance can be running at a time.
Looking at the other three manually activated human tasks in the Receive claim stage, we can see that there are dependencies between a couple of them and the Add incident report from police task. First of all, the Need legal review task is not yet enabled (we can’t see it in the case instance we started). It has an entry sentry that is triggered when the Add incident task is started, so it will only become visible to the user once that happens. We can already see the Need 3rd party report option because it didn’t have an entry sentry so had become enabled when the stage was activated.
Click the Add incident report from police action and several things will happen, as you can see in the screen below. First, we now have the Add incident report task as an active task the user needs to complete. Second, we also have an option to start a Need legal review task if needed. Finally, the option to manually start the Need 3rd party report task is no longer there. Having the police report means the 3rd party report is no longer relevant.
Maybe you’ve already realized it, but by starting the police report task it triggered the exit sentry on the 3rd party task, effectively making it no longer an option for the user to start. In fact, if the user had already manually started the 3rd party task, starting the police report task would have automatically terminated it. The same applies if it had been a process task that had started running a process instance: the exit sentry would have terminated the running process.
This can be a really clear and powerful way to represent unexpected or unpredictable events, which BPMN doesn’t do easily. Imagine a situation where some customer services process has been started to refund a failed delivery of a purchase from an online store. It’s going through the necessary checks with the delivery company followed by approval steps to get the customer refunded, when suddenly the customer says it’s just arrived. With CMMN, we only need to provide a user event listener or manually activated task that connects to the failed delivery process task with an exit sentry. That’s it – clearly visible in the CMMN diagram and achieved in a couple of clicks of the model. Have fun doing that with BPMN.
Let’s close off this post by completing the stage. Because there are so many user-driven manual options in this stage, we’re using a user event listener, Details completed, connected to an exit sentry on the stage to allow the user to say they’re all done here. Execute the user event and the stage will exit. The Receive claim stage has an exit event as the trigger for the entry sentry on the Investigate claim stage, which means that stage will become activated as soon as the user selects Details completed. With Flowable, you can actually select the event type for the exit sentry, so you could use a standard complete event linked to the next stage if you wanted. We’ve added a number of extensions to how CMMN can execute for convenience or that have come up from customers, as is always the way with standards when used for real.
In the next post we’ll see how nested stages can be used to handle some situations where we want to group dependencies. We’ll also introduce the use of milestones to help test earlier outcomes.
Leave a Comment
You must be logged in to post a comment.
