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.
