Build a Workflow using Deferred Allocation

Printer-friendly version

We want to use deferred allocation. An insurance claim will be forwarded to a specialist depending on its content. There are specialists for health, house, car and life insurance. The complete workflow is contained in file DeferredAllocation.yawl. We will outline the steps that are necessary to create this workflow.

Organisation

The first step is to set up an organisation

First name

Last name

Roles

Username

Password

Simone

Martini

claimer

sim

pass

Jean

Pucelle

allocator

jep

pass

Ambrogio

Lorenzetti

health specialist

aml

pass

Pietro

Lorenzetti

house specialist

pil

pass

Lorenzo

Monaco

car specialist

lom

pass

Jean

Fouquet

life specialist

jef

pass

You can either enter this organisation using the control center or you can import the file YAWLOrgDataExport.ybkp.

 

Instruction to import organisation data:

Please open the control center and log in as "admin" :

 

XSD Types

 

Instruction to import data type definitons:

 

In order to have the specialist roles in a drop down list in a task, we define the following type in the data type definitions of the net:

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema">

<xs:simpleType name="SpecialistRolesType">

<xs:restriction base="xs:string">

<xs:enumeration value="health specialist" />

<xs:enumeration value="house specialist" />

<xs:enumeration value="car specialist" />

<xs:enumeration value="life specialist" />

</xs:restriction>

</xs:simpleType>

</xs:schema>

 

Net variables

We define the following variables in our top level net:

Variable name

Type

Usage

Remarks

claim

string

Local

A text explaining the claim.

accept

boolean

Local

True if the claim is accepted – false otherwise.

role

SpecialistRolesType

Local

The type for the drop down list from the previous section.

roleString

string

Local

A „type conversion“ of variable role, because variables for deferred allocation must be of type string.

 

Two nets for the control flow

The first plan was to create one simple net for this example.

However, there is a problem: the YAWL User Manual says:

„Additionally, in the Net Parameters panel you may nominate one or more net-level variables that at runtime will contain a value of the userid of a participant or the name of a role (that is, deferred allocation). For a variable to appear in the Net Parameters panel, it must be of type ‘string’ and usage ‘Input & Output’ or ‘Input Only’.“

This means that we want to use variable roleString for deferred allocation we have to change its usage to „input“. The consequence is that we have to enter some value each time we start the workflow. (We do not know the reason for this restriction)

As a workaround we put the deferred allocation task „Choose specialist“ in a subnet and get the following two nets:

as top level containing

We define the following variables in our subnet:

 

Variable name

Type

Usage

Remarks

claim

string

Input Only

 

accept

boolean

Input & Output

 

role

SpecialistRolesType

Input & Output

 

roleString

string

Input & Output

This variable can now be used for deferred allocation in „Evaluate the claim“.

We have defined the net variables first in order to use „Decompose to direct data transfer“ as much as possible. Most of the mappings are standard an can be examined by loading DeferredAllocation.yawl into the YAWL editor.

One thing worth mentioning is the task „Choose specialist“, where we want to have our drop down list. The variable containing the drop down list is called „role“. The result of the user selection must be in variable „roleString“. The solution is an output mapping of „role“ to „roleString“ and to hide the task variable „roleString“ using extended attributes.