Case Management In Practice: “HelloWorld”

In the previous blog entries in this Case Management series we’ve looked at what case management is, how a case management project surfaces in BPM Studio, the lifecycle of a case management project at runtime, and a more in-depth look at case stakeholders & permissions, case activities and case rules.

Enough of the theory for the time being… in this entry we’ll build our first simple case management project… not “HelloWorld” exactly, but an uncomplicated first step into case management – a simplistic version of an insurance claim. We’ll use this project in further blog entries to demonstrate some of the more advanced features that Case Management provides for us in PS6 and beyond.

Project Overview

As mentioned, this will be an overly simplified insurance claim project. There will be two stakeholders, an investigator and an underwriter, the investigator is responsible for validating the claim and the underwriter is responsible for paying (or not) the claim. There will be two corresponding case activities, “investigate claim” and “underwrite claim”, the former will be automatically invoked on case start, the latter automatically invoked when the claim has been validated. Both of these activities will be composed of a simple BPM process. We’ll add two milestones as well, one for each of the activities.

That’s it… we’ll use some of the techniques described in previous blog entries to help with the build of the project, in particular the spreadsheet approach to case activities.

Design the Project in BPM Studio

Application, Project & Composite

Create a new “BPM Application” and name it “CMInsuranceClaim”….

CMPS6_8_01

….name the project “prjCMInsuranceClaim”…

CMPS6_8_02

…. and create as a “Composite with Case Management”…

CMPS6_8_03

… this will result in a composite with the case and its exposed service and the case rules….

CMPS6_8_04

Flesh out the Case

Open the Case artefact….

CMPS6_8_05

… and fill in the case title. Also create two milestones: “Investigated” and “Underwritten”….

CMPS6_8_06

… click on the “Stakeholders & Permissions” tab and create two stakeholders: “Investigator” & “Underwriter”….

CMPS6_8_07

… add user “jcooper” as “Investigator” and user “jausten” as “Underwriter” ….

CMPS6_8_08

Create the Case Activities

As previously mentioned both activities (investigate and underwrite) will be formed of BPM processes.

Case Data

We will use the following XSD to represent the case data: you can copy and paste the contents to an XSD file….

<?xml version="1.0" encoding="UTF-8" ?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
            xmlns:insuranceClaim="http://www.oracle.com/insuranceClaim"
            targetNamespace="http://www.oracle.com/insuranceClaim"
            elementFormDefault="qualified">
  <xsd:complexType name="ClaimType">
    <xsd:sequence>
      <xsd:element name="Claimant" type="xsd:string" maxOccurs="1"/>
      <xsd:element name="ClaimDetail" type="xsd:string" maxOccurs="1"/>
      <xsd:element name="ValueWhenNew" type="xsd:int" maxOccurs="1"/>
      <xsd:element name="AgeOfItem" type="xsd:int" maxOccurs="1"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:complexType name="ClaimDecisionType">
    <xsd:sequence>
      <xsd:element name="ClaimFindings" type="xsd:string" maxOccurs="1"/>
      <xsd:element name="ClaimRecompense" type="xsd:int" maxOccurs="1"/>
    </xsd:sequence>
  </xsd:complexType>
  <xsd:complexType name="InsuranceClaimType">
      <xsd:sequence>
        <xsd:element name="Claim" type="insuranceClaim:ClaimType" maxOccurs="1"/>
        <xsd:element name="ClaimDecision" type="insuranceClaim:ClaimDecisionType" maxOccurs="1"/>
      </xsd:sequence>
  </xsd:complexType>
  <xsd:element name="insuranceClaim" type="insuranceClaim:InsuranceClaimType"/>
  <xsd:element name="claim" type="insuranceClaim:ClaimType"/>
  <xsd:element name="claimDecision" type="insuranceClaim:ClaimDecisionType"/>
</xsd:schema>

BPM Process – Investigate Claim

Create a new BPM process….

CMPS6_8_09

… name it “bpmInvestigate”….

CMPS6_8_10

… create an input argument named “insuranceClaim”….

CMPS6_8_12

… based on a business object named “BoInsuranceClaim”….

CMPS6_8_13

… under a module called “Data”….

CMPS6_8_14

… browse to the XSD previously mentioned….

CMPS6_8_15

CMPS6_8_16

CMPS6_8_17

… and choose the “insuranceClaim” element….

CMPS6_8_18

CMPS6_8_19

… repeat for the output argument (same name, same element)….

CMPS6_8_20

Add a “User Activity” to the process….

CMPS6_8_22

… note that the previously created Stakeholders are available as swimlane roles, choose the “Investigator”….

CMPS6_8_23

CMPS6_8_24

Create a “process data object” “doInsuranceClaim” for the insurance claim….

CMPS6_8_25

 

Implement the Human Activity….

CMPS6_8_26

Do the data associations for the “Start” and “End” activities….

CMPS6_8_27

CMPS6_8_28

Auto-generate a task form from the human task….

CMPS6_8_29

… in project “UIInvestigateClaim”….

CMPS6_8_30

The process is now completed… let’s promote it to a case activity (called “actInvestigate”) and see what happens….

CMPS6_8_31

CMPS6_8_32

The first thing we notice is that the input & output data for the case activity has taken the name (& type) of the process input & output arguments….

CMPS6_8_33

If we go back to the Case itself we can see that the “insuranceClaim” has been automatically added to the case data….

CMPS6_8_34

BPM Process – Underwrite Claim

Before we go any further with the case itself, let’s create an almost identical process for underwriting the claim…. I won’t explicitly detail the steps again, they are more or less the same as above….

Process Name: bpmUnderwrite

Input & Output arguments: insuranceClaim (same as previously)

Swimlane role: Underwriter

Task form project: UIUnderwriteClaim

Case Activity Name: actUnderwrite

Note to make the human task parameter “insuranceClaim” editable this time….

CMPS6_8_35

Once we have created the underwrite process and case activity, we shouldn’t see any additions to the case data as we used the same name & type for both processes (activities)….

CMPS6_8_34

Design the Case Activities & Case Rules

If we cast our mind back to the spreadsheet approach for case design detailed in a previous blog post, we’ll use exactly that now to help us. As mentioned at the top of the post, the Investigate activity should trigger automatically when the case starts, when investigation is finished the appropriate milestone is reached and the Underwrite activity can then start, when this finishes its milestone is reached.

We can represent this in spreadsheet form thus….

CMPS6_8_36

 

Case Activities

With this we can now set the properties for the case activities.

actInvestigate” is automatic and required….

CMPS6_8_37

actUnderwrite” is automatic, required and conditional….

CMPS6_8_38

Case Rules

Open the case rules dictionary….

CMPS6_8_39

Milestone Rules

Let us begin with the “Milestone” rules, i.e. those rules which have milestone based conditions, looking at the spreadsheet above there is only one: when milestone “Investigated” is reached, activity “actUnderwrite” is activated.

Let’s create a new decision table….

CMPS6_8_40

… and call it “MilestoneRule”….

CMPS6_8_41

We need two conditions to represent the milestone “Investigated” being “REACHED”….

CMPS6_8_42

… and an associated action of “call” to “activateActivity” “actUnderwrite”….

CMPS6_8_43

Activity Rules

Create another decision table for the activity rules….

CMPS6_8_44

We need two conditions to represent the activities being “COMPLETED”….

CMPS6_8_45

…and two rules, one for each activity….

CMPS6_8_46

… and the associated actions to “reach” the appropriate milestones….

CMPS6_8_47

Deploy the Projects

Deploy the two UI projects….

CMPS6_8_48

… and the Case Management project….

CMPS6_8_49

Set the Human Task Participants 

If you remember we explicitly set the stakeholders when creating the case in BPM Studio (Investigator was “jcooper”, Underwriter was “jausten”) but we did not set the human task participants for the user activities in the associated bpm processes… there is a clear distinction here between knowledge workers (stakeholders) who work at the the level of the case, and routine workers (human task participants) who work at the level of human tasks.

Log into the BPM Workspace as “weblogic” (an administrator) and in the “Administration” tab set the human task participants, in this case as the same users as the stakeholders although as stated this is neither necessary or particularly relevant in a real-life use-case….

CMPS6_8_50

Run the Case Management Project

If we look at the composite to see what exactly we deployed….

CMPS6_8_51

… we can see that there is a “startCase” operation available on the case itself, which means we can start the case from the “Test” button inside Enterprise Manager….

CMPS6_8_52

CMPS6_8_53

Let’s change from “Tree View” to “XML View” and copy/paste the following XML into the input argument….

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Body>
    <ns1:startCaseInputMessage xmlns:ns1="http://xmlns.oracle.com/CaseService/types"                                             
              xmlns:ns2="http://xmlns.oracle.com/bpm/case">
      <ns2:case>
        <ns2:caseId>001</ns2:caseId>
        <ns2:caseHeader>
          <ns2:caseId></ns2:caseId>
          <ns2:caseNumber></ns2:caseNumber>
          <ns2:caseName></ns2:caseName>
          <ns2:caseDisplayName></ns2:caseDisplayName>
          <ns2:title></ns2:title>
          <ns2:priority></ns2:priority>
          <ns2:createdBy></ns2:createdBy>
          <ns2:createdByDisplayName></ns2:createdByDisplayName>
          <ns2:createdDate></ns2:createdDate>
          <ns2:state></ns2:state>
          <ns2:stateDisplayName></ns2:stateDisplayName>
          <ns2:ecmFolder></ns2:ecmFolder>
          <ns2:caseDefinitionId></ns2:caseDefinitionId>
          <ns2:caseDefinitionName></ns2:caseDefinitionName>
          <ns2:caseNamespace></ns2:caseNamespace>
          <ns2:identificationKey></ns2:identificationKey>
          <ns2:category></ns2:category>
          <ns2:categoryDisplayName></ns2:categoryDisplayName>
          <ns2:outcome></ns2:outcome>
          <ns2:outcomeDisplayName></ns2:outcomeDisplayName>
          <ns2:sca></ns2:sca>
        </ns2:caseHeader>
        <ns2:stakeHolders></ns2:stakeHolders>
        <ns2:milestones></ns2:milestones>
        <ns2:data>
      <ns2:id></ns2:id>
      <ns2:caseId></ns2:caseId>
      <ns2:name>insuranceClaim</ns2:name>
      <ns2:displayName></ns2:displayName>
      <ns2:data>
            <insuranceClaim xmlns="http://www.oracle.com/insuranceClaim">
  <Claim>
    <Claimant>Joe Bloggs</Claimant>
    <ClaimDetail>Crashed Car</ClaimDetail>
    <ValueWhenNew>10000</ValueWhenNew>
    <AgeOfItem>3</AgeOfItem>
  </Claim>
  <ClaimDecision>
    <ClaimFindings></ClaimFindings>
    <ClaimRecompense></ClaimRecompense>
  </ClaimDecision>
</insuranceClaim>
      </ns2:data>
      <ns2:updatedDate></ns2:updatedDate>
      <ns2:updatedBy></ns2:updatedBy>
      <ns2:updatedByDisplayName></ns2:updatedByDisplayName>
   </ns2:data>
        <ns2:comments></ns2:comments>
        <ns2:caseFabricHeaderProperty></ns2:caseFabricHeaderProperty>
      </ns2:case>
    </ns1:startCaseInputMessage>
  </soap:Body>
</soap:Envelope>

The important (and differing) parts are circled in red below.

We need to provide a caseId…

CMPS6_8_55

… we also need to provide the case data… being constructed directly from the XSD provided earlier and pasted between the start and end data tags.

CMPS6_8_56

We can see after “testing the webservice” that it was successful… we can look at the flow trace to see what has happened….

CMPS6_8_57

So…  the starting of the case has automatically triggered the Investigate activity and therefore initiated its associated Investigate process which is waiting at the human task… this should be assigned to “jcooper”… let’s log in to the BPM Workspace to check….

CMPS6_8_58

… sure enough there it is… let us complete the investigation by clicking on the “Yes” action.

We can now go back and look at the flow trace again to see how our case has progressed….

CMPS6_8_59

… the investigate process (and activity) has completed, the case rules have been invoked and as a result the Underwrite activity (and process) has been invoked, it’s now waiting at the human task associated with underwriting which should have been assigned to “jausten”… let’s log in to the BPM workspace and check….

CMPS6_8_60

…and there it is, let’s complete it by clicking on “Yes”.

We can go back once more and look at the flow trace to see the current status of our case….

CMPS6_8_61

… both case activities have now been completed. Success !

Summary

In this blog post we have successfully created, deployed and tested our first Case Management project using lessons learned in some of the previous blog entries in this series.

But… and it’s a big but… this should have raised some questions….

  • why is the case still running when we’ve completed the activities
  • why have the case rules been invoked a seemingly inordinate number of time
  • what happens if we have manual activities instead of automatic activities
  • etc….

In future blog posts we’ll try and answer some of these questions, demonstrating using our first deployed project.

Add Your Comment