Blog 08/11/2013

Adaptive Case Management series – an overview – part 2

ACM

ACM should make it possible to to support the unstructured processes described in part 1 of this Adaptive Case Management series, while adding more flexibility and less development effort to the implementation. The central part of ACM is the case. Oracle’s definition of a case is “a collection of structured, semi-structured, un-structured processes, information and interactions used to make a business decision” (Working with Case Management).

ACM at it’s current standing offers:

A standard case data model exposed via a SOAP webservice API as well as a Java API. The data model is available as XML data as well within eg. a BPM process or the Business Rules Engine;
The standard data model can be extended with custom business related elements. This is called data in ACM;
A case model containing important attributes as milestones, outcomes and stakeholders;
A case lifecycle coupled with lifecycle events (eg. a case started event). Events are raised after the lifecycle state is reached and can be acted upon;
Integration with BPM and Human Workflow. Both components can be promoted to a so called activity and coupled to a case;
Integration with the Event Delivery Network (EDN). Lifestone, milestone, activity and user events are all based on EDN and can be published as EDN events;
Content management functionality enabling a user to add documents to a case;
A Business Rules component. Dit is the central agent of a case and offers a high degree of flexibility and adaptivity to ACM. Business Rules can act upon events (optionally filtered on the values of case data) and can trigger actions (eg. call an activity). Business Rules are adaptable at runtime and in theory could be customized by someone with sufficient business knowledge without development effort.

An ACM Case can be an integral part of a Service Composite Application (SCA). Like BPM and SOA, development on ACM is done in JDeveloper. The case in it’s essential part consists of nothing more than the case component and a business rules component wrapped in a composite and exposed via a standard SOAP interface. The interface consists of operations for operating on a case (see the section on case lifecycle) and for operating on milestones.

WABO Case

Currently ACM doesn’t provide a standard GUI for managing and querying the case. One could of course develop a custom GUI making heavy use of the Java API (called the Case Management API). Given the fact that this is the first release of ACM, it is to be expected that in future versions a default (generatable) GUI will be delivered by Oracle. This GUI could possibly be integrated within the BPM workspace. It could also be possible that Webforms (also introduced in patchset 6) will play a central role in developing the Case GUI.

Case lifecycle

The picture below gives an overview of the case lifecycle

Case Lifecycle

The different states a case can be in, are somewhat self explanatory. The operations depicted in the figure correspond with the operations exposed by the external SOAP API. The state transitions clearly show that the case is not coupled to a standard process flow. A case can swith back and forth to many states. A closed case can, if necessary, be reopened. This makes ACM ideal for an ad hoc process like WABO. When for instance a permit application is rejected and the case is closed, it’s possible to reopen it again at a later time, after eg. land-use plans have changed. This relieves the applicant of the tedious task of submitting all the information all over again.

Overzicht blogs