Chapter Ten. Example: Human Workflow in Insurance Claims Processing

IN THIS CHAPTER (AND THE NEXT), WE WILL BUILD FEATURE-RICH, working examples that demonstrate some of the key concepts of process modeling. This chapter shows the design of a BPEL insurance claims process that is driven by human workflow, or by human participants performing manual activities. (See the section "Human Interaction" in Chapter 2 for a discussion of human workflow architecture.)

The process is implemented in Oracle BPEL Process Manager , a BPEL 1.1-compliant runtime engine that includes a design editor, an administrative console, and a human task manager subsystem; this chapter provides everything you need to know to download, install, and configure a working environment for the example.^[*]

^[*] Oracle, "BPEL Quick Start Guide," http://www.oracle.com/technology/products/ias/bpel/pdf/orabpel-QuickStart.pdf.

The UML activity diagram in Figure 10-1 provides a high-level overview of the behavior of the insurance process .

When the process begins, the Evaluate activity is started, which represents manual work in which an insurance agent examines the details of the claim and decides whether to accept or reject it outright, or to pass it to an adjuster for further analysis, as part of the

Figure 10-1. UML activity diagram of insurance process

Analyze activity. That activity can also result in an acceptance or refusal, and it can also time out if not completed in two days. The time-out triggers a transition to the Escalate activity, a manual task performed by a manager, who decides once and for all whether to accept or reject the claim. The processing of rejection and acceptance is the same throughout; rejection stops the process, and acceptance triggers the Activate activity, where the claim is finalized in the insurance company's systems and payment is sent to the subscriber. The process can be cancelled at any point during its execution; in parallel with its mainline processing, the process listens for a kill signal and terminates upon receipt.

Figure 10-2 illustrates a BPEL structure for this example.

The process begins with a receive activity that inputs the initial claim. The rest of the main logic is modeled as a flow activity with conditional links. The first activity is Eval sequence, which manages the execution of the Evaluate manual task asynchronously as an invoke-receive sequence; that is, it calls a service to start the task and waits for its completion. From the Eval sequence originate three conditional links: rejected, accepted, or requiresAnalysis, TRansitioning to Rejection logic, Activation logic, or Analyze sequence, respectively. Like Eval sequence, Analyze sequence starts its task with an invoke, but the remainder of its processing is more complex: it uses a pick to wait either for completion of the task (onMessage) or timeout (onAlarm). Completion means rejection or acceptance, leading, as before, into Rejection logic or Activation logic, respectively. A timeout links to the Escalate sequence, whose invoke-receive structure is isomorphic to that of Eval sequence. Escalate sequence is the penultimate step, preceding either Rejection logic or Activation logic depending on its decision of rejection or acceptance. In the background, an onMessage listener in a process-scoped EventHandler listens for a kill message and terminates the process on receipt.

Figure 10-2. BPEL model of insurance process