Blog 04/12/2013

Adaptive Case Management series – in action – part 1

Introduction

In our previous blog post series Adaptive Case Management series – an overview we explained the details of the case component in ACM. The most important aspects of a case have been highlighted and clarified with the introduction of a real-life (albeit fictional) WABO case. This blogpost series will continue on the previous series and will take a deeper dive into ACM by taking a look at the technical aspects of building an ACM project. In this series we’ll implement the WABO case we’ve sketched in the previous series.
Furthermore we’ll try to give the reader an impression of the adaptivity of an ACM solution by focussing primarily on the business rules component of ACM.

Basic WABO setup

To explore the possibilities of ACM we’ve introduced a simplified WABO process, i.e. the obtainment of a building permit. This is the case we’ll be building in this series. We’ll not go into detail in the basic setup of the ACM project. Please take a look at Case Management Part 2: Anatomy of a Project for a basic explanation on configuring the different components of an ACM case. You can also check this CaseDemo zip file for the source code. The ACM project we’re building consists of three process activities:

Validating the permit application (StartUpProcess);
Reviewing the permit application (FrontDeskTask);
Approving/rejecting the permit application (BouwVergunningProcess).

The first step in the process is the validation of the permit application. In the StartupProcess the contents of the application are checked. The structured data in the case can for the larger part be checked automatically. An application however will also contain unstructured documents. These will be checked manually by a shareholder (FrontDeskTask).

If all the necessary documents and information for the application have been received, the application is considered to be valid and can be submitted for approval. A business rule will take care of starting a new case activity instance subsequently, i.e. the Bouwvergunning BPM process. If this process is completed, the WABO case is considered to be closed.
The above steps describe the happy flow of a WABO case. If all goes according to plan, this is more or less a traditional process. The power of ACM kicks in when e.g. new documents are added to the case or if the application is changed in some other way.

One way to act upon a running case is by means of user events. User events can be fired at any moment and can be acted upon by the business rules engine. User Events will be explored later on in this series.

Case Engine

The picture below shows the interaction between the primary components of a case in ACM (See also Notes on Oracle BPM PS6 Adaptive Case Management). Case stakeholders can start a case via a (custom) GUI (e.g. by means of the Webservice API). This will create and start the case with the data supplied.

As a consequence a lifecycle event gets fired causing the business rules engineto start one or more activities. These can be human tasks as well as BPMN processes. They will in turn fire new case events and/or update case data. As the picture clearly shows there is no fixed flow behind all this. The business rules engine will determine the overall flow and in doing so allows for a high degree of flexibility. See Case Management Part 3: Runtime Lifecycle of a Project for a good reference on case interactions.