An Architecture for Querying Business Process, Business Process Instances, and Business Data Models

An Architecture for Querying Business Process, Business Process Instances, and Business Data Models Mar´ıa Teresa G´omez-L´opez1, Antonia M. Reina Quintero1 , Luisa Parody1 ,Jose´Miguel P´erez ´Alvarez1 , and Manfred Reichert2 1Departamento de Lenguajes y Sistemas Inform´aticos, Universidad de Sevilla, Seville, Spain {maytegomez,reinaqu,lparody,josemi}@us.es 2Institute of Databases and Information Systems, Ulm University, Ulm, Germany [email protected] Abstract. Business data are usually managed by means of business processes during process instances. These viewpoints (business, instances and data) are strongly related because the life-cycle of business data objects need to be aligned with the business process and process instance models. However, current approaches do not provide a mechanism to integrate these three viewpoints nor to query them all together while maintaining the information in the distributed, heterogeneous systems where they have been created. In this paper, we propose the integration of the business process, business process instance, and business data models by using their metamodels and also an architecture to support this integration. The goal of this integration is to make the most of the three models and the technologies that support them in an isolated way. In our approach, it is not necessary to change the source data formats nor transforming them into a common one. Furthermore, the proposed architecture allows us to query the three models even though they come from three different technologies. Keywords: Business Data Model ·Business Process Model Business process instance model ·Model integration Heterogeneous data sources 1 Introduction The volume, variety and velocity of process-related data are growing drastically. Some of these data are created and managed by Business Process Management Systems (BPMS). A business process (BP for short) consists of a set of activities whose execution needs to be coordinated in an organisational and technical environment in order to achieve a particular business goal [24]. The coordinated execution of activities is a fundamental principle from the viewpoint of Business Process Management, and it provokes the change of data objects during process instantiation. In general, a BP can be implemented and operationalized by a BPMS. To make the most of the heterogeneous information provided by the different viewpoints (i.e., business process, business process instance and business data), it is necessary to integrate the different models and provide a mechanism to query them all together, since they are frequently supported by different technologies. Previous solutions based on semantic models [10]have provided mechanisms to create homogeneous data stores, using the information from heterogeneous sources. The problem of this type of approaches is that they go+ against the requirements established when there are a high volume, variety and velocity of data, as in Big Data scenarios, where the changeability and quantity of data make not possible transform the sources. For this reason, this paper proposes an architecture where process querying mechanisms are inspired in the Map-Reduce paradigm. Map-Reduce is a programming paradigm that allows for massive scalability across hundreds or thousands data nodes, and it lets: (1) divide the query into the subsystems that contain the data, and (2) merge the outputs of the distributed databases. In order to define how to divide the query and combine the obtained information, it is necessary to determine the relation between subsystems. We propose the use of metamodels and the combination of them. A metamodel defines a frame and a set of rules for creating models for a specific application domain. A viewpoint is defined in relation to one or more metamodels [9]. In our scenario, each viewpoint is supported by a metamodel that defines the main elements managed in each case and their relationships. In general, there exists a fundamental relation between the three models: Business Process Model (BPM), Business Process Instances Model (BPIM), and Business Data Model (BDM). Accordingly, it is not sufficient to query each of these models separately, but to provide integrated access to the process, data and instance perspectives. In particular, process-centric queries across these different viewpoints need to be enabled [4]. The insufficient understanding of the inherent relationships existing between business processes and business data is deficient [21]. As far as we know, existing querying approaches focus on one specific model type, but they do not exploit the information resulting from that integration. This paper shows how to integrate the BPM, BPIM, and BDM by means of a weaving model that makes explicit the relationships between the elements of the three models. As an example of a BP considers the organisation of a conference. The corresponding BP model is shown in Fig. 1. Three different pools cover the main functions needed to organize the conference, to submit a paper, and to register for the conference: (1) the first pool describes how to manage the conference organisation by the conference chair who is in charge of the conference requirements; (2) the second pool shows the submission process from the viewpoint of an author; (3) the third pool deals with the conference registration and related payment. Usually, the execution of a process instance is persisted in the database of the BPMS to which the BP is deployed. According to the framework proposed in [20], this situation corresponds to a process repository composed of simulation Fig. 1. Business processes for conference organisations Fig. 2. Conceptual model of the conference process models (see Def. 3.4 in [20]) This kind of information must follow the BP instance according to the used BPMS. Moreover, business data that flows through the process is persisted in a database. For the conference example, the corresponding conceptual data model is depicted in Fig. 2. It presents the entities involved in the conference process. A Conference is defined by its id,name,location,scope (e.g., “Software Engineering”, “Business Process Management”, or “Big Data”), start and end dates, and the date until which the early registration fee is valid. In turn, an author may submit several papers, which are going to be reviewed by the Program Committee that decides on the rating and status of the paper. Regarding the conference scenario, the three models (i.e., BPM, BPIM and BDM) play an important role in extracting relevant information about the business process. Examples of queries making use of the integration of these viewpoints are “Average of execution time of the conferences with scope Business Process ”, and “Evolution of the number of registrations variable for the process named ‘Conference Management Process’ of those conferences taking place in Barcelona”. In particular, this paper shows how the three models may be integrated to process such queries. The paper is organized as follows: Sect. 2introduces the metamodels related to the business process, business process instance and business data viewpoints as well as the metamodel that supports the integration of them all. After that, Sect. 3presents our proof-of-concept prototype. Section 4discusses related work. Finally, Sect. 5concludes the paper. 2 Business Viewpoints This section describes the metamodels covering the three viewpoints on a BP, i.e., BPM, BPIM, BDM as well as the metamodel used to integrate them all. Then, these metamodels are used to enable an integration of the viewpoints. A BP corresponds to a set of coordinated activities, carried out manually or automatically, to achieve a specific business goal. The metamodel for creating BP models is summarised in Sect. 2.1. In turn, the metamodel related to the process instance viewpoint is presented in Sect. 2.2. Finally, concerning to the data viewpoint, a simplified metamodel of Unified Modeling Language (UML) [15]is introduced in Sect. 2.3. In particular, a BP needs to control its data flow, which reflects the business data managed in the context of the BP and the way this data is transferred through the activities. In general, this process-related data can be described by a conceptual model which usually is defined using UML. In practice, the three models must be considered in an integrated way due to their many interdependencies; e.g., BP instances are related to a BP model, data entities are used to define the data flow of a BP, and the various BP instances create data objects or update the values of the data. 2.1 Viewpoint 1: Business Process Metamodel The main standard used to model business processes is the Business Process Model and Notation (BPMN) as proposed by OMG [14]. Besides other elements, BPMN 2.0 includes data objects, events of various types, and artefacts. Figure 3 introduces a simplified version of the BP metamodel (BPMM for short), which includes the main metaclasses used in this paper to model the BPs as well as their relationships and attributes. The root of the metamodel is BPMNProcess, which is composed of a set of BPMNElement.ABPMNElement, in turn, may be a Swimlane,a ConnectingObject,aFlowObject,andanArtifact. Note that these metaclasses are abstract. The concrete metaclasses are subtypes of these ones. Thus, a ConnectingObject may be a MessageFlow,aSequenceFlow, and an Association. Furthermore, there are three types of FlowObject: Event,Gateway and Activity. The three of them are also abstract metaclasses. An Event may be an InitialEvent,anIntermediateEvent, and a FinalEvent.AGateway may be a XOR,OR,andAND gateway. An Activity Fig. 3. Simplified business process metamodel may be a Task (also an abstract metaclass) or a Subprocess. There are different types of Task:ManualTask,ReceivedTask,SendTask,ScriptTask, ServiceTask,andUserTask. Note that the semantics of these metaclasses is exactly the specified by the BPMN2.0 standard and also that this metamodel is a simplified version of it. We refer interested readers to [14] for knowing the semantics of each metaclass. 2.2 Viewpoint 2: Business Process Instance Metamodel A business process instance represents a concrete case in the operational business of a company [24]. Figure 4shows our proposal of Business Process Instance Metamodel (BPIMM for short). ProcessEngine is the root of the metamodel and it represents the Business Process Management System (BPMS) that executes the BP. A BPMS may deploy various processes. Each process is described by means of the ProcessDefinition metaclass. Note that ProcessDefinition is related to a Business Process (cf. Sect. 2.1). ProcessInstance represents an execution of a specific process. Thus, a ProcessDefinition is related to a set of ProcessInstance. AProcessDefinition is composed of a sequence of Activity. Accordingly, a ProcessInstance is composed of a set of ActivityInstance (childActivities relation). There is also a parent-child relation between activities instances. The first activity that is instantiated during a process execution is an activity instance that has no parent. Finally, a set of Variable can be associated to a Process Instance. Note that BPIMM deals with concepts related to process execution and that the definition of processes included in many BPMSs usually has more properties of processes and activities than the standard BPMN 2.0. Having this into account, the ProcessDefinition and Activity metaclasses model these properties that are present in the execution environments. 2.3 Viewpoint 3: Business Data Metamodel In order to be able to create BDM, we use the OMG Metamodel to represent Conceptual Models introduced in Fig. 5, which includes the main entities of the Business Data metamodel (BDMM) presumed in this paper. Fig. 4. Business Process Instance Metamodel (BPIMM) Fig. 5. Simplified Business Data Metamodel (BDMM) The root entity is BMDiagram, which is composed of a set of ModelElement. AModelElement may be an AssociationEnd,aRelationship,a Classifier,aTypedElement,oraFeature. The entities of the system are mainly represented by a Classifier, either an Association,Class,or DataType. Furthermore, through the AssociationEnd and Relationship, Classifier entities are related. Note that an instance of this metamodel which depicts entities related to the organisation of a conference is presented in Fig. 2. 2.4 Integrating BPM, BPIM and BDM Business process, business process instance and business data metamodels represent different, but complementary, viewpoints of a business process. Linking entities across these metamodels is a must in order to exploit the information provided by their specific instances, i.e., their models. In this context, model weaving is a generic operation that establishes correspondences between model elements. The resulting weaving models are a special kind of models that link together other models. In general, weaving models contain a set of links between the elements of two different models [8]. A weaving model conforms to a weaving metamodel, which defines the kind of links that may be established between the elements of the woven models. Atlas Model Weaver (AMW) [8] is a tool that allows creating and handle weaving models and metamodels. New weaving metamodels should be implemented by extending a Core Weaving Metamodel that it is included and implemented in AMW. Thus, to define our integration metamodel we extend this Core Weaving Metamodel. Figure 6shows our extension (see the metaclasses with grey background colour), which specifies the semantics of the links between the elements of Business Process, Business Process Instance and Business Data models. These elements are specific instances of the corresponding metamodels (i.e., BPMM, BDMM, and BPIMM). Note that classes belonging to the core weaving metamodel are abstract, and are extended by metaclasses (the ones coloured in grey) that refine them by adding the semantics needed in the context of our scenario. An Integration Model can be seen as a kind of weaving model that let us integrate the three kinds of models (BPIM, BDM, and BPM). This integration model defines the relationships between the elements in the three models. Match is a kind of link representing the relation between two elements from different models. Figure 7shows how three instances (i.e., models) of BPIMM, BPMM and BDMM may be related by means of an instance of the Integration Metamodel. Classes with <<BPIM>> stereotype represent instances of Business Process Instance metaclasses, classes with <<BPM>> represent instances of Business Fig. 6. Integration metamodel Fig. 7. Integrated BPIM, BPM and BDM Process metaclasses, classes with <<BDM>> stereotype represent instances of Business Data metaclasses, and classes with <<IM>> represent instances of Integration metaclasses. Thus, the ConferenceManagement::BPMNProcess instance represents the process named Conference Management Process, as depicted in Fig. 1, whereas the instance ia1::ActivityInstance represents one execution of the activity that configures the Conference BPM17. 3 Architecture for Combined Queries Data combination is an important open problem in business intelligence, as explained in [20], where the authors propose a general, abstract framework for devising process querying methods. Our architecture, based on Map-Reduce paradigm, defines how the query is divided (Map), and the partial queries are combined (Reduce). Our proposal can be seen as an instance of the abstract framework presented in [20], in such a way that it includes a real combination of technologies that can be thought as the implementation of some of the generic functionalities described in the framework. Assume one wishes to know how many institutions are involved in the execution of each task, in a context where the BPMS BonitaTM, data are persisted in an Oracle database and the BPM is persisted by using Neo4J a query similar to the one shown in Listing 1should be executed: SELECT Task.id, COUNT(institution) FROM (Task FULL JOIN ActivityInstance FULL JOIN Person) GROUP BY Task.id WHERE Task.idProcess = idP Listing 1. Query example Note that obtain the query results, you need to query data related to the three viewpoints. In other words, you need information about Tasks from the BP viewpoint, information about Activity Instances from the BPI viewpoint, and information about Persons from the BD viewpoint. Note that to obtain this information we have to deal with three different technologies (Neo4J, Bonita, and Oracle, respectively). We propose a two-step process to execute the query aligned with Map-Reduce methods. The first step, data extraction, is the responsible for transforming the original query into a set of queries that are specific for each viewpoint. The second step, data integration, has as input the results of the previous queries and is the responsible for combining them. Figure 8shows the architecture that supports the two-steps query execution. The following sections give some details about these two steps. 3.1 Data Extraction In the data extraction step, the original query is transformed into three different queries, in order to query the three different viewpoints in an isolated way (see (1) in Fig. 8). The result of these specific queries (step 2) is a set of JSON files that will be combined in step (3). The interaction with the specific technology that supports each viewpoint (i.e., Neo4J, Bonita and Oracle) is in charge of drivers. Drivers are the components that deal with the platform specific features of each technology. In other words, drivers transform a generic query to a specific query on the respective data repository. Note that these three queries can be executed in parallel since each result is obtained from isolated databases. All drivers should implement the generic operation select. This select operation extracts a set with all of the objects of a given class that fulfil certain predicate. That is, every driver should implement an operation with a prototype similar to the following one: Set<T>select (Class<?>name, Predicate<T>pred). Thus, our original query (see Listing 1) is transformed into three select calls (one to obtain a set of tasks, another one to obtain a set of Activity Instances, and, finally, one to obtain a set of Persons) that will be executed by one driver each. The Neo4J Driver transforms the select operation into a Neo4J query to obtain the set of tasks of the process whose id is idP. The driver uses Spring Data and neo4j-ogm-bolt-driver to map the graph database into Java Objects. The Bonita Driver transforms the select operation into a set of calls to the Fig. 8. Combination of technologies for the architecture