In the previous blog post Flexible processes in Kogito – Part 1 I talked about the new components and functionalities for flexible processes introduced in Kogito 0.12.0. In this post I will walk you through an example process putting all this in practice. Service Desk process The flexible-process-quarkus example is available in the kogito-examples GitHubRead more →

In the previous blog post Flexible processes in Kogito – Part 1 I talked about the new components and functionalities for flexible processes introduced in Kogito 0.12.0.

In this post I will walk you through an example process putting all this in practice.

Service Desk process

The flexible-process-quarkus example is available in the kogito-examples GitHub repository. In the project README.md file you can find instructions to build and execute the process.

It describes a service desk process where customers open a ticket related to a problem or question about a specific product. 

First, the ticket goes through a triage process where it is assigned to a support team and then a random engineer will be designated. If the system can’t decide which team has to handle the ticket, the support engineer will be assigned manually.

At any moment both, the engineer and the customer, can add comments until any part is satisfied and the case can be considered as Resolved. If for any reason, someone decides to add another comment, the case will be reopened and assigned to the other party until it is resolved again.

Finally, once resolved, the customer will have a task to send a satisfaction questionnaire considering the case as closed.

Overview

This is a diagram of the service desk process:

Create a support case

In order to start the process, an initial supportCase object has to be provided in the request. It will contain information about the product, the customer and a description of the problem itself.

{ 
  "supportCase": {   
    "customer": "Paco the customer",   
    "description": "Kogito is not working for some reason.",   
    "product": {     
      "family": "Middleware",     
      "name": "Kogito"   
    } 
  }
}

The triage

The Triage sub-process is automatically started when the process is instantiated and the support group is decided through the following decision table that takes as the entry the product name and family and returns the supportGroup.

You can see that for the case where the product family is not in the list. The engineer will have to be assigned manually.

Adding comments

The Work case sub-process is also auto-started. Anyone from the customer group can add comments and the same for people from the support group.

As mentioned above, an empty POST request has to be sent in order to create a task that can be used to add a comment. Imagine it as the “Add comment” button that renders the form next.

So, after sending this empty POST you will see something like this:

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"
}

The URL present in the Link HTTP header can be used when rendering the form action. Don’t forget to add the user and the group query parameters. Note that the data sent must be in JSON format. This example assumes the Javascript framework will deal with that.

<form action=”/serviceDesk/b3c75b24-2691-4a76-902c-c9bc29ea076c/ReceiveSupportComment/f3b36cf9-3953-43ae-afe6-2a48fea8a79a?user=kelly&group=support” method=”post”>
  <label for="comment">Comment:</label>
  <input type="text" id="comment" name="comment">
</form>

Case resolved

Let’s say the customer is happy with the resolution provided by the support engineer. The customer decides to click the “Resolve Case” button. 

This button sends an empty POST which triggers the service task. The case is then set as Resolved and a “CaseResolved” event is emitted.

Closing the case

The event will signal the milestone which doesn’t have any Condition. Then, the Questionnaire task is started and assigned to the customer.

The task expects a comment and a numeric evaluation based on the customer’s satisfaction. As a result, the questionnaire is added to the support case and the case is finally closed.

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-relatedRead more →

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!