Canonization Service for AProMoRe

QUT Faculty of Science and Technology Canonization Service for AProMoRe Done by: Abdurrahman Alshareef Supervised by: Marcello La Rosa Semester 2-2010

Table of Contents Versions history...3 Preview...4 Business Process Modeling languages... 4 AProMoRe (Advanced Process Model Repository)... 5 JAXB (Java Architecture for XML Binding)... 6 Canonization service architecture... 7 EPC canonization...8 Canonizing EPC models... 8 De-canonizing... 9 Related issues... 9 Distinguishing between split and join gateways...9 Processing conditions and events after OR, XOR splits...9 Handling consecutive functions and events... 10 Distinguishing between relations and flows... 14 Supporting directory element... 14 Processing iepc range connector... 15 Testing...15 EPCs: some covered patterns... 15 Mapping EPC to BPMN test cases... 18 Potential improvement...20 BPMN canonization... 21 Canonizing BPMN models...21 Related issues...21 Adjusting the graphical data for native EPC models... 21 Resource types, pools and lanes... 22 Placing BPMN elements in their right lanes for native EPC models... 22 Linking nodes to lanes, and lanes to pools... 23 Events types recognition... 24 Testing...24 BPMN: some covered patterns... 24 Mapping BPMN to EPC test cases... 27 Potential Improvement...29 Conclusion... 30 References... 30

Versions history Release Date Change 0.1 30 Sep 2010 First draft completed. 0.2 20 Oct 2010 More Test case have been added: - Test end events case for EPC 0.3 02 Nov 2010 Mapping multiple resources issue added with example. 1.0 12 Nov 2010 Preview section has been added including some fundamental information about: - Business Process Languages. - AProMoRe. - JAXB technology. - Canonization service architecture.

Preview In this preview, there will be a quick review for the main required background for conducting the project. The first area is the business process modeling languages. the second is AProMoRe and its related matters such as the canonical format and the main architecture. Thirdly, a bit of explanation is provided for the used technology to serialize and de-serialize the xml files, which is JAXB. Business Process Modeling languages A modelling language is any artificial language, which can be used to express knowledge, systems, structure, or information that is defined by consistent set of rules. These rules are used for interpretation of the meaning of components in the structure. There are many business process modelling languages, which have different purposes and tools. EPC, BPMN, Petri-Nets, Workflow-Nets and YAWL are some of the most common languages. The following sections will provide a brief description about each one of these modelling languages. EPC process models are state-based (or, event-driven). So, the main objective of EPC is to have a clear defined documentation of business process models. Process models for this language are concentrate on the system states and their behavior, instead of the interaction and communication between organizations. Also, processes modeled in EPC are used within one company or organization. (Transformation from EPC to BPMN) BPMN is stand for Business Process Modeling Notation and the main goal for BPMN is to have a powerful and understandable documentation of business process models that is used for all business user groups such as technical developer. In addition, control flow and interaction behavior and data flow is supported by BPMN. As a result, it is used for both processes within one organization and for modeling interaction processes of multiple organizations. (Transformation from EPC to BPMN) Petri nets are models of distributed and concurrent discrete dynamic systems for which local consequences of operations and local influences of object states play the most important roles. Petri nets can be used to model systems for which behavior is dominated by the flow of control, information, objects etc. (Process modeling using Petri nets) Workflow nets are nets modeling business processes without resources and without any history. In particular, a workflow net is intended to describe the behavior of a single workflow case in isolation. Any case handled by the procedure represented by the workflow net is created when it enters a workflow management system and is deleted once it has completed (Process modeling using Petri nets). YAWL is a BPM/Workflow system. Based on a concise and powerful modeling language, YAWL handles complex data, transformations, and integration with organizational resources and Web Service integration. Built in Java, it uses XML Schema and XQuery natively (YAWL foundation).

AProMoRe (Advanced Process Model Repository) It is a repository for process models that has been proposed to consolidate a set of advanced features to maintain, manipulate, and process a missive amount of process models. It also has been implemented as an open- source SaaS. The repository recommends an extensible format (Canonical Process Format) as a metamodel to capture all the different constructs, patterns, and behaviors. Then, it starts applying its advanced features and techniques on that format. In addition, the CPF is considered as a gateway between the different process modeling languages that have been supported within AProMoRe so far. The UML metamodel for CPF is as the following figure: The service- oriented architecture of the repository has been tailored to support the different functionalities the AProMoRe provides. A three- tier model has been designed to compse an enterprise layer (which is the front- end of the repository), an intermediary layer (which acts like a façade between the enterprise layer and the basic layer), and the basic layer (which hosts a set of data- centric and logic- centric services). The architecture is illustrated in the following figure:

The canonization service is located in the intermediary layer to provide the repository manager the ability to import and export the models to the repository basic layer. JAXB (Java Architecture for XML Binding) JAXB is a Java API that helps the developers to access XML documents from applications written in the Java programming language. It allows Java developers to access and process XML data without having to know XML or XML processing.

XML and Java technology are recommend for developing Web services and application that access Web service. XML is well recognized as the standard for exchanging data across systems. As well as, Java is considered as a platform for portable application (Oracle, 2003). All of these characteristics fairly explain the reasons behind choosing this technology for the canonization service. There are two other main ways to access XML files through Java, Simple API for XML (SAX) and Document Object Model (DOM). SAX provides a way to navigate through the XML file, but nothing is saved in the memory, while DOM creates a tree of objects that represents the content and organization of data in the document. This tree exists in the memory (Oracle, 2003). JAXB has a unique feature that it allows the developers to process and manipulate the XML file without using any XML processing. The developer can deal with XML file through the generated Java objects and then save the data after manipulation back to the file as it is simply described by the figure above. Canonization service architecture The service has been designed to receive an xml file that represents a model of any languages, for instance, XPDL file for BPMN model. Then, it produces the canonical format process of the imported model as well as the annotation data isolated in a separate file. The following model simply describes the import process.

In addition, the service supports the exporting task by extracting the canonical process format and its related annotation data. Then, it produces an XML file the represents a process of the intended process modeling language such as BPMN or EPC. The service is able to produce a model without an annotation data in case that CPF does not have any, or the user chooses to do that. EPC canonization Canonizing EPC models First of all, canonizing an EPC model was based on EPML. The adapter takes an EPML file. It does the un-marshaling process then marshals it again into a CPF and an ANF files after mapping its elements to their desired canonical element. Then, the adapter adds all those new CPF elements to a header object, which is in this case a Canonical Process. That header is our target for marshaling again into a CPF file. According to AProMoRe, the mapping table between EPML and canonical elements will be as following: No EPC element Canonical element 1 Directory 2 epc Net 3 Event Event

4 Function Task 6 And And Join 7 Or And Split Or Join 8 Xor Or Split Xor Join Xor Split 9 Role Resource Type 10 Object Object 11 Arc Edge if it contains a flow Reference if it contains a relation 12 Process interface Sub net 13 Graphical data Annotation 14 Range De-canonizing Basically, the adapter does the opposite when de-canonizing a canonical format. However, it gives the user more choices to use an annotation data or not. If the user decides not to use any annotation data, then the produced EPML file would be without any graphical information. This case is recommended for de-canonizing those files that have an initial format different from EPML where the annotation file may not be adjusted in order to comply with EPC graphical convention. Moreover, the de-canonizer gives the user a choice to change the used annotation file. Related issues Distinguishing between split and join gateways As the EPML schema does not differentiate between split and join gateways where the canonical format does, there has to be a way to map them to their proper elements. The solution was by counting the incoming and outgoing arcs from that element. The decision will base on those numbers where the gateway would be a split if it has more than one outgoing arc, otherwise, it would be a join. However, in EPC the gateway could serve as split and join at the same time, for instance, if there were another arc going out of the join gateway such as do while pattern, in this case, the adapter will consider this gateway as a split. Processing conditions and events after OR, XOR splits Each event after OR, XOR split gateway will be removed and mapped as a condition for the edge connected to this gateway.

Handling consecutive functions and events According to EPC definition: Each event can only be followed (possibly via connectors) by function, and each function can only be followed (possibly via connectors) by event. (Weske, 162). In order to maintain this rule any produced EPC model we came up with an algorithm to add events or functions as necessarily. Those new elements are considered as fakes so far. The algorithm could be enhanced in order to make more meaningful to the model by adding some behavior. It has been implemented in order to simplify the job for the user. The algorithm has been designed to solve that with minimum number of added elements. The following algorithm is for validating all the events in the model. There is also another one for functions. Validate Model { For each event { Retrieve all successors that are connected to the event via a chain of connectors } } If all the successors are functions then Do nothing; Else if all the successors are events then Add fake function after the current event; Else if there are both then { If the number of events are more than the number of functions Add fake function after the current event; Add fake event before each successor function; Else Add fake function before each successor event; } Now, we will demonstrate this algorithm via two examples. In the following example, when checking task A, we only need an event after it in order to satisfy the rule.

Then, the generated EPC model would be such the below model (The empty elements are the fakes). Considering that, there might be still a violation for some EPC rules such as the XOR split which should be followed by events only. Such an improvement might be considered in the next phases.

The second example, where we will find a drawback for this algorithm and it might produce fakes more than needed to satisfy the rule. The following BPMN model only needs two events before tasks B and A and the problem will be solved. However, according that algorithm, the produced EPC model will have many fakes but it still satisfies the rule.

The produced EPC model would be:

Distinguishing between relations and flows As they have a different mapping in the canonical format. The canonizer will map the relation as a reference for the connected object or resource type. In the other hand, it will map any flow simply as an edge. Supporting directory element The directory element is required for EPML 2.0, however it was not in the previous release. At the beginning we stick with the new release. Then, we found it more convenient to support both releases by adding a simple check for the directory element existence. Thus, the current adapters canonize the EPML files weather they have the directory element or not.

Processing iepc range connector The range element is not supported in the canonical format. The adapter will ignore it during the canonization process. However, the linked arcs will be considered just like direct connectors between the two elements after ignoring the range. Thus, there will be a reference for each connected object in the element linked to that range. The range example in the test cases may describe that in much clearer way. Testing EPCs: some covered patterns Nu m EPC Canonical 1 2 3

4 In case the events are the end of the model, or on of them. The algorithim will be applied for or element as well. 5 6 7

8 9 10 11

Mapping EPC to BPMN test cases N EPC tested model Desired BPMN 1 2 3

4 5 6

7 8 9 Potential improvement There is still a huge room for improvement. Thus, the service architecture has been built based on that fact in order to be scalable enough to include any potential improvement or special requirements. The auto- layout feature might be built in order to convert the produced BPMN models to be from left to right in case that the initial format was from top to down. Including some modification for the model

header during enhancement step could solve that. Even more, there could be more enhancements on the semantic of the models. For example, the EPC events can be processed in more efficient way when mapping to BPMN as there might be unnecessary events can be removed or modified in the model in order to produce it more accurate for BPMN users. As mentioned, there is a wide space for improvement especially when we consider all the different aspects for the produced models. BPMN canonization Canonizing BPMN models No BPMN element Canonical element 1 WorkFlowProcess 2 epc Net 3 Event Event, State 4 6 Activity Route Task, Event, Message, Timer or State And Join 7 Route And Split Or Join 8 Route Or Split Xor Join Xor Split 9 Pool, Lane Resource Type 10 DataObject Object 11 Transition Edge 13 Graphical data Annotation Related issues Adjusting the graphical data for native EPC models Allowing AProMoRe users to view their models in different languages is one of the features that AProMoRe supports. However, that causes producing un-organized view when viewing a model using a different modeling language. That leads to come up with a conversion algorithm for the graphical information in order to produce more organized BPMN models from those models that their initial format is EPC. The issue is specifically related to some elements that have different shapes in those notations. For example, a circle visualizes the event in BPMN while it is visualized by hexagonal in

EPC. In addition that causes some gaps between the transitions and their linked elements. Thus, we implemented some modifications in order to enhance the produced BPMN models layout. those are some: - All generated events would have the same width and height of 30. - All generated gateways would have the same width and height of 40. - After doing steps above, transitions will be attached to nodes, but nodes won t be aligned as they were in the source language. To put nodes in right position, new node s center coordinate should be same as old nodes center position. Example: old node with coordinates (X1,Y1) is converted to new node with coordinates (X2, Y2). Old object s width and height are W1 and H1. We can find X2 and Y2 by applying this formula: X2=X1+W1 W2/2 and Y2=Y1+H1 H2/2. By using this new coordinate, this new object will be places exactly at the same position of the old object. - As a result of the previous step, all transitions to and from events or gateways should be pointed to the center of the node. As we already know that the default size of the gateway is 40X40. Therefore, for finding the center we only need to add 20 to gateway s new coordinates. As a general rule, to all transitions from/to gateways, we add 20 to both X and Y of the starting/ending point. In case of events, we add 15. There is still a space for such an enhancement either for the imported EPC models or any other languages. Thus, that algorithm has been isolated from the main canonization process in order to give an opportunity for any further modifications. Resource types, pools and lanes This would not be an issue when canonizing and de- canonizing the same model, as each pool will be mapped to a resource type and the lanes will be managed using a specialization feature in the canonical format. However, it might need more processing for the models with an EPC initial format. In general, it happens when the nodes within one Net in the canonical format have more than one resource type and none of them are linked to the other, for instance, when two EPC functions are linked to different roles. In this case, when we need to de- canonize such a model, the canonizer will create a new main pool and then include those two roles as lanes into that pool. As a result of that, the generated XPDL file would not specify which element is belong to which lane as the whole work flow process will be linked to the main pool only. To work around, there should a graphical algorithm to set up the produced model in order to position each element in its right place. Placing BPMN elements in their right lanes for native EPC models Currently, Oryx does not support the vertical pools and lanes, which is needed to conduct the work related to this issue, as the EPC model is most likely to be vertically designed. However, those are some rules that would be considered during the mapping process for such a situation: All the non- task elements would be placed in the same lane as their last predecessor task.

In case of many predecessor tasks placed in different lanes, such as an XOR join, the element would be placed in the first successor task lane. The elements that do not have any task as a predecessor, they would be placed in their task successor lane. In case of many, such as XOR split, they would be placed in the first successor task lane. The following example basically demonstrates those rules. Then, the resulted BPMN model would be: Linking nodes to lanes, and lanes to pools In relation to the previous issue, when canonizing XPDL model, there are no direct relations between the lanes and their correspondent element such as tasks and events. The workflow would be linked to the pool. That pool would have its lanes. Thus, we need to implement a way to figure out the relation between the elements and the lanes using the graphical information then representing those relations as references in those elements to

a resource type in the canonical format. In addition, those lanes that have been mapped to resource types would be linked to their mapped parent pool using the specialization feature in the canonical format. The implemented procedure will be such the following in case we face that issue: For each element in the XPDL { Get the graphical information For each Lane If the element coordinates within the lane graphical range Add reference to this mapped resource type; } Events types recognition In BPMN, there are many types of events. Some of those types are not supported by the canonical format such as start and end event. The canonizer deals with those events by checking out their incoming as well as outgoing transitions. It also sets the trigger or the result for that event based on its original type in the canonical format. Testing BPMN: some covered patterns Nu BPMN m Canonical 1 2

3 4 5 6

7 8 9 10 11

Mapping BPMN to EPC test cases N Tested BPMN Desired EPC model 3 2 1

6 5 4

9 8 7 Potential Improvement Due to the XPDL 2.1 schema, the representation of the lanes and their belonging elements would be only captured using the graphical data. Therefore, there should be an algorithm somehow in order to link each canonical element to its appropriate resource types by checking their graphical information. If the element is belong to the area that covered by that lane, then the element would be linked to the mapped resource type, otherwise not. Consequently, there should be another algorithm somehow to draw the lanes and the elements that belong to them properly when mapping from the canonical format to BPMN. Optimizing the exported graphical information needs more work in order to produce more understandable and nice looking models.

Conclusion To sum up, the canonization service is a major service within AProMoRe. It has been implemented with a significant amount of consideration to provide a sophisticated work in order to improve the quality and reliability of the project. The infrastructure of the service is extensible. It has been designed in such a way to allow further developments, further languages, and more covered patterns. The architecture of the canonization service has been kept under improvement during all the development phases. It also might need more explanation in order to be more adaptable for further development. So far, the service composed BPMN and EPC adapters. It also has many covered patterns and some of these patterns have been demonstrated via the provided test suit within the project. They can be used for maintaining the adapters quality and avoiding any possible regression during the development process. Further work might be conducted on the existing adapters by enhancing their ability to process the models interchange. In addition, more adapters are needed to cover the other modeling languages. References La Rosa, M and others. (2010). APROMORE: An Advanced Process Model Repository. Tscheschner, W. (d.a). Transforming from EPC to BPMN. Retrieved 1 Sep 2010 from http://bpt.hpi.uni-potsdam.de/pub/public/oryxresearch/transformepc2bpmn.pdf. Weske, M. (2007). Business Process Management: Concepts, Languages, Architectures. Springer Berlin Heidelberg New York.