A university for the world real R © 2009, Chapter 5 Exception Handling Michael Adams Nick Russell.

a university for the worldrealR

WW LLLYYY AA

© 2009, www.yawlfoundation.org YYY

Chapter 5Exception Handling

Michael Adams

Nick Russell


2WW LLLYYY AA

YYYYY

© 2009, www.yawlfoundation.org

Overview

• Abstracting complex business concepts, practices & rules into process models is often far from trivial

• Because of discrepancies between ‘real world’ activities and formal representations of them, process instances experience exceptions

– not an error– a deviation from the process as defined– happen frequently– substantial part of everyday tasks– have real value


3WW LLLYYY AA

YYYYY


Overview

• Historically, exceptions were interpreted thus:– if an exception was or could have been expected (a priori

knowledge), it should have already been in the model• can lead to very complex models, much of which is not executed

in each run

• mixes business logic with exception handling routines

– if an exception was unexpected (no a priori knowledge), the model is deemed deficient, and so should be amended for current and future runs

• ignores frequency and cost

• usually handled off-line or terminating the process


4WW LLLYYY AA

YYYYY


A General Framework

• An exception is a distinct, identifiable event, that occurs at a specific point in time during process instance execution

• Generally, an exception occurs in the context of an executing work item

• An exception is immediately detectable and can be categorised to a specific type

• The act of dealing with an identified exception is called exception handling

• Exception handling strategies can be defined that describe the actions to be taken to mitigate the effects of the exception


5WW LLLYYY AA

YYYYY


Exception Handling Strategy

• Depends of four main factors:– The type of exception detected– How the work item the detected the exception will be

handled– How the other work items of the case are handled– What recovery action is taken to resolve its effects


6WW LLLYYY AA

YYYYY


Exception Types

• Work Item Failure (WIF)• Deadline Expiry (DEX)• Resource Unavailability (RUN)• External Trigger (EXT)• Constraint Violation (CVI)


7WW LLLYYY AA

YYYYY


Work Item Failure

• Cannot continue execution or progress any further towards completion

• Causes include:– user-initiated termination of an application performing the work

item – the failure of a hardware, software or network resource

associated with the work item– a user indication that the work item should considered as

having failed rather than completed successfully

• Often not easily dealt with within the context of a process model or the effects of such a failure are not localised to a specific part of the process


8WW LLLYYY AA

YYYYY


Deadline Expiry

• The use of deadlines within business processes are a common means of enforcing performance requirements

• Generally they are associated with a specific work item and indicate when it should be completed

– commencement deadlines are also possible

• Often when specifying a deadline, it is also useful to define the action that will be pursued if the deadline is reached and the work item has not been started or completed.


9WW LLLYYY AA

YYYYY


Resource Unavailability

• These may be data resources required for execution, or physical resources (human or non-human)

• If they are not available, the work item can’t proceed• For example:

– at distribution time, no suitable human resource can be found who meets the specified allocation criteria

– some time after allocation, the resource is no longer able to undertake or complete the work item

• Can be automatically detected, but often can’t be resolved within the context of the process instance itself


10WW LLLYYY AA

YYYYY


External Trigger

• Triggers from the environment are a common means of signaling that an event has occurred that affects the process instance.

• Can originate from external or internal sources, for example:

– other work items in the process– work items in other processes

• Although a work item can anticipate events such as triggers and make provision for dealing with them, it is not predictable if or when such events will occur.


11WW LLLYYY AA

YYYYY


Constraint Violation

• Constraints are a common means of specifying operational invariants over control-flow, data or resource elements.

– They are generally monitored on an ongoing basis in order to ensure that they are enforced.

• Generally it is a work item that will need to detect and deal with a violation

– though sometimes constraints may be specified and enforced at the process level.


12WW LLLYYY AA

YYYYY


Exception Handling at Work Item Level

• The way an exception should be handled depends on the current context of the work item and on its possible states post-handling


13WW LLLYYY AA

YYYYY


Exception Handling at Case Level

• It is possible that a work item level exception may also affect other current work items in the same and possibly other cases.

• The third consideration is how to handle the exception at the case level. There are three alternative options:

– continue workflow case (CWC) – The workflow case can be continued, and no intervention occurs in the execution of any other work items

– remove current case (RCC) – selected or all remaining work items in the current case are removed

– remove all cases (RAC) – selected or all remaining work items in both the current all other executing cases which correspond to the same process model are removed.


14WW LLLYYY AA

YYYYY


Recovery Action

• The final consideration is what action is to be undertaken to mitigate the effects of the exception. There are three alternatives:

– no action (NIL) – do nothing– rollback (RBK) – rollback the effects of the exception by

undoing the preceding work item(s) based on the state changes recorded in an execution log. In order to specify a rollback action, the point in the process (i.e. the task) to which the process should be undone needs be stated. By default this is just the current work item

– compensate (COM) – compensate for the effects of the exception by executing an alternative task or sub-process. In order to specify a compensation action in a process definition, the corresponding compensation task(s) or sub-process needs to be identified.


15WW LLLYYY AA

YYYYY


Charcterising Handling Strategies

• From the various alternatives defined for each of the four exception handling elements, 135 possible patterns can be conceived

– not all combinations apply for each exception type

• For example, the pattern WIF-SFF-CWC-COM means:– for a particular work item failure exception– the work item should be failed (terminated)– no action is required for other work items in the case– a nominated compensation task or process should be

executed


16WW LLLYYY AA

YYYYY


Table of Relevant Strategy Combinations

EXT-SFF-RCC-NILEXT-SFF-RCC-COMEXT-SFF-RCC-RBKEXT-SFF-RAC-NILEXT-SFC-CWC-NILEXT-SFC-CWC-COM

RUN-SRO-CWC-NILRUN-SRO-CWC-COMRUN-SRO-CWC-RBKRUN-SFF-CWC-NILRUN-SFF-CWC-COMRUN-SFF-CWC-RBK

DEX-ARO-CWC-NILDEX-AFF-CWC-NILDEX-AFF-RCC-NILDEX-AFC-CWC-NILDEX-SCE-CWC-NILDEX-SCE-CWC-COMDEX-SRS-CWC-NIL

WIF-OFC-CWC-NILWIF-OFC-CWC-COMWIF-AFF-CWC-NILWIF-AFF-CWC-COMWIF-AFC-CWC-NILWIF-AFC-CWC-COMWIF-SRS-CWC-NIL


17WW LLLYYY AA

YYYYY


YAWLeX Language

• An exception handling language that allows strategies to be defined using a graphical notation

– intended to be compact and generic

• It comprises a set of primitives (block icons) that support various aspects of exception handling

– can be combined into a sequence of actions

• Allows a clear distinction between the process model and its exception handling strategies


18WW LLLYYY AA

YYYYY


YAWLeX Primitives


19WW LLLYYY AA

YYYYY


Example: Travel Booking Process

• Each customer is checked for available credit– if OK, processes the booking– if not, the booking is rejected


20WW LLLYYY AA

YYYYY


Example: Travel Booking Process


21WW 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


22WW 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


23WW LLLYYY AA

YYYYY



• For an unanticipated exception (i.e. an event for which a handling exlet has not yet been defined):

– an existing exlet can be manually selected (re-used) from the repertoire

– one may be adapted on the fly to handle the immediate situation

– a new exlet constructed and immediately deployed while the parent workflow instance is still active

• In each case, execution of the process that raised the exception is allowed to take the necessary action and either continue unhindered or terminate, as specified


24WW LLLYYY AA

YYYYY



• The YAWL Engine provides notifications to the Exception Service at various points in the lifecycle of each case

– but has no knowledge of the occurrence of any exception or the invocation of any handling process

• Unlike the Worklet Selection Service, which is invoked for particular specified tasks, the Exception Service, when enabled, is invoked for every case and task that the Engine executes


25WW LLLYYY AA

YYYYY



• Each specification may have a discrete RDR rule set defined for each of the eight exception types handled

– In addition to the one for selection

• When a notification of a potential exception occurs: – If a rule set is defined for that exception type, the service

will invoke a contextually selected exception handling process

– If there is no associated rule set, or if there is but none of its rule nodes are satisfied, the exception is simply ignored.

• To construct an exlet, a process designer may choose from various actions (such as canceling, suspending, completing, failing and restarting) and apply them at a work item, case and/or specification level.


26WW 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


27WW LLLYYY AA

YYYYY


Architecture

Exlet Specs


28WW LLLYYY AA

YYYYY


Interface X


29WW LLLYYY AA

YYYYY


Exception Types - Constraints

• Constraints are checked immediately before an after the execution of a task or case:

– CasePreConstraint - case-level pre-constraint rules are checked when each case instance begins execution

– ItemPreConstraint - item-level pre-constraint rules are checked when each work-item in a case becomes enabled (i.e. ready to be checked out or executed)

– ItemPostConstraint - item-level post-constraint rules are checked when each work item reaches a finalized status (e.g. completed, cancelled, failed)

– CasePostConstraint - case-level post constraint rules are checked when a case completes


30WW LLLYYY AA

YYYYY


Exception Types - Constraints

• The service receives notification from the Engine when each of these life-cycle events are reached within each case and work item instance

• It then checks the rule set associated with the specification to determine:

– if there are any rules of that exception type defined for the specification, and if so

– if any of the rules evaluate to true using the contextual data of the case or work item

• If the rule set finds a rule that evaluates to true for the exception type and data, an associated exlet is selected and invoked


31WW LLLYYY AA

YYYYY


Exception Types - Timeout

• A timeout event occurs when a work item has an enabled timer and the deadline set for that timer is reached.

• In this case, the Engine notifies the service of the timeout event, and passes to the service a reference to the work item and each of the other work items that were running in parallel with it.

• Separate timeout rules may be defined for each of the work items affected by the timeout, including the actual timed out work item itself.

– Thus, separate actions may be taken for each affected work item individually


32WW LLLYYY AA

YYYYY


Exception Types – External Trigger

• Externally triggered exceptions occur, not through the case’s data parameters or via an engine initiated event, but rather because of the occurrence of an event in the external environment, outside of the process instance, that has an effect on the continuing execution of the process.

– thus, these events are triggered by a user or administrator.

• Depending on the actual event and the context of the case or work item, a particular exlet will be invoked.

• There are two types of external exceptions: – CaseExternalTrigger for case-level events – ItemExternalTrigger for work item-level events


33WW LLLYYY AA

YYYYY


Exception Types – Resource Unavailable

• A Resource Unavailable exception is triggered by the Resource Service when an attempt has been made to allocate a work item to a human resource and the resource reports that it is unable to accept the allocation or the allocation cannot otherwise proceed.

• Item Abort (the failure of a work item being processed by an external application) and Constraint Violation (occurring during work item execution rather than pre- or post-execution) are not currently supported by the Exception Service


34WW 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


35WW LLLYYY AA

YYYYY


Exlets

35

• 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


36WW LLLYYY AA

YYYYY


Exlet Primitives

• Remove Work Item: removes (or cancels) the work item; execution ends, and the work item is marked with a status of cancelled. No further execution occurs on the process path that contains the work item

• Remove Case: removes the case - execution ends

• Remove All Cases: removes all case instances for the specification in which the task of which the work item is an instance is defined, or of which the case is an instance


37WW LLLYYY AA

YYYYY


Exlet Primitives

• Suspend Work Item: suspends (or pauses) execution of a work item, until it is continued, restarted, cancelled, failed or completed, or the case that contains the work item is cancelled or completed

• Suspend Case: suspends all ‘live’ workitems in the current case instance (a live work item has a status of fired, enabled or executing), effectively suspending execution of the entire case

• Suspend All Cases: suspends all ‘live’ workitems in all of the currently executing instances of the specification in which the task of which the work item is an instance is defined, effectively suspending all running cases of the specification


38WW LLLYYY AA

YYYYY


Exlet Primitives

• Continue Work Item: unsuspends (or continues) execution of the previously suspended work item

• Continue Case: unsuspends execution of all previously suspended work items for the case, effectively continuing case execution

• Continue All Cases: unsuspends execution of all work items previously suspended for all cases of the specification in which the task of which the work item is an instance is defined or of which the case is an instance, effectively continuing all previously suspended cases of the specification


39WW LLLYYY AA

YYYYY


Exlet Primitives

• Restart Work Item: rewinds work item execution back to its start. Resets the work item’s data values to those it had when it began execution

• Force Complete Work Item: completes a ‘live’ work item. Execution of the work-item ends, and the work item is marked with a status of ForcedComplete, which is regarded as a successful completion, rather than a cancelation or failure. Execution proceeds to the next work item on the process path.

• Force Fail Work Item: fails a ‘live’ work item. Execution of the work item ends, and the work item is marked with a status of Failed, which is regarded as an unsuccessful completion, but not as a cancelation—execution proceeds to the next work item on the process path


40WW LLLYYY AA

YYYYY


Exlet Primitives

• Compensate: run one or more compensatory processes (i.e. worklets). Depending on previous primitives, the worklets may execute simultaneously to the parent case, or execute while the parent is suspended

• A number of compensatory worklets may be executed consecutively by adding a sequence of compensation primitives to an exlet.

• Optionally, a particular compensation primitive may contain an array of worklets — launched concurrently as a composite compensatory action when the exlet is executed

C


41WW LLLYYY AA

YYYYY


Ancestor Cases

• Compensatory worklets make invoke child worklets to any depth.

• The ‘All Cases’ primitives may be restricted in the Rules Editor to to Ancestor Cases only – those in hierarchy of worklets back to the original parent case


42WW LLLYYY AA

YYYYY


Local and Global Perspectives

• Locality of change means the ‘worker’ (task expert) instigates additions to the repertoire

– exceptions are created locally (at the work item level) and propagated upwards

• Global Exceptions may also be raised at any time– case, specification, ancestor cases– effects are propagated downwards

• Thus, the Worklet Service supports deviations:– locally and globally– triggered automatically or manually– handled automatically or manually


43WW LLLYYY AA

YYYYY


Contextual Perspective

If, for a particular case having a certain context, a method of handling an exception at a particular point in the life-cycle of the case has been previously defined and deemed the most suitable method, then it is appropriate to assume that, given another instance of the same case which has exactly the same context, that same exception handling method can be correctly applied to that instance.


44WW LLLYYY AA

YYYYY


Benefits of Automated Selection

• It is vastly more efficient• Manual selection introduces the capacity for human

error– if the case contexts are identical, then it is simply at the

whim of the user as to which handler is selected – for a decision to be correctly made about the invocation of

a certain handler, the decision of whether to choose one handler over another depends directly on the context of the case instance.

– It cannot be asserted that two case instances would require two different handlers if their contexts were identical. It is precisely the differences in context that define and require differences in exception handling methods.

A university for the world real R © 2009, Chapter 5 Exception Handling Michael Adams Nick Russell.

Documents

Transcript of A university for the world real R © 2009, Chapter 5 Exception Handling Michael Adams Nick Russell.