Monday Jun 24, 2013

Notes on Oracle BPM PS6 Adaptive Case Management

I have recently been looking at the  latest release of the BPM Case Management feature in the Oracle BPM PS6 release. I had put together some notes to help me gain a better understanding of the context of the PS6 BPM Case Management. Hopefully, this along with the other resources will enable you to gain a clear picture of the flexibility of this feature.

Oracle BPM PS6 release includes Case Management capability. This initial release aims to provide:

  • Case Management Framework

  • Integration of Case Management with BPM & SOA suite

It is best to regard the current PS6 case management feature as a case management framework. The framework provides the building blocks for creating a case management system that is fully integrated into Oracle BPM suite. As of the current PS6 release, no UI tooling exists to help manage cases or the case lifecycle.

Mark Foster has written a good blog which outlines Case Management within PS6 in the following link. I wanted to provide more context on Case Management from my perspective in this blog.

PS6 Case Management - High level View

BPM PS6 includes “Case” as a first class component in a SOA Suite composite. The Case components (added to the SOA Composite) are created when a BPM process is assigned to a case in JDveloper.

The SOA Case component is defined and configured within JDevloper, which allows us to specify the case data structures and metadata such as stakeholders, outcomes, milestones, document stores etc.

"Activities" are associated with a case, and become available to be executed via the case apis. Activities are BPM processes, Human Activities or Java call outs.

The PS6 release includes some additional database tables to store the case metadata and case instance data (data object, comments, etc…). These new tables are created within the SOA_INFRA schema and the documents associated with that case into a document repository that is configured with the case.

One of the main features of Case Management is the control of the case logic through case events and case business rules. A PS6 Case has an associated business rule component, which can be configured to control the availability and execution of activities within the case. The business rules component is able to act upon events that the PS6 Case Management framework generates during the lifecycle of that case. Events are fired during the lifetime of the case (e.g. Case created, activity started, activity ended, note added, document uploaded.)

Internal Case state

The internal state of a case is represented by the diagram below. This shows the internal states and the transition paths for a Case from one state to the next

Each transition in state will create an event that can be enacted upon via the Case rules engine.

The internal case state lifecycle is defined as follows

Defining a case

A Case is created and defined as a component of a JDeveloper BPM project. When you create a Case as part of a BPM project, JDeveloper, creates the following components within the SCA composite:

  • Case component
  • Case component interfaces (WSDL etc)
  • Case Rules component (Oracle Business Rules)
  • Adds the Case Component and Case Rules Component to the BPM SOA composite

Case Configuration

The following section gives a high level overview of the items that can be configured for a BPM Case.

Case Activities

A Case is associated with a set of activities that are to be performed as part of that Case. Case activities can be:

  • SOA Human Tasks
  • BPM processes
  • Custom Task (Java Class)

Case activities are created from pre-existing BPM process or human tasks, which, once defined, can be configured additionally as Case activities in JDeveloper and made available within the lifecycle of a case.

I've described the following configurable components of a case (very!) briefly as:


  • Milestones are (optional) user defined logical milestones that can be achieved within a case.
  • No activities are associates with a milestone, but milestone attainment can be programmatically set and events raised when milestones are reached


  • User defined status of a completed case. An event is fired when an outcome is attained.

Case Data

  • Defines the data that will be stored with a case
  • XML schemas define the data that is stored with the case.

Case Documents

  • Defines the location of documents that are attached to a case (e.g. WebCenter Content)

User Defined Events

  • Optional user defined events that can be fired or captured to drive case processing rules


  • Defines the actors who can participate in the case (roles, users, groups)
  • Defines permissions for individual case permissions (read case, create document etc…)

Business Rules

  • Business rules are the main component controlling the flow of a Case
  • Each case has an associated business ruleset
  • Rules are fired on receiving Case events (or User defined events)
    • Life cycle events
    • Milestone events
    • Activity events
    • Data events
    • Document events
    • Comment events
    • User event

Managing the Case

Managing the lifecycle of a case is achieved in two ways:

  • Managing case logic with Business Rules
  • Managing the case lifecycle via the Case APIs.

A BPM Case can be viewed as a set of case data & documents along with the activities that can be performed within a case and also the case lifecycle state expressed as milestones and internal lifecycle state.

The management of the case life is achieved though both the configuration of business rules and the “manual” interaction with a case instance through the Case APIs.

Business Rules and Case Events

A key component within the Case management framework is the event model. The BPM Case Management solution internally utilizes Oracle EDN (Event Delivery Network) to publish and subscribe to events generated by the Case framework.

Events are generated by the Case framework on each of the processes and stages that a case instance will travel on its lifetime. The following case events are part of the BPM Case:

    • Life cycle events
    • Milestone events
    • Activity events
    • Data events
    • Document events
    • Comment events
    • User event

The Case business rules are configured to listen for these events, and business logic can be coded into the Case rules component to enact upon an event being received.

Case API & Interaction

Along with the business rules component, Cases can be managed via the Case API interfaces. These interfaces allow for the building of custom applications to integrate into case management framework. The API’s allow for updating case comments & documents, executing case activities, updating milestones etc.

As there is no in built case management UI functions within the PS6 release, Cases need to be managed via a custom built UI, interacting with selected case instances, launching case activities, closing cases etc. (There is expected to be a UI component within subsequent releases)

Logical Case Flow

The diagram below is intended to depict a logical view of the case steps for a typical case.

  1. A UI or other service calls the Case interface to create a Case instance
  2. The case instance is created & database data inserted
  3. A lifecycle event is raised indicating a case activity (created) event
  4. The case business rules capture the event and decide on an action to take
  5. Additionally other parties can subscribe to Case events via EDN
  6. The business rules may handle the event, e.g. configured to execute a case activity on case creation event
  7. The BPM/Human Workflow/Custom activity is executed
  8. A case activity event is raised on the execute activity
  9. A case work UI or business service can inspect the case instance and call other actions to progress that case, such as:
    • Execute activity
    • Add Note
    • Add document
    • Add case data
    • Update Milestone
    • Raise user defined event
    • Suspend case
    • Resume case
    • Close Case


Having had a little time to play around with the APIs and the case configuration, I really like the flexibility and power of combining Oracle Business Rules and the BPM Case Management event model. Creating something this flexible and powerful without BPM Case Management would take a lot of time and effort. This is hopefully going to save my customers a lot of time and effort!

I may make amendments to this post as my understanding of Case Management increases!

Take a look at the following links for official documentation etc.


Welcome to my blog, a space for me to share information on various Oracle middleware technology issues. My day job as an architect within UK Oracle Consulting enables me to look at solutions for a wide variety of issues and I will share some of these issues and solutions here in the hope that it will help you out some day!


« August 2016