YAWL and its Support Environment

Transcription

1 YAWL and its Support Environment Alessandro usso based on the slides available online at a university 2009,

2 Acknowledgment This presentation is based on the slides prepared by Wil van der Aalst Arthur ter Hofstede Nick ussell Michael Adams Marlon Dumas Marcello La osa Stephan Clemens The slides are available at 2

3 Overview The emergence of YAWL The Workflow Patterns Initiative control-flow patterns data patterns resource patterns YAWL: the language control-flow perspective data perspective resource perspective The YAWL system architecture main components Live demo Summary 3

4 BPM Life-Cycle and Process Modeling XPDL Feedback equirements (e-)design Process Models BPEL BPMN EPCs UML ADs Analysis & Mining Execution Traces Diagnosis BPM life-cycle Enactment Monitoring Configuration Executable Processes YAWL = Petri/Workflow Nets Yet Another Workflow Language 4

5 Emergence of YAWL Yet Another Workflow Language Defined by Wil van der Aalst and Arthur ter Hofstede in 2002 Intention: to provide comprehensive support workflow patterns Inspired by Workflow Nets, but with direct support for Cancelation Multiple executions of the same task in the same process instance Synchronization of active paths only (O-join) Formal semantics 5

6 Why Yet Another Workflow Language? Problems in the BPM field Lack of commonly accepted conceptual foundations Lack of proper formal foundations No lack of proposed standards Tools are typically hard to use, expensive and not easily integrated Lack of support for processes that need to change on-the-fly Lack of proper support for exceptions Limited support for design time analysis (verification and validation) esource perspective does not match - needs Insufficient support for inter-process communication Workflow Patterns Initiative ( 6

7 The Workflow Patterns Initiative (1/2) Joint initiative by Eindhoven University of Technology (TU/e, the Netherlands) and Queensland University of Technology (QUT, Australia) started in 1999 Aims to address lack of commonly accepted foundation for workflow management WfMC s proposal lacked precision and expressiveness This foundation provides: Unbiased comparison of approaches to business process specification Basis for adaptation and refinement of such approaches Emphasis on suitability rather than on expressive power Patterns-based approach Technology independent Description, motivation, issues, solutions Three point evaluation scale (full support +, partial support or workaround +/, no support ) 7

8 The Workflow Patterns Initiative (2/2) Objectives define a conceptual basis for process technology identify workflow modelling scenarios and solutions delineate the fundamental requirements that arise during business process modelling on a recurring basis and describe them in an imperative way provide foundations for evaluating and selecting workflow solutions (benchmarking model) esults a set of patterns that provide a comprehensive analysis of the various perspectives (control flow, data, resource, and exception handling) that need to be supported by a process modelling language evaluations of commercial offerings, research prototypes, proposed standards for web service composition, etc Usage examining the suitability of a particular process language or workflow system for a particular project assess relative strengths and weaknesses of various approaches for process specification basis for language and tool development 8

9 What is a pattern? Abstraction from concrete form which keeps recurring in specific, non-arbitrary contexts* In process context: Imperative in format Not dependent on actual products/technologies Motivated Solution-oriented Components of a Pattern Description: what is it? Synonym(s) Example(s) Motivation: why needed? Overview & Context: conditions + CPN formalisation Implementation: how typically ised? Issues: what problems can be encountered? Solutions: how and to what extent can these problems be overcome? Evaluation criteria Product Evaluation * D. iehle and H. Züllighoven. Understanding and Using Patterns in Software Development. Theory and Practice of Object Systems 2(1):3-13,

10 Patterns Identification, Validation and Tool Evaluation Identify patterns control flow (43) data (40) resource (43) Set evaluation criteria Select tools to be assessed Since their release, Assess pattern the patterns have been support widely used by practitioners, vendors and academics alike in the selection, design and development of workflow systems and process modeling languages eview findings with vendors 10

11 Control-flow and Data Perspectives Control-flow perspective (43 patterns) Describes the structure of a process in terms of tasks and the relationships between them defining the overall flow of control focuses on the representation and execution of processes in terms of tasks and arcs indicating how the thread of control is passed between them Abstracts from the actual implementation of individual tasks Data perspective (40 patterns) Describes data elements consumed, produced and exchanged during process executions focuses on the representation and utilisation of data in a process context Considers both internal and external data resources and the interactions between them 11

12 esource and Exception Handling Perspectives esource perspective (43 patterns) Describes the operational and organizational context for process execution in terms of resources (i.e., people, systems and services able to execute tasks) and their capabilities (i.e., any qualification, skill, equipment, property etc. relevant for task assignment and execution) policies and rules used to assign tasks to resources for execution Focuses on the manner in which work is offered to, allocated to and managed by process participants Assumes the existence of a process model and related organisational and work distribution models Exception Handling perspective (not covered in these slides) Describes the approaches to be used to deal with undesirable events that may arise 12

13 Classes of Control-flow Patterns Branching Patterns capture branching scenarios in processes (AND, XO, O, ) Synchronisation Patterns describe synchronization scenarios arising in processes epetition Patterns describe various ways in which repetition may be specified (loops, recursion, ) Multiple Instances (MI) Patterns delineate situations with multiple threads of execution in a workflow which relate to the same activity See: Concurrency Patterns reflect situations where restrictions are imposed on the extent of concurrent control-flow in a process instance Trigger Patterns catalogue the different triggering mechanisms appearing in a process context Cancellation and Completion Patterns categorise the various cancellation scenarios that may be relevant for a workflow specification Termination Patterns address the issue of when the execution of a workflow is considered to be finished 13

14 Branching constructs AND Split Parallel split, initiation of parallel threads O Split Multi-choice, thread of control is passed to one or more outgoing branches XO Split Exclusive choice, thread of control is passed to exactly one of the outgoing branches (choice made by the system, based on data) Deferred choice, thread of control is passed to exactly one of the outgoing branches. Selection decision is deferred to the user and/or operating environment. Thread Split Thread split, thread of control is split into multiple concurrent threads in same branch. 14

15 Classes of Data Patterns Data Visibility the extent and manner in which data elements can be viewed and utilised by workflow components Internal Data Interaction data communication between active elements within a workflow External Data Interaction data communication between active elements within a workflow and the external operating environment Data Transfer data element transfer across the interface of a workflow component Data outing the manner in which data elements can influence the operation of the workflow See: 15

16 Data Visibility Scopes 16

17 Data Interaction between Tasks Integrated Control and Data Channels A use(x,y) pass(x,y) B use(x) pass(y) C use(y) Single integrated control-flow and data channel Synchronous passing of control-flow and data between preceding and subsequent task(s) Data passing approach used by YAWL and BPEL 17

18 Data Interaction between Tasks Distinct Control and Data Channels A use(x,y) pass(x) B use(x) C use(y) pass(y) Different control-flow and data channel Timing considerations in order to ensure both control-flow and data arrive at tasks at the required time Used by WebSphere where data passing is based on the notion of containers sent between tasks 18

19 Data Interaction between Tasks No Explicit Data Passing Global Shared Data def var X def var Y A use(x,y) B use(x) C use(y) No explicit data passing Data elements held in global data store and used by tasks when required Data passing approach used by Staffware, FLOWer, COSA, BPMN, etc. 19

20 Data Interaction - Task to/from Environment case A B D def var M pattern 14 pass(m) pattern 15 request(t) pass(t) external process def var S def var T C E def var N pattern 16 pass(s) pattern 17 request(n) pass(n) 20

21 Data-based outing workflow repository def var M 2.7 workflow case repository def var N AB02 case > 10 B A par out ret M > 3.1 C N <> AB01 D 21

22 Classes of esource Patterns Creation patterns design-time work allocation directives (which resources may execute a work item at runtime) Push patterns workflow system proactively distributes work items Pull patterns resources proactively identify and commit to work items Detour patterns re-routing of work items Auto-start patterns automated commencement Visibility patterns observability of workflow activities Multiple resource patterns work allocation involving multiple participants or resources See: 22

23 Understanding the basic esource Patterns Work Item life-cycle S:offer-s offered to a single resource :allocate-s :start-s suspended :suspend :resume S:create created S:allocate allocated to a single resource :start started :complete completed S:offer-m :allocate-m offered to multiple resources :start-m failed :fail S: System : esource creation push pull 23

24 Main Creation Patterns Design time considerations relating to which resources may execute a work item at runtime Direct Allocation The ability to directly specify at design time the identity of the resource that will execute a task ole-based Allocation The ability to specify at design time that a task can only be executed by resources which correspond to a given role Capability-based Allocation The ability to offer or allocate instances of a task to resources based on specific capabilities that they possess 24

25 Main Push Patterns Correspond to situations where newly created work items are proactively routed to resources by the workflow system Key dimensions: Offer or allocation Single or multiple resources Basis of allocation (random, round-robin, shortest queue) Timing of distribution vs enablement Distribution by Offer Single/Multiple esource(s) The ability to offer a work item to a selected resource or to a group of selected resources Distribution by Allocation Single esource The ability to allocate a work item to a selected resource 25

26 Main Pull Patterns Correspond to situations where a resource proactively seeks information on available work and commits to undertaking specific work items Key dimensions Allocation vs execution Configurability of work basket Autonomy in selecting next work item esource-initiated Allocation The ability for a resource to commit to undertake a work item without needing to commence working on it immediately The work item is considered to be allocated to the resource and it cannot be allocated to or executed by another resource esource-initiated Execution Allocated/Offered Work Item The ability for a resource to commence (start) a work item previously allocated/offered to him/her 26

27 The YAWL Language Control-flow Perspective a university 2009,

28 From the Patters to YAWL YAWL Highlights Comprehensive approach Workflow Patterns original control-flow patterns*, resource patterns, and exception handling patterns not through a construct-per-pattern approach as in BPMN considered the most powerful process specification language for capturing control-flow dependencies and resourcing requirements Extends Workflow Nets Formal semantics original definition of YAWL: state-transition system latest definition: CPN (Colored Petri nets) interpreter this removes ambiguity and provides opportunities for verification Sophisticated verification support Sophisticated flexibility support Exception handling Dynamic workflow Declarative workflow * initial set of 20 patterns 28

29 YAWL vs Petri/Workflow Nets Petri nets have difficulties capturing: The General Synchronising Merge Patterns involving Multiple Instances Cancellation of a certain part of a process For the Control Flow Perspective, YAWL takes some concepts from Petri/Workflow nets and adds constructs for: O-join to deal with General Synchronising Merge Multiple Instance (MI) tasks Cancellation regions Syntactic Sugar (various splits/joins, direct connections between tasks) 29

30 Control-flow Perspective: YAWL Notation Composite task Multiple Instance task 30

31 YAWL Language Lexicon (1/3) The Input condition is where a process starts The Output condition is where a process ends The Atomic task represents a single task to be performed by a human or an external application The Condition represents a state process The AND-split activates all outgoing links from this task upon completion The AND-join activates this task when all incoming links have been activated 31

32 YAWL Language Lexicon (2/3) The O-split activates a number of outgoing links from this task upon completion The O-join activates this task when one or more incoming links are activated and there is no possibility for other links to be activated if the task continues to wait The XO-split activates one outgoing link from this task upon completion The XO-join activates this task each time an incoming link has been activated 32

33 YAWL Language Lexicon (3/3) The Composite task is a container for another YAWL process, and as such provides a decomposition mechanisms The Multiple Instance task allows multiple instances of a task to run concurrently. The min and max number of instances, the threshold for completion and whether new instances can be created on the fly or not can be specified In a Cancellation egion, all elements (from single tasks up to whole processes) within the dotted region are deactivated upon task activation Source: 33

34 Basic Control-flow Patterns in YAWL (1/2) Sequence: Task B follows task A. Parallel Split: Task B, task C and task D are executed in parallel after task A. Synchronisation: After the execution of task B, task C, and task D, task E can be executed. AND-split AND-join 34

35 Basic Control-flow Patterns in YAWL (2/2) Exclusive Choice: A choice is made to execute either task B, task C or task D after execution of task A. Note that such a choice typically involves predicates specified for the various arcs. Currently such conditions are specified in XPath. Simple Merge: Task A will be started when any one of the tasks B, C or D completes. This solution is identical to the solution Multiple Merge. This pattern though makes a context assumption: there is no parallelism preceding task A. XO-split XO-join 35

36 Some Other Patterns in YAWL (1/2) Multiple Choice: Task B, task C, task D or any combination thereof is executed after task A Note that such a choice typically involves predicates various arcs. Currently such conditions are specified in XPath. Synchronising Merge: Task A can execute when at least one of the tasks B, C, or D has completed and there is no possibility of another incoming branch becoming active in the foreseeable future, given the current state of the workflow. O-split O-join 36

37 Some Other Patterns in YAWL (2/2) Deferred Choice: After task A, both tasks B and C are enabled. When one of them is selected for execution, the other one is disabled. Multiple Instances With a Priori Design Time Knowledge: After task A, n instances of task B are created. When all such created instances are completed, task C can start. Source and other patterns 37

38 Example: Applying for a Credit Card Consider a credit card application process.the credit application process starts when an applicant submits an application (with the proposed amount). Upon receiving an application, a credit clerk checks whether it is complete. If not, the clerk requests additional information and waits until this information is received before proceeding. For a complete application, the clerk performs further checks to validate the applicant's income and credit history. Different checks are performed depending on whether the requested loan is large (e.g. greater than 500) or small. The validated application is then passed on to a manager to decide whether to accept or reject the application. In the case of acceptance, the applicant is notified of the decision and a credit card is produced and delivered to the applicant. For a rejected application, the applicant is notified of the decision and the process ends. 38

39 Applying for a Credit Card: YAWL Net Source 39

40 The YAWL Language Data Perspective a university 2009,

41 Overview of the Data Perspective in YAWL The data patterns were finalized after the initial data perspective for YAWL was developed the data perspective in YAWL is not based on a comprehensive analysis of the data patterns The data perspective in YAWL relies on XML technology Data epresentation and Validation: XML Schema Data Transfer and Transformations: XQuery Decision making (data-based conditional routing): XPath 41

42 Data epresentation in YAWL In YAWL, all data are represented as XML documents Data elements are stored in variables; there are: net variables for storing data that need to be accessed and/or updated by tasks in a net task variables for storing data that needs to be accessed and/ or updated only within the context of individual execution instances of a task YAWL applies strong data typing data types are defined using XML Schema 46 XML Schema simple data types for variable definition (boolean, string, double, etc.) the users can also supply their own XML Schema to define more complex data types 42

43 Data as XML Documents The data inside of YAWL exists as many XML documents 43

44 Strong Data Typing and XML Schema 44

45 Variables Definition in YAWL Variables describe what data must be supplied to a running net or task instance, and what data that net or task instance will eventually deliver Each variables has: a name it may be referenced by a type dictating valid values it may store (cf. XML Schema) a designation indicating how that data may be used a scope defining the visibility of the variable (net or task variable) Valid designations for a variable are input, output, both input&output, and local in general, data are written to input variables and read from output variables only net variables can be defined as local local variables are used to store data that can be manipulated only internally within the scope of the corresponding net they are used to store intermediate data during the execution of a process instance 45

46 Data Transfer in YAWL YAWL does not support direct data passing between tasks data cannot be directly transferred from one task instance to another this is because each task variable is local to the task that the variable belongs to, i.e., it is not accessible by other tasks In YAWL, all data is passed from net-level variables to task-level variables when a task instance starts a task variable with an input designation is one where we expect data to be delivered from a net-level variable to that variable at run-time from task-level variables back to net-level variables when the task instance completes a task variable with an output designation can have its data output to a containing net-level variable once a task instance has completed Data transfer from a net to a task and viceversa is achieved via inbound and outbound mappings defined as XPath or XQuery expressions an inbound mapping is a statement that says how to transfer data from the net's variables to a task's input variables an outbound mapping is a statement that says how to transfer data from the task's output variables to its containing net's variables 46

47 Data Transfer and Mappings 47

48 Data Transfer and XQuery 48

49 Data-based Conditional outing When tasks have XO or O splits, which branch(es) to choose is determined by conditional expressions associated with branches these conditions are boolean expressions that involve data within the process In YAWL, the branching conditions are specified as XPath boolean expressions the branches whose conditions evaluate to true will be executed all true branches for an O-split the first true branch for a XO-split for each task with XO or O split, there is always a default branch that will be taken if none of the other branch conditions evaluate to true Only net variables are allowed to be used in specifying branch conditions this is because the evaluation for a task with XO or O split is conducted after completing the execution of the task, and therefore the task variables are no longer available 49

50 Decision Making and XPath 50

51 The YAWL Language esource Perspective a university 2009,

52 Overview of the esource Perspective in YAWL The resource perspective is primarily responsible for modeling an organizational structure, and the people who populate it In general, a resource may be a person (participant), or an application, service or codelet (piece of code) Workflow tasks that require resourcing at runtime have their resourcing requirements specified at design time 52

53 YAWL Organisational Model (1/2) *all relations are from the perspective of a unique participant 53

54 YAWL Organisational Model (2/2) Each participant may perform one or more oles a role is a duty or set of duties that are performed by one or more participants (e.g., manager, employee, officer, etc.) hold one or more Positions (each of which belongs to an Org Group) a position typically refers to a unique job within an organization (e.g., CEO) purposes of defining lines-of-reporting within the organizational model (hierarchy) an organizational group (org group) is a functional grouping of positions (e.g., marketing, sales, human resources groups) possess a number of Capabilities a capability is some desired skill or ability that a participant may possess (e.g., first aid skills, driving license, etc.) 54

55 Design-time esourcing equirements For a manual task, a designer may provide details of a distribution set of resources to which the task should be offered at runtime A distribution set may consist of the union of: zero or more individual participants, zero or more roles, and zero or more dynamic variables (which at runtime will be supplied with details of participants and/or roles) The resultant distribution set may be further filtered by specifying that only those participants with certain capabilities, occupying certain positions and/or being members of certain org groups, be included 55

56 esourcing Interaction Points There are three interaction points places in a work item s lifecycle where resourcing decisions are to be made up to and including the moment the work item is placed in a work queue At each interaction point, the decision may be: system-initiated automatically performed by the system, using parameters set at design time, or user-initiated manually performed by a participant or administrator at runtime The three interaction points are: Offer: The work item is offered to one or more participants for execution. There is no implied obligation (from a system perspective) participant to accept the offer Allocate: The work item is allocated to a single participant, so that the participant is committed (willingly or not) to performing that work item at a later time. If the work item was previously offered to several other participants, the offer is withdrawn from them at this time; and Start: The work item is started by the allocated participant (i.e. enters executing state) 56

57 The YAWL System Architecture a university 2009,

58 The YAWL System The YAWL System enacts processes defined in the YAWL language First prototype was released late 2003 First full open-source release was beta 2 in July 2004 control flow only Later releases added the data perspective and, most recently, the resource perspective current release: YAWL 2.3 (19/04/2012) Support environment is open source currently LGPL no acquisition costs avoids vendor lock-in available at 58

59 Service-Oriented Architecture The YAWL System has a Service-Oriented Architecture (SOA) architecture made of an extensible set of YAWL Services each has a unique address and endpoint each has one or more interfaces some offer functionality to end users, some interact with other services and applications, some do both The YAWL System uses the epresentational State Transfer (EST) architectural style YAWL Services provide access to resources (workflow specifications, data, etc.), each referenced with a UI YAWL Services communicate via HTTP GET (retrieve information about a resource) and POST (create or update a resource) operations transferred data documents are in XML format 59

60 YAWL System: Language & Deployment The YAWL System is written in Java Each service is, at its base, a Servlet is packaged as a web archive (war) file is deployed in a Servlet Container YAWL uses Apache Tomcat Each service can be deployed to the same or different containers, local or remote, to other YAWL Services 60

61 YAWL System Simplified Architecture YAWL Engine Persisted Data Event Log Process Designer Interfaces Other Custom Services Process epository esource Service Org Data Event Logs Admin Users Applications 61

62 YAWL System: 3 Tier (Holistic) View 62

63 Data Layer Specifications: consisting of control-flow logic, data definitions and data & resource mappings Execution data: current case instance and archival data, including data instances and values Organisational Model: hierarchical resource definitions (roles, positions, org groups, capabilities) Worklets: specialised specifications and associated rules Codelets: executable code fragments that may be triggered by tasks 63

64 Business Logic Layer (1/2) Workflow Engine: the core service, creates, routes and synchronises the execution of tasks according to a specification esource Manager: assigns tasks to resources according to a specification and an Org Model Worklist Handler: presents assigned work to end users via a set of work queues in a browser form Process Validator: validates specifications to ensure they adhere to a schema and are syntactically and semantically correct 64

65 Business Logic Layer (2/2) Forms Connector: loads and populates pre-defined or dynamically generated forms for task presentation Worklet Manager: adds dynamic flexibility and exception handling capabilities to designated specifications Codelet Manager: executes code fragments of behalf of a task Other Services: WS-Invoker, SMS-Invoker, Digital Signature Service, Declare Service, Twitter Service, etc. (and any other user-defined custom services) 65

66 Presentation Layer Process Designer: (aka the Editor) a desktop Java application for designing specifications in the YAWL language Worklist Dashboard: a set of browser based forms that allow task management and execution by participants Administration Console: a set of browser based forms that allow loading of specifications, case launching, registration of services, management of Org Model data, work queue administration, etc. Worklet Designer: a desktop.net application that is used to define Worklet rule sets 66

67 YAWL Services and Interfaces The YAWL System architecture is inspired by the Workflow eference Model (WM) The WM describes a core engine interacting with a number of generic components. It identifies 5 major component types and their interfaces: 1: Process definition import and export 2: Client Application where work items are passed from engine to client app (e.g. a worklist) and back again 3: Invoked Application where the engine can directly invoke an external app to process a work item 4: Interoperability with other workflow engines 5: Administration & Monitoring 67

68 Workflow eference Model a university 2009, 68

69 YAWL Engine Interfaces The YAWL Engine provides four interfaces, three of which broadly correspond to the WM interfaces YAWL Engine Interfaces A: Specification upload and unload, service registrations, basic connectivity services (WM 1) B: Establishing sessions, Case launch, passing work items to services and applications, state retrieval (WM 2, 3 & 4) E: Process Log retrieval and analysis (WM 5) X: Detection and handling of runtime process exceptions 69

70 YAWL System Architecture 70

71 Interface B The YAWL System combines the WM interfaces 2, 3 and 4 into one YAWL Interface (B) done to ensure the Engine remains agnostic to its external services delegates management of the interaction of those component types to a YAWL Service Thus all communication between the Engine and external components are handled through a single, generic interface for example, the Web Service Invoker Service acts as an abstraction layer between the engine and external web services 71

72 The YAWL Editor The YAWL Editor is a Java desktop application creation and verification of YAWL process specifications It allows the process designer to: set up process control logic (tasks and control flow) specify data aspects (net and task level variables) define resource perspective verify and analyze process specifications It communicates with a running Engine through Interface A, to obtain a list of the YAWL Services currently registered with the Engine It also communicates with a running esource Service through Interface, to obtain lists of the various organizational resources and codelets currently available, so that selected resources can be associated with particular tasks YAWL process specifications are serialized into an XML document with the file extension *.yawl 72

73 YAWL Editor Screen Shot 73

74 Process Specifications A specification is expressed as an XML document that describes the structure, format, data and layout of a process that has been expressed graphically in the Editor, and written when saved to file Each specification is loaded into the Engine via Interface A The Engine can execute a number of cases at the same time, each one an instance of some specification several versions of the same specification can be loaded at the same time 74

75 Task vs Work Item A YAWL process specification will contain a number of task definitions, and control-flow, data and resourcing specifications are all defined with reference to tasks at design time At runtime, each task acts as a template or contract instantiation of one or more work items that is, a work item is a runtime instance derived from a task definition task work items 75

76 The YAWL Engine The Engine manages the execution of instances (cases) each case is progressed according to its current state and control-flow description the engine performs the specified data mappings between the case and its tasks as required At each stage of a process, the Engine determines which work items should be offered, and which events should be announced to the environment each task in a process instance is associated at design time with a YAWL Service (either explicitly or, if not specified, is implicitly associated with the default worklist handler) 76

77 The Engine: Basic Operations The Engine is totally unaware of the operations of external services, so that each could be served in a generic way from an engine perspective, each service is a black-box that avails itself to process data served by the engine through its interfaces The Engine will prepare work items for execution according to control-flow, but: it is not responsible for how the work is performed; rather it delegates responsibility to a custom service it knows nothing about users, but only of custom services it is unconcerned with how work items are resourced It does manage two perspectives: control-flow: determining which task(s) are enabled at certain times during the life-cycle of a process, based on flows, conditions, splits, joins and so on data: mapping values to and from tasks and their parent nets, performing transformations and evaluating expressions using the specified XPath and XQuery predicates 77

78 The esource Service Provides the resource perspective for specifications completely separate from the Engine Basic role is to allocate work items to resources for processing It has four primary components: esource Manager: handles all the resource patterns Worklist: a web-based user interface Forms Connector: show either custom designed or dynamically generated forms for work items Codelet Server: for executing codelets 78

79 esource Service untime At runtime, the esource Service receives notifications from the Engine via Interface B for all enabled work items that are not specifically registered with another YAWL Service The service undertakes to distribute the work item to resource(s) using the resourcing specifications task from which the work item was created, as specified at design time For manual tasks it will use the resourcing specification defined at design time to determine the initial distribution set of participants, and then apply the defined filters, constraints and allocation strategies to that set before distributing the work item to the appropriate participant(s) For automated tasks the service retrieves a reference to the specified codelet (if any) and then executes it using the work item s data as inputs 79

80 The Worklist Each participant has access to his/her own worklist, which is a graphical representation of his/her work queues via a series of web forms Each worklist consists of four work queues: Offered, Allocated, Started and Suspended depending on a participant s privileges, there are a number of actions that can be performed on a work item in each queue A complete forms rendering engine is encapsulated by the esource service it is responsible for taking a work item s data parameter set and rendering it as a web-based form with an appropriate set of input fields 80

81 YAWL Engine Worklist Screenshot 81

82 YAWL System Sample Work Item 82

83 Typical Work Item Execution Path 83

84 YAWL Live Demo The Editor Defining control-flow, data and resource requirements The un-time Environment Process execution and worklists a university 2009,

85 Summary a university 2009,

86 Summary (1/5) YAWL refers to both a language and a support environment YAWL provides support for a broader range of processes than traditionally covered by workflow management systems Its development was triggered by limitations in existing software Lack of consensus about best approach to process analysis and enactment Standardization efforts have failed (e.g. too much driven by vendor interests) 86

87 Summary (2/5) The Workflow Patterns initiative was driven by the lack of consensus and the inherent complexity of business processes Process modeling requirements are captured through patterns in a language independent way Other than control-flow patterns, many other pattern collections have been developed over the years (e.g. data, resource, exception handling, flexibility, service interaction) Many approaches have been subjected to a patternsbased analysis Process modeling Proposed standards Workflow management systems (both commercial and open source) 87

88 Summary (3/5) A patterns-based analysis provides deep insight into the capabilities of an approach to process specification Many gaps were exposed YAWL was developed to demonstrate that comprehensive patterns support is feasible by means of a simple yet powerful language Petri nets provided the starting point YAWL language The limitations of Petri nets for workflow specification were overcome through the introduction of some dedicated new constructs The resulting language was given a formal semantics to remove any ambiguity and to allow for verification support 88

89 Summary (4/5) YAWL is more than a pen-and-paper exercise Open source support environment has been developed this environment has gradually extended over time and grew into a full-blown BPM solution Substantial interest from both academia and business System uses a service-oriented architecture Engine provides support for control-flow and data, other perspectives are supported through custom services (e.g. resources, exceptions) YAWL, and associated systems such as ProM, provide a wide range of sophisticated analysis techniques 89

90 Summary (5/5) YAWL is a BPM solution that can be used in practice Offers expected BPM functionality Expressive due to comprehensive patterns support Additional aspects can be supported by services (e.g. flexibility) Sophisticated analysis support Open source (easy to install, no software acquisition costs) Use of standard XML technology Well-defined interfaces Influence on current tools and standards Aims to advance the maturity of other approaches End-users may develop a better understanding of BPM requirements 90

91 eferences A comprehensive overview of YAWL and its support environment is provided in the book ter Hofstede, A.H.M.; van der Aalst, W.M.P.; Adams, M.; ussell, N. Modern Business Process Automation - YAWL and its Support Environment; ISBN ; Springer, See also: All references can be found in the extended versions of these slides, available at Useful links Workflow Patterns: YAWL: 91