Best Practices from Oracle Development's A‑Team

Case Management in BPM 11g

Mark Foster


Oracle BPM 11g & Case Management - PRE PS6

I've seen many customers using BPM 11g to develop a case-management solution, and I've seen many questions on forums asking whether BPM 11g supports case-management. The current plan is, that BPM PS6 & more specifically, BPM 12g, will be a much better fit for more dynamic case-management than BPM 11g, however using BPM 11g is not trying to force a square peg into a round hole, more like fitting it in a rectangular hole.... the fit is good but there are some gaps which need to be filled outside of BPM 11g, but it can be done elegantly. More than this, any effort in producing a case-management solution in BPM 11g can easily be re-used in BPM 12g with the added bells & whistles this is currently planned to bring.

Main Article

The intention of this blog is to provide a simple and proven pattern for case-management in BPM 11g and given time, in subsequent blogs, build this up into a working solution.

Case Management - Terminology

First I'd like to define some terms, as it is clear that there is much confusion about what case-management is, and how the concepts of adaptive/dynamic case management & social BPM relate to it. These are my opinions, gleaned from reading many articles on the subject, however there is a lot of discussion out there on just these terminologies.


  • A solution based on top of BPM where the "case" and its data provide the shared-context for all activities in the case.
  • Would normally include artefacts outside of BPM, such as UCM functionality, but these would form an intrinsic part of the process.
  • Would tend to be knowledge-worker driven, and as a consequence, not as prescriptive as classic BPM.
  • As a result processes tend to be more "state-machine" like, i.e. driven by events or data, rather than flow-based.
  • Can be modelled, with some gaps, in Oracle BPM 11g

Adaptive/Dynamic Case Management:

  • Case-management++
  • Tends to be goal or milestone driven, i.e. as long as a milestone is reached, the journey is, to a certain extent, irrelevant.
  • Multiple examples of phases of the case can be chosen between at runtime, possibly rated socially, e.g. many ways to do a credit check.
  • New phases of the case can be created on-the-fly at runtime and added to the pool of phase choices. Existing phases can be adapted dynamically.
  • Planned for Oracle BPM 12g
  • "Flavor of the month" - many customers think they need ACM but on closer inspection either don't need it ("standard" case management would suffice) or are not yet able to handle the agility it bring from a technical perspective

Social BPM:

  • BPM + E2.0.
  • Embedding of collaborative tools & concepts in BPM such as IM, Twitter, rankings etc. and more importantly providing these within the context of the business process
  • Important feature for both simple & adaptive case management.
  • Mostly available in Oracle WebCenter Spaces 11g but not 100% integrated with BPM 11g, plan is to be fully integrated in Oracle BPM 12g.... see the recent announcement around Oracle Social Network for ideas where this may lead.

Scenario Bank Transfer

Outline of the Process

  • an individual has accounts at one bank and wishes to transfer them to the target bank
  • individual has any combination of credit cards, current/savings accounts, mortgages, pensions etc... all of which should be transferred
  • individual may need to be credit checked, this is at the discretion of the process owner
  • individual has an active role in the procedure, needing to sign forms etc... thus phases of the process can be long-running
  • the process owner needs to keep track of the progress of all phases
  • at any point in the procedure, the process owner can cancel the request
  • once all relevant phases have completed, the process owner can successfully terminate the bank transfer process

Step 1: Create the Case Process

The “Case” process is the overriding controlling process for the solution. It is initiated via a webservice call, as opposed to an initiating human activity, in order to make the process as generic as possible. The process ID is immediately returned as this will be used for later correlation. A Human activity and associated task/UI allows the user to asynchronously initiate one or many “Phase” processes (for example “credit check”, “move account”, “order cards” etc...) before looping back to the same human activity for further “Phase” process initiation, monitoring of the “Phase” process statuses or completion/cancellation of the “Case”. The call to the “Credit Check Phase” is implemented as an asynchronous send & receive, the Phase itself is a completely separate & re-usable process.











Step 2: Create the “Credit Check” Phase Process

The Credit Check “Phase” process is one of many potential phases that the user can choose to initiate from the “Case”. The process ID is immediately returned as this will be used for later correlation. All further
activities are placed in an embedded sub-process, the reason for which will become apparent later (to allow cancel functionality). Based on the balance of the account being transferred, either the credit check is approved, denied or needs manual approval for which a human activity and associated task/UI is provided.



Step 3: Add the Event Sub-Process to Case Process to Allow Asynchronous

In order to asynchronously cancel the request at any time, an Interrupting Event Sub-Process (denoted by a solid border on the associated message start event) is required in the Case process, correlated on the process ID. This event sub-process throws a signal event, to be caught by any dependant Phase processes and then terminates, thus terminating the overall Case process.



Step 4: Add the Signal Catch in the Phase Process

The ideal solution for cancelling the phases would be to have an interrupting event sub-process initiated by a catch signal event, however the plan is to support interrupting signals from BPM 12c. The alternative is to have a non-interrupting signal catch immediately followed by an error throw, this error can be caught at the boundary of the embedded sub-process and followed by a terminate end event which will terminate the Phase process. This pattern can be repeated for all dependant Phase processes.



Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha

Recent Content