What are flexible processes you might be wondering about? If you are familiar with Case Management you will get it quickly. If not, I suggest you start here.
As a brief introduction. In Case Management there is the concept of Case that is opened. Then the knowledge workers will perform tasks or update the Case-related information, known as Case File. At a certain point the Case can be considered as closed. Cases might eventually be reopened, depending on the situation.
Case Management is a way to provide traditional processes with more flexibility because the execution path is not rigid. This is an advantage when the process can’t be fully automated or the scope is hard to measure. A typical example is related to healthcare. A patient has a file that is accessible to the doctor and any health professionals assigned to the patient. They take actions, make different decisions and assessments until the patient is diagnosed and treated.
Instead of implementing Case Management as defined in the CMMN specification we decided to use BPMN extensions to provide a similar experience. This is what we call Flexible processes in order to avoid false expectations and misunderstandings.
What’s new?
Ad-Hoc process
Starting with the processes themselves, the first thing to do is to say that your process is an ad-hoc process in the modeler. For that, open the process properties and check the Ad-Hoc flag. This flag tells the modeler that you are defining a flexible process that might or might not have a start node.
Ad-Hoc sub-processes
An Ad-Hoc sub-process is a way to wrap related tasks together. Consider it as the equivalent to Stages in Case Management.
This type of sub-processes have some interesting features like the Activation and Completion Conditions. Activation Conditions control when the tasks within a node can start their execution. On the other hand, Completion Conditions decide when is time to move on to the next node. The same applies to the completion condition after the execution of all the nodes. The sub-process node will wait for the right state to complete and continue to the next node, if any.
These conditions are defined as Java lambdas and they will be re-evaluated each time a process variable is updated.
Milestones
This is a concept directly taken from Case Management. Although the same functionality can be achieved through different BPMN components we considered some users might find it simpler to understand and to apply.
Milestones are a node that can be automatically started by an event with the same name of the node
Additionally, they can have an optional “Condition” input assignment. Use a Java expression to decide when this node is ready to be completed and move forward to the next one.
Imagine the example about the patient. Possible milestones could be “Patient diagnosed” or “Patient recovered”. Each milestone implies that a specific state has been achieved and it’s time to move on to the next one.
AdHoc Fragments
We call AdHoc fragments nodes that don’t have an incoming connection to any other node and are not start nodes. AdHoc fragments may or may not start automatically, depending on the AdHoc Autostart flag.
If the node is automatically started it will be executed when the process is created. However, when this flag is not set, the only way to trigger the node execution is with a signal. Processes receive signals externally through the REST API, internally by using events or programmatically. See more about external signals in the next section.
REST API
For non-flexible processes, the main POST request will trigger the Start node whereas in a flexible process it will just create the process instance. All nodes with the AdHoc Autostart flag will start with the process.
For the case of the AdHoc fragments an empty POST can be sent to start the execution of the node. In the specific case of the HumanTasks where a new task is created, users or API consumers will most likely be interested in the generated task URL. This is possible through the Link HTTP header present in the response. It will contain a relative path with the process instance ID, the task name and the task instance ID.
curl curl -D - -XPOST -H 'Content-Type:application/json' -H 'Accept:application/json' http://localhost:8080/serviceDesk/b3c75b24-2691-4a76-902c-c9bc29ea076c/ReceiveSupportComment
HTTP/1.1 200 OK
Content-Length: 305
Link: </b3c75b24-2691-4a76-902c-c9bc29ea076c/ReceiveSupportComment/f3b36cf9-3953-43ae-afe6-2a48fea8a79a>; rel='instance'
Content-Type: application/json
{
"id":"b3c75b24-2691-4a76-902c-c9bc29ea076c",
"supportCase":{
"product": {
"name":"Kogito",
"family":"Middleware"
},
"description":"Kogito is not working for some reason.",
"engineer":"kelly",
"customer":"Paco the customer",
"state":"WAITING_FOR_OWNER",
"comments":null,
"questionnaire":null
},
"supportGroup":"Kogito"
}Give me an example!
In the next blog post I use all this in an example. Go to Flexible processes in Kogito – Part 2 and see it in action!
