KIE Community

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.