JWT-To-Activiti

2,296 views

Published on

Published in: Software, Technology, Business

JWT-To-Activiti

  1. 1. Master's Thesis in Computer Science Integrating Java Workflow Tooling with the Activiti process engine A concept of transforming, executing, deploying and monitoring business processes Eugen Petrosean (Matr-Nr. 1071092) May 2014
  2. 2. Contents Part 1 – Introduction.........................................................5 1 Motivation........................................................................................5 Part 2 – Introducing workflow concepts, terminology and relations ...........................................................................7 2 Workflows – Introducing the basics of business processes..............7 2.1 Getting to know relationships between basic terminology............................7 2.2 Taking a closer look at the workflow reference model..................................9 2.3 Understanding workflow components........................................................10 3 Business Process Modeling and Notation – Introducing high-level modeling with BPMN 2.0...................................................................13 3.1 Getting to know BPMN 2.0..........................................................................13 3.2 Walking around the business process management life cycle.....................15 3.3 Understanding the BPMN 2.0 meta model.................................................16 4 Java Workflow Tooling – Introducing the service-oriented JWT tool stack..................................................................................................18 4.1 Getting to know Java Workflow Tooling......................................................18 4.2 Dealing with the Java Workflow Tooling meta model................................19 4.3 Understanding the implementation approach of the meta model .............21 5 Activiti – Introducing executable business processes in BPMN 2.0.23 5.1 Getting to know Activiti...............................................................................23 5.2 Getting familiar with the Activiti Engine component.................................25 5.3 Understanding execution and task listeners...............................................27 5.4 Deploying processes to the Activiti Engine.................................................28 6 Esper – Introducing complex event processing (CEP)....................29 6.1 Understanding business activity monitoring..............................................29 6.2 Understanding complex event processing..................................................30
  3. 3. 6.3 Working with the event processing language..............................................31 6.4 Taking a closer look at the Esper CEP Engine............................................32 Part 3 – Integrating Java Workflow Tooling with the Activiti process engine.....................................................34 7 Introducing a real business process................................................34 7.1 Analyzing the loan request process..............................................................34 7.2 Using decision tables in the loan request process ......................................35 8 Specifying integration requirements between Java Workflow Tooling and the Activiti process engine.............................................37 8.1 Understanding integration challenges between JWT and Activiti..............37 8.2 Dealing with conceptional differences between JWT and Activiti.............38 8.3 Using the Activiti tool stack for extending JWT business processes ..........41 Part 4 – Implementing executable Java Workflow Tooling business processes..........................................................42 9 Creating the JWT Extensions development environment...............43 9.1 Introducing the JWT Extensions approach ................................................43 9.2 Illustrating the JWT Extensions development process .............................46 9.3 Clarifying the implementation details of the JWT Extensions development environment......................................................................................................48 10 Transforming Java Workflow Tooling business processes ...........55 10.1 Developing an in-memory transformation mechanism.............................55 10.2 Creating, mapping and appending target transformation elements........60 10.3 Applying a post-transformation mechanism ...........................................63 11 Executing Java Workflow Tooling business processes ..................66 11.1 Mavenizing Activiti dependencies..............................................................66 11.2 Generating service task listeners ...............................................................67 11.3 Specifying user tasks..................................................................................69 12 Deploying Java Workflow Tooling business processes..................74 12.1 Generating deployment archives................................................................74 12.2 Deploying processes via the Activiti Explorer...........................................75 13 Monitoring Java Workflow Tooling business processes................78 13.1 Specifying additional monitoring listeners ...............................................78 13.2 Understanding monitoring parameters....................................................84 13.3 Dealing with monitoring event types and queries.....................................87 13.4 Developing monitoring unit tests..............................................................92
  4. 4. 13.5 Analyzing monitoring outputs...................................................................95 Part 5 – Summary............................................................98 14 Conclusions..................................................................................98 Appendix A.....................................................................101 Appendix B....................................................................103 Appendix C.....................................................................105 References.....................................................................107
  5. 5. Part 1 – Introduction Part 1 – Introduction 1 Motivation In recent years, information technology has made huge steps forward, resulting in the creation of new ways of organizing business processes. At the beginning, the development of business processes implied that they were developed with the assumption that business processes would be managed by people. According to this approach, an organizational structure was developed under which particular tasks were assigned to groups of people, or departments. Only then did people consider whether information systems could support, or take over, the work. Nowadays, business processes are designed in a more abstract way, without considering implementation. Only then the information systems and the organization can be designed hand in hand by deciding whether each task in a business process should be performed by an information system or a person. Information systems like word processors, drawing systems, spreadsheet systems, database systems and electronic-mail systems are used to reduce people's workload in offices but simultaneously they remain generic in nature and are not limited to a specific business application, as, for example, accounting systems are. Alongside with these information systems a new class of generic software for managing business processes has been evolving – so-called workflow management systems. Workflow management systems ensure that the right information reaches the right person at the right time, or is submitted to the right computer application at the right moment. Thus, they do not perform any of the tasks in a process but delegate their execution to a specific application software. In the past, the functional structure of an organization played the most important role in how it was organized. Now, as already mentioned, business processes are crucial, and therefore good tools are required to define and analyze business processes. Today, Activiti represents one of the most powerful open-source workflow management systems due to its concept and architecture. It is not only a generic workflow management system but also a framework which can be integrated in every Java application software. This vision to consider workflow management systems not as a monolithic architecture, provides a graceful approach to use Activiti for different development tasks in regard to business processes. Java Workflow Tooling is another important attempt in scope of a research project to provide a number of tools which would simplify the process of defining and improving business processes. In order to have a mechanism of analyzing business processes, it is important for business analysts to get insight into the execution of business processes. This is not an easy task because Java Workflow Tooling does not have any mechanisms to execute business processes and therefore the analysis of processes which targets at improving them, seems to be impossible. For this purpose, we consider two possibilities how we can deal with this problem: either we implement a standalone solution for executing and monitoring processes, or we use powerful components from the Activiti tool stack, integrate them with Java 5
  6. 6. Part 1 – Introduction Workflow Tooling, and implement afterwards only the monitoring mechanism. The second choice is a more realistic one because we can rely on techniques and approaches which were developed by people from the Activiti community with much technical expertise in implementing such business process technologies. That's why we are going to focus in this master's thesis on how we will integrate Java Workflow Tooling with Activiti, and ensure that business processes defined within the Java Workflow Tooling tool stack will become executable by means of Activiti, and then on this basis implement monitoring aspects required for further analyses of business processes. As Java Workflow Tooling is a tool stack for developing business processes within Eclipse, the technological realization of integration aspects will be performed from a developer's point of view by extending the Eclipse plugins of Java Workflow Tooling and Activiti. The remainder of this master's thesis is organized as follows. Part 2 introduces the standard terminology developed by the Workflow Management Coalition (chapter 2) and explains how these workflow concepts are applied in BPMN 2.0 (chapter 3), in Java Workflow Tooling (chapter 4), and in Activiti (chapter 5). Furthermore, it provides fundamental understanding of how business activity monitoring (chapter 6) can be implemented in regard to mentioned workflow concepts. Part 3 highlights the idea of how we are going to integrate Java Workflow Tooling with Activiti. On the basis of a real business process (chapter 7) we will specify integration requirements between the two technologies and illustrate possible difficulties of integrating Java Workflow Tooling components with the Activiti tool stack (chapter 8). Part 4 explains how we propose to implement the concept resulted from the integration requirements between Java Workflow Tooling and Activiti. For this purpose we are going to present an approach of creating a Java Workflow Tooling Extensions development environment (chapter 10) to ensure that Java Workflow Tooling process definitions can be transformed to Activiti/BPMN 2.0 process definitions (chapter 11), executed by the Acitiviti process engine (chapter 12), deployed to the Activiti Explorer (chapter 13), and afterwards monitored (chapter 14) according to techinques imple- mented on the basis of knowledge presented in chapter 6. 6
  7. 7. Part 2 – Introducing workflow concepts, terminology and relations Part 2 – Introducing workflow concepts, terminology and relations 2 Workflows – Introducing the basics of business processes 2.1 Getting to know relationships between basic terminology Before we start implementing the integration of JWT with Activiti, we will first take a look at the topic of business process management [Wfm99, Hol94, Wak02]. We should, as far as possible, use the terminology developed by the Workflow Management Coalition (WfMC). This is an organization dedicated to developing standard termino- logy and standard interfaces for workflow management systems components. Once we have a good sense of this broad world, we will look at the BPMN 2.0 specification and see why it is such an important industry standard. Now let us take a look at figure 2.1 to understand how different terms hang together because they will be used throughout this thesis. Figure 2.1: Relationships between basic terminology [Wfm99] 7
  8. 8. Part 2 – Introducing workflow concepts, terminology and relations In figure 2.1, you can see two branches of interrelated terms. The left one represents a branch of terms which are important to know while defining business processes. In contrast, the right branch contains terms which deal with the execution of business processes. For each of this terms we present a concise definition according to the WfMC which formulated the main terms and concepts of the business process management approach [Wfm99]. Definition (Business Process). A set of one or more linked procedures or activities which collectively realize a business objective or policy goal, normally within the context of an organisational structure defining functional roles and relationships. Definition (Workflow). The automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules. Definition (Workflow Engine). The workflow engine takes care of the actual management of the workflow. Amongst other things, it is concerned with task- assignment generation, resource allocation, activity performance, case preparation and modification, the launching of application, and the recording of logistical information. Definition (Workflow Management System). A system that defines, creates and manages the execution of workflows through the use of software, running on one or more workflow engines, which is able to interpret the process definition, interact with workflow participants and, where required, invoke the use of IT tools and applications. Definition (Process Definition). The representation of a business process in a form which supports automated manipulation, such as modeling, or enactment by a workflow management system. The process definition consists of a network of activities and their relationships, criteria to indicate the start and termination of the process, and information about individual activities, such as participants, associated IT applications and data, etc. Definition (Activity). A description of a piece of work that forms one logical step within a process. An activity may be a manual activity which does not support computer automation, or a workflow (automated) activity. A workflow activity requires human and/or machine resources to support process execution; where human resource is required and an activity is allocated to a workflow participant. Definition (Automated Activity). An activitiy which is capable of computer automation using a workflow management system to manage the activity during execution of the business process of which it forms a part. Definition (Manual Activity). An activity within a business process which is not capable of automation and hence lies outside the scope of a workflow management system. Such activities may be included within a process definition, for example, to support modeling of the process but do not form part of a resulting workflow. Definition (Process Instance). The representation of single enactment of a 8
  9. 9. Part 2 – Introducing workflow concepts, terminology and relations process including its associated data. Each instance represents a separate thread of execution1 of the process which may be controlled independently and will have its own internal state and externally visible identity which may be used as a handle, for example, to record or retrieve audit data relating to the individual enactment. Thus, these definitions give us insight into aspects which will be discussed throughout this thesis from a practical point of view. It is possible to implement a concrete prototype concerning the ideas of the integration of JWT and Activiti because of their maturity among business process management tools. 2.2 Taking a closer look at the workflow reference model In section 2.1, we described the most important terms which we are going to use throughout this thesis. Among the definitions presented in the previous section, we explained the behaviour of the Activity object type. As processes consist of logical steps represented by the Activity object type, it is important to understand how does the Activity object type relates to other object types. In figure 2.2, you can see a number of interrelated object types. For each of these object types we are going to provide a short definition according to the WfMC specification. Figure 2.2: Basic process definition meta model [Hol94] As you can see, WfMC introduced a basic meta model for process definitions by identifying core object types which are appropriate for the interchange of process definitions. Now let us have a look at definitions mentioned in the introduction of this section. 1 Where a process includes parallel activities, a process instance may include multiple concurrent threads of execution 9
  10. 10. Part 2 – Introducing workflow concepts, terminology and relations Definition (Workflow Participant – Role). A resource which performs the work represented by a workflow activity instance. This work is normally manifested as one or more work items assigned to the workflow participant via the worklist. A workflow participant is normally identified by reference within the process definition to a role or organizational entity which can then be filled by one or more of the resources available to the workflow system to operate in that role during process enactment. Definition (Transition Condition). A logical expression which may be evaluated by a workflow engine to decide the sequence of activity execution within a process. Transition conditions identify the flow relationship between activities and are used to effect the desired sequence of activity execution which may include parallel or sequential execution conditions. Definition (Invoked Application). An invoked application is a workflow application which is invoked by the workflow management system to automate an activity, fully or in part, or to support a workflow participant in processing a work item. Definition (Workflow Relevant Data). Data which is used by a workflow management system to determine the state transitions of a workflow instance, for example within pre- and post-conditions, transition conditions or workflow participant assignment. These core object types form the basis of process definitions for such specifications/technologies like BPMN 2.0, Activiti and Java Workflow Tooling. The concrete details of how these core object types are implemented, we will discuss in the following sections of this chapter. 2.3 Understanding workflow components As mentioned in section 2.1, in order to define and to execute business processes, we need to proceed in two different ways. According to figure 2.1, we have to take into account two aspects – how a process definition can be defined and how a process definition can be executed. In figure 2.3, you can see the dividing line between the runtime and the build time of a process definition. The dividing line emphasizes that the process definition obtained during the build time is shared with the Workflow Enactment Service during the runtime. The Workflow Enactment Service is defined as follows. Definition (Workflow Enactment Service). The workflow enactment service provides the runtime environment in which process instantiation and activation occurs, utilising one or more workflow management engines, responsible for interpreting and activating part, or all, of the process definition and interacting with the external resources necessary to process the various activities. From this point of view two different types of components are used in order to model and to run business processes. There are clear benefits in using this kind of approach. Firstly, it defines a point of separation between the build time and runtime environments enabling a process definition generated by one modeling tool to be used as input to a number of different workflow runtime products. Secondly, it offers the potential to export a process definition to several different workflow products which 10
  11. 11. Part 2 – Introducing workflow concepts, terminology and relations could co-operate to provide a distributed runtime enactment service. Figure 2.3: Different phases during build and run time [Wfm99] Figure 2.4 illustrates from another point of view what kind of components interact with the Workflow Enactment Service. Figure 2.4: The workflow reference model [Wfm99] The interaction of the Workflow Enactment Service with external resources occurs via the Invoked Applications interface and the Workflow Client Applications 11
  12. 12. Part 2 – Introducing workflow concepts, terminology and relations interface. The Invoked Applications interface which enables the workflow engine to directly activate a specific tool to undertake a particular activity. This would typically be a server-based application with no user interface. For this purpose a particular activity uses a tool which requires end-user interaction. It will normally be invoked via the work list interface to provide more flexibility for user task scheduling. The Workflow Client Applications interface represents an interface through which a workflow engine interacts with a work list handler responsible for organizing work on behalf of a user resource. It is the responsibility of the work list handler to select and progress individual work items from the work list. 12
  13. 13. Part 2 – Introducing workflow concepts, terminology and relations 3 Business Process Modeling and Notation – Introducing high-level modeling with BPMN 2.0 3.1 Getting to know BPMN 2.0 When the Business Process Management Initiative (BPMI) published BPMN in 2004 (see figure 3.1), the abbreviation stood for “Business Process Modeling Notation“. The goal was to create a process notation with standard graphics which also could be used for process automation. In 2005, the Object Management Group (OMG) took over the development of BPMN. In 2011, the OMG approved version 2.0. Now, BPMN means “Business Process Model and Notation” and has its own meta model [Fre12, Rad12]. Figure 3.1: The timeline of the BPMN 2.0 standard [Rad12] Before version 2.0, it was not possible to execute BPMN process definitions directly in process engines because version 1.2 had not defined all the technical aspects required to execute BPMN process definitions. But the introduction of BPMN 2.0 enabled direct execution of BPMN process models in process engines. This was the first important criterion in favor of its use. The second important criterion was the standardization of BPMN which yields the following benefits: (1) You become less dependent on certain business process management tools because you do not need to learn a new notation every time you change tools. (2) The likelihood increases that your customers, suppliers, consultants and etc. have a grasp of BPMN and will therefore understand your process definitions 13
  14. 14. Part 2 – Introducing workflow concepts, terminology and relations more readily. (3) When you hire new staff members, the odds are higher that they have already heard about BPMN and can create such process definitions. BPMN was developed to model processes as logical and chronological sequences of events. You often hear BPMN being criticized for not representing organizational structures, strategies, business rules and it landscapes. On the one hand, it is important to incorporate these topics into process documentation, on the other hand, it relieves BPMN from further complex constructs and keeps it from being a monstrosity that nobody would want to compile, develop, or even understand. But even without these constructs, the BPMN 2.0 specification represents a substantial specification (550 pages) including over 100 BPMN 2.0 constructs. It can be very difficult to get started with BPMN 2.0 and try to comprehend the basics of the specification. Therefore, it is important to start by structuring the BPMN 2.0 into different groups of modeling detail (see figure 3.2). Figure 3.2: A categorization of BPMN 2.0 constructs by the WfMC [Rad12] With these different levels in mind (see figure 3.2), it is easier to start with BPMN by using, for example, the first level group of BPMN constructs. A more concrete description of level groups is presented below. Level 1 – is described as descriptive BPMN which can be used for high-level modeling with a restricted palette of BPMN constructs. 14
  15. 15. Part 2 – Introducing workflow concepts, terminology and relations Level 2 – can be used for detailed modeling, including event and exception handling, and is described as analytical BPMN. It uses a wide range of BPMN constructs. Level 3 – is the execution model of BPMN (which is new in BPMN 2.0) which can be deployed on a process engine. 3.2 Walking around the business process management life cycle In order to be able to implement business processes, it is important to understand that a number of steps have to be performed to obtain high-quality business processes. Creating fully functional business processes involves five steps, often referred to collectively as the business process management life cycle [Rad12, Wes07] shown in figure 3.3. Figure 3.3: The five steps of the BPM life cycle [Rad12] Each of these five steps represents an important development phase in implementing a successful process solution. That's why we will take a closer look at these aspects in part 3 and 4 of this thesis by explaining what kind of approaches we applied to provide support for the business process management life cycle. According to these five steps we will describe how JWT process definition can become executable by means of the Activiti Engine. These five steps are explained as follows: Design – The first step consists of activities that define the business process: identifying high-level activities, discussing possible organizational changes, defining service level agreements, and specifying process details such as actors, notifications, and escalations. Modeling – In this step, the business process is fully specified and validated. The process flow is formalized, for example, by using BPMN; additionally, process variables are defined and candidate services which can be used to execute an activity, are identified. To validate the business process, “what-if” scenarios are performed with process simulation. 15
  16. 16. Part 2 – Introducing workflow concepts, terminology and relations Execution – The modeled business process is implemented in a business process application, often using a business process management system. You still need to add technical details to the business process before you can execute it. The process is implemented with a process language like BPMN 2.0. Monitoring – The processes are monitored for business goals that are defined by key performance indicators (KPIs). Examples of KPIs are “the average number of orders received in a day should be at least 30” and “the time to send a proposal to a customer based on a web inquiry should not exceed eight hours”. Optimization – Based on new insights, changing business requirements, and monitoring results, the implemented business processes will need to be optimized. When the optimization phase is done, the business process goes into the design phase again and the cycle is completed. 3.3 Understanding the BPMN 2.0 meta model As the OMG document [Omg11] describing the BPMN 2.0 specification comprises 550 pages, it contains many details about the BPMN 2.0 meta model. This meta model represents an approach of how BPMN 2.0 model elements with their dependencies should be used and implemented. For example, Activiti (see chapter 5) applies the same meta model as described in the BPMN 2.0 standard. That's why while using Activiti, we can rely on the knowledge presented in this specification. In figure 3.4, you can see the class diagram of the BPMN 2.0 meta model. We illustrated the main aspects of the meta model which will be important for us during this master's thesis. We left out many classes and associations between them, and focused only on the inheritance hierarchy of the core model elements because the explanation of the entire meta model would go beyond the scope of this thesis. As mentioned in section 3.1, the minimal set of elements of the first level (see figure 3.2) are elements of three categories – activities, gateways and events. Activities are represented in figure 3.4 by the Activity abstract class which is the base class for tasks – for the ServiceTask and UserTask. The second category are gateways. Two important gateways are the ParallelGateway and the ExclusiveGateway. The definitions of these elements are presented in appendix A. The third category are events. The BPMN 2.0 specification defines many different events but we will focus only on the StartEvent and the EndEvent. The SequenceFlow element cannot be assigned to one of these three categories because it connects other elements with each other. Therefore, the SequenceFlow element can be considered as a standalone element which does not belong to any of these three categories. The Process and SubProcess elements represent element containers for other model elements, among other things, model elements of the categories mentioned above. It is also important to emphasize that the BPMN 2.0 meta model with its basic concepts was implemented in scope of Activiti by introducing Activiti extensions for the constructs which were necessary to execute process definitions, and which has not been defined in the BPMN 2.0 specification, for example, execution and task listeners. But we will go into greater detail of this topic in section 5.5. 16
  17. 17. Figure 3.4: The BPMN 2.0 meta model [Omg11] 17 Part2–Introducingworkflowconcepts,terminologyandrelations
  18. 18. Part 2 – Introducing workflow concepts, terminology and relations 4 Java Workflow Tooling – Introducing the service- oriented JWT tool stack 4.1 Getting to know Java Workflow Tooling Java Workflow Tooling (JWT) is an Eclipse Technology project and its goal is to provide a set of tools which will help to develop, deploy and test workflows [Jwt14]. The development of Java Workflow Tooling started in 2007 (see figure 4.1) when small and medium-sized enterprises realized that business processes in the context of ERP can improve their productivity and provide a new level of innovative working methods within their organizations. As most companies use simultaneously several applications, it is important to have the possibility to integrate them in a way that relevant data can be exchanged among them. As process integration is not an aspect which can easily be implemented, Java Workflow Tooling aims to provide a new concept by introducing an adaptable framework for different graphical representations and XML notations, as well as different workflow engines. Figure 4.1: The timeline of Java Workflow Tooling The JWT project aims to provide build-time and runtime generic tools for workflow engines and to introduce generic APIs for defining and administrating business processes. Java Workflow Tooling comprises several important components which are important to achieve the mentioned objective. Workflow Editor – The Workflow Editor is a visual tool for creating, managing and reviewing process definitions. 18
  19. 19. Part 2 – Introducing workflow concepts, terminology and relations Workflow Administration and Monitoring – This compo- nent is used for deploying and testing workflows in a workflow engine i.e. handle an engine's process definition repository by loading/unloading/updating/instantiating/monitoring process definitions and performing mappings among participant defini- tions and real users and among application and tool agents. Runtime Tools – This component provides the user with all kinds of tools to adapt a workflow at runtime. 4.2 Dealing with the Java Workflow Tooling meta model As mentioned in previous sections, it is important to understand how elements of a process definition relate to each other. For the JWT process definition a number of interesting concepts were introduced to provide a notation (see appendix B) which shows similarities with BPMN 2.0 core constructs and with UML Activity Diagram elements [Bar07, Lau07]. The meta model of JWT is designed in a way that each element in JWT is an element of type ModelElement. The ModelElement class (see figure 4.2) is the basic unit and represents the most abstract element of the meta model. A special kind of a model element is an element of type NamedElement. All elements which have a name and an icon are at least elements of type NamedElement. Figure 4.2: The Java Workflow Tooling meta model – Roles and Applications The ReferenceableElement class represents an element which can be referenced by other elements. To include elements into an activity which are normally outside the scope and are defined for more than one process model, the reference approach can be 19
  20. 20. Part 2 – Introducing workflow concepts, terminology and relations used to point to an existing element of type ReferenceableElement. These references can be connected through edges of type ReferenceEdge (see figure 4.3) . Figure 4.3: The Java Workflow Tooling meta model – References An example for a referenceable element would be a Role element or an Application element (see figure 4.2) . To model the flow of executable elements, let us take a look at figure 4.4. To model the start or finish of a process, the InitialNode and FinalNode elements can be used. To model parallel process flows and the synchronization afterwards the ForkNode and JoinNode elements can be applied. For exclusive choices and merges afterwards the DecisionNode and the MergeNode elements can be used. Figure 4.4: The Java Workflow Tooling meta model – Control nodes It is also important to understand how these elements fit into the entire JWT meta model. All processes modeled with JWT are activities which are subclasses of the Scope class which in turn includes all elements in a graphical model (see figure 4.5). Examples for such elements are elements of type ActivityNode and ActivityEdge. One example for an element of type ActivityNode is an Action element which is executable (subclass of ExecutableNode) and has therefore a name and an icon 20
  21. 21. Part 2 – Introducing workflow concepts, terminology and relations (subclass of NamedElement). The StructuredActivityNode class represents an executable element and simultaneously has its own scope with elements of type ActivityNode and edges of type ActivityEdge which connect two elements and can be constrained with a Guard object. Figure 4.5: The Java Workflow Tooling meta model – Processes 4.3 Understanding the implementation approach of the meta model The meta model of Java Workflow Tooling is based on the Eclipse Modeling Framework (EMF) which provides tools and runtime support to produce a set of Java classes for the model and a set of adapter classes which enable viewing and command- based editing of the model [Sbp09]. This means that the implementation of the specific logic can be generated, and therefore manual coding can be avoided. It is also important to emphasize that the JWT meta model is built according to the Meta-Object Facility (MOF) standard which defines four layers: M0 – This layer is used to describe real world objects. M1 – This layer is used to create user-defined models. This would be, for example, models written in UML. M2 – This layer is used to define how models are build and structured. The most prominent example is the UML meta model, the model which describes UML itself. Also JWT is such a meta model. 21
  22. 22. Part 2 – Introducing workflow concepts, terminology and relations M3 – This layer represents meta meta models which are used to build meta models. The construction of a meta meta model is implemented by means of the M3 layer itself. The example is the Ecore meta meta model of EMF. In figure 4.6, you can see how in the basic editor of EMF the Java Workflow Tooling meta model can be defined and edited. Figure 4.6: The Java Workflow Tooling meta model in the EMF editor 22
  23. 23. Part 2 – Introducing workflow concepts, terminology and relations 5 Activiti – Introducing executable business processes in BPMN 2.0 5.1 Getting to know Activiti The Activiti project was started in 2010 by Tom Baeyens and Joram Barrez, the former founder and the core developer of jBPM (JBoss BPM). The goal of the Activiti project is to build a super-fast and a rock-solid open source BPMN 2.0 process engine [Act14, Rad12]. It is funded by Alfresco2 but it acts as an independent open source project. Alfresco uses the Activiti process engine to support features such as a review and approval process for documents which means that the document has to be approved by one or a group of users. For this kind of functionality, Activiti is integrated into the Alfresco system to provide the necessary process and workflow engine capabilities. Figure 5.1: The timeline of Activiti As Activiti is a BPMN 2.0 process engine framework, it aims to provide an approach for implementing business processes in isolation and to be applicable as a component in everyday software development. This vision will help to avoid that executable business processes can become indispensible and monolithic part of a larger application. It is also important to emphasize that Activiti called its first stable and production-ready release 5.0. The version 5.0 indicates that Activiti is not building experimental stuff but continues to build on the experience of its founders which they gained developing the jBPM versions 1 to 4 (see figure 5.1). They use that knowledge as a base line and work 2 Alfresco is known for its open source document management system of the same name. 23
  24. 24. Part 2 – Introducing workflow concepts, terminology and relations with the community to build the next generation BPM solution. The Activiti project contains a number of components, among other things, the process engine which provides the core capabilities to execute BPMN 2.0 processes. Figure 5.2 illustrates an overview of the full Activiti tool stack. Figure 5.2: An overview of the Activiti tool stack [Rad12] The different components are summarized as follows. Activiti Engine – The core component of the Activiti tool stack that performs the process engine functions, such as executing BPMN 2.0 business processes and creating workflow tasks. Activiti Modeler – A web-based modeling environment for creating BPMN 2.0 – compliant business process diagrams. Activiti Designer – An Eclipse plugin that can be used to design BPMN 2.0 – compliant business processes with the addition of Activiti extensions, such as a Java service task and execution listeners. You can also define unit test processes, import BPMN 2.0 processes, and create deployment artifacts. Activiti Explorer – A web application which can be used for a wide range of functions in conjunction with the Activiti Engine. You can, for example, start new process instances and get a list of tasks assigned to you. In addition, you can perform simple process management tasks, like deploying new processes and retrieving the process instance status. 24
  25. 25. Part 2 – Introducing workflow concepts, terminology and relations Activiti REST – A web application which provides a REST interface on top of the Activiti Engine. In the default installation, the Activiti REST application is the entry point to the Activiti Engine. 5.2 Getting familiar with the Activiti Engine component Activiti is a BPMN 2.0 process engine framework which implements the BPMN 2.0 specification. It is able to deploy process definitions, start new process instances, execute user tasks and perform other BPMN 2.0 functions. The core of the Activiti Engine is the Activiti engine component which consists of two layers as shown in figure 5.3. The first layer is the engine itself which provides the engine interfaces and implements the BPMN 2.0 specification. The engine component also includes a process virtual machine abstraction which translates the BPMN 2.0 engine logic into a state machine model (see figure 5.4). This process virtual machine, therefore, is capable of supporting other process languages and provides the foundational layer of the Activiti Engine. Figure 5.3: An overview of the different layers of the Activiti Engine [Rad12] The core of the process virtual machine is the state machine model. A BPMN 2.0 process definition consists of elements like events, tasks and gateways which are wired together via sequence flows. When such a process definition is deployed on the process engine and a new process instance is started, the BPMN 2.0 elements are executed one by one. This process execution is similar to a state machine where there is an active state and, based on conditions, the state execution progresses to another state via transitions. In the Activiti engine most BPMN 2.0 elements are implemented as a state (see figure 5.4). They are connected with leaving and arriving transitions. Every state or corresponding BPMN 2.0 element can have a piece of logic which will be executed when the process instance enters the state. As mentioned above, the Activiti Engine is the entry point to deploying new process definitions, starting new process instances, querying for user tasks, and so on. But it is also responsible for the options of how the Activiti Engine can be run during the development of business processes. 25
  26. 26. Part 2 – Introducing workflow concepts, terminology and relations Figure 5.4: An abstract overview of a state machine and how it is implemented in the Activiti Engine [Rad12] A good way to test a BPMN 2.0 process is to run the Activiti Engine inside the Java Virtual Machine (JVM) with in-memory database (see figure 5.5). In this deployment scenario, the unit tests can also be run within a continuous build environment without the need for external server components. Figure 5.5: The deployment scenario where the Activiti Engine runs within the JVM with an in-memory database [Rad12] But there are also other options for running the Activiti Engine in a development environment. The deployment alternative can be when the Activiti Engine runs within the same JVM as the unit test and connects to a standalone database. It is also possible to run unit tests when the Activiti Engine runs on an application server, such as Apache Tomcat, with a standalone database by using the Activiti REST API (see figure 5.6). 26
  27. 27. Part 2 – Introducing workflow concepts, terminology and relations Figure 5.6: A typical Activiti Engine environment where the process engine runs on an application server with a standalone database [Rad12] 5.3 Understanding execution and task listeners When the process engine executes a process, several things happen in the background. Automatic activities are executed, transitions are performed and user tasks are created and assigned to the configured users and groups. When you want to get more information out of the process execution, Activiti provides an extension on top of the BPMN 2.0 specification, referred to as execution and task listeners (see table 5.1). BPMN 2.0 construct Event types Description Process start, end A start and end event of a process instance can be captured with a process execution listener. Activity start, end A start and end execution listener of an activity can be implemented. Transition take A transition execution listener can catch a take transition event. User task create, assignment, complete A user task throws events when it is created, when the task assignment has been performed, and when the user task has been completed. Table 5.1: An overview of the event types that can be configured using the Activiti execution and task listeners extension Activiti supports two types of listeners, the ExecutionListener and the Task- Listener. The ExecutionListener can be used to implement a listener for the process, activity, and transition event types. The TaskListener is solely dedicated to the listener implementation of a user task. These listeners provide great hooks into the process execution, and they can be used for things like business process monitoring. 27
  28. 28. Part 2 – Introducing workflow concepts, terminology and relations 5.4 Deploying processes to the Activiti Engine In previous sections, we described how the Activiti Engine comes into play when BPMN 2.0 elements within a process definition should be executed. But before a process can be started, its process definition should become available to the Activiti Engine. That's why another step is required during which the specific process definition will be deployed on the Activiti Engine and serve as a basis for starting new process instances. For this purpose Activiti introduced two types of deployment archives which can be accepted/consumed by the Activiti Engine/Activiti Explorer. Let us take a look at these definitions. Definition (Activiti BAR file). A business archive (.bar file) is the unit of deployment on the Activiti Engine. It is equivalent to a standard Java .jar file and is therefore a zip file. It should contain only BPMN 2.0 processes because Java classes which are added in the .bar file will not be added to the classpath. When a .bar file is deployed, it is scanned for files with a bpmn20.xml extension. Each file that has this extension will be parsed and can contain multiple process definitions. In general, there are three options for deploying a business archive. You can use Java, Ant, or Activiti Explorer. In part 4 we will describe more precisely how Activiti process definitions obtained from JWT process definitions can be deployed with the Activiti Explorer by uploading business archives. Another important archive is the Activiti Java archive which can be defined as follows. Definition (Activiti JAR file). A Java archive (.jar file) is the unit of deployment on Activiti Engine and contains all the classes the process needs at runtime, such as the Java service tasks or implementations of event listeners, should be present on the Activiti Engine classpath for the processes in the business archive to run. To include Activiti Java archives to run processes with the Activiti Explorer, you have to copy that archive to the webapps/activiti-explorer/WEB-INF/lib directory of the Tomcat distribution. 28
  29. 29. Part 2 – Introducing workflow concepts, terminology and relations 6 Esper – Introducing complex event processing (CEP) 6.1 Understanding business activity monitoring When many different business processes are running in an organization, it is very interesting for each organization to get real-time insight into all of their running processes and thus get a better understanding of what kind of effective and swift decision-making procedures can be defined. To provide this real-time information about what is happening in an organization, business activity monitoring (BAM) can be applied [Rad12, Rsa13]. This section will cover what business monitoring is and what aspects come into play in order to implement it. Now let us take a look at the definition of business activity monitoring. Definition (BAM). Business activity monitoring (BAM) is a discipline that focuses on real-time monitoring, and therefore it is all about knowing what is going on in an organization at any given moment of time. But business activity monitoring is often used in the same context as business intelligence. Although both have the shared goal of providing an organization with vital information concerning the business state, there are differences between the two aspects. The next definition will clarify these differences. Definition (BI). Business intelligence (BI) is a discipline that focuses mainly on historic data to perform its analysis. Information is gathered from different systems and stored in data warehouses, where it can be analyzed and processed to produce reports and possibly forecasts. Although business activity monitoring and business intelligence serve similar goals of improving business in the future, BI focuses mainly on the past to achieve those goals, whereas BAM focuses on the present. Figure 6.1: A typical business monitoring solution [Rad12] In figure 6.1, you can see the three main steps which are important to implement a BAM solution: 29
  30. 30. Part 2 – Introducing workflow concepts, terminology and relations (1) Gather events – This involves inputting data by receiving events from as many sources as needed. Events are typically sent from other applications and contain short messages of information, such as, “customer A bought 5 items of product B for $100”. (2) Analyze the gathered data – An example of analysis in this step is filtering. When a certain product has recently been heavily advertised, a company might be interested in how many people are in the process of buying it. In this case, filtering takes place on the shopping baskets to retrieve only the information that is needed for a specific measurement. (3) Report the result of the analysis – After the information has been analyzed, the results need to be communicated. Dashboards, like the one illustrated in figure 6.1, can help to quickly display trends and spot exceptional situations. When values reach certain limits, actions can be taken, such as sending an email. 6.2 Understanding complex event processing CEP is the technology that performs filtering, correlation, aggregation and computing on volumes of real-time event data [Eni11, Rad12]. For example, a manufacturing plant management system diagnoses mechanical failures based on observable symptoms. In this case the basic events are symptoms describing things that do not work properly, and the main purpose of the event processing is to find the root cause of these symptoms. This means that from basic events, an event processing system may infer a complex event. Many complex event processing applications keep the logic that processes the events separate from the event producers and event consumers, as shown in figure 6.2. Figure 6.2: The structure of an event processing application [Eni11] A CEP engine looks like an inverted database. Whereas you first store data in a database and then start quering, a CEP system lets you define the queries first and then starts running data through those queries. The events which enter the CEP engine are processed immediately. There is no database underneath this mechanism. Only the concept of event windows exists which 30
  31. 31. Part 2 – Introducing workflow concepts, terminology and relations can be defined as follows. Definition (Event window). An event window defines how many events the CEP engine is going to remember when performing its pattern matching. There are two different types of windows: Length windows – A length window instructs the CEP engine to keep the last N events. When the length window is full and a new event arrives, the oldest events are published out of the window. Time windows – A time window instructs the CEP engine to keep events for the specified amount of time. If the age of an event exceeds the time interval, it is pushed out of the window. In figure 6.3, you can see a stream of different event types entering the CEP engine. The engine performs different types of operations on the events, like filtering, aggregating similar events, and joining different types of events together. While these operations are performed on the events, a pattern matching mechanism runs on the results to search for combinations of data the engine needs to put out. Finally, the output is sent to possible listeners to act upon. Figure 6.3: Basic overview of a CEP engine in action [Rad12] In figure 6.3, you can also see a timeline which emphasizes that there is some sort of life of the event in the engine during which processing takes place. 6.3 Working with the event processing language The event processing language (EPL) follows an SQL-like syntax and allows a CEP engine to store queries as EPL queries which will run through the data [Esp14]. It has all important SQL constructs: select, from, where, group by, having and order by. The select clause in an EPL query specifies the event or the event properties to retrieve. The from clause refers to the event type, and where, just like in SQL, specifies 31
  32. 32. Part 2 – Introducing workflow concepts, terminology and relations filter conditions in the statement. select specific_attribute as specific_name from specific_event where user_name = 'John' Besides filtering using the where clause, EPL supports the concept of windows. With this concept, you are looking at a stream of events. Suppose you are looking for specific events which were sent in the last 30 seconds. The EPL would look like this: select * from specific_event.win:time(30 seconds) EPL support some standard functions as well, such as sum, avg, min and max: select sum(specific_attribute) from specific_event.win:time(30 seconds) With the sum function, the sum of all specific events over the last 30 seconds is returned. The last feature is the joining of different event types: select * from specific_event1.win:time(30 seconds) as se1, specific_event2.win:time(30 seconds) as se2 where se1.id = se2.id Two different event types occuring in a window of 30 seconds are joined by their ids. We will use EPL queries to implement the logic of business activity monitoring for Activiti processes obtained from corresponding JWT business processes. 6.4 Taking a closer look at the Esper CEP Engine Esper is an open source complex event processing implementation, and uses the event processing language to perform operations on events by filtering out certain events, changing an event instance from one form to another, and examining a collection of events to find a particular pattern [Esp14]. The reason why we decided to use the Esper CEP Engine is that it is an open source project (see table 6.1) and works with any Java process. It is a lightweight framework in comparison to the OpenESB platform which comprises a wide range of enterprise service bus technologies which are not crucial for our task. Language or product name Vendor or open source Aleri SAP Esper Open source IEP – Open ESB Open source Oracle CEP Oracle SPADE IBM StreamInsight Microsoft StreamSQL EventFlow TIBCO Table 6.1: Event processing technologies [Eni11] 32
  33. 33. Part 2 – Introducing workflow concepts, terminology and relations The Esper Engine can be described (see figure 6.4) as a set of aspects which are necessary to perform complex event processing. EPServiceProvider acts as a real engine which provides core functionality such as filtering, aggregating, and joining events. Another important aspect is the support of EPL statements which can be defined by the user and afterwards interpreted by the engine. Figure 6.4: Overview of the Esper Engine [Jte09] But also the support for defining new events is crucial for performing customized complex event processing. We will talk about all these aspects in part 4 with the objective to develop an approach which will enable us to apply business activity monitoring to Activiti processes obtained from JWT process definitions. 33
  34. 34. Part 3 – Integrating Java Workflow Tooling with the Activiti process engine Part 3 – Integrating Java Workflow Tooling with the Activiti process engine 7 Introducing a real business process 7.1 Analyzing the loan request process In this section, we will introduce the loan request process which we are going to use as a sample process for explaining how JWT process definitions can be integrated with the Activiti Engine. That's why it is important to start by exploring the loan request from a business perspective. In figure 7.1, you can see the loan request process defintion which uses the BPMN 2.0 modeling notation with explanations what kind of documents have to be generated while performing loan request process steps. Figure 7.1: An overview of the loan request process For an organization which wants to handle loan requests from its newly created website, it is important to use a business process responsible for this kind of work flow. The process contains automated steps for checking the credit amount in relation to the income of the potential customer. Not all steps in the process will need to be automated because the management believes that each loan request should be evaluated by the management group when certain conditions cannot be satisfied. A loan request process starts when the organization receives a request for a loan. This information is accompanied by some basic information, like the customer's name, 34
  35. 35. Part 3 – Integrating Java Workflow Tooling with the Activiti process engine email address, current income, and the amount of money the customer wants to borrow. Before the loan request is evaluated, a credit check is performed. The credit check ensures that the requested loan amount is not higher than half of the income of the applicant. The result of the credit check is stored as additional process information which indicates whether the management group should evaluate the loan request or not. 7.2 Using decision tables in the loan request process In section 7.1, we explained the main ideas of the loan request process and how it will be modeled to provide the necessary work flow while working on loan requests. But the logic of the credit check should be defined anywhere in the process definition. As a typical business process in a financial organization involves retrieving, creating, or storing a document, we are going to use an Excel document to store formulas used in the credit check (see table 7.1). A B C 1 Customer name 2 Email address 3 4 Income Loan amount Loan amount * 2 5 0 0 0 6 7 Credit check = A5 > C5 8 Table 7.1: The credit check Excel template showing the formula for the credit check calculation This Excel document will serve as an Excel template for generating a new Excel sheet which will contain the loan request details and the outcome of the credit check for that specific loan request (see table 7.2). A B C 1 Customer name Paul Smith 2 Email address paul.smith@gmail.com 3 4 Income Loan amount Loan amount * 2 5 5000 8000 16000 6 7 Credit check False 8 Table 7.2: The result of the loan request evaluation The second step is the evaluation of the specific loan request. The loan request 35
  36. 36. Part 3 – Integrating Java Workflow Tooling with the Activiti process engine evaluation task differs a bit because it only reads an Excel document containing a decision table (see table 7.3). The task looks up the evaluation outcome in the decision table and adds the credit check value to the executing loan request process. This value will be used to decide whether the loan request should be evaluated by the management group or not. A B C 1 Credit check Loan amount Status 2 True < 4000 Approved 3 True >= 4000 Needs manager approval 4 False N/A Denied 5 Table 7.3: The Excel decision table to be used in the loan request evaluation According to table 7.2, the credit check detected that the requested loan amount is higher than half of the income of the applicant. That's why the decision table 7.3 provides that the loan request will be denied and this automatic decision will not even require the opinion of a member of the management group. 36
  37. 37. Part 3 – Integrating Java Workflow Tooling with the Activiti process engine 8 Specifying integration requirements between Java Workflow Tooling and the Activiti process engine 8.1 Understanding integration challenges between JWT and Activiti In section 2.1, we illustrated the main connections between modeling and execution aspects of business processes which can be handled by standard business process management systems. As Activiti aims to provide a framework which should function as a component in everyday software development, we have very good prerequisites to succeed in integrating Java Workflow Tooling with Activiti and provide an important feature for JWT, namely making JWT business processes executable. In figure 8.1, we presented interrelations between Java Workflow Tooling and Activiti by modifying figure 2.1. Figure 8.1: Relationships between Java Workflow Tooling and Activiti Thus, you can see that the left branch contains JWT terms, whereas the right branch only Activiti concepts. This means that according to our integration approach the lifecycle of a business process can be considered as a composition of two technologies which are based on principles explained in section 2.1. This fact will make it easier to realize our visions that Java Workflow Tooling business processes can become executable without implementing a new workflow engine. 37
  38. 38. Part 3 – Integrating Java Workflow Tooling with the Activiti process engine 8.2 Dealing with conceptional differences between JWT and Activiti The main difference between JWT constructs and Activiti elements is how activities (see Activity definition described in section 2.1) can be modeled. As we distinguish between automated activities and manual activities, two different constructs should be provided. In section 4.2, we described the concept of referenceable elements implemented in the JWT meta model which enable to specify whether an Action element should be considered as an automated activity or as a manual activity. From this point of view, we can now take a look at table 8.1 which illustrates how automated and manual activities of JWT correspond to BPMN 2.0 activities. Table 8.1: Main differences between core constructs of JWT and Activiti This insight is very important to us because during the transformation phase of JWT process definitions to Activiti process definitions, we should take into account the concept of referenceable elements implemented in JWT and therefore develop a mechanism to map a group of JWT elements to single BPMN 2.0 constructs. It is also important to emphasize that Activiti (see appendix C) provides significantly more modeling elements than JWT. As our goal is to implement an one-directional transformation mechanism (integration of JWT with the Activiti Engine), it is therefore only important to find for each JWT modeling approach the corresponding BPMN 2.0 construct, and perform the necessary transformation step. Thus, the sample process illustrated in section 7.1 can be modeled as a JWT business process (the result is shown in figures 8.3 (part 1 and part 2)) within the JWT Eclipse plugin, and after applying our future transformation mechanism we will obtain a BPMN 2.0 process definition with Activiti extensions as shown in figures 8.4 (part 1 and part 2). 38
  39. 39. Figure 8.3: An overview of the loan request process designed in the JWT Workflow Editor – Part 1 Figure 8.3: An overview of the loan request process designed in the JWT Workflow Editor – Part 2 39 Part3–IntegratingJavaWorkflowToolingwiththeActivitiprocessengine 39 Part3–IntegratingJavaWorkflowToolingwiththeActivitiprocessengine
  40. 40. Figure 8.4: An overview of the loan request process designed in the Activiti Designer – Part 1 Figure 8.4: An overview of the loan request process designed in the Activiti Designer – Part 2 40 Part3–IntegratingJavaWorkflowToolingwiththeActivitiprocessengine
  41. 41. Part 3 – Integrating Java Workflow Tooling with the Activiti process engine 8.3 Using the Activiti tool stack for extending JWT business processes In section 2.3, we described workflow components defined by the WfMC which are crucial for running business processes in an organization. As we are going to integrate Java Workflow Tooling with the Activiti process engine, it is important to understand what kind of components should be put together to achieve the desired level of integration between JWT and Activiti. As JWT provides only one matured component, the JWT Workflow Editor, it is interesting to get insight into how this component will be interrelated with Activiti components. In figure 8.2, you can see the illustration of our approach. Figure 8.2: Overview of integration components between JWT and Activiti Thus, our goal is to implement a strong integration between the JWT Workflow Editor and the Activiti Engine by means of providing the process definition xml format which could be accepted and consumed by the Activiti Engine. As the Activiti Designer and Activiti Explorer interact directly/indirectly with the Activiti Engine, there is no need to change something on their behaviour. It is easier to transform the output produced by the JWT Workflow Editor into the BPMN 2.0 format. For this purpose we are going to introduce the JWT Extensions component which will contain the logic of obtaining the BPMN 2.0 structure of JWT process definitions, and implementation approaches in regard to monitoring aspects. 41
  42. 42. Part 4 – Implementing executable Java Workflow Tooling business processes Part 4 – Implementing executable Java Workflow Tooling business processes The fourth part of the master's thesis gives a detailed insight into the architecture of main components which are necessary to execute Java Workflow Tooling business processes by means of the Activiti Engine. As mentioned in the previous part (part 3) and in section 3.2, there is a number of steps which are crucial for an efficient and accurate integration of Java Workflow Tooling with Activiti. These steps (see figure 8.5) form the basis for our implementation and will be discussed in detail in the next chapters. Figure 8.5: An overview of implementation steps As you can see in figure 8.5, we illustrated the main steps in a flowchart to emphasize how the specific steps relate to each other and at the same time fit into the big picture of our implementation tasks. The main ideas can be summarized as follows: Step (1) – Integration (see chapter 9) Implementing concepts for extending the JWT development environment. Step (2) – Transformation (see chapter 10) Implementing a transformation mechanism for transforming JWT models to Activiti models in the BPMN 2.0 notation. Step (3) – Execution (see chapter 11) 42
  43. 43. Part 4 – Implementing executable Java Workflow Tooling business processes Implementing a mechanism for generating service and user tasks. Step (4) – Deployment (see chapter 9, chapter 12) Implementing a packaging mechanism for bundling process defini- tions and process-related execution/task listeners into a package which in turn can be consumed by the Activiti Explorer. Step (5) – Monitoring (see chapter 13) Implementing a monitoring mechanism for getting real-time insight into the status of business processes running in an organization. Step (6) – Evaluation (see chapter 13, section 13.5) Implementing an evaluation mechanism for merging the results of the monitoring analysis with JWT process definitions. However, this topic goes beyond the scope of this thesis. 9 Creating the JWT Extensions development environment In order to implement the steps explained above, we need a well-conceived approach of how we want to integrate the JWT plugin with the Activiti process engine. This approach should provide a basis (classes and mechanisms) for extending JWT process definitions so that they can become executable by means of the Activiti process engine. 9.1 Introducing the JWT Extensions approach In the introduction of this chapter, we described the main mechanisms which are important for developing and running business processes in an organization. As our goal is to extend the modeling capabilities of the JWT plugin and to provide the opportunity to run JWT process definitions, we need to define an integration layer between the JWT plugin and the Activiti Engine. For this purpose we introduce the JWT Extensions tier (see figure 9.1) which comprises all the aspects dealing with the execution of business processes. 43
  44. 44. Part 4 – Implementing executable Java Workflow Tooling business processes Figure 9.1: An architectural overview of the JWT Extensions layer The JWT Extensions layer consists of three Java projects (see figure 9.2) which contain the specific functionality for making JWT process definitions executable. Figure 9.2: The Java projects for the JWT Extensions layer The tasks of each project can be described as follows: jwt-transformation-activiti – comprises packages for transforming JWT process definitions into BPMN 2.0 models with Activiti extensions (jwt.trans- formation.activiti) as shown in figure 9.3. It also contains packages for generating for each JWT process definition a separated Activiti project (jwt.generation.activiti) with execution/task listeners and service task listeners (jwt.execution.activiti). These listeners make use of additional libraries (jwt- transformation-activiti-util, jwt-transformation-activiti-integ- ration) which will be automatically integrated into Activiti projects during their generation (jwt.integration.activiti). Figure 9.3: The Java packages of the jwt-transformation-activiti project jwt-transformation-activiti-util – comprises packages for serializing and deserializing xml configuration formats. These formats are part of the JWT Extensions layer and are used to configure the behaviour of monitoring and unit 44
  45. 45. Part 4 – Implementing executable Java Workflow Tooling business processes testing approaches (see figure 9.4). Figure 9.4: The Java packages of the jwt-transformation-activiti-util project jwt-transformation-activiti-integration – comprises packages for provi- ding a framework for integrating execution/task listeners with the monitoring infrastructure (see figure 9.5). Figure 9.5: The Java packages of the jwt-transformation-activiti- integration project The concept which was implemented to include integration and util packages into Activiti projects generated on the basis of JWT process definitions, represents a generic approach. There is no need to generate manually a .jar file with the integration and util packages and include it through the Eclipse environment as a class library into the generated Activiti project because, on the one hand, it may be complicated and time- consuming, on the other hand, any changes to the source code during the development of the JWT Extensions layer will cause the repitition of the integration process and, amongst other things, a manual generation of the specific .jar file. Our solution is to consider the jwt-transformation-activiti-integration and jwt-transformation-activiti-util projects as Eclipse plugins which in turn enable us to access the source code and compiled Java bytecode by means of the Eclipse infrastructure (org.eclipse.core.runtime). This implies that we can manage source and bytecode files from our main project, the jwt-transformation-activiti project, and generate the specific .jar file on-the-fly. In Listing 9.1, we illustrated how we can get the source code and the bytecode location of the integration and util plugins in order to replicate the folder structures in our .jar file and subsequently copy plugin files to it. //the bin folder path of the jwt-transformation-activiti-integration plugin URL integrationBinBundleRoot = Platform.getBundle( ActivitiIntegrationProjectOptions.integrationPluginName) .getEntry("/"+ ActivitiIntegrationProjectOptions.binFolderPath +"/"); 45
  46. 46. Part 4 – Implementing executable Java Workflow Tooling business processes //the src folder path of the jwt-transformation-activiti-integration plugin URL integrationSrcBundleRoot = Platform.getBundle( ActivitiIntegrationProjectOptions.integrationPluginName) .getEntry("/"+ ActivitiIntegrationProjectOptions.srcFolderPath +"/"); //the bin folder path of the jwt-transformation-activiti-util plugin URL utilBinBundleRoot = Platform.getBundle( ActivitiIntegrationProjectOptions.utilPluginName) .getEntry("/"+ ActivitiIntegrationProjectOptions.binFolderPath +"/"); //the src folder path of the jwt-transformation-activiti-util plugin URL utilSrcBundleRoot = Platform.getBundle( ActivitiIntegrationProjectOptions.utilPluginName) .getEntry("/"+ ActivitiIntegrationProjectOptions.srcFolderPath +"/"); Listing 9.1: Retrieving the source code and the bytecode location of the integration and util plugins 9.2 Illustrating the JWT Extensions development process In the previous section, we introduced three basic projects for realizing the JWT Extensions layer and providing the necessary infrastructure for extending the JWT tool stack. Whereas the aspects mentioned in the previous section were explained from an architectural point of view, the aspects in this section will be illustrated from a user's point of view describing how a developer can extend a JWT process definition and implement a process execution model on its basis. We use the example described in section 7.1, and illustrate how the development process will look like, namely how the transition from the JWT project to the Activiti project will be performed by means of the JWT Extensions layer. By analyzing the flowchart in figure 9.8, we determine that the creation of the Activiti project involves the subsequent creation of a number of JWT Extensions files which are crucial for executing JWT process definitions. Our approach does not base on the concept of creating the specific Activiti project by using the Activiti tool stack and integrating JWT Extensions files into it but, on the contrary, we create a Java project realizing the structure and behaviour of an Activiti project what enables us to integrate the JWT Extensions layer into the pre-defined structure of the Activiti project more easily and efficiently. As a result, we get the opportunity to keep generated Activiti projects completely under our control. Figure 9.6 shows the JWT project with its process definition file as a starting point of the transition between JWT and Activiti. Figure 9.6: The JWT project showing the loan request process files 46
  47. 47. Part 4 – Implementing executable Java Workflow Tooling business processes The result of applying the transition between JWT and Activiti is shown in figure 9.7. As mentioned above, it is a Java project which comprises a number of files considered as files belonging to the JWT Extensions layer. Figure 9.7: The Activiti project showing the loan request process files The most important aspects taken into consideration during the generation of the Activiti project are: • Creating execution/task listener classes in the monitoringListeners package. It is part of the JWT Extensions layer. • Creating service task listener classes in the serviceTaskListeners package. It is part of the JWT Extensions layer. • Integrating the jwt-transformation-activiti-integration.jar file as a referenced library. It is part of the JWT Extensions layer. • Creating configuration resources in the monitoring package. It is part of the JWT Extensions layer. As you can see, the diagrams package containing the bpmn file was not mentioned in the list above because this part of the Activiti project represents the native structure defined by Activiti, and therefore was not created within the scope of the JWT Extensions layer. The mechanism of how the JWT .workflow file can be transformed to an Activiti .bpmn file will be explained in the next chapter (see chapter 10). Another pre-defined approach within the Activiti project is the dependency 47
  48. 48. Part 4 – Implementing executable Java Workflow Tooling business processes management and the project build management. Their support is realized by means of Apache Maven to retrieve the necessary Activiti libraries and dependencies from the Activiti workspace directory. The pom.xml in the root of the Activiti project stores the necessary Maven configuration. Figure 9.8: The flowchart showing the relationship between the loanRequestProcess and jwt-loanRequestProcess-activiti 9.3 Clarifying the implementation details of the JWT Extensions development environment In the previous two sections, we introduced the fundamental aspects of the JWT Extensions layer and illustrated the development environment within the Eclipse IDE from a developer's point of view as a demonstration of how JWT process definitions can be extended by means of the Activiti infrastructure. Now it is time to take a look at the core asset of the JWT Extensions layer from an architectural point of view and explain how the main ideas have been implemented to provide the mentioned functionality. As you can see in figure 9.9, we distinguish between two types of project classes: ActivitiGenerationProject – represents the core functionality shown in figure 9.9. It manages any dependencies like Java class files, xml files and .jar files of the JWT Extensions layer which will be automatically included into any 48
  49. 49. Figure 9.9: The class diagram showing the relationship between ActivitiGenerationProject and ActivitiIntegrationProject 49 Part4–ImplementingexecutableJavaWorkflowToolingbusinessprocesses
  50. 50. Part 4 – Implementing executable Java Workflow Tooling business processes generated Activiti project. All files managed by the ActivitiGeneration- Project class can be compressed and bundled (via the IProjectDeployer interface) into packages (see figure 9.12) which in turn will be accepted by the Activiti Engine. ActivitiIntegrationProject – represents the functionality to access Java class files located in the jwt-transformation-activiti-integration project and in the jwt-transformation-activiti-util project. It also implements the IProjectDeployer interface which can be considered as a mechanism for bundling Java class files from both projects. In this context, it is also important to describe the approach of how we bundle Java class files from different locations into a single .jar file. In figure 9.10, we presented a class structure which is responsible for managing temporary folders of each project. Figure 9.10: The class diagram showing the concept of temporary folders They are important for performing copy operations on files which afterwards will be included into a .jar file like jwt-transformation-activiti-integration.jar (see figure 9.7). 50
  51. 51. Part 4 – Implementing executable Java Workflow Tooling business processes Figure 9.11: The process of generating and integrating a .jar file into an Activiti project As you can see in figure 9.11, the process of generating and integrating a .jar file into an Activti project goes through several phases. The main idea is to copy all folders and files to a temporary folder – in our case to the tempClasses folder, and compress it as a whole folder to a .jar file. Then the compressed .jar file will be automatically copied to the libs folder of the generated Activiti project and integrated into it as a referenced library. We can emphasize that the process described above is the most important step to set up the Activiti development environment and to extend it in a way that the JWT Extensions layer infrastructure can be accessed from there. In figure 9.12, you can see a similar process – the deployment process – during which two deployment packages (.bar file and .jar file) will be created so that they can be consumed by the Activiti Engine. Figure 9.12: The process of creating deployment packages As shown in figure 9.7, the generated Activiti project comprises a number of files which are created on-the-fly and included into the project. In order to generate project files with a specific content (xml structure or Java source code) in the right way, we introduced a mechanism for specifying different file templates which in turn can be easily rendered and maintained. In figure 9.13, we illustrated a class diagram of how we can access different file templates and retrieve the corresponding contents. For this purpose we defined a file template factory (ActivitiGenerationProjectFileTemplateFactory) and a file 51
  52. 52. Part 4 – Implementing executable Java Workflow Tooling business processes template object (ActivitiGenerationProjectFileTemplate) which interact with each other in a way that the file template factory assumes responsibility to create concrete templates implementing the ICodeTemplate interface (see figure 9.14), renders them, assigns the file path and file content to the file template object, and afterwards returns it to the ActivitiGenerationProject. Figure 9.13: The class diagram showing a list of defined file templates As you can see in figure 9.13, we created templates for almost all types of files used in the generated Activiti project shown in figure 9.7. An example of how we define a template is illustrated in listing 9.2. In the template string we define only place holders for specific parameters which will be included during the rendering process of the specific template. public class ActivitiGenerationProjectServiceTaskClassTemplate implements ICodeTemplate { public String getCode() { return "package %s;n" + "n" + "import org.activiti.engine.delegate.DelegateExecution;n" + "import org.activiti.engine.delegate.JavaDelegate;n" + "n" + "public class %s implements JavaDelegate {n" + 52
  53. 53. Part 4 – Implementing executable Java Workflow Tooling business processes "t@Overriden" + "tpublic void execute(DelegateExecution execution) throws Exception {" + "n" + "t}n" + "}n"; } } Listing 9.2: Implementing a file template to generate Java service task classes A detailed illustration of how the template classes in figure 9.14 are involved in the entire process of creating project files is shown in figure 9.15. Figure 9.14: The class diagram showing template classes which derive from the ICodeTemplate interface The starting point of the sequence diagram in figure 9.15 is the JWT plugin which listens to user interactions. When the user clicks the button “Generate Activiti Project”, the process of generating a new Activiti project starts. It activates the Activiti- GenerationProjectFactory class which is responsible for creating Activiti projects by the specific project name and performs the creation of template classes by using the ActivitiGenerationProjectFileTemplateFactory class. Afterwards the Activi- tiGenerationProject class consumes the created templates and embeds them in the Eclipse Java project. 53
  54. 54. Figure 9.15: The sequence diagram showing the creation of file templates 54 Part4–ImplementingexecutableJavaWorkflowToolingbusinessprocesses
  55. 55. Part 4 – Implementing executable Java Workflow Tooling business processes 10 Transforming Java Workflow Tooling business processes One of the most important challenges in integrating Java Workflow Tooling with the Activiti process engine is the fact that JWT process definitions cannot be interpreted by the Activiti Engine. The only format which can be accepted by the Activiti Engine are the BPMN 2.0 modeling constructs. As mentioned in part 2, there are many different elements grouped into three different levels which can be used for high-level business modeling without a lot of restrictions. But we are going to take into account only those constructs which are supported by the Activiti Engine (see appendix C), and which can be easily mapped to JWT constructs. JWT constructs do not represent elements which can be assigned to different levels because all of them originate from the first level (level 1) to provide a minimal set of elements for high-level modeling (see figure 3.2). This means that our transformation approach has only to deal with elements from the first level and perform only level 1 – to – level 1 transformations. As we want to provide the ability to extend the list of transformations with new ones in the event of introducing new JWT constructs, we are going to realize a generic transformation approach which will be explained in detail throughout this section. Figure 10.1: An overview of the transformation objectives between JWT and Activiti In figure 10.1, we emphasized one more time two main transformation aspects which we are going to take into account while implementing the functionality of transforming JWT process definitions to Activiti process definitions. However, our objective is not only to provide a mechanism for generating a reliable output for the Activiti process engine but also to make transformed JWT process definitions visually editable by means of the Activiti tool stack. That's why, we should also provide a mechanism for transforming graphical information of JWT process definitions into a format which can be accepted by the Activiti Designer. Activiti makes use of the BPMN 2.0 Diagram Interchange standard which serves as a basis for visualizing Activiti process definitions within the Activiti Designer. Thus, when the transformed information about graphical positions of JWT elements will be included into the BPMN 2.0 output of JWT process definitions, the developer will get the opportunity to see and to modify them as BPMN 2.0 diagrams. 10.1 Developing an in-memory transformation mechanism In order to implement an in-memory transformation mechanism, we should be aware of two main aspects which we have mentioned above. We do not only want to make 55
  56. 56. Part 4 – Implementing executable Java Workflow Tooling business processes JWT process definitions to be accepted by the Activiti Engine but we also want to provide the possibility for editing them as BPMN 2.0 process definitions. For this purpose the process of transforming the relevant graphical information of JWT process definitions should become an inherent part for our in-memory transformation approach. We decided to realize our transformation approach as a custom implementation because the meta model of Activiti process definitions does not base on the Ecore model of EMF [Sbp09] which in turn is the basis for the Model-to-Model Transfor- mation [Mot14] framework of which we could make use, if Activiti supported EMF. Now let us take a closer look at the code snippet (see listing 10.1) which was implemented to initialize the transformation process between JWT and Activiti process definitions. private void transformModel( final JwtMemoryModel jwtMemoryModel, final ActivitiMemoryModel activitiMemoryModel){ TransformationManager transformationManager = new TransformationManager(); transformationManager.defineTransformation( jwtMemoryModel, activitiMemoryModel, new ITransformation() { public void onTransformModel( TransformationPerformer performer) { JwtToActivitiModelFormatter formatter = new JwtToActivitiModelFormatter(performer); formatter.transform( jwtMemoryModel.getModel(), activitiMemoryModel.getModel()); } public void onTransformDiagramInterchange( TransformationPerformer performer) { ... } }); transformationManager.startTransformation(); } Listing 10.1: Implementing the initialization of the transformation process In listing 10.1, you can see how a transformation process between JWT and Activiti can be defined and afterwards started. A detailed explanation of how the specific classes are related to each other is presented in the class diagram in figure 10.2. The private method transformModel which is also shown in listing 10.1 is part of the JwtToActivitiTransformation class (see figure 10.4) and functions as a holder of the transformation logic. 56
  57. 57. Figure 10.2: The class diagram showing the architecture of the transformation process 57 Part4–ImplementingexecutableJavaWorkflowToolingbusinessprocesses
  58. 58. Part 4 – Implementing executable Java Workflow Tooling business processes The class diagram in figure 10.2 reveals the concept of classes which were introduced to provide a flexible mechanism for defining in-memory transformations between two different meta models. The starting point of this transformation mechanism is the TransformationManager class which provides the functionality for registering a transformation (see defineTransformation method) and afterwards starting it (see startTrans- formation method). Each transformation which can be registered and executed by the TransformationManager class implements the ITransformation interface with two basic methods onTransformModel and onTransformDiagramInterchange. These methods were designed intentionally in that way in order to separate the two transformation flows and to strengthen their isolation. In listing 10.1, you can see that we did not create a concrete class which would implement the ITransformation interface but, in contrast, we make use of one of the most powerful features of Java programming language by notifying it that an anonymous class which implements the interface should be instantiated [Fla05]. Each of these two methods onTransformModel and onTransformDiagramInter- change await an instantiated TransformationPerformer class as a parameter. It tracks each transformation step by instantiating each time the Transformation- Element class and storing it within the TransformationPerformer object. In turn, the TransformationElement class stores the mapping information about how an element of the source meta model was transformed into an element of the target meta model. Both elements are also stored within the specific Transformation- Element object. However, in listing 10.1 we cannot see how a new transformation step can be defined. This aspect will be explained in section 10.2. As shown in figure 10.3, the main transformation phases can be arranged into a sequence of logical steps which begins with the reading process of a JWT model (.workflow file) from the hard drive and ends with the writing process of the corresponding Activiti model to the hard drive. We did not implemente both the first step (1) and the third step (3) because the first step is performed automatically by the EMF framework and the third one by a helper class within the Activiti Designer plugin. Hence, we focused on the second step (2) and implemented the concept which we described in detail throughout this section. Figure 10.3: An overview of the main transformation phases The sequence diagram (see figure 10.4) gives one more time an overview of main steps performed between the JWT plugin and the JwtToActivitiTransformation class in order to transform a JWT process definition into a BPMN 2.0 output. After creating and passing back the transformation result in terms of BPMN 2.o XML, the JWT plugin will create a .bpmn file with the specific content. As soon as we click on this file, it will be loaded and displayed by the Activiti diagram editor. 58
  59. 59. Figure 10.4: The sequence diagram showing the main steps to start the transformation process 59 Part4–ImplementingexecutableJavaWorkflowToolingbusinessprocesses
  60. 60. Part 4 – Implementing executable Java Workflow Tooling business processes 10.2 Creating, mapping and appending target transformation elements As mentioned above, our goal is to create an architecture which will provide a reliable mechanism for performing in-memory transformations between JWT and Activiti process definitions. We decided to implement this approach without using the Eclipse transformation framework – Model-to-Model Transformation – because only the meta model of JWT makes use of EMF as a core framework for the mentioned transformation framework. In contrast, the Activiti meta model was implemented without usage of EMF. This means that the only way to perform transformations between JWT and Activiti is to develop a custom transformation mechanism. We have described that for creating high-value process definitions a simple minimal set of elements can be sufficient. Thus, we are going to illustrate the main concepts of our approach by including the basic model elements into our class diagrams. As we want to make JWT process definitions executable by the Activiti process engine, only an unidirectional transformation comes into question. Therefore, the perspective of describing the approach and applying naming conventions for the specific classes is always – JWT-to-Activiti. The ActivitiModelElementFactory class (see figure 10.5) is a factory which is responsible for creating BPMN 2.0 elements with additional Activiti extension definitions. When our transformation logic needs to transform a new JWT element, we can just extend the ActivitiModelElementFactory class in the way that we add a method which will create during its invocation an instance of the corresponding BPMN 2.0 element from the Activiti meta model. Figure 10.5: The factory class for creating Activiti model elements After creating a BPMN 2.0 element by means of the ActivitiModelElementFactory class, this element should be appended to an Activiti model. For this purpose we have introduced the ActivitiModelElementAppender class (see figure 10.6). The number of methods in this class is the same as in the ActivitiModelElementFactory class because each method is responsible for appending only one concrete BPMN 2.0 element to the Activiti model. Another class which represents a similar behaviour is the JwtToActivitiModelElementMapper class (see figure 10.6). It has the same number of methods and provides the necessary functionality to perform mappings between 60
  61. 61. Part 4 – Implementing executable Java Workflow Tooling business processes JWT and Activiti meta model elements. Figure 10.6: An overview of map and append methods between JWT and Activiti Consequently from this standpoint, it follows that these three classes should function together and be controlled by a more major one (see figure 10.7). Figure 10.7: An overview of transform methods The JwtToActivitiModelFormatter class contains only one public method trans- 61
  62. 62. Part 4 – Implementing executable Java Workflow Tooling business processes form which represents the functionality for transforming a JWT process definition to the corresponding Activiti process definition. Thus, this method is responsible for transforming each element of the JWT model to its target element and appending them to the Activiti model. All other methods are private methods because they contain only the specific logic for transforming a single model element, and their invocation is therefore controlled by the main transform method. Each private transform method transforms a model element according to the following illustration (see figure 10.8). Figure 10.8: An overview of dependencies used in transform methods Hence, according to our approach three logical steps should be performed to transform an element of one model to an element of another model. Firstly, we create the target model element; secondly we map data from the source model element to the target model element and finally append it to the target model. Now let us have a look at the concrete implementation of these methods. In the following listings (listing 10.2, 10.3, 10.4) we illustrated how the JWT Activity element will be transformed to the Activiti/BPMN 2.0 Process element by invoking – create (see listing 10.2), map (see listing 10.3), append (see listing 10.4) – operations. Transform private Process transformActivity( final Activity activity, final Bpmn2MemoryModel model){ //transforms the jwt activity element to the activiti process element final Process process = ActivitiModelElementFactory.createProcess(); this.performer.transform(activity, process, new ITransformationStep(){ public void onPerform() { JwtToActivitiModelElementMapper .mapActivityToProcess(activity, process); } public void onFinish() { ActivitiModelElementAppender 62
  63. 63. Part 4 – Implementing executable Java Workflow Tooling business processes .appendProcess(process, model); } }); return process; } Listing 10.2: A transform method for transforming the JWT Activity model element to the Activiti Process model element Map public static void mapActivityToProcess( Activity jwtActivity, Process activitiProcess) { if(!StringUtils.isEmpty(jwtActivity.getName())) { activitiProcess.setName(jwtActivity.getName()); } } Listing 10.3: A map method for mapping the JWT Activity model element to the Activiti Process model element Append public static void appendProcess( Process process, Bpmn2MemoryModel appendTo){ appendTo.addProcess(process); } Listing 10.4: An append method for appending the Activiti Process model element to the Activiti model 10.3 Applying a post-transformation mechanism In section 10.1, we described how a JWT process definition can be transformed into an Activiti process definition by passing through three phases (see figure 10.3). It is a flexible approach when we want to transform static process definitions. However, our transformation mechanism has to deal with dynamic data which is essential for extending and adapting to Activiti process definitions. The dynamic information about model elements originates every time when execution and monitoring aspects should be taken into account. As mentioned throughout this thesis, in order to provide Activiti process definitions with the specific logic, we must define Java classes containing the logic and attach them to the corresponding service tasks. As the transition from a JWT process definition to an Activiti process definition is planned as an automatic transformation, Java classes must be generated on-the-fly and referenced within the 63
  64. 64. Part 4 – Implementing executable Java Workflow Tooling business processes transformed Activiti process definition. As our in-memory transformation mechanism was implemented as an isolated module for performing transformations between JWT and Activiti, we cannot combine it with the generation of Java classes for service tasks. They should be generated afterwards. This means that a new phase (see figure 10.9) should be introduced and placed between the last two phases (see figure 10.3). Figure 10.9: Extending the main transformation phases As mentioned above, we clarified that in order to apply Activiti listeners according to table 5.1 (see section 5.5), we need to include them into Activiti process definitions as references by providing their class names. For this purpose we introduced the ActivitiModelElementListenerFactory class which contains methods for creating Activiti listeners for the basic Activiti model elements (see figure 10.10). Figure 10.10: An overview of create methods for defining Activiti listeners But our objective is to initialize Acitiviti listeners in a way that they could be identified by our post-transformation mechanism and supplemented with the right class names. Now let us have a look at a concrete implementation of the createSequenceFlow- Listeners method (see listing 10.5) in order to understand how we performed the current task. public static List<ActivitiListener> createSequenceFlowListeners() { ActivitiListener takeListener = new ActivitiListener(); takeListener.setEvent("take"); takeListener.setImplementation( "{{ sequenceFlowTakeExecutionListener }}"); List<ActivitiListener> listeners = new ArrayList<ActivitiListener>(); 64

×