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.
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.
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.
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.
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.
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.
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.