WF Example to Demonstrate WF Orchestration

D.1 Introduction

As discussed briefly in Section 5.7 of the main body of the dissertation, an example will be used of an insurance claim processing workflow (shown in Figure D.1) to demonstrate how WEWE built on the blackboard paradigm will orchestrate this workflow. This will provide the reader of a better holistic understanding of the workflow engine. This Appendix is dedicated to provide detailed information about how this workflow process is actually orchestrated in WEWE.

Figure D.1: Hypothetical workflow of approving or rejecting an insurance claim.

D.2 Designing the Specialists

It is found through experimentation that specialists should be created for every single atomic workflow activity. It is possible that all the workflow activities within the workflow can be put inside one single specialist as many rules. However, this prevents the concurrent execution of workflow activities that are required to be executed concurrently. Furthermore, blackboard data write conflicts will occur. Therefore, many modular specialists should be created for concurrency and to prevent data conflicts on the blackboard.

Send to Inspector & Access Claim

___________

Specialist A Process Claim

___________ Specialist B Notify Client (decline) ___________ Specialist D Notify Client (approve) ___________ Specialist C end end start u se r message

D.3 WF Proccess Orchestration

This section will deliver detailed information about the WF process orchestration which will include the state of the blackboard and the interactions of the specialist and agents that change the state of the blackboard at every stage of the workflow.

D.3.1. WF Spawn

When a new WF process is spawned, a new WF process object is created by the orchestrator and placed on the blackboard with the following data as seen in Figure D.2. It can be seen that the production data is stored as constants so specialists can simply use data and not alter it in any way. All the constants are stored as Plain Old Java Objects (POJOs) containing information about the insurance claim; the client’s information and the insurance inspector’s information that the specialists can use to execute their actions.

Figure D.2: Initial blackboard data when the process is spawned.

From the blackboard in Figure D.2, there is a flag to enable the assess claim action but no trigger flag to actually execute the action, since it is user triggered. The first rule of Specialist A has an action to send the claim information to the claim inspector when the ‘assess claim’ action is enabled. This is seen in Figure D.3 as only the first of the three rules is actually executed. The action of this rule does not change the content of the blackboard but uses the content on the blackboard specifically all the production data (constants) in order to send the insurance claim information to the inspector.

Blackboard

Variables

enable_assess_claim True

Constants

Insurance Claim Information WF Object (POJO)

Client Information WF Object (POJO)

D.3.2. Access Claim Activity

Figure D.3: Specialist A interacting with the blackboard.

The inspector will assess the claim through a client application within the WFMS. When the inspector accepts or rejects the claim, agents are created by the client application that will post data to the WF process object on the blackboard as seen in Figure D.4. In this example, the inspector approves the claim. Two agents will post the data on the blackboard; one will post the approval and the other will post a trigger flag for executing the ‘assess claim’ action. This change on the blackboard will enable the specialists to start monitoring the blackboard.

Blackboard

Variables

enable_assess_claim True

Constants

Insurance Claim Information WF Object (POJO)

Client Information WF Object (POJO)

Insurance Inspector Information WF Object (POJO)

Specialist A

IF (enable_assess_claim AND NOT(execute_assess_claim)) Send Claim

IF (enable_assess_claim AND execute_assess_claim) IF (claim_approved)

Assess Claim Enable Process Claim

Disable assess claim triggers Execute Process Claim

IF (enable_assess_claim AND execute_assess_claim) IF (NOT claim_approved)

Assess Claim Enable Notify Client (Decline)

Figure D.4: Agents interacting with the blackboard to trigger an action.

Specialist A monitoring this WF process object on the blackboard will notice that ‘execute_assess_claim’ trigger flag exists. Specialist A will execute its second rule that will be executed when the inspector approves the claim. The third rule will never be executed in this example since it is only executed when the inspector rejects the claim. The second rule consists of the ‘assess claim’ action which is an action to log the inspector’s actions on a tracking system. It can be seen that there are two separate action threads in this second rule. While the specialist is executing the current action of logging the access claim details on the tracking system, it simultaneously enables and triggers the next action to ‘process claim’. Notice that the next action of ‘process claim’ is automatically enabled and triggered so it can automatically be executed after the ‘assess claim’ action. After the ‘assess claim’ action is executed, the specialist also disables the triggers to the ‘enable_assess_claim’ and ‘execute_assess_claim’ actions (changed to the Boolean, false) which is crucial. If this is not done, Specialist A will keep on executing its second rule. Specialists respond to triggers on the blackboard. If the triggers remain unchanged, this workflow will be locked in a certain state that might only execute one specialist (one WF activity) repeatedly.

Blackboard Variables enable_assess_claim True execute_assess_claim True claim_approved True Constants

Insurance Claim Information WF Object (POJO)

Client Information WF Object (POJO)

Insurance Inspector WF Object (POJO)

Insurance Claim Approval Information WF Object (POJO)

Create Agent Execute Assess Claim

Create Agent

Approve Insurance Claim

Figure D.5: Specialist A interacting with the blackboard for the second time.

D.3.3. Process Claim Activity

Specialist A has placed the triggers on the blackboard to execute the WF activity in Specialist B which is to process the claim as seen in Figure D.5. Specialist B will execute its first rule and process the claim. Thereafter, the triggers to process the claim will be disabled so that Specialist B will not execute its rules repeatedly. While Specialist B is executing its actions, it will enable the next WF activity which is to notify the client that the claim has been approved. This is shown in Figure D.6.

Blackboard Variables enable_send_claim False execute_sent_claim False enable_assess_claim False execute_assess_claim False claim_approved True enable_process_claim True execute_process_claim True Constants

Insurance Claim Information WF Object (POJO)

Client Information WF Object (POJO)

Insurance Inspector WF Object (POJO)

Insurance Claim Approval Information WF Object (POJO)

Specialist A

IF (enable_assess_claim AND (NOT execute_assess_claim)) Send Claim To Inspector

IF (enable_assess_claim AND execute_assess_claim) IF (claim_approved)

Assess Claim Enable Process Claim

Disable assess claim triggers Execute Process Claim

IF (enable_assess_claim AND execute_assess_claim) IF (NOT claim_approved)

Assess Claim Enable Notify Client (Decline)