I want to explain how to bring Case Management to Kogito using the tools that flexible processes provide.
Previously I introduced flexible processes in Kogito. See part 1 for a generic introduction and part 2 to see it in action.
I would like to highlight that I will not cover all the concepts described in the CMMN specification, just the most important and the ones that we considered a must for having a good Case Management experience. If you feel we are not covering some important use cases, don’t hesitate to join the Kogito Community and ask us directly.
The blog post contains is structured as follows:
- Go through the most common Case Management concepts and explain how to use Kogito’s flexible processes in each case.
- How to use Documents in Kogito.
Concepts
From my experience I find Case Management open to interpretation and what I will define is my point of view so it is fine to not agree with what I say 🙂
Case
A Case can be understood as an unstructured process where there isn’t necessarily a defined starting or end point. Maybe none of them even exist.
Cases are driven by Knowledge workers and they decide what information is missing or when the Case is ready to move forward or back to a previous stage.
So if we consider a Case a special process where we don’t need a start or an end… In Kogito we can say our process is an Ad-Hoc process.
By checking the Ad-Hoc flag our process will not require to have a start node because we will be adding individual tasks or groups of tasks that are known as discretionary tasks.
This is a hypothetical case for a public organization grant funding. You can see several discretionary tasks for preparing the proposal, adding comments and archiving the proposal. They do not depend on any previous action but may depend on the state of the case, that is, the Case file.
Case File
Knowledge workers will manipulate and transform the data used during the life of the Case. This data is the Case File. As we are in a process, the Case File will just be our Process Data. Sub-processes and tasks can share the data, either totally or partially.
Case ID
The Case ID is a value that helps Knowledge workers uniquely identify the Case, a correlation key. It is usually a sequential number with a prefix. E.g. CASE-00010230
In Kogito there is the concept of Business Key that you can set to each process instance, i.e. the Case instance upon creation. The process will always be created using a generated UUID but it will be possible to identify the process by the Business Key.
Milestones
The concept of a milestone is almost self-descriptive. We can define it as a single point of achievement within a case instance. No work is associated with a milestone, but it will allow the possibility to work on a different set of tasks after a certain state is reached.
A Milestone will wait for a signal to occur, the event will have the same name as the Milestone.
In this example, when the Resolve Case service task is executed, the “CaseResolved” is emitted. This signal triggers the CaseResolved milestone.
Milestones may have “Conditions” to control their completion. Conditions are defined using Java expressions and will be re-evaluated each time a variable is updated.
These conditions allow you to synchronize multiple events or states into a single point. Imagine a case where our “Approved” milestone should be completed when it has been reviewed by the expert and the financial availability check has also succeeded. We would have a condition like the following:
financialAvailability.isApproved() && technicalReview.isApproved()
Stages
Stages can be defined as a group of tasks that are executed for a common reason. In this example, there is the “Proposal preparation” stage that includes two tasks related to the preparation of a proposal. Once the proposal is ready to be reviewed, the stage will complete and the Case will move to the next stage.
In flexible processes we consider that Stages are a sub-process embedded in the main process. The formal name for that is Ad-hoc sub-process. You don’t need to define any task within a Stage but it will help with business visualization and grouping. Ad-hoc sub-processes can have activation and completion conditions that allows you to set the stage as completed or to re-use it when needed.
For example, if the knowledge worker responsible for the documentation review concludes that there is something missing this stage can be activated again so that the user can update or attach more documents.
Ad-Hoc Fragments
Discretionary tasks are any type of task that users or the knowledge workers can interact with at any point in time during the Case life cycle.
These tasks can be of any type and can be triggered by signals (internal or external). In flexible processes a discretionary task or an ad-hoc fragment is any node that:
- Is not a start node
- Is not linked with a previous node. I.e. doesn’t have an incoming connection
- Is not auto-started
Case Life cycle
Cases have a life cycle, they can be started, aborted, suspended, completed or terminated.
After receiving a new request containing the initial Case File data the process will be started. If it has a start node and/or ad-hoc auto-start nodes, they will all be executed.
Then users and knowledge workers can interact with the discretionary tasks or any other active tasks in the process.
The End node sets the process as completed but not terminated. Tasks are still available in case the knowledge worker wants to execute any more actions.
The process terminates after reaching the Termination End node.
It is important to mention that once the case is terminated, Case data will remain in the Data Index but will be removed from the engine memory. See more about the Data Index
Documents in Kogito
Case Files very often contain documents but nowadays most companies and individuals rely on cloud services for that document management. That means the most common way to work with documents is by using the reference or the minimal metadata to uniquely identify such documents in a specific cloud provider.
For example in Microsoft OneDrive, if you wanted to identify a document you will need to provide:
- userId
- driveId
- itemId
Whereas for Google Drive it seems enough to just keep the fileId (similar to the OneDrive’s itemId)
So it seems reasonable to create a POJO that represents a reference to the document depending on your organizations requirements and just provide the necessary metadata to identify the documents in the cloud provider.
With this solution, Kogito doesn’t need to directly handle documents which is something that it wasn’t meant to do. It’s up to the developers to provide the best experience with documents to their users and knowledge workers. Besides it provides an additional layer of confidentiality and security already defined at the organization level.
Examples of front-end applications:
- Embed a widget to let the user pick documents directly from their OneDrive folders and attach them without even uploading them.
- Let the users upload the document to an application-managed drive to just keep the document metadata.
