Chapter 11 The Worklet Service Michael Adams a

  • Slides: 33
Download presentation
Chapter 11 The Worklet Service Michael Adams a university for the real world R

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

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

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 subservices: – 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 real a university for the © 2009, www. yawlfoundation. org world R 2

A Worklet Is: • • • a small, self-contained, complete workflow process designed to

A Worklet Is: • • • a small, self-contained, complete workflow process designed to handle one specific action (task) in a larger, composite activity (process) a member of an extensible repertoire contextually chosen at runtime to perform a task a dynamically substituted subprocess and/or exception compensation process an implicit part of the parent process model real a university for the © 2009, www. yawlfoundation. org world R 3

The Selection Service • The Selection Service allows a workitem to be substituted at

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

Exception Handling in YAWL • Exception Handling is a specific area within the wider

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 worklet service flexibility exception handling real a university for the © 2009, www. yawlfoundation. org world exception service R 5

The Exception Service • The Exception Service uses the same repertoire and Ripple-Down Rule

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 repertoiremember exception handling processes may be maintained, known as exlets – an exlet is defined in the YAWLe. X 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 real a university for the © 2009, www. yawlfoundation. org world R 6

Architecture real a university for the © 2009, www. yawlfoundation. org world R 7

Architecture real a university for the © 2009, www. yawlfoundation. org world R 7

Interface X Architecture real a university for the © 2009, www. yawlfoundation. org world

Interface X Architecture real a university for the © 2009, www. yawlfoundation. org world R 8

Internal Service Architecture real a university for the © 2009, www. yawlfoundation. org world

Internal Service Architecture real a university for the © 2009, www. yawlfoundation. org world R 9

Process Definition real a university for the © 2009, www. yawlfoundation. org world R

Process Definition real a university for the © 2009, www. yawlfoundation. org world R 10

Order Fulfilment: Payment Sub-Net real a university for the © 2009, www. yawlfoundation. org

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

Same Sub-Net, Worklet Enabled real a university for the © 2009, www. yawlfoundation. org

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

Issue Shipment Invoice Dialog real a university for the © 2009, www. yawlfoundation. org

Issue Shipment Invoice Dialog real a university for the © 2009, www. yawlfoundation. org world R 13

Worklet Decomposition Rules • It is only necessary to map from the parent task

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

Exlets • Exception handling processes – or exlets – are defined graphically using a

Exlets • 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 real a university for the © 2009, www. yawlfoundation. org world R 15 15

Exception Perspectives • An exlet can take these actions against these targets for these

Exception Perspectives • An exlet can take these actions against these targets for these events Targets Events Actions Task Case. Pre. Constraint Suspend Case. Post. Constraint Continue All Cases Item. Pre. Constraint Restart Ancestor Cases Item. Post. Constraint Complete Time. Out Fail Case. External Remove Item. External Compensate Resource. Unavailable real a university for the © 2009, www. yawlfoundation. org world R 16

A Simple RDR Example Root real a university for the © 2009, www. yawlfoundation.

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

Ripple Down Rule Sets • A repertoire of exlets may be formed for each

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

Example Rule Tree • Time. Out tree for Arrange Delivery Appointment task of the

Example Rule Tree • Time. Out tree for Arrange Delivery Appointment task of the Payment subnet of the Order. Fulfilment Process real a university for the © 2009, www. yawlfoundation. org world R 19

Rule Set Hierarchy • Rule Node: contains the details of one discrete ripple-down rule.

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

Worklet-Exlet Hierarchy compensation worklet cancel stadium book theatre advise fans Change. To. Mid. Venue

Worklet-Exlet Hierarchy compensation worklet cancel stadium book theatre advise fans Change. To. Mid. Venue Item. Pre. Constraint exlets C C ‘parent’ process book stadium sell tickets do show Organise. Concert real a university for the © 2009, www. yawlfoundation. org world R 21

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

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

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

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 RDRCondition. Function 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 real a university for the © 2009, www. yawlfoundation. org world R 23

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

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

Adding a New Rule Tree/Set • The New Rule Set Screen supports the creation

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

Adding a New Rule • Each node incorporates a set of case descriptors, called

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. • 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 subset of differences. – 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. real a university for the © 2009, www. yawlfoundation. org world R 26

Replacing a Running Worklet • After a new rule is added, the Rules Editor

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

Static Process Model real a university for the © 2009, www. yawlfoundation. org world

Static Process Model real a university for the © 2009, www. yawlfoundation. org world R 28

A Worklet Solution real a university for the © 2009, www. yawlfoundation. org world

A Worklet Solution real a university for the © 2009, www. yawlfoundation. org world R 29

A Worklet Solution real a university for the © 2009, www. yawlfoundation. org world

A Worklet Solution real a university for the © 2009, www. yawlfoundation. org world R 30

Meeting the Criteria for Flexibility and Exception Handling • Flexibility and Re-use: – –

Meeting the Criteria for Flexibility and Exception Handling • Flexibility and Re-use: – – – Extensible worklets repertoire Contextual choice Constraint checking rules Modular approach: loosely defined Worklets may be reused complete • 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 real a university for the © 2009, www. yawlfoundation. org world R 31

Meeting the Criteria for Flexibility and Exception Handling • Dynamic Evolution of Tasks: –

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 real a university for the © 2009, www. yawlfoundation. org world R 32

Meeting the Criteria for Flexibility and Exception Handling • Comprehensibility of Process Models: –

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 real a university for the © 2009, www. yawlfoundation. org world R 33