Introducing CMMN in Action: Part Four
Blog: Flowable Blog
We’ve been following through an example CMMN model as a means to introduce some of the ways to use CMMN to describe case management automation. In the previous post, we got to the point where the third stage, Handle claim, was activated. In this post we’ll look at an entry sentry with a condition and how auto-completion can be used.
It’ll be no surprise to you by now that the task, Inform claimant of decision, will have become active as soon as the stage it’s in became active, because it has no entry sentry. What else you’ll see will depend on what action you selected: accept or reject.
The process task, Make claim payment, does have an entry sentry. This sentry doesn’t have an event linked to it, so it will be evaluated every time the state of the case is updated – for example, by case variables values being modified. If you selected the accept claim action and look at the current tasks in the UI, you’ll see it must have triggered as there’s an active task from the linked process.
What went on for this to happen? If you select the entry sentry in the model, you’ll see the condition expression that needs to be true for the sentry to trigger the process task. There isn’t a definition in the CMMN standard for the syntax of an expression, much the same as for BPMN. Flowable uses the same expression language and evaluation in both CMMN and BPMN. The expression we’ve used in our example is:
${vars:equals(claimAccepted, true)}
This is going to test if the claimAccepted variable is equal to true, as well as failing if the variable doesn’t exist. If we knew the variable would always be available with a value of true or false, we could have just used ${claimAccepted}.
Where was this variable set? We didn’t look at this at the time, but select the Claim accepted milestone in the previous stage. In its attributes you’ll see that the Create milestone variable is set to a value of claimAccepted. This means that whenever the milestone is activated, that variable will be created and set to true. There’s a different variable defined for the Claim rejected milestone. This use of milestones is very useful for indicating some point in a case or stage has already been met when the case has progressed further.
Entry criteria are an example of a powerful way of starting different processes depending on information gathered so far: a stage can have a set of process tasks, all with different entry conditions that define when those processes are appropriate to start automatically, or offered to the user to start manually if desired. We’ve used this coupled with Machine Learning as a way of having smart sentries – the sentry condition calls out to the “AI” to see if it should trigger in the given circumstances. In this way, some case behavior can be sitting waiting for any case data to change that the AI is watching to trigger on. Well, that’s what the marketing brochure would say, coupled with a photo of a white humanoid robot!
Complete the remaining tasks for the case and you’ll see the case itself complete. It needed a bit of help in the model for this to happen. Because the process task has an entry condition, if the reject milestone is met, the condition will initially fail; however, the stage doesn’t know if this variable could be changed to be true at some point in the future, so it sits waiting for that possibility to happen. To stop this potential future holding up the present, we can set the auto-complete attribute on the process task. This means that even if the task is enabled or available, it can be ignored and the stage completed automatically (you can also mark elements as required in CMMN, which means the parent stage can’t be automatically completed when the element has not terminated or completed.). The stage has a black rectangle at the bottom to visually indicate that it will auto-complete.
With the final stage completed, the case itself is still prevented from completing unless we set the overall case plan to auto-complete. This is because the human task and user event listener outside all the stages would hold up completion in the same way as for the last stage.
Even though we’ve completed the case, we’ll come back to look at these two items outside the stages in our next post, introducing repeating tasks.
Leave a Comment
You must be logged in to post a comment.
