2006
DOI: 10.1007/11767138_20
|View full text |Cite
|
Sign up to set email alerts
|

Workflow Exception Patterns

Abstract: This paper presents a classification framework for workflow exception handling in the form of patterns. This framework is independent of specific modelling approaches or technologies and as such provides an objective means of delineating the exception-handling capabilities of specific workflow systems. It is subsequently used to assess the level of exceptions support provided by eight commercial workflow systems and business process modelling and execution languages. On the basis of these investigations, we pr… Show more

Help me understand this report

Search citation statements

Order By: Relevance

Paper Sections

Select...
2
1
1
1

Citation Types

0
120
0
2

Year Published

2008
2008
2018
2018

Publication Types

Select...
4
3
1

Relationship

0
8

Authors

Journals

citations
Cited by 188 publications
(122 citation statements)
references
References 18 publications
0
120
0
2
Order By: Relevance
“…The scientist specifies a desired sequence of tasks through some manner of task graph construction, either by writing the XML-based script directly, through a visual interface wherein which the scientist connects tasks together, or through a declarative language or other simplification means. A workflow graph's ability to respond to events in the external environment is built into the formal specification of most workflow languages (through support for a specific workflow patterns called a "persistent trigger pattern" (Russell et al 2006) where a trigger can initiate a task (or the beginning of a thread of execution) that is not contingent on the completion of any preceding tasks. In the BPEL workflow language this behavior is achieved through the <pick> construct waiting on specific message type; in UML 2.0 Activity Diagrams, support is provided through signals.…”
Section: Simplifying Assumptionsmentioning
confidence: 99%
See 2 more Smart Citations
“…The scientist specifies a desired sequence of tasks through some manner of task graph construction, either by writing the XML-based script directly, through a visual interface wherein which the scientist connects tasks together, or through a declarative language or other simplification means. A workflow graph's ability to respond to events in the external environment is built into the formal specification of most workflow languages (through support for a specific workflow patterns called a "persistent trigger pattern" (Russell et al 2006) where a trigger can initiate a task (or the beginning of a thread of execution) that is not contingent on the completion of any preceding tasks. In the BPEL workflow language this behavior is achieved through the <pick> construct waiting on specific message type; in UML 2.0 Activity Diagrams, support is provided through signals.…”
Section: Simplifying Assumptionsmentioning
confidence: 99%
“…In the BPEL workflow language this behavior is achieved through the <pick> construct waiting on specific message type; in UML 2.0 Activity Diagrams, support is provided through signals. We extend the persistent trigger pattern (Russell et al 2006) with event sequences to capture the behavior of an interaction between a workflow and its external environment through a bounded period of time.…”
Section: Simplifying Assumptionsmentioning
confidence: 99%
See 1 more Smart Citation
“…The work by Russell et al [11] presents workflow exception patterns. These patterns investigate the expressiveness of the workflow language and does not deal with the interplay between the workflow layer and the layers below.…”
Section: Related Workmentioning
confidence: 99%
“…We denote these recurrent functions as workflow activity patterns (activity patterns for short); i.e., activity patterns represent business functions that occur several times within one or multiple process models, and therfore might be reused when defining other business processes. Recently, workflow patterns have been suggested capturing different process aspects: control flow (Russell, 2006a), data flow (Russell, 2004a), resources (Russell, 2004b), exception handling (Russell, 2006b), service interactions (Barros, 2005), process change (Weber, 2007), application-oriented aspects (Bancroft, 1998), and process compliance (Namiri, 2007). Yet, all these patterns have in common that they are relevant for implementing BPM systems and for defining adequate and expressive process modeling languages.…”
Section: Introductionmentioning
confidence: 99%