A university for the world real R © 2009, Chapter 11 The Worklet Service Michael Adams

a university for the worldrealR

WW LLLYYY AA

© 2009, www.yawlfoundation.org YYY

Chapter 11The Worklet Service

Michael Adams


2WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

The Worklet Service

• The Worklet Service has been implemented as a YAWL Custom Service

– but it is in no way limited to the YAWL environment, and may be ported to other environments by making the necessary links in the service interface

• It comprises two discrete but complementary sub-services:

– a Selection Service, which enables dynamic flexibility for process instances, and

– an Exception Service, which provides facilities to handle both expected and unexpected process exceptions at runtime


3WW LLLYYY AA

YYYYY


A Worklet Is:

• a member of an extensible repertoire

• contextually chosen at runtime to perform a task

• a dynamically substituted sub-process and/or exception compensation process

• an implicit part of the parent process model

• a small, self-contained, complete workflow process• designed to handle one specific action (task) in a larger, composite

activity (process)


4WW LLLYYY AA

YYYYY


The Selection Service

• The Selection Service allows a workitem to be substituted at runtime with a dynamically selected worklet

– Corresponding data inputs of the original workitem are mapped to the inputs of the worklet, and the worklet is launched as a separate case

– When the worklet has completed, its output data is mapped back to the original workitem, which is then checked back into the engine, allowing the original process to continue.

• An extensible repertoire of worklets is maintained by the service for each task in a specification.

– Each worklet may be designed and provided to the service at any time, even while a parent process instance is executing


5WW LLLYYY AA

YYYYY


Exception Handling in YAWL

• Exception Handling is a specific area within the wider Flexibility domain

• It therefore makes sense that an exception handling solution would extend from ways of making workflow more flexible

• In YAWL, an extension of the Worklet Service, known as the Exception Service, provides dynamic exception handling with corrective and compensatory actions

flexibility

exception handling

worklet service

exception service


6WW LLLYYY AA

YYYYY


The Exception Service

• The Exception Service uses the same repertoire and Ripple-Down Rule (RDR) set framework as the wider Worklet Service

• It can handle both expected and unexpected exceptions at runtime

• For each anticipated exception, a set of repertoire-member exception handling processes may be maintained, known as exlets

– an exlet is defined in the YAWLeX language using a graphical editor and may include worklets as compensation processes

• An exlet may be dynamically incorporated into a running workflow instance on an as-needed basis

– selected based on the context of the case and the type of exception that has occurred


7WW LLLYYY AA

YYYYY


Architecture


8WW LLLYYY AA

YYYYY


Interface X Architecture


9WW LLLYYY AA

YYYYY


Internal Service Architecture


10WW LLLYYY AA

YYYYY


Process Definition


11WW LLLYYY AA

YYYYY


Order Fulfilment: Payment Sub-Net


12WW LLLYYY AA

YYYYY


Same Sub-Net, Worklet Enabled


13WW LLLYYY AA

YYYYY


Issue Shipment Invoice Dialog


14WW LLLYYY AA

YYYYY


Worklet Decomposition Rules

• It is only necessary to map from the parent task to the worklet those variables that contain values to be displayed to the user, and/or those variables that the user will supply values for to be passed back to the parent task when the worklet completes

• The definition of variables is not restricted to those defined in the parent task. Any additional variables required for the operation of the worklet may also be defined here; their values will not be passed back to the parent task when the worklet completes

• Only those variables that have been defined with an identical name and data type to variables in the parent task and:

– with a usage of ‘Input Only’ or ‘Input & Output’ will have data passed into them from the corresponding variables of the parent task when the worklet is launched

– with a Usage of ‘Output Only’ or ‘Input & Output’ will have their data values mapped back to the corresponding variables of the parent task by the Worklet Service when the worklet completes


15WW LLLYYY AA

YYYYY


Exlets

15

• Exception handling processes – or exlets – are defined graphically using a set of 'exception handling primitives'

• A specification can have a repertoire of handlers for each exception type - the appropriate handler will be chosen contextually at runtime– For item-level exceptions, each item in the specification has its own

repertoire of handlers

• Each exlet may contain any number of compensation primitives, each associated with a worklet

– Worklets can run in parallel with the parent task, or while the parent is suspended

– A compensation primitive can launch any number of worklets simultaneously


16WW LLLYYY AA

YYYYY


Exception Perspectives

Targets

Task

Case

All Cases

Ancestor Cases

Events

CasePreConstraint

CasePostConstraint

ItemPreConstraint

ItemPostConstraint

TimeOut

CaseExternal

ItemExternal

ResourceUnavailable

Actions

Suspend

Continue

Restart

Complete

Fail

Remove

Compensate

• An exlet can take these actions against these targets for these events


17WW LLLYYY AA

YYYYY


A Simple RDR Example

Root


18WW LLLYYY AA

YYYYY


Ripple Down Rule Sets

• A repertoire of exlets may be formed for each exception type

• Each specification has a unique rule set that may contain between one and nine tree sets (or sets of rule trees)

– one for selection rules and one for each of the eight implemented exception types

• Three relate to case-level exceptions and so each of these will have at most one rule tree in the tree set

• The other six tree sets relate to work item-level events, and so may have one rule tree for each task in the specification

– the tree sets for these eight rule types may consist of a number of rule trees


19WW LLLYYY AA

YYYYY


Example Rule Tree

• TimeOut tree for Arrange Delivery Appointment task of the Payment subnet of the OrderFulfilment Process


20WW LLLYYY AA

YYYYY


Rule Set Hierarchy

• Rule Node: contains the details of one discrete ripple-down rule. The conclusion of a node equates to an exlet.

• Rule Tree: consists of a number of rule nodes conceptually linked in a binary tree structure.

• Tree Set: a set of one or more rule trees. Each tree set is specific to a particular exception type.

– The tree set of a case-level exception type will contain exactly one tree.

– The tree set of an item-level type may contain one rule tree for each task of the specification that has rules defined for it.

• Rule Set: a set of one or more tree sets representing the entire set of rules defined for a specification. Each rule set is specific to a particular specification.


21WW LLLYYY AA

YYYYY


Worklet-Exlet Hierarchy

book stadium sell tickets do show

‘parent’ process

ItemPreConstraint exletsC

C

C

cancel stadium book theatre advise fans

compensation worklet

OrganiseConcert

ChangeToMidVenue

C


22WW LLLYYY AA

YYYYY


Cornerstone Cases

• Each rule node has a set of case descriptors called the Cornerstone Case

– describe the actual case context that was the catalyst for the creation of the rule

• When a new rule is added to the rule set, its conditional predicate is determined by comparing the descriptors of the current case to those of the cornerstone case and identifying a sub-set of differences.

• Not all differences will be relevant—it is only necessary to determine the factor or factors that make it necessary to handle the current case in a different fashion to the cornerstone case to define a new rule.


23WW LLLYYY AA

YYYYY


Contextual Data

• The conditional expressions in each node can test values sourced from:

– The data parameters of the current workitem– The data parameters of the current case– Process state information– A discrete RDRConditionFunction class, which allows the

definition of functions that can use data from any external source, such as:

• Archival data from process logs

• External databases

• User-defined values


24WW LLLYYY AA

YYYYY


The Rules Editor

• The Worklet Rules Editor is a purpose built tool that enables:

– the browsing of rule sets;

– the addition of new rules to existing rule trees;

– the creation of new rule trees for existing rule sets; and

– the creation of new rule sets.


25WW LLLYYY AA

YYYYY


Adding a New Rule Tree/Set

• The New Rule Set Screen supports the creation of:

– New rule trees for non-defined exception types

– New tree sets for new specifications


26WW LLLYYY AA

YYYYY


Adding a New Rule

• Each node incorporates a set of case descriptors, called the ‘cornerstone case’, which describe the actual case that was the catalyst for the creation of the rule.

– it is only necessary to determine the factors that make it necessary to handle the current case differently

• The current case descriptors become the cornerstone case for the newly formulated rule.

• A new rule is determined by comparing the descriptors of the current case to those of the cornerstone case of the last satisfied rule and identifying a sub-set of differences.


27WW LLLYYY AA

YYYYY


Replacing a Running Worklet

• After a new rule is added, the Rules Editor provides an administrator with the choice to replace the previously started (inappropriate) worklet instance with an instance of the worklet defined in the new rule.

• If the administrator chooses to replace the worklet, the Rules Editor contacts the worklet service to request the change. The service responds with a dialog similar to that below.


28WW LLLYYY AA

YYYYY


Static Process Model


29WW LLLYYY AA

YYYYY


A Worklet Solution


30WW LLLYYY AA

YYYYY


A Worklet Solution


31WW LLLYYY AA

YYYYY


Meeting the Criteria for Flexibility and Exception Handling

• Flexibility and Re-use: – Extensible worklets repertoire– Contextual choice– Constraint checking rules– Modular approach: loosely defined complete– Worklets may be reused

• Different repertoires• Selection/Compensation

• Adaptation via Reflection:– Plans not prescriptive but fluid and extensible– Each instance a 'learning experience'– Dynamically extensible rule set

• Encapsulates 'organisational memory'• Refines understanding of domain


32WW LLLYYY AA

YYYYY



• Dynamic Evolution of Tasks:– No more straight-jacketed, regimented, demotivating work– Different methods and efficiencies larger repertoires – Natural work methods motivation, ownership,

responsibility– Process evolves incrementally, not monolithically

• Locality of Change:– Change emanates from local level

• Workers (domain experts) nominate change

– Worklet/Exlet addition does not change parent or repertoire• Ease of verification


33WW LLLYYY AA

YYYYY



• Comprehensibility of Process Models:– Allows models to concentrate on business logic

• Removes conditional control flow constructs

– Parent process is a guide– Worklets/Exlets better understood by individual participants– Different levels of granularity

• Exceptions as 'First-Class Citizens':– Fully featured exception handling service

• Context-aware Exlets

– Detects, reacts, handles, maintains and incorporates • Learning experience

• Organisation memory retained

– Supports expected and unexpected exceptions in real-time

Documents

A university for the world real R © 2009, Chapter 11 The Worklet Service Michael Adams