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.
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”….
….name the project “prjCMInsuranceClaim”…
…. and create as a “Composite with Case Management”…
… this will result in a composite with the case and its exposed service and the case rules….
Flesh out the Case
Open the Case artefact….
… and fill in the case title. Also create two milestones: “Investigated” and “Underwritten”….
… click on the “Stakeholders & Permissions” tab and create two stakeholders: “Investigator” & “Underwriter”….
… add user “jcooper” as “Investigator” and user “jausten” as “Underwriter” ….
Create the Case Activities
As previously mentioned both activities (investigate and underwrite) will be formed of BPM processes.
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….
… name it “bpmInvestigate”….
… create an input argument named “insuranceClaim”….
… based on a business object named “BoInsuranceClaim”….
… under a module called “Data”….
… browse to the XSD previously mentioned….
… and choose the “insuranceClaim” element….
… repeat for the output argument (same name, same element)….
Add a “User Activity” to the process….
… note that the previously created Stakeholders are available as swimlane roles, choose the “Investigator”….
Create a “process data object” “doInsuranceClaim” for the insurance claim….
Implement the Human Activity….
Do the data associations for the “Start” and “End” activities….
Auto-generate a task form from the human task….
… in project “UIInvestigateClaim”….
The process is now completed… let’s promote it to a case activity (called “actInvestigate”) and see what happens….
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….
If we go back to the Case itself we can see that the “insuranceClaim” has been automatically added to the case data….
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….
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)….
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….
With this we can now set the properties for the case activities.
“actInvestigate” is automatic and required….
“actUnderwrite” is automatic, required and conditional….
Open the case rules dictionary….
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….
… and call it “MilestoneRule”….
We need two conditions to represent the milestone “Investigated” being “REACHED”….
… and an associated action of “call” to “activateActivity” “actUnderwrite”….
Create another decision table for the activity rules….
We need two conditions to represent the activities being “COMPLETED”….
…and two rules, one for each activity….
… and the associated actions to “reach” the appropriate milestones….
Deploy the Projects
Deploy the two UI projects….
… and the Case Management project….
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….
Run the Case Management Project
If we look at the composite to see what exactly we deployed….
… 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….
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…
… 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.
We can see after “testing the webservice” that it was successful… we can look at the flow trace to see what has happened….
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….
… 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….
… 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….
…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….
… both case activities have now been completed. Success !
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
In future blog posts we’ll try and answer some of these questions, demonstrating using our first deployed project.
All site content is the property of Oracle Corp. Redistribution not allowed without written permission