Case Management Part 2: Anatomy of a Project
By Mark Foster on Apr 03, 2013
In Oracle BPM 11g PS6, BPM Studio (JDeveloper) is the design-time environment for Case Management. This blog entry will describe the make-up of a Case Management project in BPM Studio, stepping through all the terms and properties associated but will stop short of giving recommendations or best-practices, which will follow in a later blog entry.
BPM Studio: Case Management Project
- One Case per BPM project.
- Checkpoints in the progress of a Case
- Logical grouping of deliverables – no direct activity or work associated
- User-defined statuses on completion of a case
Data & Documents Tab
- Data associated with the Case – user defined / XSD etc
- Manually added in this tab for use within Case
- Automatically added on creation of new case activity
- Where the data associated with the Case is stored
- Defaults to database
- Oracle UCM & Alfresco CMIS as current alternatives (April 2013)
User Events Tab
- Manual actions that can occur during the lifetime of a case which trigger events inside the case
- An example would be – a fax arrives and a milestone can be marked as complete
Stakeholders & Permissions Tab
- People involved in the processing of the Case – the case workers
- Defined as a user, group, application role or process role
- By default granted all available permissions on case objects, modifiable after deployment by Administrator….
- Attached to case objects such as documents and data to define who has what kind of access to objects
- CONFIDENTIAL & PUBLIC by default, can add custom permissions
- Allows localization of a Case and its case objects
Represent specific work in the context of a case and can comprise....
- A Human Task....
- A BPMN Process....
- Custom (java code)....
Once created, Case Activities can be configured as follows....
- Manual – activated from the UI
- Automatic – activated by the engine on some condition
- Required – must always be activated
- Repeatable – can be activated more than once
- Conditionally Available – only available to be manually or automatically activated depending on business rule
- Permission – who has access to this activity ?
- Determined by input & output of the human task or BPMN process if this case activity relates to these
- Entered manually for custom activity
Case Business Rules
- Each Case has a business rules dictionary generated automatically
- Rules can be added to the ruleset accordingly to control the flow of the case
- Rules can be fired on every type of case event…
- Life cycle events
- Milestone events
- Activity events
- Data events
- Document events
- Comment events
- User event
As an example, assume that once milestone “Returned” has been reached the activity “ChargeCustomer” should be activated….
Interacting With a Case - Proactively
- From the User Interface (see later blog entry)
- Service call from composite artefact (BPM, mediator etc…)
- API call
- Available operations
Interacting With a Case - Reactively
- Event Delivery Network (EDN)
- System events automatically generate EDN events....
- case lifecycle
- case activity lifecycle
- User events can be set to publish to EDN....
Now that we have investigated the design-time for Case Management inside BPM Studio and understand the concepts behind it, we will move on to looking at a typical lifecycle of a simple Case Management project.