Introducing CMMN in Action: Part Three
Blog: Flowable Blog
We’ve been following through an example CMMN model as a means to introduce some of the ways CMMN can be used to describe case management automation. In the previous post, we’d completed the first stage, Receive claim, and were just about to dig into the second stage, Investigate claim. What we’re going to do in this post is look at substages and milestones.
The case has now moved to the next stage and will have automatically started the process referenced by the process task, Do claims adjustment. In our definition of that process in the example app there are three user tasks in sequence, so the first of these will now be waiting for user input.
In the Investigate claim stage, there’s one other element at the top level of the stage, but as it’s linked by a completed event, it will only become available when the process task has completed. There’s no forms associated with any of the tasks, so we can just Complete each one in turn. Once that process completes, then the process task that referenced it from the case stage also completes. If you’ve been following this series of posts, you’ll know that the element connected the process task by a complete event will now become available (there’s no other condition on the entry sentry). But what is that element?
It’s a substage – a stage within a stage. There’s no limit to the nesting you can have, which allows you to control the scope of behavior in more complex scenarios. The reason we’re using it here is because we want to give the user the option to select if they want to accept or reject the claim. We could have done that within the process we called and passed out the decision as a case variable, but it’s not always possible if you have reusable process fragments called from a case. Also, it allows us to explain some more of the CMMN by doing it this way!
We’re using user event listeners in this scenario because we don’t want to create an additional and unnecessary manual task to get the decision made. We just want a couple of actions to be available to the user to signal the outcome. Again, with a real case management scenario, there may be a whole number of other activities that the user could possibly do within this stage before making the final accept or reject decision. One feature of user event listeners is that they don’t have entry sentries. In our example, we only want the options for user to appear once some state has been reached within the stage, not immediately. Without entry sentries on the user event listeners, we need some other way to provide the scope for that context. Substages can provide that scope.
We’ve reached the state where the process task has completed and the substage consequently has become active, so everything inside it is evaluated to see if they become active, enabled or available. Suddenly, our two user event listeners become enabled and visible in the Flowable UI.
When the user selects one of these options, the user event listener triggers and activates its linked milestone. A milestone has no real behavior other than existing or not – in Flowable, if a milestone is made active, a variable is created for it. With our example, as soon as a milestone occurs, it then triggers the substage to exit (see the exit sentries). With the substage context gone, the user event listeners are no longer available to the user (the options are gone from the UI). With the process task and substage completed, there are no other elements in the Investigate claim stage that could become available, so the stage itself completes. You won’t be surprised to learn the final stage, Handle claim, now becomes active. We’ll see how the milestone can be used to trigger behavior in the next post.
Leave a Comment
You must be logged in to post a comment.
