Best Practices from Oracle Development's A‑Team

BPM 11g - Case Management Part 2: Anatomy of a Project

Mark Foster

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.

General Tab

  • 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

Translation Tab

  • Allows localization of a Case and its case objects

Case Activities

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
    • abortCase
    • closeCase,
    • reopenCase
    • suspendCase,
    • resumeCase
    • attainMilestone
    • revokeMilestone

Interacting With a Case - Reactively

  • Event Delivery Network (EDN)
    • System events automatically generate EDN events....
      • case lifecycle
      • case activity lifecycle
      • Milestone
      • Document
      • Comment
    • User events can be set to publish to EDN....

Coming Next

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.


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