Transcript Exception Handling

Y
A W L
Chapter 5
Exception Handling
Michael Adams
Nick Russell
a university for the
real world
R
© 2009, www.yawlfoundation.org
Y
Overview
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
2
Overview
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
3
A General Framework
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
4
Exception Handling Strategy
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
5
Exception Types
•
•
•
•
•
Y
Work Item Failure (WIF)
Deadline Expiry (DEX)
Resource Unavailability (RUN)
External Trigger (EXT)
Constraint Violation (CVI)
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
6
Work Item Failure
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
7
Deadline Expiry
Y
• 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.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
8
Resource Unavailability
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
9
External Trigger
Y
• 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.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
10
Constraint Violation
Y
• 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.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
11
Exception Handling at Work Item Level
Y
• The way an exception should be handled depends on
the current context of the work item and on its possible
states post-handling
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
12
Exception Handling at Case Level
Y
• 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.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
13
Recovery Action
Y
• 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.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
14
Charcterising Handling Strategies
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
15
Table of Relevant Strategy Combinations
WIF-OFC-CWC-NIL
WIF-OFC-CWC-COM
WIF-AFF-CWC-NIL
WIF-AFF-CWC-COM
WIF-AFC-CWC-NIL
WIF-AFC-CWC-COM
WIF-SRS-CWC-NIL
DEX-ARO-CWC-NIL
DEX-AFF-CWC-NIL
DEX-AFF-RCC-NIL
DEX-AFC-CWC-NIL
DEX-SCE-CWC-NIL
DEX-SCE-CWC-COM
DEX-SRS-CWC-NIL
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
RUN-SRO-CWC-NIL
RUN-SRO-CWC-COM
RUN-SRO-CWC-RBK
RUN-SFF-CWC-NIL
RUN-SFF-CWC-COM
RUN-SFF-CWC-RBK
Y
A W L
Y
EXT-SFF-RCC-NIL
EXT-SFF-RCC-COM
EXT-SFF-RCC-RBK
EXT-SFF-RAC-NIL
EXT-SFC-CWC-NIL
EXT-SFC-CWC-COM
16
YAWLeX Language
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
17
YAWLeX Primitives
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
Y
A W L
18
Example: Travel Booking Process
Y
• Each customer is checked for available credit
– if OK, processes the booking
– if not, the booking is rejected
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
19
Example: Travel Booking Process
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
Y
20
Exception Handling in YAWL
Y
• 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
Y
A W L
21
The Exception Service
Y
• 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 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
22
The Exception Service
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
23
The Exception Service
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
24
The Exception Service
Y
• 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.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
25
Worklet-Exlet Hierarchy
Y
compensation worklet
cancel stadium
book theatre
advise fans
ChangeToMidVenue
ItemPreConstraint
exlets
C
C
C
C
‘parent’ process
book
stadium
sell tickets
do show
OrganiseConcert
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
26
Architecture
Y
Exlet
Specs
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
27
Interface X
real
a university
for the
© 2009,
www.yawlfoundation.org
world
Y
R
Y
A W L
28
Exception Types - Constraints
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
29
Exception Types - Constraints
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
30
Exception Types - Timeout
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
31
Exception Types – External Trigger
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
32
Exception Types – Resource Unavailable
Y
• 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 preor post-execution) are not currently supported by the
Exception Service
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
33
Exception Perspectives
Y
• An exlet can take these actions against these
targets for these events
Targets
Events
Actions
Task
CasePreConstraint
Suspend
Case
CasePostConstraint
Continue
All Cases
ItemPreConstraint
Restart
Ancestor Cases
ItemPostConstraint
Complete
TimeOut
Fail
CaseExternal
Remove
ItemExternal
Compensate
ResourceUnavailable
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
34
Exlets
Y
• 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
Y
A W L
35
35
Exlet Primitives
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
36
Exlet Primitives
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
37
Exlet Primitives
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
38
Exlet Primitives
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
39
Exlet Primitives
Y
• 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
C
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
40
Ancestor Cases
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
41
Local and Global Perspectives
Y
• 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
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
42
Contextual Perspective
Y
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.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
43
Benefits of Automated Selection
Y
• 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.
real
a university
for the
© 2009,
www.yawlfoundation.org
world
R
Y
A W L
44