Accepted Version (PDF 4MB)
Contents
1. Set Custom Form Fig 9 Decomposition to direct data transfer Besides input and output parameters multiple instance tasks need further infor mation for data manipulation This information is specified via four XQuery ex pressions An example of these expressions is provided in Figure 10 which refers to the multiple instance task Log Trackpoint Order Entry in the Order Fulfillment The Design Environment 11 example cf Figure in Appendix The designer needs to define a Multiple Instance Variable that will contain the data to be distributed to the various task in stances at runtime The content of this variable can be taken from net variables using input parameters The data contained in this variable can be separated with the Split ter query to pass a unique value to each instance task The Accessor query can be used to manipulate the content of the variable before the unique values are split out e g if some format conversions are needed Upon completion of all instances the Instance query can be used to transform the returned XML document from each instance to a form suitable for the Aggregate query to generate an overall result A Result Net Variable needs also to be specified to contain the overall result This variable can then be mapped onto net variables via output parameters Bounds Queries Multiple Instance Variable TrackpointNotice v Create Accessor Query Freight_in_Transit2. expiry the task is started In contrast to manual tasks automated tasks are not assigned to any human resource Therefore the timeout is always activated upon work item enablement 6 Stephan Clemens Marcello La Rosa and Arthur ter Hofstede In the Order Fulfillment process model the Ordering sub net has an automated timer task Order Timeout see Figure in Appendix This task is set to a duration of 3 days as shown in Figure 4 After the purchase order has been approved it can be either confirmed task Confirm Purchase Order or modified task Modify Purchase Order Should none of these two tasks be executed within 3 days the Order Timeout task will then be triggered LL FEILIN Prarisit LU LUS5 LYI Vamaye_ManayEmeEnLl LY SAarneErLApPpPUINUNENL LJ NRELUITI_Managemene V7 VUveldll Ordering O Payment Set limer Detail for Atomic lask Order Timeout x Iv Task is required to timeout Timeout Create Purchase at the time of after a duration of P3D 7 s a D Timer begins upon work item enablement o dify ie irm Order Bs set O upon work item starting D Order Puchase Orde FAD c o Cut LA Cop Done Cancel E yj Del i end_ ing T view Cancellation Set Set Ree Timer gt 1S Fig 4 Setting up the parameters of the timer task Order Timeout In the case of multiple incoming flows the task needs to be decorated with a join cons
3. of element s content Output Parameters from element of net variable Porder v add XQuery of entire element XQuery Approve_Purchase_Order XQuery false lt POrder gt Ordering POrder Ce AP PP LILLO T IITE GEG LI LL LL AIL HLA HSS EH ESAS feeeeeteatas CELLET LLLI LELLI LELLI TI LITT LIITE lt POrder gt populates he task vale Powder Fig 8 The input parameter to transfer the content of net variable POrder to task variable POrder LJ PPC TL_ Ot ITAnNSIL LJ tUSS_VI_LUV E L o Ordering at E fa Atomic Task Approve Purchase Order x Select a number of net variables to be used as input to this task Do the same for output The selected net variables will have type compatible task variables of the same name created for them and mappings that will enact a direct data copy between the newly created task variables and the specified selected net variables Decomposition name Approve Purchase Order Net Variables for Input Net Variables for Output Name Type Name Type POrder PurchaseOrder POrder PurchaseOrderType v P0Approva boolean POApprovat E Po_timedout_ boolean kpo timedout LI PO_Manager L PO_Manager Za O O O O O Decompose this task to a direct data transfer with its net Drop Task Decomposition Modify Purchase Order Task Decomposition Detail Update Parameter Mappings Y Update Flow Detail end_Orde Manage Resourcing
4. 1 gt lt attributes gt lt lineStyle gt I11l lt lineStyle gt lt points gt lt value x 192 5 y 111 0 gt lt value x 191 5 ys 153 0 gt lt points gt lt attributes gt lt flow gt Listing 2 Layout information for task Create Purchase Order 7 Summary This chapter introduced the main features of the YAWL Editor It showed how to create and analyze the control logic of a YAWL process how to specify the involved data and how to link organizational resources to process tasks Moreover the chapter demonstrated the error reporting feature of the Editor and provided an overview of the YAWL interchange format Exercises 1 Download the Editor from SourceForge more details in the Chapter Notes and start the tool Open the Order Fulfillment example available with the distribution and browse the various sub nets cf Appendix Specifically check how data and resourcing requirements have been specified and how different icons were used to identify the various task types 2 Create a workflow specification with two atomic tasks Enter command and Dis play command Through the first task the user should be able to enter a sequence of characters into a variable Command of type string The value of Command should then be displayed via the second task Enrich the specification with icons from the Task Icons palette 3 Extend the above example such that after displaying a command the user should be asked
5. The Design Environment Stephan Clemens Marcello La Rosa and Arthur ter Hofstede 1 Introduction The core modeling component of the YAWL system is the Editor This tool enables workflow designers to graphically define complex YAWL process models and to analyze and export these models to the Engine Specifically the Editor is a rich client application offering visual support for the definition of the process control logic the data associated with the process and its tasks and the organizational resources participating in the process An important aspect of the Editor is the provision of sophisticated logic to verify the produced models Through this capability a designer can pinpoint syntactical and semantic issues at a mouse click so as to avoid potentially costly mistakes before deploying a process to a workflow engine The main driver behind the development of a visual editor for YAWL was the necessity to speed up the creation of YAWL process models and to foster the up take of the language by non technical users In light of this the Editor had to fulfill the requirements of free availability portability ease of use and interoperability The tool had to be freely available therefore it was decided to release it under the open source LGPL license Portability was guaranteed by developing the Editor in Java and avoiding any code dependency on OS specific libraries Ease of use was achieved by providing the Editor with an intuitive use
6. TrackpointNotices w y Splitter Query for i in TrackpointNotices return i a Instance Query lt TrackpointOrderEntry gt lt TrackpointNotice gt lt OrderNumber gt Log_ a Trackpoint_Order_Entry TrackpointNotice OrderNumber text lt OrderNumhbers lt eShinmentNiumhers Ss l oa Tracknoint Order F vy te W Aggregate Query for i in Log_Trackpoint_Order_Entry TrackpointOrderEntry re turn i A Y Result Net Variable TrackpointOrderEntries v Create Done ane Fig 10 Four XQuery expressions for a multiple instance task Finally data aspects also concern the timer task This task in fact allows designers to late bind its expiry value to a period of time or fixed date via the use of a variable of type YTimerType In this way the expiry value will be dynamically determined at runtime 4 Assigning Human Resources to the Process The Editor provides a Resource Manager Wizard which allows designers to assign participants to manual tasks This wizard can be invoked by clicking on Manage Resourcing from the task s context menu after participants have been created in the YAWL workflow environment see Chapter the task has been assigned a 12 Stephan Clemens Marcello La Rosa and Arthur ter Hofstede decomposition and the task has been associated with the default worklist i e the Resource Service It need to be ensured that the R
7. al 3 sourceforge net projects yawl The Design Environment 21 The development aspects behind the YAWL system are illustrated in the Techni cal manual Finally software bug reports and feature requests can be made through the Google code project 4 code google com p yawl
8. and Pre Paid boolean Q YAWLEditor Specification Net Edit Elements Tools View Help Creat Open Specification 2 Update Data Type Definitions it trol l Save Specification Ctrl S A Save Specification As lt xsischema xmlns xs http waw w3 org 2001 XMLSchema elementF amp Validate Specification lt xs complexType name PurchaseOrderType gt Analyse Specification Saa a SEE lt xs element name Company type CompanyType gt Print Specification Ctri P lt xs element name Order type OrderType gt lt xs element name FreightCost type xs double gt Update Specification Properties lt xs element name DeliveryLocation type xs string gt b gt Update Data Type Definitions lt xs element name InvoiceRequired type xs boolean gt lt xs element name PrePaid type xs boolean gt d Close Specification Ctrl W a il Exit 7 Plugin f Fig 6 Complex XML Schema type definition of PurchaseOrderType Before nets and tasks are able to read or modify data they need to be assigned a decomposition see Chapter A decomposition has one decomposition label a unique identifier within the whole workflow specification and may have one or more variables The Editor facilitates the assignment of the same decomposition to multiple tasks and prevents the workflow designer from creating more than one decomposition with the same
9. appings gt lt resourcing gt lt offer initiator system gt lt resourcing gt lt decomposesTo id Create_Purchase_Order gt lt task gt Listing 1 Conceptual information for task Create Purchase Order The XML extract in listing 2 represents the layout information for task Create Purchase Order and for its incoming and outgoing arcs Layout information for a task includes the size and location of the task as well as the path of the icon used to decorate the task Layout information for an arc includes the location of the arc and a code for its line style which can be orthogonal encoded as 11 bezier 12 or spline 13 lt container id Create_Purchase_Order_104 gt lt vertex gt lt iconpath gt Manual png lt iconpath gt lt attributes gt lt bounds x 177 0 y 80 0 w 32 0 h 32 0 gt lt attributes gt lt vertex gt lt label gt lt attributes gt lt bounds x 144 0 y 112 0 w 96 0 h 28 0 gt lt attributes gt lt label gt lt container gt lt flow source InputCondition_16 target Create_Purchase_Order_104 gt lt attributes gt lt lineStyle gt I11l lt lineStyle gt lt points gt lt value x 188 5 y 31 0 gt lt value x 192 5 y 80 0 J gt lt points gt lt attributes gt lt flow gt The Design Environment 19 lt flow source Create_Purchase_Order_104 target Approve_Purchase_Order_190
10. arting net Overall of the Order Fulfillment process model see Appendix displayed on the canvas The control flow of a YAWL specification can be defined by using elements from the palette located at the top of the left toolbar The palette Wf Elements amp Tools contains seven buttons which assist with creation selection and positioning of work flow elements on the canvas see Figure 2 The first five buttons are used to place workflow elements on the net such as an atomic task or a condition The marquee button allows the selection of individual or multiple elements which can be moved within the net while the Net Drag button indicated by a cross is used to drag or modify single workflow elements on the canvas The palette Task Icons contains a set of predefined icons to decorate tasks see Figure 2 For example icons can be used to distinguish tasks that are executed by a human resource from those executed by an application as in the Order Fulfill ment process model This set of standard icons can be enriched with custom made icons added through a plug in mechanism The use of icons can increase the overall understanding of a process but it will not influence the task s behavior A YAWL workflow specification is composed of one starting net and zero or more sub nets The starting net captures the behavior of the overall process and is the first net to be executed when a case is launched Each sub net captures the behav ior of a com
11. cation The point at which one of the participants offered the work item is nominated to do that work item Start The point at which the participant allocated a work item begins working on it Offering a work item for this task to a number of participants is to be done by O User System Allocating a work item for this task to one of the offered participants is to be done by User O System Starting an allocated work item of this task is to be done by O User System gt Next Finish Fig 11 Step one choosing how to offer allocate and start a work item Step two enables a workflow designer to select individual participants by their name e g Peter Clemenza and or participants of a certain role e g PO Manager see Figure 12 In step three it is possible to restrict the group of participants to those who belong to a certain organizational group or positions or have appropriate capabilities see Figure 13 In some cases it may be required to defer the choice of which participant will get offered a particular work item until runtime This can be done by setting the offering to user initiated to allow a user with offering rights e g an administrator to determine whom the work item is to be offered to at runtime Alternatively the The Design Environment 13 Step 2 Specify System Behaviour when Offering a Work Item The offer process involves choosing which participants should be informed of the existence of the work it
12. em one of whom will eventually do this work As you have specified the system manage the offer process you must now choose who the work item should be offered to Begin by specifying a set of participants and or to distribute offers of work to You may also specify a net parameter which at runtime will contain a participant s userid or the name of a role Participants Roles Net Parameters Kay Adams ka Account Manager Name Refers to Billy Van Arsdale bva Carrier Admin Officer Momo Barone mb Client Liaison Emilio Barzini eb Courier Peter Clemenza po Finance Officer hana aman Junior Supply Officer Order Fulfilfment Manager PO Manager N Senior Finance Officer Unselect All Senior Supply Officer Unselect All Fig 12 Step two specifying the distribution group for work item offering Step 3 Specify Distribution Set Filter s Filters Select the filters to be applied to the distribution set Set parameter values for the selected filter as required Filter Parameter Value Filter by Organisational Data _ Filter by Capability Runtime Constraints _ Allow this task to be piled to a single participant _ Choose participant s who completed previous task Timeout v _ Do not choose participant s who completed previous task Fig 13 Step three filtering the distribution group Editor enables the use of a variable to store the participant s user identification late bindin
13. ents are provided in Section 4 An atomic task associated with the default worklist handler is manual by default If set as automated a designer may assign a codelet or an external application to the task via the Update Task Decomposition dialogue available from the task s con text menu Codelets are code snippets that are executed internally by the Engine To select a codelet the Editor needs to be connected to the Resource Service A predefined set of codelets is provided with the Editor These include a codelet for executing shell commands and a codelet for evaluating XQuery expressions In ad dition workflow designers can plug their own codelets into the YAWL environment The Design Environment 5 Similarly in order to assign an external application to an atomic task the application needs to be exposed as a Web Service and the latter be registered with the YAWL environment The YAWL system provides a number of custom services already see Chapter In order to associate a custom service with a task the Editor needs to be connected to the Engine If the Engine is active but the status icon in the Editor see bottom left of Figure 2 states it as offline a connection can be manually established by invoking the dialogue Engine Connection Settings via menu entry Tools If an atomic task is neither manual nor automated it is an empty task An empty task may be a routing task which is essentially a silent task that is only used for routin
14. esource Service is running so that resources can be associated with a task The status of the Resource Service is reflected by the second right icon in the bottom left corner of Editor see Figure 2 If the Resource Service is active but the status icon states this service offline a connection can be manually established by invoking the dialogue Resource Service Connection Settings via menu entry Tools The first step of the wizard allows designers to set up the way a manual task should be offered allocated and started These are called interaction points The interaction points for task Create Purchase Order are shown in Figure 11 At the first interaction point the work item gets offered to one or more participants The offering can be set up as system initiated or user initiated In the case of a system initiated offering it is required to specify the group of participants at design time This can be done in the second and third steps of the wizard Step 1 Choose Behaviour At Interaction Points There are three key decision points for managing the resourcing of work items spawned from a task At each of these interaction points you may choose to have the system dynamically make a decision on resourcing at each point or alternately allow a user to manually make each decision Each interaction point is briefly described below Offer The point at which it is decided that a number of participants could undertake the work item Allo
15. g The variable can be specified within step two of the wizard In the sub net Ordering task Create Purchase Order allows one to specify a participant who will work on the purchase order if the latter needs to be modified So should the task Modify Purchase Order be executed the participant in the net variable PO_Manager will get offered the work item 14 Stephan Clemens Marcello La Rosa and Arthur ter Hofstede At the second interaction point the work item gets allocated to a participant out of the group of participants who have been selected for this work item Once a work item is allocated to a specific participant the work item offer is withdrawn from all other participants In the case of a user initiated allocation the participant who is offered the work item can decide whether or not to accept it On the other hand in a system initiated allocation the workflow system decides which participant the work item should be allocated to However in this case the workflow designer needs to define the appropriate allocation strategy during design time The fourth step of the Resource Manager Wizard provides several strategies to choose from e g Round Robin or Shortest Queue see Figure 14 Step 4 Specify System Behaviour when Allocating a Work Item The allocation process involves choosing a single participant from those who are offered a work item to actually undertake that work As you have specified that the system dynamically do
16. g purposes Routing tasks are executed internally by the Engine Another type of task is the multiple instance task which captures an atomic or composite task to be executed multiple times in parallel The upper and lower bounds for the number of instances the threshold for completion and the way of instance creation can be specified via the Set Instance detail dialogue available from a multiple instance task s context menu Figure 3 shows the tasks hierarchy in the Editor Task Atomic Composite Single Multiple Single Multiple CH O A N Manual Automated Routing Manual Automated j is Lo Fig 3 Tasks hierarchy in the Editor An atomic single instance task can have a timer set if it needs to be executed within a given timeframe The parameters of a timer task can be specified via the Set Task Timer dialogue accessible from the task s context menu These are the expiry value and the activation type The expiry value indicates when the timeout should expire This can be after a period of time e g 3 hours or at a specific point in time e g 25 12 2008 The activation type depends on whether the task is manual or automated In the case of a manual task the designer can specify whether the timer should be activated when work items of that task are enabled or when they are started In the case of automated tasks the timeout behaves as a delay i e the execution of the task is delayed by the timeout value Upon timeout
17. he application is passed on to a manager who decides whether to accept or reject it In either case the customer is notified of the decision and the process finishes 6 Extend this workflow by allowing the possibility to cancel the application process at any time after a complete application is received but before the manager decides on the application 7 Apply the following change to the credit card application process When an approved application is notified the customer is asked to choose any extra features they may want to add These include customized card reward program and secondary cardholders Chapter Notes In this chapter we used the YAWL Editor version 2 0 The tool along with the other components of the YAWL system can be downloaded from the YAWL project Web site hosted by SourceForge Here the reader can find documentation on various aspects of the Editor and consult the mailing lists and forums to learn the latest news about the system The YAWL user manual is the complete reference documentation for the YAWL user It contains information on how to install YAWL and dedicated guides for the Editor and the YAWL runtime environment In addition it includes the tutorial Get ting started with YAWL which provides a brief overview for the reader interested in experimenting with the Editor On the other hand the reader interested in advanced data aspects can consult the section How to manipulate data in YAWL of this manu
18. ile the runtime environ ment represents a Workflow Enactment Service for the execution of such workflows The interaction between these two components is achieved via the Workflow Defini tion Interchange Interface 1 which is embodied by the XML format and the set of APIs in the YAWL system According to the WfMC the advantage in using a standard interaction format is twofold Firstly it defines a clear point of separation between design and runtime environments Secondly it enables the use of different design tools and workflow engines For example a workflow specification exported by an editor could be ex ecuted by a number of independent workflow engines that cooperate to provide a distributed runtime environment Similarly it is also conceivable to think of a de velopment environment in which a number of design tools can export workflow l www jgraph com www wfmc org The Design Environment 3 specifications to the same runtime environment For example these tools could dif fer in their look n feel or preferences to address different classes of users 2 Setting up the Process Control Logic The Editor user interface comprises a modeling canvas located in the centre two toolbars one on top and the other on the left of the canvas a bottom panel for notes problems and a status bar reflecting the status of the Engine Resource Ser vice and general messages Figure 2 shows a screenshot of the user interface with the st
19. in the arc is in cluded The cancellation set of a task can be visualized on the canvas by clicking on View cancellation set from the task s context menu This enables two buttons in the top toolbar Cancellation Sets see Figure 2 which can be used to add in elements or remove them from the cancellation set The task that initiates a cancellation set is grayed out while the elements in the cancellation set are indicated with a red border 3 Defining Data Aspects In a YAWL specification the data flow is captured by means of net variables The passage of data to from tasks is achieved by mapping net variables to tasks vari 8 Stephan Clemens Marcello La Rosa and Arthur ter Hofstede ables At runtime variables are used to compose the content of a task s work item and to determine the routing behavior of splits A variable acts as a container in which a value of a certain XML Schema data type is stored The Editor supports the full set of simple XML Schema types e g long string boolean Complex XML types can be defined as compositions of sim ple and complex types via the Update Data Type Definitions dialogue which can be found under the File menu For example PurchaseOrderType is a complex type used in the Order Fulfillment process model to describe the content of a purchase order see Figure 6 It consists of further complex type variables such as Company and Order and of simple type variables such as DeliveryLocation string
20. label The details of a net decomposition i e its label and variables can be set up through the Update net detail dialogue under the Net menu whereas task decom positions can be created via the Select Task Decomposition dialogue and modified via the Task Decomposition detail both available from the task s context menu Figure 7 shows the decomposition of task Create_Purchase_Order Here variable PO_Manager is of simple data type string to contain the username of the purchase order manager while POrder has been assigned the complex type PurchaseOrder Type as defined in Figure 6 The Editor supports the workflow designer in setting up inbound and outbound mappings to specify how data is transferred between net and task variables In partic ular for each task s decomposition input parameters are used to transfer the content The Design Environment 9 LY TEYIN FEES Ly VDF _VI_UV aI ayet_iViadiiayeriins Oo Ordering l O Payment A Update Task Decomposition Create_Purchase_Order x Standard Extended Attributes Task Decomposition Label Create_Purchase_Order a Task Decomposition Variables n 6 i Create Purchase Name Type Usage Create Order ii PO_Manager string Output Only P POrder Purchase0rderType Output Only Update ary 4 Update Task Variable POrder Standard Extended Attributes YAWL Registered Serv YAWL Na
21. me POrder Type PurchaseOrderType w OrderLinesType OrderType Default Value PackageType PackagesType PurchaseOrderType RouteGuideType TrackpointsType TrailerUsageType External Interaction Usage Output Only iy Cancel Fig 7 Decomposition of task Create_Purchase_Order and set up of variable POrder of net variables into task variables inbound mapping while output parameters are used to transfer the content of task variables into net variables outbound mapping These parameters are defined as XQuery expressions via the Update Parameters di alogue from the task s context menu Figure 8 shows the mapping for task Approve Purchase Order of the sub net Ordering Figure Here an input parameter is used to copy the content of the variable POrder of the net Ordering indicated by the XQuery Ordering POrder x into the task variable POrder Even though both variables are labeled the same they are assigned to different decompositions and therefore different scopes This copy operation does not create any issue On the other hand the two output parameters of task Approve Purchase Order take care of copying the content of the task variables PO_timeout and POApproval to the net variables bearing the same names The creation of decompositions can be labor intensive in the case of large work flow specifications Complex types may need to be created variables
22. mic task Approve Purchase Order in the sub net Ordering Figure is decorated with a split and a join The XOR construct at the bottom of the task splits the control flow if the purchase order is not approved the flow is routed to the end condition of the sub net Otherwise the flow is routed to the subsequent condition leading to the atomic tasks Modify Purchase Order Confirm Purchase Order and Order Timeout CPCI YTEC OP OP Gaeta CUCL Vv LI ordes S Flow detail for Atomic Task Approve Purchase Order x m Target Task Predicate 0rdering P0Approval tex end_Ordering true Create Purchase Ortier The bottom most flow will be used as the default a a 4 Update Flow Predicate ma Set Label Purchase Order of Cut Net variable POApproval M XPath Expression Fa Copy 0rdering P0Approval text true T Delete T View Cancellation Set D _ Set Task Timer Decompose to Direct Data T Confirm Puchas Order sa Select Task Decomposition Drop Task Decomposition Done Cancel Task Decomposition Detail Update Parameter Mappings m Y Update Flow Detail N end_Ordering Manage Resourcing Set Custom Form Fig 5 Setting up routing conditions for an XOR split A task can be associated with a cancellation set which may include a number of tasks conditions and or arcs in the latter case the implicit condition
23. need to be typed and mappings need to be defined between net and task variables The Editor is able to facilitate this process as long as no decomposition has been assigned to an atomic task yet This can be done via dialogue Decomposition to direct data trans fer accessible from a task s context menu Here the designer can use net variables as a template to create a task s decomposition Specifically the designer can select a set of net variables to be used as input to the task and similarly a set of net variables to be used as output from the task Then the Editor creates task variables bearing the same type of the net variables input parameters to map input net variables onto task variables and output parameters to map task variables onto output net variables Figure 9 shows the direct data mapping for task Approve Purchase Order 10 Stephan Clemens Marcello La Rosa and Arthur ter Hofstede ee eee ANDIL LJ t gt gt _Vi_wvail Fa j O Ordering P Update Parameters for Atomic Task Approve Purchase Order Input Parameters XQue Task Variable Ordering POrder POrder Purchase Order Z m Net Variables Task Variables A o Name Type Usage Name Type Usage Approve POrder PurchaseOrderType Output Only fa POrder PurchaseOrderType Input Only fa Order POApproval boolean Input_ amp 0 POAnnrows hoolean Out n On PO_timedout boolean out S Update task Parameter POrder Xx PO_Manager string add XQuery
24. nts to manipulate Fig 16 The missing inbound mapping for variable bar causes the listed validation problems the Editor interface see Figure 2 Figure 17 shows a workflow with a potential deadlock and the respective analysis result Analyse i Specification Notes Specification Analysis Problems ResetNet Analysis Warning The net New_Net_1ndoes not have an option to complete The final marking is not ResetNet Analysis Warning The net New_Net_1 tan deadlock at marking s 1c A_5_C_3 1c A_5_B_4 ResetNet Analysis Warning The net New_Net_l does not satisfy the soundness property Select a number of net elements to manipulate Fig 17 The Editor detects a potential deadlock The Design Environment 17 6 Specification File The Editor serializes a workflow specification into an XML document with exten sion yawl This document contains a mandatory conceptual part with information about decompositions workflow elements and their relations While the conceptual information is required to execute a workflow its visualiza tion is important for communication purposes Workflow elements might be placed in a certain way or enriched with specific icons to improve the process understand ing This information is contained in the layout part which is optional and ignored by the Engine when a specification is loaded The Editor uses layout information in conjunction with the conceptual information to represent a wo
25. posite task and is executed once the respective task fires For example in the Order Fulfillment process model the net labelled Overall is the starting net while nets Ordering Payment and Freight in Transit are sub nets mapped to the homonymous composite tasks see Figure 2 The division of a process model into smaller parts by means of sub nets can facilitate maintenance and readability espe cially in the case of complex process models such as the Order Fulfillment example Each net features two mandatory elements the input and the output condition which cannot be removed from the canvas Tasks can be arranged between these two nodes to describe the control flow of the process and are connected to each other by means of arrows which represent order dependencies While a composite task is a placeholder for a sub net an atomic task captures a standalone piece of work namely a work item There are three types of atomic task manual automated and routing task A manual task is executed by a human re source e g a particular employee or an organization participant with a certain role or position In the sub net Ordering Figure of the Order Fulfillment process 4 Stephan Clemens Marcello La Rosa and Arthur ter Hofstede Net Maintenance iew Help Cancellation Sets Specification Maintenance Specification Net Edit Elements Tools B S alalelsB q Alignment Options Specification Verifica
26. r interface on top of a core Stephan Clemens Queensland University of Technology Brisbane Australia e mail stephan clemens qut edu au Marcello La Rosa Queensland University of Technology Brisbane Australia e mail m larosa qut edu au Arthur ter Hofstede Queensland University of Technology Brisbane Australia e mail a terhofstede qut edu au 2 Stephan Clemens Marcello La Rosa and Arthur ter Hofstede graphical component based on extensions to the JGraph libraries Interoperability was supported by the definition of acommon XML format and a set of API calls for the exchange of workflow specifications between an editor and the runtime environ ment see Chapter The interaction between design and runtime environment in the YAWL system is depicted in Figure 1 YAWL Process Editor Visual process model XML Oy Workflow API calls specification YAWL Runtime Environment Fig 1 Workflow specifications created with an editor are deployed to the runtime environment The decision to minimize the dependencies between the design environment and the runtime environment via the use of a common interchange format and a set of APIs is inspired by the Workflow Reference Model proposed by the Workflow Man agement Coalition WfMC In WfMC terminology an editor embodies a Process definition tool for modeling and analysis of workflows wh
27. rkflow However if no layout information is enclosed within the XML document the Editor will visualize the workflow specification with a standard layout Listing 1 is an extract of the conceptional information for the Order Fulfillment process model see Appendix It shows a decomposition with its identifier Cre ate_Purchase_Order and two of its variables Below the task Create Purchase Or der is represented with its reference to its successor task Approve Purchase Order related mappings and resource information This task refers to the mentioned de composition Create_Purchase_Order lt decomposition id Create_Purchase_Order gt lt outputParam gt lt name gt PO_Manager lt name gt lt type gt string lt type gt lt outputParam gt lt outputParam gt lt name gt POrder lt name gt lt type gt PurchaseOrderType lt type gt lt outputParam gt lt externalInteraction gt manual lt externalInteraction gt lt decomposition gt lt task id Create_Purchase_Order_104 gt lt name gt Create Purchase Order lt name gt lt flowsInto gt lt nextElementRef id Approve_Purchase_Order_1901 gt lt flowsInto gt lt completedMappings gt lt mapping gt lt expression query amp lt POrder amp gt Create_Purchase_Order POrder x amp 1t POrder amp gt gt lt mapsTo gt POrder lt mapsTo gt 18 Stephan Clemens Marcello La Rosa and Arthur ter Hofstede lt mapping gt lt completedM
28. that will prevent the specification from running in a workflow engine For example by vali dating the specification in Figure 16 the workflow designer will be informed about the missing inbound mapping for variable bar of task Task A Another error reporting feature of the Editor is the analysis of a specification This can be trigged via button Analyze this specification from the top toolbar Spec ification Verification and Analysis see Figure 2 Analysis allows the workflow de signer to detect potential behavioral problems of the workflow specification That is for example deadlock situations unnecessary cancellations set members or un necessary OR joins see Chapter for further information Analysis results are reported in the Specification Analysis Problem panel displayed at the bottom of 16 Stephan Clemens Marcello La Rosa and Arthur ter Hofstede Ai pp l Fa Update Parameters for Atomic flask A x New Net 1 Input Parameters Task Variable Net Variables Task Variables Name Type Usage Name Type Usage foo string Local j bar j string Input Only aa Output Parameters Net Variable Notes Specification Validation Problems tomic Task A_3 id A_3 the XQuery for param bar cannot be equal to null or the empty string he task id A_3 needs to be connected with the input parameter bar of decomposition YAWLServiceGateway A Select a number of net eleme
29. this you must now Select the strategy for doing so Choose from one of the strategies below Choose the runtime allocation strategy Random Choice v Round Robin by frequency Shortest Queue Random Choice N Round Robin by time lt Back gt Next Finish Fig 14 Step four specifying the allocation strategy At the third interaction point the work item gets started 1 e executed by a par ticipant This is usually done via a Web form that is linked to the manual task The Editor allows a designer to specify the URL of this form by clicking on Set Custom Form from the task s context menu If no custom form is specified a default form is dynamically generated for the workitem at runtime If the third interaction point is user initiated the participant whom the work item has been allocated to can de cide when to start the execution of that work item In the case of a system initiated start it is the workflow environment which places the work item in the participant s started queue Finally step five of the Resource Manager Wizard allows the specification of sev eral participant privileges for runtime such as suspending or skipping the execution of a work item see Figure 15 The Design Environment 15 Step 5 Establish Default User Runtime Privileges for this Task Can a participant suspend a started work item of this task No Yes Can a participant reallocate a work item of this task
30. tion and Analysis Edit Options Zoom Options Wf Elements amp Tools ci Task Icon No Icon o a Manual o 4 Automated Routing Plugin Task icons Modeling canvas Decorations Notes amp Problems panel Notes Invalid Resource References invalid resource reference in Task Loss Or Damage Management of Net Loss_Or_Damage_Management has been removed invalid resource reference in Task Process Freight Payment of Net Process_Freight_Payment has been removed invalid resource reference in Task Prepare Transportation Quote of Net Carrier_Appointment has been removed invalid resource reference in Task Arrange Delivery Appointment of Net Carrier_Appointment has been removed Use the palette toolbar to edit the selected net Engine Status Resource Service Status Hints amp Messages Fig 2 Graphical user interface of the Editor model tasks Create Purchase Order and Confirm Purchase Order are manual tasks which are performed by the Purchase Order Manager The Editor supports the work flow designer in setting up resource related aspects e g which manual task will be performed by which resource or what strategy to use when allocating a work item This can be done via the Manage Resourcing dialogue which 1s available from the context menu that pops up by right clicking on the task More details on resource assignm
31. to another participant resetting state No Yes Can a participant reallocate a work item of this task to another participant retaining state No Yes Can a participant deallocate themselves from a work item of this task No Yes Can a participant delegate a work item of this task to another participant No Yes Can a participant skip a work item of this task No Yes Fig 15 Step five configuring participant s privileges for execution 5 Error Reporting The underlying philosophy of the Editor is to support the workflow designer in de tecting certain undesirable characteristics in the workflow specification at design time As shown before XQuery and XPath expressions are strongly used in YAWL for data handling However those expressions are not very intuitive to build and can be complex An incorrect expression can have undesired side effects during workflow execution Therefore each XQuery or XPath expression is verified by the Editor when it is entered Correct expressions are shown in green font color incor rect expression are shown in red Furthermore in the case of an incorrect expression a suggestion is provided on how the error can be solved By validating the specifi cation via button Validate this Specification in the top toolbar a table with listed problems appears in the Specification Validation Problem panel located at the bot tom of the Editor interface The entries show details about inconsistencies
32. to enter another command However if the user enters the command quit the process should terminate straightaway without displaying the command quit 4 Introduce a timer task Timeout which cancels task Enter command if no command is given within 20 seconds In this case ensure that the message timeout has been 20 Stephan Clemens Marcello La Rosa and Arthur ter Hofstede triggered is visualized in task Display command What happens to task Timeout if Enter command is completed in time 5 Create a YAWL workflow specification which represents the following credit card application process A typical credit card application process begins when a customer submits an appli cation with a proposed amount of credit Next a credit clerk verifies the status of the application If the application is incomplete e g the customer s credit history is missing the clerk requests additional information and waits until the customer provides this information However if no information is received within a given pe riod of time e g 3 days a request is sent again This is done at most 3 times then the process terminates assuming the customer is no longer interested in the applica tion If a complete application is received on time the clerk verifies the customer s income and credit history Different checks need to be performed depending on the amount of credit e g more stringent requirements may apply to amounts greater than 1000 After this t
33. truct while a split construct needs to be applied in the case of multiple outgoing flows The type of split and join for a task can be chosen from the Decorations palette see Figure 2 and appears as soon as the task is selected on the canvas As long as a task has no join or split decoration the Editor does not allow the connection of more than one incoming or outgoing arc to that task to prevent creating structural issues If a task is decorated with an X OR split the workflow designer can specify routing conditions for each outgoing arc of the split These conditions are predicates expressed in XPath which can be set via the Update flow detail dialogue available from the task s context menu see Figure 5 This dialogue shows the list of outgoing arcs of the split where each arc is referred to by the label of the subsequent node In the case of an XOR split the list of arcs needs to be ordered to determine the evaluation order of the predicates at runtime Control will be passed along the first arc whose predicate evaluates to true In this way only one branch will be executed even if more than one predicate evaluates to true In the case of an OR split control will be passed along each arc whose predicate evaluation is true If all predicates of an X OR split evaluate to false control will be passed along the designated default arc the last arc of the list irrespective of the predicate s result The Design Environment 7 The ato
Download Pdf Manuals
Related Search