What the …Case Management framework!

Alright, so by now you are probably aware that the OutSystems’ Case Management framework is available for you to start using. You’ve heard some talk about it on Next Step, you’ve seen the Forge component and you know that Documentation exists. (If not, open this link.) You might very well be very hyped or very sceptical about it. But either way, you are ready to get those juicy technical details. And man, do I have some nice technical details to share with you today!

A golden oldie: BPT

It’s important for you to understand what BPT is before we dive into it. So here is my TLDR on BPT: with BPT (Business Process Technology) you are able to build -surprisingly- Business Processes. A Business Process is a set of activities that jointly result in a desired product or output.
With BPT you are able to model such business processes by stringing human activities and automated activities together. When an activity has been executed the process will automatically proceed to the next step. If an activity happens to create a delay, for example you are waiting for a human to do something, this will automatically be addressed by BPT. It is possible to start a process by calling on it from the code, but also to start it based on database events.
More complex features include parallel processes, SLA’s and task assignments, you can find out more in the documentation.

BPT is very useful for modelling sequential processes, but not all processes are sequential.

Queue the dramatic music, drop the curtains and celebrate the new hero of the day: the Case Management framework.

What is Case Management framework?

The Case Management framework combines BPT with the concept of a case. A case is hard to define, but easy to describe with an example: when you go to a doctor, they are going to keep records of all the interactions they have with you, all information they capture about your health and all documents gathered along the way. The entire set of information exchanged and documents gathered are part of your case. That is the business concept.

If you are a developer it might help to think of a case as a record in a database that will slowly be filled with information over time. Add an audit trail to that, and you’ve got a very basic version of a case.

You were always able to keep track of cases with OutSystems, and a lot of customers did. In fact, many customers did Case Management using BPT features such as processes, tasks, SLA, ad-hoc activities, decisions and outside events.
So what is the added value of the Case Management framework?
Well the Case Management framework creates a standardized Case Management library for everyone to use. It takes a lot of work that has traditionally been done by customers themselves and moves it to OutSystems. This makes Case Management much more accessible for many of our customers who would like to start working with cases.
The Case Management framework accomplishes this by taking the ability to orchestrate across the automated actions and human activities with BPT, and adding the ability to coordinate the follow up activities based on the Case rather than in a sequential order. This might mean that an activity happens because of a business rule being triggered, because of which date of the month it is or because some new information became available. It can also be triggered by a myriad of other reasons. This is how Cases enable you to model a more circumstances based approach. Actions do not happen in a specified order, but in a specified circumstance.

A library for you to use

So under the hood the Case Management framework is an add-on on top of BPT, to handle the concept of Cases. But there are a lot of layers part of that.

I’ve drawn a picture of the simplified architecture below.

Let me be the first to admit to some oversimplification here: the real architecture contains 16 modules, I’ve drawn 7.
Luckily, in the end we only really care about three of the modules, namely the API modules, which will enable us to interact with all the things so diligently built into the other 13.

These are the three API’s:

1. CaseConfiguratons_API

2. CaseProcessConfigurations_API

3. CaseServices_API

In broad strokes the first two API’s allow you to create the cases and processes, indicate how they are related to each other and which other features might be connected to them (Calendars, Rule Engines, etcetera).
The final API is the one you use to utilize the things you’ve built with the other two. So with the CaseConfigurations API you might give accesses to specific groups, and with the Cases API you would then check if a specific user has access to the case based on the groups they belong to.

Wait… configuration APIs? How do I use this thing again?

So, the first thing to do when you build a Case Management Application is to configure your case and related processes.

If we oversimplify it a little, Case Management is a complex set of data tables with associated logic. To start using Case Management capabilities we need to fill the data tables with the details of our specific Case. This will allow us to then use the capabilities that the Case Management framework provides us with, such as audit trails, access management and a rule engine.
Warning: Technical Jargon and very specific instructions ahead, sorry. (If you’re not here for that, skip to the final three paragraphs.)

How to do the actual work?
There is a pretty good tutorial that helps you understand that here. The TLDR is as follows: You start with building the data table that keeps data that is specific to your own business case. This is called the Business Entity. Not all the Case data will necessarily be inside this table, but all the data related to the case should be connected to the Business Entity. Your Business Entity has a CaseId as Identifier.

You will also need to make at least one Process that you will link to this Business Entity. In all likelihood you will also need to configure other things, such as Business Rules related to the case, Accesses related to it or perhaps set up a calendar that allows you to manage SLA’s . You do this through the Configuration API’s provided by the Case Management framework. In the tutorial you use a Configuration module with timers and static data entities to accomplish this. I can imagine people might also like to do this through a simple back-office application instead.
If this all sounded like AbraCadabra to you, I recommend following the tutorial, it will make things much easier to understand.

Now that you have set up your Case with associated processes and governance you can start building screens, logic etcetera to start the actual application building. Using the CaseServices API you can interact with the things set up through the configuration part of the building.

To make this a bit more concrete: say that you want to add a rule into a rule engine into your existing Case Management Application. This would be a two step process:

1. You would first go into the configuration module and add the data related to the rule here, using the CaseConfiguration API. When you publish that configuration is bootstrapped into the system. From now on, when that rule is invoked and the conditions you added are met, the outcome you’ve added will be given.
2. You could then go into your process for example and build what will happen when that rule is invoked. Here you are using the CaseServices API to execute the rule, and will use an if-statement to connect that outcome with an action.

*welcome back to the jargon-averse*

Does that sound complicated to you? Well, it is.

If you want to start using these new features, some hands-on experience is absolutely mandatory, as well as a functional understanding of concepts like State Machines, Rule Engines and SLA’s. I will do my best to clarify these concepts in a series of articles over the following months, but it is up to you to start playing with the new tools and build your Case Management skills.
While you are working on your base of knowledge you might want to see some working applications in action. Perhaps you will want to build some scenario’s you come up with to see how that works out.

And that is exactly where the Workflow Builder comes into play. With its simplified User Interface you can very easily set up cases, with an associated process and set of business rules. Underwater it will translate your visual workflow into a Service Studio application, utilizing the case configuration API’s to set up the model for you. The good part is that you then can take a look under the hood and edit the behavior, as if it were an application you’ve developed in Service Studio directly. This is what makes Workflow Builder an easy entry into what is essentially a whole new way of designing applications.
The actual goal of Workflow Builder is of course to provide a good interface for Subject Matter Experts who do not necessarily have the technical expertise to build case management systems through Service Studio. But it also is a great accelerator for you to use while getting started on new Case Management applications.

I hope I’ve given you some more in-depth detail on the Case Management framework and the Workflow Builder. To me it is an interesting addition to the OutSystems toolset that allows me to explore a whole new approach to designing Workflow applications. I’d love to hear about what you think!