Open-source Workflow Evaluation An evaluation of the Activiti BPM Platform. Mikael Nilsson. M.Sc. Thesis within Computer Engineering AV, 30 ECTS

Transcription

1 Mid Sweden University The Department of Information Technology and Media (ITM) Author: address: Study programme: M. Sc. In engineering computer engineering, 240 ECTS Examiner: Tingting Zhang, Tutors: Anders Trollås, Cybercom Group, Fredrik Håkansson, Mid Sweden University, Scope: words inclusive of appendices Date: M.Sc. Thesis within Computer Engineering AV, 30 ECTS Open-source Workflow Evaluation An evaluation of the

2 Abstract Abstract The aim of this thesis is to evaluate the newly released open-source business process management platform Activiti. The platform is evaluated in the first instance by implementing the control-flow patterns which will be used at a later stage as a comparison with other platforms that have already been evaluated. Activiti comes with a web application called Activiti Explorer which is a graphical user interface between the process engine and the user. As all the desired features commissioned by the Cybercom Group were not available in the Activiti Explorer its source-code was extended. These extended features included support for several companies per installation and the ability to customize the layout of the components in user task forms. The report is concluded with a comparison between Activiti, jbpm, OpenWFE and Enhydra shark with regards to the control-flow patterns. Keywords: Open-source, Workflow, BPM, BPMN 2.0, Activiti, Workflow patterns, Control-flow patterns ii

3 Acknowledgements Acknowledgements Thanks to... Anders Trollås, my tutor from Cybercom Group, for your help, guidance and support during this thesis. Fredrik Håkansson, my tutor from Mid Sweden University, for your help, reviews and valuable advice for my report. iii

4 Table of Contents Table of Contents Abstract... ii Acknowledgements... iii Terminology...ix 1 Introduction Background and problem motivation Overall aim and verifiable goals Scope Outline Contributions Theory BPMN Activiti Designer Workflow Patterns Control-flow patterns Basic Control Flow Patterns Advanced Branching and Synchronization Patterns Multiple Instance Patterns State-based Patterns Cancellation and Force Completion Patterns Iteration Patterns Termination Patterns Trigger Patterns Activiti source code Activiti Explorer Spring Framework Vaadin Activiti Process Engine iv

5 Table of Contents 3 Methodology Literature studies Workflow patterns initiative Workflow patterns evaluation Implementing the patterns Product comparison Building the extended version of Activiti Explorer Implementation Control-flow patterns Pattern 1 Sequence Pattern 2 Parallel split Pattern 3 Synchronization Pattern 4 - Exclusive Choice Pattern 5 - Simple Merge Pattern 6 - Multi-Choice Pattern 7 - Structured Synchronizing Merge Pattern 8 - Multi-Merge Pattern 9 - Structured Discriminator Pattern 10 Arbitrary Cycles Pattern 11 - Implicit Termination Pattern 12 - Multiple Instances without Synchronization Pattern 13 - Multiple Instances with a priori Design- Time Knowledge Pattern 14 - Multiple Instances with a priori Run-Time Knowledge Pattern 15 - Multiple instances without a priori runtime knowledge Pattern 16 - Deferred Choice Pattern 17 - Interleaved Parallel Routing Pattern 18 Milestone Pattern 19 - Cancel Activity v

6 Table of Contents Pattern 20 - Cancel Case Pattern 21 - Structured Loop Pattern 22 - Recursion Pattern 23 - Transient Trigger Pattern 24 - Persistent Trigger Pattern 25 - Cancel Region Pattern 26 - Cancel Multiple Instance Activity Pattern 27 - Complete Multiple Instance Activity Pattern 28 - Blocking Discriminator Pattern 29 - Cancelling Discriminator Pattern 30 - Structured Partial Join Pattern 31 - Blocking Partial Join Pattern 32 - Cancelling Partial Join Pattern 33 - Generalized AND-Join Pattern 34 - Static Partial Join for Multiple Instances Pattern 35 - Cancelling Partial Join for Multiple Instances Pattern 36 - Dynamic Partial Join for Multiple Instances Pattern 37 - Acyclic Synchronizing Merge Pattern 38 - General Synchronizing Merge Pattern 39 - Critical Section Pattern 40 - Interleaved Routing Pattern 41 - Thread Merge Pattern 42 - Thread Split Pattern 43 - Explicit Termination Support for multiple companies Company Database and Admin web application CloudProcessEngines Login User Cache Activiti Company Deployment Manager vi

7 Table of Contents Deployment helper tools Support for a business payment model Support for custom layout in task forms XML specification Validating custom forms Extending Activiti to support the custom form layouts Helper tools Improvements and bug fixes High resolution screen support Boolean bug fix Date field Enum fields Textarea component Results Control-flow patterns evaluation Support for multiple companies Admin web application and payment model Activiti Company Deployment Manager Set up a new server with the extended version of Activiti Explorer Support for custom layout in task forms Improvements and bug fixes Large screen support Boolean bug fix Date field Enum fields Conclusions Control-flow evaluation Basic Control Flow Patterns Advanced Branching and Synchronization Patterns Multiple Instance Patterns vii

8 Table of Contents State-based Patterns Cancellation and Force Completion Patterns Iteration Patterns Termination Patterns Trigger Patterns Control-flow patterns Extended Activiti Explorer Support for multiple companies Support for custom layout in task forms Support for a business payment model Improvements and bug fixes Future work Workflow pattern evaluation Multiple companies Custom form layout References Appendix A: Process constricts in Activiti Designer Appendix B: Control-flow patterns definitions Appendix C: New Features Appendix D: Improvements and bug fixes Appendix E: XML implementation of the supported patterns viii

9 Terminology Terminology Acronyms BPM Business Process Management BPMN XML Business Process Model and Notation Extensible Markup Language ix

10 1 Introduction 1 Introduction The concept of workflow has its early roots in industrialization and was introduced in order to increase efficiency in production. In the beginning, processes were carried out entirely by humans but today processes are carried out partially or totally by computer information systems. According to Medina-Mora et al. [1] processes can be organized into material processes, information processes and business processes. Material processes consist of the assembly and delivery of physical products. Information processes are related to automated computer software that fully or partially perform tasks with interaction from humans. Business processes are a higher level concept and consist of information processes and/or material processes. Business processes describe the organization's activities from a market-centred perspective and are engineered to fulfil a business contract or to satisfy the requirements of a specific customer. This thesis deals exclusively with business processes implemented as information processes. [1] The term workflow is used casually to refer to a business process, the specification of a business process, the software that implements and automates a process or the software that supports the coordination and collaboration of people that implement a process. What workflow is and which features a workflow management system should support are not fully agreed upon, even the definition of the terms differs among software vendors. [2] Georgakopoulos et al. [2] defines the term workflow as a collection of tasks organized to accomplish some business process (e.g., processing purchase orders over the phone, provisioning telephone services, processing insurance claims). A task can be performed by one or more software systems, one or a team of humans, or a combination of these. Human tasks include interacting with computers closely (e.g., providing input commands) or loosely (e.g., using computers only to indicate task progress). In addition to a collection of tasks, a workflow defines the order of task invocation or condition(s) under which tasks must be invoked, task synchronization, and information flow (dataflow). [2] There are many different approaches to process specification with different syntax, semantics and terminology. This makes the choice of 1

11 1 Introduction workflow system more complex because all process specifications have their weaknesses and their strengths thus making it difficult to choose a process definition language that is suitable for a particular project. This thesis focuses on the Business Process Model and Notation language (BPMN) version 2.0. The Workflow Patterns initiative was started in 1999 by Eindhoven University of Technology and Queensland University of Technology. The goal of the initiative was to provide a comprehensive examination of the various perspectives supported by workflow systems and their process definition languages. This was conducted by categorizing common constructs used in real world processes. The purpose of the patterns is to provide an objective means of evaluating and comparing different workflow platforms and their definition languages. At the beginning they received little attention outside academia but, as of the present time, more and more vendors are evaluating their products and submitting the results to workflow patterns initiative. [3] This thesis deals with the control flow patterns as described by Wil van der Aalst et al. (2003, 2006) [4][5]. Workflow patterns are related to design patterns in architecture and computer science and were first introduced by Christopher Alexander (1977) [6] in the field of architecture and by the Gang of Four 1995 [7] in computer science. Christopher Alexander provides the following definition, Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice. [6] Business Process Management (BPM) extends the concept of workflow by focusing on all aspects of processes within an organization. It has methods to handle both process reengineering and process redesign and it supports the complete business process lifecycle (Design & Analysis -> Configuration -> Enactment -> Evaluation) see figure 1. [8] 2

12 1 Introduction Evaluation: Process Mining Business Activity Monitoring Evaluation Enactment: Operation Monitoring Maintenance Enactment Business process lifecycle Configuration Design & Analysis Design: Business Process Identification and Modeling Analysis: Validation Simulation Verification Configuration: System Selection Implementation Test and Deployment Figure 1: Business Process Lifecycle [8] The reengineering addresses the issues of system efficiency, system cost and it explores the use of new advancement in technology. Business process redesign improves the efficiency of business operations, the quality of products, reduces costs, meets new business challenges and increases customer satisfaction. A software BPM platform delivers greater control and visibility over processes and workflow integration with other applications. [8] Open-source software has grown both in popularity and maturity and is becoming a viable alternative to commercial enterprise business products. The advantages associated with choosing open-source software are that there is full control over the source code meaning that it is possible to learn how it works, to modify it, fix errors and continue its development even after the product has been discontinued. Another benefit is that there are no license fees and free community support is available. For many businesses this is not sufficient and therefore many products offer full professional support and extra features but this involves a fee. The disadvantages of choosing an open-source product are that it might not be sufficiently developed to the degree that it is able to be used in a demanding business environment. Enterprise open-source products are often more difficult to learn than their proprietary counterparts and 3

13 1 Introduction their intended user group are more focused towards software engineers than business analysts. 1.1 Background and problem motivation Activiti [9] is a new open-source light-weight workflow and Business Process Management platform. The development is led by Tom Baeyens and Joram Barrez and it is funded by the company Alfresco [21]. It had its first stable release on December 1 st 2010 and it has been in active development ever since. The first stable release was version 5.0 and this was because the lead developers had previously worked on jbpm (up to version 4.0) before they left Red Hat to work for Alfresco. Activiti is a relatively new product and it lacks proper independent evaluations and scientific reports. Petia Wohed et al 2007 [10] conducted a pattern-based evaluation of the open-source BPM systems, jbpm version [11], OpenWFE version [12] and Enhydra Shark version 2 [13]. The process definition languages used were jbpm Process Definition Language (jpdl) for jbpm, XPDL 1.0 for Enhydra shark and the OpenWFE process definition language for OpenWFE. They used the patterns from the workflow pattern initiative as the basis for their study. As of today this is the only evaluation of open-source BPM products available at the workflow patterns initiative website. Many other BPM platforms and process languages have been evaluated against the workflow patterns and the result can be found on their website [3], but since the focus of this thesis is on open-source platforms the results from other platforms will not be discussed. At the time of writing, both Activiti and its process definition language BPMN 2.0 have not yet been evaluated by the workflow pattern initiative. For this reason the IT consulting company Cybercom Group would like Activiti to be evaluated against both the control flow patterns and as an open-source product. The result from the pattern evaluation makes it easy to compare Activiti with other products. It is also easier to choose an appropriate product for a particular project by looking at its strengths and weaknesses with regards to its supported patterns. The result from the pattern evaluation of Activiti should therefore be compared to the result from the open-source BPM evaluation conducted by Petia Wohed et al 2007 [10] to determine which platform is more suitable with regards to the control flow patterns. 4

14 1 Introduction Activiti will also be evaluated as an open-source project by modifying and extending the source code to fit the requirements given by the Cybercom Group. 1.2 Overall aim and verifiable goals The overall aim of this thesis is to evaluate Activiti and detail its strengths and weaknesses. This result from the control flow evaluation should be used at a later stage to determine the suitability of using Activiti in a particular project and to compare it against the other opensource BPM platforms (jbpm, OpenWFE and Enhydra shark). The goal is also to offer a short theoretical overview of the control flow patterns and a brief theoretical overview of the frameworks used by the Activiti open-source project. In the practical part of this thesis an attempt to implement all the control flow patterns is made. The result should include: Table of the evaluation of Activiti against all Control flow patterns Comparison of Activti, jbpm, OpenWFE and Enhydra shark in regards to their support for the control flow patterns defined in [5]. The pattern support for jbpm, OpenWFE and Enhydra shark are taken from [10]. The Cybercom Group also requested the following extensions and modifications to Activiti Explorer, for creating an extended Activiti Explorer: Support for multiple companies within Activiti Explorer Support for customizing the layout of user task forms in Activiti Explorer. Support to change the main colours and logotypes in Activiti Explorer. Support for a business payment model (ex. pay per process instance). 5

15 1 Introduction All of the above points must be implemented without changing the source code of the Activiti engine. 1.3 Scope The theoretical and practical parts of the pattern evaluation will be restricted to the control flow patterns. When conducting the evaluation each pattern is implemented in Activiti Designer and graded with a '+' for direct support, '+/-' for partial support and '-' if the pattern is not supported [30]. Activiti is an open-source platform and the main interest in this study is in relation to the suitability of Activiti when choosing an open-source BPM platform. This, and the fact that the majority of commercial software is not provided with source code, is the reason why this study is limited to only open-source products. Since the extended Activiti Explorer platform is a commission from the Cybercom Group both the theoretical and practical parts will primarily focus on how to achieve the requested features. The evaluation, from an open-source perspective, consists of implementing two extensions and fixing some minor bugs. A brief theoretical presentation of the project and the major frameworks is also provided. Finally a list of all the required changes and the classes created to implement the extensions and fixes will be presented in Appendices C and D. 1.4 Outline Chapter 2 introduces the reader to BPMN 2.0 and Activiti Designer and to the control-flow patterns and then offers a short introduction to the foundation of the Activiti source code. Chapter 3 describes the methodology used in this thesis. Chapter 4 describes the implementation of the patterns and the modifications made to the source code. Chapter 5 presents the result of this thesis with tables for the patterns and screenshots of the added features. Chapter 6 presents the conclusion and discussion of this thesis. Chapter 7 presents the ideas for future work regarding the extensions to Activiti Explorer. 6

16 1 Introduction Appendix A: contains a list with description of the process constructs used in Activiti Designer when implementing the patterns. Appendix B: contains the definitions of all 43 control-flow patterns. Appendix C: contains a description of how the new features were added to Activiti Explorer. Appendix D: contains a description of how the improvements and bug fixes were added to Activiti Explorer. Appendix E: contains the XML implementation of the supported patterns. 1.5 Contributions The author has contributed to the Activiti evaluation of the controlflow patterns, the XML specification for the custom form layout, extensions made to the source-code of Activiti Explorer to support the requirements given by the Cybercom Group and the helper tools to facilitate the use of the extended version of Activiti Explorer. 7

17 2 Theory 2 Theory This chapter consists of a brief explanation of the BPMN 2.0 notation language, Activiti Designer and the workflow patterns. The last part consists of an overview of the Activiti source code and the frameworks used. 2.1 BPMN 2.0 BPMN stands for Business Process Model and Notation and version 2.0 specifies both a graphical notation language in addition to the XML notation language. It was developed by the Business Process Management Initiative and is now maintained by the Object Management Group since the merger in Business processes are modeled using connections, events, activities and gateways. Connections are used to connect activities, gateways and events together. Events are displayed as a circle and denote that something has occurred, for example start and end events. Events can also be throwing and catching events. Activities represent a piece of work that is required to be conducted. The work can be automatic or manual with human involvment. Gateways are a means of splitting up or merging the execution flow in a process. The constructs used when modeling the control-flow patterns are described in Appendix A. [20] 2.2 Activiti Designer The Activiti Designer is an Eclipse [22] plugin which allows the process developer to develop BPMN 2.0 processes using a graphical user interface with drag and drop components. Activiti Designer does not support the complete set of BPMN 2.0 components and features at the present time, but more support arrives with each new version. Activiti 5.9 has just been released with support for some new components which, at present, are labeled experimental and which are not included in Activiti Designer. Experimental components were not used when modelling the patterns. For a description of the components used in the implementation of the workflow patterns see Appendix A. 8

18 2 Theory 2.3 Workflow Patterns The Workflow Patterns initiative was started in 1999 by Professor Wil van der Aals and Professor Arthur ter Hofstede [3]. It was established to describe the fundamental structures in an imperative way [3]. These structures are reoccurring over and over again when modelling business processes. The research project first produced a set of twenty controlflow patterns for workflow systems [4]. Since then patterns have evolved and they now cover the following workflow perspectives, control-flow, data, resource, exception handling and presentation. These patterns have been used to evaluate existing workflow systems so as to determine their suitability for a particular project and for the development of workflow systems. [24] 2.4 Control-flow patterns In 2006 a new paper with a revised view on the control-flow patterns was released [5]. The new revised definitions were an effort to make the implementation and interpretation of the patterns less ambiguous by taking the strictest possible interpretations. In addition to the twenty revised patterns, twenty-three new control-flow patterns were also introduced. For the definitions of all 43 control-flow patterns see Appendix B. The forty-three control-flow patterns can be divided into eight classes which are described below. [25] Basic Control Flow Patterns In the class Basic Control Flow Patterns are those patterns dealing with the execution order of activities and the ability to run activities concurrently and patterns that deal with simple choice and merger. These patterns are the fundamental building blocks of a workflow system. The following patterns belong to the basic control flow patterns, for their definitions see Appendix B. [25] 1. Sequence 2. Parallel Split 3. Synchronization 4. Exclusive Choice 9

19 2 Theory 5. Simple Merge Advanced Branching and Synchronization Patterns In the class Advance Branching and Synchronization Patterns are patterns that deal with advance merging and synchronization constructs during which several branches come together. There is also a pattern that deals with the choice regarding which branches to activate. In the case of synchronization the subsequent activity should be called first when all the active branches have reached the construct, while in some patterns, only the first thread is passed to the subsequent activity while the others are blocked. There are also patterns that deal with the creation and synchronization of threads within a branch. The following is the complete set of patterns belonging to the advanced branching and synchronization patterns and for their definitions see Appendix B. [25] 6. Multi-Choice 7. Structured Synchronizing Merge 8. Multi-Merge 9. Structured Discriminator 28. Blocking Discriminator 29. Cancelling Discriminator 30. Structured Partial Join 31. Blocking Partial Join 32. Cancelling Partial Join 33. Generalised AND-Join 37. Local Synchronizing Merge 38. General Synchronizing Merge 41. Thread Merge 42. Thread Split 10

20 2 Theory Multiple Instance Patterns In the class Multiple Instance Patterns are those patterns dealing with multiple instances of the same activity. The patterns deal with the initiation, the synchronization for completed instances and in dynamically adding new instances. The following patterns belong to the multiple instance patterns, for their definitions see Appendix B. [25] 12. Multiple Instances without Synchronization 13. Multiple Instances with a Priori Design-Time Knowledge 14. Multiple Instances with a Priori Run-Time Knowledge 15. Multiple Instances without a Priori Run-Time Knowledge 34. Static Partial Join for Multiple Instances 35. Cancelling Partial Join for Multiple Instances 36. Dynamic Partial Join for Multiple Instances State-based Patterns In the class State-based Patterns are those patterns dealing with synchronization, choice and which branches are able to be activated based on the state of the process instance. The state of a process instance is referring to its execution status and the related process and working data, which includes the status of activities. The following patterns belong to the state-based patterns, for their definitions see Appendix B. [25] 16. Deferred Choice 17. Interleaved Parallel Routing 18. Milestone 39. Critical Section 40. Interleaved Routing 11

21 2 Theory Cancellation and Force Completion Patterns In the class Cancellation and Force Completion Patterns are those patterns dealing with the forced cancellation and completion of running activities and process instances. These patterns can easily be implemented using exception handling. The following patterns belong to the cancellation and forced completion patterns, for their definitions see Appendix B. [25] 19. Cancel Task 20. Cancel Case 25. Cancel Region 26. Cancel Multiple Instance Activity 27. Complete Multiple Instance Activity Iteration Patterns In the class Iteration Patterns are those patterns dealing with the repetitive behaviour of a process. The following patterns belong to the iteration patterns, for their definitions see Appendix B. [25] 10. Arbitrary Cycles 21. Structured Loop 22. Recursion Termination Patterns In the class Termination Patterns are the patterns that deal with the termination and completion of a process. The following patterns belong to the termination patterns, for their definitions see Appendix B. [25] 11. Implicit Termination 43. Explicit Termination Trigger Patterns In the class Trigger Patterns are those patterns dealing with the external signals that might be necessary to start certain activities. The following 12

22 2 Theory patterns belong to the trigger patterns, for their definitions see Appendix B. [25] 23. Transient Trigger 24. Persistent Trigger 2.5 Activiti source code The Activiti open-source project consists of many different modules. The modules that are found in the Activiti 5.9 subversion repository [26] are activiti-cactus, activiti-camel, activiti-cdi, activiti-cxf, activiti-engine, activiti-mule, activiti-osgi, activiti-spring, activiti-webapp-exploirer2 and activiti-webbapp-rest2. The code is written in Java and it is using the build manager Maven. The modules that are of interest in this study are primarily the activiti-engine, which is a BPMN 2.0 process engine and the activiti-webapp-explorer2, which is a web interface that uses the process engine. All the source code is licensed under the Apache License, Version 2.0 [14]. 2.6 Activiti Explorer Activiti Explorer [27] is a web application that is built with the Vaadin framework and it utilizes the Spring framework to start the process engine. It has an easy-to-use interface for starting processes and handling human tasks. On the task page, the tasks appear in the user s inbox or, if they are assigned to a group, under the queued menu. The process page allows the users to start new processes or to view the current execution state on an already started processes belonging to the user. The manage page is visible for users with administrator rights. The administrator can deploy new processes in this page, delete old ones, manage users and groups and investigate the content in the database tables. [27] Spring Framework The Spring framework assists in the building of enterprise Java applications by allowing the programmer to focus on the problem rather than on pluming code [15]. The module used by Activiti is the inversion of control container, which is responsible for managing objects lifecycles, and this is conducted by means of dependency injection. The main principle behind dependency injection is to load objects at runtime 13

23 2 Theory instead of at compile time, which is the usual way of loading objects. This is conducted by specifying all objects to be loaded in an XML file that is parsed by Spring and the objects are then instantiated and loaded into a container, accessible from the Java code. This makes it possible to add objects to the software without the necessity to recompile it. Apart from the late binding, it is also possible to assign values (this includes other objects loaded by Spring) to objects using either the constructor or setters directly in the XML file. This is of course a small sub set of the features provided by the Spring framework but deals with those used in Activiti Vaadin Vaadin [16] is a Java framework for rich internet applications. Vaadin is based on the Google Web Toolkit (GWT) [17], and it is a rapid application development framework to build secure rich internet applications. It allows the programmer to write an Internet application directly in Java and compiles it to both the client and server software. The client and server communicate via asynchronous Javascript (AJAX) and thus there is no requirement for any browser plugins. See figure 2 for the complete communication chain. Web Browser Client-Side Engine Java Web Server Vaadin UI Components Your Java Application Web Service EJB DB Vaadin UI Components Figure 2: Vaadin communication [28] All user interface components that are available in Vaadin are listed in the inheritance diagram in figure 3. 14

24 2 Theory Figure 3: UI Component Inheritance Diagram. [28] The Component class is the top most class in this hierarchy. The components used when creating input forms are all descendants of the Field class and they are all implementing the AbstractField interface. Fields are components that have a value that can be changed directly in the interface by the user. Fields use the Vaadin data model which means that the value is handled as a Property. A Property is an interface that uses get and set methods which take a value of type Object. This makes the interface compatible with all types of components and values since all objects inherit from the Object class in Java. For the inheritance diagram of the Field class see figure 4. [28] 15

25 2 Theory Figure 4: Field Interface Inheritance Diagram. [28] Activiti Process Engine The central point of the Process Engine API is the ProcessEngine class. To create an instance of the ProcessEngine the ProcessEngineConfiguration object can be used via the Spring framework [15], xml or directly in Java code. To handle multiple instances of the ProcessEngine the ProcessEngines class can be used and it contains methods for safely creating and closing all running engines. Once an engine is up and running its services containing the workflow/bpm methods can be obtained by calling the corresponding getters on the engine object, see figure 5 for all available services. [29] ProcessEngine RepositoryService ManagmentService TaskService HistoryService IdentityService FormService RuntimeService Figure 5: Activiti Engine and its services [29] Repository Service The RepositoryService provides access to the repository of process definitions and other deployments. It is used for deploying to the database and retrieving deployed items. [29] 16

26 2 Theory Management Service The ManagementService is used for maintenance and administration operations on the process engine. [29] Task Service The TaskService provides access to tasks and form operations. [29] History Service The HistoryService provides access to information about ongoing and past process instances. [29] Identity Service The IdentityService provides information on users and groups. [29] Form Service The FormService provides access to form data. [29] Runtime Service The RuntimeService provides access to process instances, definitions and deployments. [29] 17

27 3 Methodology 3 Methodology The methodology used in this thesis consists, in the first instance, a theoretical study on BPM, workflow patterns, Activiti and Vaadin. The second part is a practical implementation of the patterns and the extension of the functionality of Activiti Explorer. 3.1 Literature studies The online library at Mid Sweden University was used to search for articles and publications regarding BPM and workflow patterns. The workflow patterns initiative website [3] also contained many sources. The following documents were found [1][2][4][5][8][10] via the online library or at the workflow patterns initiative website. To learn about Activiti and Vaadin the main websites [9][16] were used as the primary sources and, in addition, the following books were used [18][19]. 3.2 Workflow patterns initiative The workflow patterns initiative website [3] together with the papers [4][5] were the main source of information regarding the patterns. The sources were used when studying the theory behind the patterns and for the implementation and to evaluate the result. 3.3 Workflow patterns evaluation When evaluating Activiti against the patterns, Activiti Designer was chosen as the process development tool. Because it is an official tool and offers an easy graphical environment with drag and drop components. There are other BPMN 2.0 modelling tools, for example, Activiti Modeller, which is a web based modeller but these do not offer support for Activiti specific extensions to the BPMN 2.0 language. For the evaluation of the patterns, the requirement is that a graphical development tool is to be used and that the patterns are able to be implemented through its use. [30] Implementing the patterns The description of the pattern was read first and from this the motivation was provided as were the, context and implementation. Once the pattern had been fully understood an attempt was made to implement it 18

28 3 Methodology in Activiti Designer. If the functionality of the pattern was achieved then the evaluation criteria and product evaluation was read. Finally, the finished implementation was graded according to the product evaluation criteria. If the functionality was not achieved then further reading with regards to Activiti and BPMN 2.0 was conducted. Once all the attempts have failed then the pattern is considered to be not supported. [30] When grading the support for the patterns a + sign is given to the patterns that are directly supported, meaning that one of the language constructs satisfies the evaluation criteria of the pattern. For partial support +/- is given, meaning that there is some limitation when implementing the pattern. The sign is given to patterns that are not supported. A pattern is considered to be not supported if any form of programming or scripting is required or the solution results in a spaghetti diagram. [30] 3.4 Product comparison The Activiti open-source BPM platform was compared to the other BPM platforms by looking at the support for the different control-flow patterns. The patterns support for the different platforms is discussed for each control-flow patterns class. The pattern support for jbpm, Open- WFE, and Enhydra Shark comes from this study [10] and the result is also available at the workflow patterns initiative website [30]. 3.5 Building the extended version of Activiti Explorer The extended platform was created by extending the Activiti Explorer to support several companies per installation and the customization of user input forms. Since Activiti is an open-source project, the source code for Activiti Explorer was downloaded with Apache Subversion and modifications were made directly in the code. The development tool used was Eclipse with the Maven plugin installed. The code was firstly examined in order to discover a means of implementing the different features. Once a sound strategy had been determined that did not involve many changes, the implementation commenced. Following this, a great deal of testing was conducted to ensure that the implementation worked as intended. During the course of the project some bugs and smaller imperfections were discovered and changed to a more desirable 19

29 3 Methodology solution. At the conclusion of the project, version 5.9 of Activiti was released. All the changes had been made to version 5.8 and these were re-examined and brought over to version 5.9 one at a time and all the changes documented (see Appendix C and D for details). 20

30 4 Implementation 4 Implementation The first part of this chapter shows the implementation of all controlflow patterns with a description and a diagram for the supported patterns. In the second part the implementation of the extended version of Activiti Explorer is explained. 4.1 Control-flow patterns All patterns are modelled using the Activiti Designer which is an eclipse plugin. A brief description is provided for all the patterns and a graphical diagram is additionally shown for the supported patterns. The graphical diagrams are saved as a png file in Activiti Designer and they depict the graphical representation of the process being modelled. When modelling the patterns, all tasks are represented by a user task that is assigned to the initiator. This simplifies the testing easier as the same user both initiates the process and receives all the user tasks. For each of the supported patterns there is also a detailed XML in Appendix E Pattern 1 Sequence The pattern is directly supported by using a Sequence Flow construct between activities. For its graphical representation see figure 6. Figure 6: Pattern 1 - Sequence Pattern 2 Parallel split The pattern is directly supported by using a Parallel Gateway construct. For its graphical representation see figure 7. 21

31 4 Implementation Figure 7: Pattern 2 - Parallel split Pattern 3 Synchronization The pattern is directly supported by using a Parallel Gateway construct. For its graphical representation see figure 8. Figure 8: Pattern 3 - Syncronization Pattern 4 - Exclusive Choice The pattern is directly supported by using an Exclusive Gateway construct. For its graphical representation see figure 9. 22

32 4 Implementation Figure 9: Pattern 4 - Exclusive choice Pattern 5 - Simple Merge The pattern is directly supported by using an Exclusive Gateway construct. For its graphical representation see figure 10. Figure 10: Pattern 5 - Simple merge Pattern 6 - Multi-Choice The pattern is directly supported by using an Inclusive Gateway construct with conditions on the outgoing Sequence Flows. For its graphical representation see figure

33 4 Implementation Figure 11: Pattern 6 - Multi-choice Pattern 7 - Structured Synchronizing Merge The pattern is directly supported by using an Inclusive Gateway construct. For its graphical representation see figure 12. Figure 12: Pattern 7 - Structured synchronizing merge Pattern 8 - Multi-Merge The pattern is directly supported by using an Exclusive Gateway construct. For its graphical representation see figure

34 4 Implementation Figure 13: Pattern 8 - Multi-merge Pattern 9 - Structured Discriminator The pattern is not supported. Support for this pattern is referred to in the BPMN specification but Activiti Designer does not support the complex gateway construct. Pattern 10 Arbitrary Cycles The pattern is directly supported by using the Exclusive Gateway construct with Sequence Flows to construct the loops. For its graphical representation see figure 14. Figure 14: Pattern 10 - Arbitrary cycles Pattern 11 - Implicit Termination The pattern is directly supported by the BPMN process language and when all paths have reached an end event the process is terminated. For its graphical representation see figure

35 4 Implementation Figure 15: Pattern 11 - Implicit Termination Pattern 12 - Multiple Instances without Synchronization The pattern is partially supported. By default, the multi instance task will synchronize and the subsequent flow will only be called once all instances are completed. In order to circumvent this a Parallel Gateway is used to split the thread of control before calling the multiinstance. To specify the number of instances to be started, the Loop cardinality is set to the variable containing the number of instances. For its graphical representation see figure 16. Figure 16: Pattern 12 - Multiple instances without synchronization Pattern 13 - Multiple Instances with a priori Design-Time Knowledge The pattern is directly supported. The Loop cardinality for the multiinstance is set at the design time to the number of activity instances in this case 3. For its graphical representation see figure

36 4 Implementation Figure 17: Pattern 13 - Multiple instances with a priori design-time knowledge Pattern 14 - Multiple Instances with a priori Run-Time Knowledge The pattern is directly supported. The Loop cardinality for the multiinstance is set at the design time to a process variable. For its graphical representation see figure 18. Figure 18: Pattern 14 - Multiple instances with a priori run-time knowledge Pattern 15 - Multiple instances without a priori run-time knowledge The pattern is not supported. The number of instances cannot be changed after the multi-instance task has started. Pattern 16 - Deferred Choice The pattern is partially supported. It can be modelled using a sub process with error events to cancel the remaining listeners after a choice has been made. Experimental support exists for the event based gateway construct and signals which should offer full support for this pattern (Support for this patterns is therefore expected in future releases). For its graphical representation see figure

37 4 Implementation Figure 19: Pattern 16 - Deferred choice Pattern 17 - Interleaved Parallel Routing The pattern is not supported. There is no construct that offers serial execution of parallel activities. Pattern 18 Milestone The pattern is not supported. Activiti has no support for states. Pattern 19 - Cancel Activity The pattern is directly supported by using an error boundary event attached to the activity being cancelled and issue an error message to cancel the activity. For its graphical representation see figure

38 4 Implementation Figure 20: Pattern 19 - Cancel activity Pattern 20 - Cancel Case The pattern is directly supported, by encapsulating the process in a subprocess and using error events. For its graphical representation see figure 21. Figure 21: Pattern 20 - Cancel case Pattern 21 - Structured Loop The pattern is directly supported. Both post- and pre-test loops can be constructed using exclusive gateways and a process variable. For the post-test loop see figure 22 and for the pre-test see figure

39 4 Implementation Figure 22: Pattern 21 - Structured loop (post-test) Figure 23: Pattern 21 - Structured loop (pre-test) Pattern 22 - Recursion The pattern is not supported. There is no means of specifying recursion in the Activiti Designer. Pattern 23 - Transient Trigger The pattern is not supported.there is no means of specifying triggers in Activiti Designer. Pattern 24 - Persistent Trigger The pattern is not supported. There is no means of specifying triggers in Activiti Designer. Pattern 25 - Cancel Region The pattern is partially supported, by encapsulating the region in a subprocess and using error events to cancel the region. For its graphical representation see figure

40 4 Implementation Figure 24: Pattern 25 - Cancel Region Pattern 26 - Cancel Multiple Instance Activity The pattern is directly supported by using an error boundary event to cancel all remaining instances. For its graphical representation see figure 25. Figure 25: Pattern 26 - Cancel Multiple Instance Activity Pattern 27 - Complete Multiple Instance Activity The pattern is directly supported, by using a boundary event or setting the completion condition of the multi-instance. For the graphical representation when using a boundary event see figure 26 and figure 27 for an example using the completion condition. 31

41 4 Implementation Figure 26: Pattern 27 - Complete Multiple Instance Activity (Boundary event) Figure 27: Pattern 27 - Complete Multiple Instance Activity (completion condition) Pattern 28 - Blocking Discriminator The pattern is not supported. Activiti Designer does not support the complex gateway construct. Pattern 29 - Cancelling Discriminator The pattern is directly supported, using a sub-process and an error event to cancel the remaining activities. For its graphical representation see figure 28. Figure 28: Pattern 29 - Cancelling Discriminator Pattern 30 - Structured Partial Join The pattern is not supported. Activiti Designer does not support the complex gateway construct. Pattern 31 - Blocking Partial Join The pattern is not supported. Activiti Designer does not support the complex gateway construct. 32

42 4 Implementation Pattern 32 - Cancelling Partial Join The pattern is not supported. Activiti Designer does not support the complex gateway construct. Pattern 33 - Generalized AND-Join The pattern is not supported. The parallel gateway executes the subsequent activity when it has received the same number of input signals as the number of input branches, even if all signals come from the same branches. Pattern 34 - Static Partial Join for Multiple Instances The pattern is not supported. There is no means of triggering the subsequent task without cancelling the other instances. Signals, which at present are labelled experimental, might be used to accomplish this. Pattern 35 - Cancelling Partial Join for Multiple Instances The pattern is supported, and can be modelled by using an error boundary event or by setting the completion condition to M=N. For its graphical representation see figure 29. Figure 29: Pattern 35 - Cancelling partial join for multiple instances Pattern 36 - Dynamic Partial Join for Multiple Instances The pattern is not supported. The number of instances cannot be changed after the multi-instance task has started. Pattern 37 - Acyclic Synchronizing Merge The pattern is not supported. The Inclusive Gateway has to be used in a structured context. Pattern 38 - General Synchronizing Merge The pattern is not supported. The Inclusive Gateway has to be used in a structured context. Pattern 39 - Critical Section The pattern is not supported. Activiti Desiger offers no support for limiting concurrent execution of activities. 33

43 4 Implementation Pattern 40 - Interleaved Routing The pattern is not supported. Ad-hoc processes are not supported in Activiti Designer. Pattern 41 - Thread Merge The pattern is not supported. startquantity attribute of activities is not supported in Activiti Designer. Pattern 42 - Thread Split The pattern is not supported. completionquantity attribute of activities is not supported in Activiti Designer. Pattern 43 - Explicit Termination The pattern is not supported. The Terminate End Event construct is missing in Activiti Designer. 4.2 Support for multiple companies To support multiple companies without changing the code for the engine, the ProcessEngines class was used to register one engine per company. For a complete list of changes required to implement the multi-company support see Appendix C Company Database and Admin web application When Activiti Explorer is initialized it loads a configuration file via Spring to start the engine. Since one engine will be used per company, it is necessary to start several engines and to add engines without restarting the application. Because of this, the configuration file was changed to contain the configuration for a JDBC connection to a MySQL database that stores the configuration parameters for the engines. See figure 30 for the database table. When the application starts it loads the JDBC connection via Spring and investigates all the records and sets up one engine per company and starts it. 34

44 4 Implementation Company PK CompanyName DriverClassName URL UserName Password MailServerHost MailServerUserName MailServerPassword MailServerPort MailServerDefaultFrom MailServerUseTLS Figure 30: Company database table To handle the administration of companies, a Vaadin web application was created that can be accessed by adding /admin to the URL. The Admin web application can be used to start and stop the engines for companies that are already in the database. The login information for the admin web application is stored in the Admin database table (see figure 31) and the password is stored using a SHA-1 cryptographic hash function. Admin PK UserName Password Figure 31: Admin database table CloudProcessEngines The CloudProcessEngines class was created to ease the handling of multiple companies. The class communicates directly with the engines, and all communications between a logged in user in Activiti Explorer and the engine pass through this object. All classes that have previously communicated with the engine were changed to communicate via the CloudProcessEngines with the exception of the classes handling the login of the user (see next section). When the process engines are registered they are associated with a name, which in this case is the same as the company name. When getprocessengine() method is called on the CloudProcessEngines object, it firstly reads the company name associat- 35

45 4 Implementation ed with the logged in user and then calls the ProcessEngines class in order to retrieve the engine registered with that company name and then returns it. The Admin web application also communicates with this class Login A new implementation of the logged in user interface was created with the addition of a field containing the company name. This class is attached to the application object and is therefore globally available. The login screen was also extended to include an input field for the company name. When the user attempts to log in, an engine is loaded associated with the given company and, if it exists, the user s credentials (name and password) are sent to the engine for verification. If no engine is associated with the company name, then the login fails. After the login has succeeded and providing that the credentials were correct, the user object (with company name) is attached to the application object and the user is logged in. User Cache The user cache is used to cache users for the purpose of speeding up user lookup operations. Only one user cache does not work with multiple companies since they have different users, and because of this and the time constraints on this project, the user cache implemented simply retrieves users from the database instead of actually caching them. Activiti Company Deployment Manager This application makes it easier to create and modify company information that is used when deploying a new company. It is a Java application with a graphical user interface (GUI) that is using the Swing framework. The file format, when saving and loading the company deployment file, is a zip file with the structure shown in figure 32. The theme/img directory contains all the images for the theme, the users/pictures directory contains all the pictures of the users and the processes directory contains all processes to be deployed. 36

46 4 Implementation / theme img styles.xml users pictures users.xml processes Figure 32: File structure of the company deployment zip file To create a theme, one color is picked and the logos are loaded from a file or generated based on the first logo. After the color and logos have been selected the application will generate images for buttons and the menubar together with a css file to be used as a Vaadin theme. The algorithm used for the real-time preview of the menubar uses the hardware accelerated graphics and lower settings to make it faster on older machines. The algorithm used when generating the actual images uses the Java 2d graphics API with the best quality settings together with antialiasing. The theme can be exported as a Vaadin theme or saved in a zip file, making it usable for both the modified version in addition to the original version of Activiti Explorer. Users can be easily added, deleted and edited directly in the application. The users are saved in an XML file, with pictures in a separate directory, for an example, see below. In the edit user dialog, groups can be added or removed. The dropdown menu of available users is loaded from the groups.xml file, which is located in the application directory. This file can be edited in a text editor to add more groups, see below for the xml structure. The processes are merely a list of loaded process files that will be saved in the zip file. 37

47 4 Implementation <?xml version="1.0" encoding="utf-8"?> <users> <user> <userid>kermit</userid> <firstname>kermit</firstname> <lastname>the Frog</lastname> <password>kermit</password> <picture>kermit.jpg</picture> <groups> <group id="admin" type="security-role">admin</group> <group id="management" type="assignment">management</group> <group id="sales" type="assignment">sales</group> <group id="marketing" type="assignment">marketing</group> <group id="engineering" type="assignment">engineering</group> </groups> </user> </users> User xml file format <?xml version="1.0" encoding="utf-8"?> <groups> <group id="admin" type="security-role">admin</group> <group id="management" type="assignment">management</group> <group id="sales" type="assignment">sales</group> <group id="marketing" type="assignment">marketing</group> <group id="engineering" type="assignment">engineering</group> </groups> Groups xml file format Deployment helper tools To make it easier to set up the initial database and to write the configuration file used by Activiti Explorer when it is started, a command line Java application was created. The application takes the path to the Activiti Explorer, database info and credentials (to create the schemas and tables). It creates the activiti_cloud schema and a MySQL user with the same name and sets the privileges for this user to only use Select operations on the activiti_cloud schema. The password for the user is auto generated with a simple random algorithm. Finally, the configuration file with the credentials is created in the Activiti Explorer directory path. To make it easier to set up a new company a command line Java application was created. The application takes a zip file containing the theme to be used together with all users and processes (see Activiti Company Deployment Manager). It also takes the path to the theme directory and the database credentials. It firstly copies the theme to the Activiti Explorer theme directory and then launches an offline process engine. 38

48 4 Implementation Then a schema and a user are created (they both have the company name). Following this, the process engine sets up the database and builds all the tables. All users are then added to the database via the engine and finally the processes are deployed. When everything is completed the process engine is shut down and the configuration and the database credentials are written to the Company table (for uml diagram see figure 30). 4.3 Support for a business payment model The invoice can be reached from the admin web application (for an image see result chapter). For each company there is a date field and a button. By choosing a month and pressing the invoice data button an invoice for the selected month is downloaded for that company. The invoice is created by accessing the process engine for the selected company and accessing its HistoryService. In order for this to work, the engine must be started and running. The invoice created is in a XML format for easy integration with the desired billing software, since it is a well-known standard in data serialization. 4.4 Support for custom layout in task forms By default, all form components are as shown in figure 33. There is no means of changing this layout, thus, in order to provide the process developer with the ability to change it, Activiti Explorer was extended. In order to support different types of layouts, an XML specification (for the tags see below) for describing the layout was developed. When developing processes, each user task has an associated formkey property, the name of this property should be the same as the filename of the desired layout file for that form. If this field is left empty the default layout is choosen, which is one field per row. When deploying processes which are using custom layouts, the process definition file, together with all layout files, must be zipped and deployed as a zip file, this is because no changes are required in the code responsible for the deployment. 39

49 4 Implementation Figure 33: Standard form layout in Activiti Explorer XML specification The following shows, all the tags available in the XML specification created for the purpose of offering the process developer the ability to customize form layouts: Form, block, row, column, field, divider, a, img, br, space. form The form is the outer most tag and it contains the entire layout. field 40

50 4 Implementation The field is the graphical component that is displayed together with its label. The field takes an id attribute, which should be the same as the id of the field in the corresponding task form in the process definition. The description attribute is a text attribute that is used as a tool tip text, which is displayed when the user is hovering over the input field with the mouse pointer. If the id of a field is not found in the process definition file then the field is not displayed. The field tag cannot contain any other tags. block The block layout can contain any of the following tags: row, column, field, divider, a, img and br. It has a type attribute which can be one of the following two values divider and panel. The divider has a line on top and the panel has four borders that can be styled by specifing a style name in the style attribute (the name should corespond to a style in the Vaadin theme). The caption of the block is the title that is written at the top of the block. A block is only displayed if at least one of its interior fields is also displayed. row The row tag displays all its conponents on a single line. It can contain the following tags: field, a, img and space. The expand attribute can be either true or false, with the true meaning being that all the components are distributed with equal width over the entire row and the false meaning being that the components are laid out one after the other with their default width. column The column tag lays out the components one per row with the difference is that the label is on the left side of the component instead of being on top, which is the default. The column can contain the folowing tags: field, divider, a, img and br. divider 41

51 4 Implementation The divider tag draws a line on the screen and the content of the element. It cannot contain any other tags. a The a tag represents a url link. It can contain an img tag. Its attributes are href, used to refer to a static link and var, to a process variable that contains the link. If an image is not used the element is displayed. img The img tag represents an image that is displayed. The image can be part of a link but cannot contain any tags. The src attribute is the URL in which the image can be reached. The alt attribute is the text that is displayed when the image cannot be located. The height and width attributes are used to change the default size of the image. All of these attributes are written directly to the HTML page that is viewed by the user. br The br tag is used to write a linebrake by writing the br tag to the generated HTML page. The br tag cannot contain any tags, attribues or elements. space The space tag is used to insert a space between components in the row tag when its expand attribute is set to false. It cannot contain any tags, attributes or elements Validating custom forms When developing custom forms a dtd file can be used to validate its syntax. The dtd can be found in Appendix C. Extending Activiti to support the custom form layouts The following classes were changed to add support for custom form layouts: FormPropertiesComponent, FormPropertiesForm, ProcessDefinitionDetailPanel and TaskDetailPanel. Their functions are to take data from the process engine and render the form and to send the data from 42

52 4 Implementation the components to the process engine. For a more detailed description regarding the changes see Appendix C. The FormTemplateParser class was created and it is instantiated with the process instance id and the formkey. It loads the custom form layout xml by looking for the file with the same name as the formkey in the deployment of the process instance, by accessing the RepositoryService of the process engine. Once the xml is loaded it is parsed. The getformlayout method is then called and it takes a map with all components (Vaadin Field objects) and properties, and returns a VerticalLayout with all components ready to be displayed. When the user is finished, the map with all the components is used to go through them for validation and if an error occurs then this is displayed and the user is unable to proceed before it is fixed. After the validation has finished successfully the component values are sent to the engine Helper tools To speed up the development of the custom form files, a command-line application written in Java was created. This application takes the path to the process definition file as the command-line input and writes one custom layout file per start event / user task that has a value written in the formkey property. This auto generated custom form file will have the same filename as the value in the formkey and contain all fields. The default files is an acceptable starting point when developing the custom form layouts as the developer only has to add rows, columns, blocks and so on. 4.5 Improvements and bug fixes Here are some of the improvements and bug fixes made to Activiti Explorer. A more detailed description is available in Appendix D High resolution screen support The reason why the Activiti Explorer web application is not able to achieve a webpage beyond the width of 1920 pixels (see figure 34) is that it is specified in the css file. By removing this line the webpage will fill up all the space on the higher resolution screens. For a detailed description regarding how this can be performed see Appendix D. 43

53 4 Implementation Figure 34: The Activiti web page not extending beyond 1920 pixels Boolean bug fix The reason why the Boolean datatype does not work (see figure 35) when it is referenced to display the value of a process variable is because of a data conversion error. The checkbox component in Vaadin is using the interface Property, which has a member function setvalue that takes a value of type Object (the object which all objects inherit from). In the particular case of the checkbox it takes the type Object to conform to the standard interfaces used by all components in Vaadin but it expects that it can be cast to a Boolean. The Activiti process engine stores process variables as strings, which cannot be cast to a Boolean and in order to to fix this a conversion from string to Boolean is necessary. 44

54 4 Implementation Figure 35: Error message when trying to display a form using a Boolean field that is showing the value of a process variable Date field The standard date field is, by default, shown with controls with a resolution of milliseconds, even if the date format written in the process definition file is at a lower resolution. In figure 36 a date field with millisecond resolution and input field with a minute resolution is shown. 45

55 4 Implementation Figure 36: Date field for selecting date and time with higher resolution than required Enum fields The enum fields have, by default, an empty option null even when it is a required field, making this choice invalid (see figure 37). That is why the null was removed when the field is required, even after it has been removed the field is empty before a choice is made. Figure 37: Enum dialog for a required field Textarea component To add a custom component such as the textarea component (figure 38) it is necessary to create two classes. The first class implements Abstract- FormType and it is used to register the type with the engine. The second class implements AbstractFormPropertyRenderer and it is used to convert between the Field and FormProperty. Both of these files are loaded with Spring when Activiti Explorer starts, thus it is possible to extend without the necessity of changing the source code. For a description of changes and source code for the implemented classes see Appendix D. Figure 38: Textarea component 46

56 5 Results 5 Results This chapter is divided in two parts, the result from the control-flow pattern evaluations and then a presentation of the extended version of Activiti Explorer. 5.1 Control-flow patterns evaluation The result from the control-flow patterns implementation can be seen in table 1 together with the result from this paper [10]. Table 1: Control-flow pattern eveluation Pattern Basic Control Flow Patterns Pattern 1 (Sequence) Pattern 2 (Parallel Split) Pattern 3 (Synchronization) Pattern 4 (Exclusive Choice) Pattern 5 (Simple Merge) Advanced Branching and Synchronization Patterns Pattern 6 (Multi-Choice) + - +/- + Pattern 7 (Structured Synchronizing Merge) Pattern 8 (Multi-Merge) Pattern 9 (Structured Discriminator) Pattern 28 (Blocking Discriminator) Pattern 29 (Cancelling Discriminator) Pattern 30 (Structured Partial Join) Pattern 31 (Blocking Partial Join) Pattern 32 (Cancelling Partial Join) Pattern 33 (Generalized AND-Join) Pattern 37 (Local Synchronizing Merge) - - +/- - Pattern 38 (General Synchronizing Merge) Pattern 41 (Thread Merge) - +/- - - Pattern 42 (Thread Split) - +/- - - Activiti JBPM OpenWFE Enhydra Shark 47

57 5 Results Pattern Multiple Instance Patterns Pattern 12 (Multiple Instances without Synchronization) +/ Pattern 13 (Multiple Instances with a priori Design-Time Knowledge) Pattern 14 (Multiple Instances with a priori Run-Time Knowledge) Pattern 15 (Multiple Instances without a priori Run-Time Knowledge) Pattern 34 (Static Partial Join for Multiple Instances) Pattern 35 (Cancelling Partial Join for Multiple Instances) Pattern 36 (Dynamic Partial Join for Multiple Instances) State-based Patterns Pattern 16 (Deferred Choice) +/ Pattern 17 (Interleaved Parallel Routing) - - +/- - Pattern 18 (Milestone) Pattern 39 (Critical Section) Pattern 40 (Interleaved Routing) Cancellation and Force Completion Patterns Pattern 19 (Cancel Task) Pattern 20 (Cancel Case) + - +/- - Pattern 25 (Cancel Region) +/ Pattern 26 (Cancel Multiple Instance Task) Pattern 27 (Complete Multiple Instance Task) Iteration Patterns Pattern 10 (Arbitrary Cycles) Pattern 21 (Structured Loop) Pattern 22 (Recursion) Termination Patterns Pattern 11 (Implicit Termination) Pattern 43 (Explicit Termination) Trigger Patterns Pattern 23 (Transient Trigger) Pattern 24 (Persistent Trigger) Activiti JBPM OpenWFE Enhydra Shark In table 2, 3 and 4 are the number of directly, partially and not supported patterns per class for each platform. In table 5 the sum of all supported, partially supported and not supported patterns for each platform are shown. 48

58 5 Results Table 2: Number of directly supported patterns per class. Directly supported pattern classes Basic Control Flow Patterns (5) Advanced Branching and Synchronization Patterns (14) Multiple Instance Patterns (7) State-based Patterns (5) Cancellation and Force Completion Patterns (5) Iteration Patterns (3) Termination Patterns (2) Trigger Patterns (2) Activiti JBPM OpenWFE Enhydra Shark Table 3: Number of partially supported patterns per class. Partially supported pattern classes Basic Control Flow Patterns (5) Advanced Branching and Synchronization Patterns (14) Multiple Instance Patterns (7) State-based Patterns (5) Cancellation and Force Completion Patterns (5) Iteration Patterns (3) Termination Patterns (2) Trigger Patterns (2) Activiti JBPM OpenWFE Enhydra Shark 49

59 5 Results Table 4: Number of not supported patterns per class. Not supported pattern classes Basic Control Flow Patterns (5) Advanced Branching and Synchronization Patterns (14) Multiple Instance Patterns (7) State-based Patterns (5) Cancellation and Force Completion Patterns (5) Iteration Patterns (3) Termination Patterns (2) Trigger Patterns (2) Activiti JBPM OpenWFE Enhydra Shark Table 5: All control-flow patterns. All control-flow patterns Directly supported Partially supported Not supported Activiti JBPM OpenWFE Enhydra Shark 5.2 Support for multiple companies The extended login screen can be seen in figure 39 and the admin web application in figure 40 and

60 5 Results Figure 39: Activiti Explorer login screen with the extended support for multiple companies Admin web application and payment model The admin web application requires a different set of login credentials (which are stored in the admin database table). After a successful login the user has the ability to start and stop company engines for all companies that have their configuration stored in the company database table. If the process engine of a company is stopped, then no proceses will run and users belonging to that company cannot log in. Another feature is the ability to download an invoice for a given company and month, below is en example of such an invoice. <?xml version="1.0" encoding="utf-8"?> <invoice customerid="cybercom" period="201205"> <current_no_uses>4</current_no_uses> <usage> <process id="employeedevelopment:2:318" started="1" usertasks_started="9" /> <process id="employeedevelopment:1:8" started="1" usertasks_started="5" /> <process id="workrelatedinjury:1:16" started="1" usertasks_started="3" /> <process id="neworder:1:105" started="1" usertasks_started="2" /> </usage> </invoice> The process id tag in the invoice is composed of <process definition key>:<process definition version>:<generated id>. The generated id is a unique number to guarantee uniqueness in a cluster environment. Started is the number of times that the process has started and usertasks_started is the total number of user tasks started by the process (this number may vary for each run since there can be more than one path in a process). 51

61 5 Results Figure 40: Admin web application login Figure 41: Admin web application with one company Activiti Company Deployment Manager The company deployment manager is used to create the company deployment file. This file contains the theme, users and processes for the company. In figure 42 is the application with the default theme used by Activiti. 52

62 5 Results Figure 42: Company deployment manager with default theme In figure 43 the company deployment manager with a custom theme is displayed. The buttons next to the logos are open file, reload original logo and the button with the gears is to auto generate a logo based on the top most logo which has been used in figure 43. Figure 46 shows this theme in use. 53

63 5 Results Figure 43: Manager with custom theme The company deployment manager is shown in figure 44 with the user s tab selected and the user Kermit open for editing. In the user tab, users can be added, removed and edited from the user menu or by right clicking on a user in the table view. It is also possible to export and import users from an xml file. 54

64 5 Results Figure 44: Editing a user in the company manager application The company deployment manager is shown in figure 45 with the processes tab selected. Here, the user is able to add and remove processes. 55

65 5 Results Figure 45: Processes tab in the company manager application Set up a new server with the extended version of Activiti Explorer. 1. Install Java, Tomcat and MySQL if they are not installed. 2. Deploy the war file in tomcat (wite down the path to the directory). 3. Run setup command-line Java application with the directory (from 2) and credentials to the database as parameters. To run this step requires credentials that can write on the path and create a schema and user in the database. Enter a username and password for the admin web application. 4. Restart the webapplication (required to obtain the database credentials). 5. Make a company deployment file (using the Activiti company deployment manager or manualy). 6. Run the company deployment command-line Java program with database credentials and the path to the deployment file. This step 56

66 5 Results requires credentials that allow a write access to the company table and the creation of a new schema and user. 7. Log in to the admin web application and start company process engine. To add more companies repeat steps 5, 6 and Support for custom layout in task forms The custom form layout works by deploying the process definition together with layout xml files for each user input form that has a name written in its formkey attribute. Below is an example of a task form declaration from a process definition file followed by a form layout that was auto generated using the helper tool and the final version which uses many of the tags for demonstration purposes. <usertask id="enterorder" name="enter Order (${uuid)" activiti:assignee="${initiator" activiti:formkey="custom_form_layout.xml"> <extensionelements> <activiti:formproperty id="user" name="user" type="user" required="false" readable="true" writable="true"></activiti:formproperty> <activiti:formproperty id="companyname" name="company Name" type="string" required="true" readable="true" writable="true"></activiti:formproperty> <activiti:formproperty id="companyaddress" name="company Address" type="string" required="true" readable="true" writable="true"></activiti:formproperty> <activiti:formproperty id="description" name="description" type="textarea" required="true" readable="true" writable="true"></activiti:formproperty> <activiti:formproperty id="firstname" name="first Name" type="string" required="true" readable="true" writable="true"></activiti:formproperty> <activiti:formproperty id="middlename" name="middle Name" type="string" required="false" readable="true" writable="true"></activiti:formproperty> <activiti:formproperty id="lastname" name="last Name" type="string" required="true" readable="true" writable="true"></activiti:formproperty> <activiti:formproperty id="address" name="address" type="string" required="true" readable="true" writable="true"></activiti:formproperty> <activiti:formproperty id="zipcode" name="zip Code" type="string" required="true" readable="true" writable="true"></activiti:formproperty> <activiti:formproperty id="city" name="city" type="string" required="true" readable="true" writable="true"></activiti:formproperty> <activiti:formproperty id=" " name=" " type="string" required="true" readable="true" writable="true"></activiti:formproperty> <activiti:formproperty id="phone" name="phone" type="string" required="true" readable="true" writable="true"></activiti:formproperty> <activiti:formproperty id="articleid" name="article Id" type="string" required="true" readable="true" writable="true"></activiti:formproperty> <activiti:formproperty id="nbrofarticles" name="number of Articles" type="long" required="true" readable="true" writable="true"></activiti:formproperty> <activiti:formproperty id="delivery" name="delivered by" type="enum" required="true" readable="true" writable="true"> <activiti:value id="fedex" name="fedex"></activiti:value> <activiti:value id="dhl" name="dhl"></activiti:value> <activiti:value id="ups" name="ups"></activiti:value> </activiti:formproperty> <activiti:formproperty id="deliverydate" name="delivery date" type="date" datepattern="yyyy-mm-dd" required="true" readable="true" writable="true"></activiti:formproperty> 57

67 5 Results <activiti:formproperty id="fast" name="fast delivery" type="boolean" required="true" readable="true" writable="true"></activiti:formproperty> <activiti:formproperty id=" to" name="to" type="string" required="true" readable="true" writable="true"></activiti:formproperty> <activiti:formproperty id="subject" name="subject" type="string" required="true" readable="true" writable="true"></activiti:formproperty> <activiti:formproperty id="message" name="description" type="textarea" required="true" readable="true" writable="true"></activiti:formproperty> </extensionelements> </usertask> <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE form SYSTEM "activiti_custom_forms.dtd"> <form> <field id="user" description="" /> <field id="companyname" description="" /> <field id="companyaddress" description="" /> <field id="description" description="" /> <field id="firstname" description="" /> <field id="middlename" description="" /> <field id="lastname" description="" /> <field id="address" description="" /> <field id="zipcode" description="" /> <field id="city" description="" /> <field id=" " description="" /> <field id="phone" description="" /> <field id="articleid" description="" /> <field id="nbrofarticles" description="" /> <field id="delivery" description="" /> <field id="deliverydate" description="" /> <field id="fast" description="" /> <field id=" to" description="" /> <field id="subject" description="" /> <field id="message" description="" /> </form> <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE form SYSTEM "activiti_custom_forms.dtd"> <form> <block type="panel" caption="company"> <column> <field id="user" description="user" /> <field id="companyname" description="companyname" /> <field id="companyaddress" description="company Address" /> <divider /> <field id="description" description="description" /> </column> </block> <br /> <block type="divider" caption="personal"> <row> <field id="firstname" description="enter your first name here" /> <field id="middlename" description="enter your middle name here" /> <field id="lastname" description="enter your last name here" /> </row> <field id="address" description="enter your address here" /> <row> <field id="zipcode" description="enter your zip code here" /> <field id="city" description="enter your city here" /> </row> <divider /> <field id=" " /> <field id="phone" /> 58

68 5 Results <a href=" >Cybercom Group</a> </block> <br /> <divider>article</divider> <field id="articleid" description="enter article id here" /> <field id="nbrofarticles" description="enter the number of articles here" /> <row> <field id="delivery" /> <field id="deliverydate" /> </row> <field id="fast" /> <br /> <divider> </divider> <column> <field id=" to" /> <field id="subject" /> <divider /> <field id="message" /> </column> <br /> <row expand="false"> <a href=" ><img src=" alt="cybercom website"/></a> <space/> <img src=" alt="cybercom logo"/> </row> </form> All the tabs have been removed from the XML above in order to increase the readability in this document. In figures 46 and 47 screenshots regarding the appearance of the custom form (from the XML above) when it is displayed in the modified version of Activiti Explorer are shown. 59

69 5 Results Figure 46: The first part of the custom form layout This is almost the same user form as that in figure 33 (Implementation chapter) with the exception of the two textarea fields, which are not supported by default in Activiti Explorer. In figure 33, standard string input fields are used instead of the two textarea fields. Another difference is that Related content, People and Subtasks have been moved to after the user input form since they are considered less important than the form. 60

70 5 Results Figure 47: The second part of the custom form layout 5.4 Improvements and bug fixes The following provides information relating to some of the improvements and bug fixes performed in the extended version of Activiti Explorer Large screen support The fix for large screen support can be seen in figure

71 5 Results Figure 48: Large screen support Boolean bug fix A Boolean field working without error messages when assigned a process variable can be seen in figure 49. Figure 49: Working Boolean field Date field The date field displaying only the controls nesssesary to enter a date and time in the requested resolution is shown in figure

72 5 Results Figure 50: Improved date field Enum fields The enum field without the option to enter a null value when the field is required is shown in figure 51. Figure 51: Improved enum field 63