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

a university for the world real R 2 © 2009, 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

a university for the world real R 3 © 2009, 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)

a university for the world real R 4 © 2009, 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

a university for the world real R 5 © 2009, 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

a university for the world real R 6 © 2009, 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

a university for the world real R 7 © 2009, Architecture

a university for the world real R 8 © 2009, Interface X Architecture

a university for the world real R 9 © 2009, Internal Service Architecture

a university for the world real R 10 © 2009, Process Definition

a university for the world real R 11 © 2009, Order Fulfilment: Payment Sub-Net

a university for the world real R 12 © 2009, Same Sub-Net, Worklet Enabled

a university for the world real R 13 © 2009, Issue Shipment Invoice Dialog

a university for the world real R 14 © 2009, 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

a university for the world real R 15 © 2009, 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

a university for the world real R 16 © 2009, 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

a university for the world real R 17 © 2009, A Simple RDR Example Root

a university for the world real R 18 © 2009, 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

a university for the world real R 19 © 2009, Example Rule Tree TimeOut tree for Arrange Delivery Appointment task of the Payment subnet of the OrderFulfilment Process

a university for the world real R 20 © 2009, 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.

a university for the world real R 21 © 2009, Worklet-Exlet Hierarchy book stadium sell tickets do show ‘parent’ process ItemPreConstraint exlets C C C cancel stadiumbook theatre advise fans compensation worklet OrganiseConcert ChangeToMidVenue C

a university for the world real R 22 © 2009, 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.

a university for the world real R 23 © 2009, 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

a university for the world real R 24 © 2009, 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.

a university for the world real R 25 © 2009, 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

a university for the world real R 26 © 2009, 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.

a university for the world real R 27 © 2009, 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.

a university for the world real R 28 © 2009, Static Process Model

a university for the world real R 29 © 2009, A Worklet Solution

a university for the world real R 30 © 2009, A Worklet Solution

a university for the world real R 31 © 2009, 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

a university for the world real R 32 © 2009, Meeting the Criteria for Flexibility and Exception Handling 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

a university for the world real R 33 © 2009, Meeting the Criteria for Flexibility and Exception Handling 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