A Mashup-based Framework for Business Process Compliance Checking

JOURNAL OF L A T EX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 1 A Mashup-based Framework for Business Process Compliance Checking Cristina Cabanillas, Manuel Resinas and Antonio Ruiz-Cortés Abstract—Business process compliance ensures that the business processes of an organisation are designed and executed according to the rules that enforce the compliance controls that govern the company. We faced the challenge of building a Business Process Compliance Management System (BPCMS) for a process-aware organisation that had to provide support for several needs that, despite having been identified in the literature, were only partially satisfied by existing approaches. The variability in the types of rules and their interpretation generally restricts the existing support for compliance checking to specific types of rules (e.g., rules affecting the control flow of the process), a specific phase of the business process management (BPM) lifecycle (e.g., design time or run time), or certain information systems (ISs) for data retrieval (e.g., process event logs). Motivated by this, we designed a conceptual framework for design-time and run-time compliance checking that relies on the use of mashups for rule specification and checking. It presents the following advantages: (i) an open-ended set of types rules can be specified by designing and connecting mashup components; (ii) (parts of) the definitions of the rules can be reused as needed; and (iii) the mashup-based compliance checking (MCC) system can be integrated with ISs of the organisation, enabling the verification of actual facts on actions performed during the execution of a process (e.g., the existence of a specific document in a concrete location). Design-time and run-time implementations of the framework were conducted and tested in a real setting. Index Terms—Business process compliance, business process management, compliance checking, compliance framework, mashups F 1 INTRODUCTION BUSINESS process compliance ensures that the business processes of an organisation are designed and executed according to the regulations and internal policies that govern the company. Based on these regulations and internal policies a set of compliance controls1, which must be observed by the organisation, can be defined. An example of compliance control is “On a quarterly basis, a tax completion checklist is used and signed by the Tax Manager and the Financial Controller” (CC1). Each compliance control can be further decomposed into a set of compliance rules or constraints2[1], [2]. These rules are specific checks that must be carried out in order to evaluate whether the control is being fulfilled. Therefore, rules specify how controls can be materialised in the context of the business processes and the Information Systems (ISs) of an organisation. Compliance rules relate to different aspects of a process (a.k.a. business process perspectives), such as the execution order of the activities (control flow or behavioural perspective); the data accessed and produced (informational perspective); or the people (human resources or just resources) that participate in the process (organisational perspective). For instance, CC1 could be materialised in a rule like “Every four months, it is necessary to check whether a new document has been uploaded to the Document Management System (DMS) that contains the checklist completed and signed by the Tax •Cristina Cabanillas was with the Institute for Information Business, Vienna University of Economics and Business, 1020 Vienna, Austria. •Cristina Cabanillas, Manuel Resinas and Antonio Ruiz-Cortés are currently with the University of Seville, 41012 Seville, Spain. E-mails: [email protected], [email protected], [email protected] Manuscript received in August 2019; revised in –, 2020. 1. By compliance we always refer to business process compliance. 2. We will use rule,compliance rule and constraint interchangeably. Manager and the Financial Controller” (CR1). Compliance rules can be checked at different phases of the Business Process Management (BPM) lifecycle [3], which results in two big modalities [4]. On the one hand, forward or pre-mortem compliance checking is the most proactive way to check compliance and comprises design time and run time. Design-time compliance checking is usually performed after process modelling to ensure that the process is compliant with the given rules before its execution, saving time and effort to business analysts. Run-time compliance checking (a.k.a. compliance monitoring or online auditing [5]) assesses rules at run time using data stored in the ISs of the organisation, so if a rule is violated or some problematic situation arises while running the process we might be able to solve the problem in time to avoid ending in a non-compliant state. On the other hand, backward or post-mortem compliance checking (a.k.a. offline auditing [5]) determines whether past instances of a process were compliant with rules from data stored in the ISs of the organisation. The result helps stakeholders to be prepared for potential future audits. The complexity of checking business process compliance has been acknowledged in the literature [6], [7]. In this paper we introduce a conceptual framework for forward compliance checking that, besides supporting most of the Compliance Monitoring Funcionalities (CMFs) identified and addressed in the literature [5], tackles the needs encountered when building and deploying a fullyfledged Business Process Compliance Management System (BPCMS) [8] in a real organisation. These needs, related to the heterogeneity of the ISs and the number and variability of compliance rules, can be covered if three requirements are met. The fact that the requirements have also been identified and partially addressed in the literature as we discuss next shows that their interest goes beyond a particular case. JOURNAL OF L A T EX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 2 Requirement 1 (Req 1). Seamless integration with enterprise ISs. Several authors have already identified the need for compliance systems to obtain and integrate the required data from heterogeneous data sources [7], [9], [10]. Based on this observation, Giblin et al. identify the challenge of managing compliance rules in such distributed and heterogeneous IT environments [10], and Sadiq and Governatori highlight that integration technologies can be helpful in that regard [7]. This heterogeneity of sources is particularly relevant because approaches that assume homogeneous data sources may not be well suited for these scenarios. For instance, many proposals [11] consider as a unique data source the event logs of the process which, in turn, must be very complete in order to enable doing checks on the different process perspectives. However, in some cases, a direct evaluation of a system or database state may be more useful. This holds in cases in which it is inefficient to transform all data necessary to check the compliance rules into events [10] either because of the complexity of the transformation or because it might not be reasonable to include some required information in the log (e.g., when the check involves querying the content of a document). Requirement 2 (Req 2). Support for an open-ended set of types of rules at design time and at run time. A compliance system must be able to specify and check rules regardless of the phase of the BPM lifecycle in which compliance is checked [12] and the business process perspectives involved. The challenge is that each business process perspective includes many types of rules [5]. This variability [4] leads to consider that supporting several formalisms for expressing rules is a desirable feature for frameworks. Moreover, even for the same type of rule, the system must provide the ability to fine tune its meaning. For instance, a well-known type of compliance rule is the separation of duties. While it is typically implemented to prevent the same person from performing two specific tasks of a process, under certain circumstances it is extended to enforce that the two people involved must also have different roles [5], [13]. Therefore, it is convenient to have a system that is not closed as to the types of rules that can be defined in it and the formalism used to check them. Requirement 3 (Req 3). Rule specification reuse. The importance of compliance rule specification reuse has already been identified in several proposals [1], [12], [14]. All of them provide evidence on the existence of a high similarity between some compliance rules and the convenience of having a mechanism that enables reusing their specification instead of having to redefine them from scratch. This would help to save effort since only the adaptation to the business process at hand would be necessary [10], [14]. Research proposals have mostly focused on developing specific techniques for compliance checking, tending to disregard (some of) these 3 requirements. Moreover, assumptions usually made in terms of the required input data or the formalism used limit their ability to be extended to consider them. Exceptions to this are frameworks like [2], [15], [16], [17], [18] that focus on the problem of implementing a general architecture or infrastructure for compliance checking. However, as we discuss in Section 2, in the best case, they only partially address some of these requirements, which may limit their applicability in scenarios with high IS heterogeneity and a large variety of compliance rules. Our proposal is related to such existing frameworks as we do not develop a new specific technique for compliance checking. We propose to use mashups [19] as a means to provide a homogeneous framework to specify rules and check design-time and run-time business process compliance, and we present an implementation of the framework that has been applied in a real setting within an R&D project. Mashups are easy to understand and use [20], and they can be implemented in many ways (e.g., by using spreadsheets [21]). Different formalisms can be combined in a single mashup provided that there is a way to connect the information resulting from a technique with the input required by another approach3. That enables their use to support an open-ended set of types of rules by integrating techniques of different nature (Req 2). Mashups offer flexibility, portability and reusability [19] so (part of) already defined rules can be saved and used to build other mashups (Req 3). The fact that mashups are designed for information integration (Req 1) and that they have already been used for analysis purposes in other domains [22], [23] motivated us to explore their applicability to check compliance rules. Throughout this paper we will describe how our approach addresses the 3 requirements as well as a methodology to use it. The framework has been validated with a detailed comparison to similar frameworks and by using it on real data. The rest of the paper is structured as follows. Section 2 examines the state of the art on compliance checking, especially on compliance frameworks. Section 3 describes our mashup-based framework for forward compliance checking and exemplifies its use with a running example. Section 4 introduces a methodology for the use of the framework. Section 5 reports on our experience when applying it on real data. Finally, Section 6 presents the conclusions drawn from this work and outlines potential future work. 2 RELATED WORK A conceptual model of compliance checking similar to other conceptual models [1], [2] is depicted in Figure 1. A Compliance Source (e.g., a Regulation or an Internal Policy) defines a set of Compliance Controls that must be observed by the organisation. The compliance controls are not necessarily specific to a compliance source but may be shared by several of them. When the compliance sources are abstract, a consultant company is usually hired to define the compliance controls that apply to the organisation. Each control can be further decomposed into a set of Rules that specify how the controls can be materialised. This is usually dependent on the ISs used. For example, the rule CR1 (cf. Section 1) would be defined differently if the checklist was created in a dedicated IS instead of being a document uploaded to a DMS. At design time, rules are assessed once for the whole process (e.g., one could check whether the organisation has a document specifying its security policies) but at run time, rules have to be assessed for each process instance (e.g., one could check that a given action has been recorded in an IS for each instance of the change request process). Moreover, rules have a Process Context in which they apply. 3. The complexity of a mashup lies within each component, and the greatest effort is put into how to integrate them. JOURNAL OF L A T EX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 3 Compliance Source Compliance Control 1..* define Regulation Internal policy Rule decomposed into 1..* Evidence 0..1 design-time Compliance mashup 0..1 run-time 1 applies to Process context Geographic region Business unit ... ... 0..* proves refers to 1 Business process Context 0..* Fig. 1: Conceptual model of compliance checking This includes the Business Process to which the rule refers and an optional Context within that process like a specific geographic region or a certain business unit of the company. Finally, there must be Evidences, like documents or log traces, that prove that the rules are being fulfilled (for CR1, the evidence would be the document uploaded to the DMS). The main approaches addressing business process compliance checking up to 2010 were analysed according to several criteria in [24]. Later, Ly et al. derived 10 CMFs from a systematic literature review and several case studies in [5], which can be used as an evaluation framework of compliance checking approaches. The CMFs are divided into 3 groups: the CMFs on modelling requirements refer to the ability to deal with constraints that address aspects beyond control flow and they include constraints referring to time (CMF 1), constraints referring to data (CMF 2) and constraints referring to resources (CMF 3); the CMFs on execution requirements refer to requirements imposed by the execution domain in which compliance checking is performed and they include supporting non-atomic activities (CMF 4), supporting activity life cycles (CMF 5) and supporting multiple instances constraints (CMF 6); lastly, the CMFs on user requirements refer to aspects that improve the user experience and they include the ability to reactively detect and manage violations (CMF 7), the ability to pro-actively detect and manage violations (CMF 8), the ability to explain the root cause of a violation (CMF 9) and the ability to quantify the degree of compliance (CMF 10). Ly et al. also classified compliance monitoring approaches into 5 categories [5]. One category includes core compliance approaches, which provide specific techniques for compliance checking with limited scopes. Most research efforts lie in this category. Regarding design-time compliance checking, many solutions separately model the business process and the rules, convert the 2 models into formal representations and apply model-checking algorithms to assess the degree of compliance [25], [26], [27]. These approaches especially focus on control-flow constraints and usually show the violations with counterexamples. Patterns are sometimes used either to simplify rule modelling or to facilitate compliance checking in scenarios that often recur [25], [27], [28]. Consequently, new pattern-based languages have been designed for the purpose of defining rules, such as PENELOPE [29] and BPMN-Q [27]. Other approaches annotate the process models using different formalisms for rule definition and analyse the annotated models for compliance checking [30], [31]. As far as run-time compliance checking is concerned, a detailed classification of approaches can be found in [5], including MobuconEC [32], which supports the monitoring of temporal and data constraints (among others) based on Event Calculus; MobuconLTL [33], which can monitor any rule that can be expressed in Linear Temporal Logic (LTL); and Seaflows [11], which uses Compliance Rule Graphs (CRGs) to monitor a stream of events encoded in a predefined format. Another category of compliance checking approaches [5] includes enabling technologies like Complex Event Processing (CEP) or conformance checking. CEP can be very useful at run time in systems with a large amount of events and near real-time requirements but it cannot be used for design-time compliance checking. Moreover, having as input a stream of events prevents the execution of some checks, such as the verification of the content of a document. Concerning conformance checking, it differs from compliance checking especially in the fact that it involves checking the log against a complete process model instead of compliance rules. The 3 categories that have received the least attention so far include, respectively: approaches that collect compliance patterns [34], [35], whose goal is to understand and categorise the different types of compliance rules that may exist, regardless of how to automate them; approaches for specific domains like healthcare [36]; and frameworks that provide general architectures or infrastructures for compliance checking [2], [16], [17], [18], [37]. The latter category is the most closely related to our work. We have found 5 frameworks that can be compared to ours. Next, we explain how the specifications of these frameworks support our 3 pursued requirements as well as the 10 CMFs. Table 1 collects the results of the evaluation. In it, + means that the feature is fully supported, +/−means that it is partially supported, −means that it is not supported, and n.a. means that the criterion is not applicable (e.g., CMFs 4-8 are not applicable at design time). Note two considerations beforehand: (i) there are several reasons for a partial support of Req 2, as explicitly explained for each approach; and (ii) beyond being able to use exactly the same rule definition several times by copy-pasting it, Req 3 involves configurability (i.e., a definition can be adapted to be reused for different rules - e.g., by means of parameterisation). The EU FP7 project COMPAS [37] worked on the development of an integrated solution for compliance checking [15], resulting in a framework for process monitoring based on CEP techniques. Three Domain Specific Languages (DSLs) were developed to define rules in 3 specific domains, and the processes were modelled with the View-based Modelling Framework (VbMF) [38]. The DSLs support controlflow, temporal and data-based rules, and their extensibility capabilities allow supporting the organisational perspective using the Role-Based Access Control (RBAC) model [39] (CMFs 1-3). The CEP engine is capable of aggregating and correlating low-level streams of events, so non-atomic activities can also be handled (CMF 4). We believe that dealing with activity lifecycles and multi-instance constraints is also possible thanks to CEP but we could not find evidence of such support in the COMPAS literature, so we consider JOURNAL OF L A T EX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 4 Req 1 Req 2 Req 3 CMF 1 CMF 2 CMF 3 CMF 4 CMF 5 CMF 6 CMF 7 CMF 8 CMF 9 CMF 10 Approach integration variability reuse time data resources non-atomic lifecycle multi-inst. reactive pro-active root cause degree COMPAS [15] +/−+/−+/−+++++/−+/−+−+ + Awad et al. [16] +/−+/−n.a. +++++++− − − eCRG [17] +/−+/−++++++++++ + OPAL [18] − − + + − − n.a. n.a. n.a. n.a. n.a. +− Schumm et al. [2] −+/−+ + + + n.a. n.a. n.a. n.a. n.a. +− Our framework + + + + + + + + + + −+/−+ TABLE 1: Requirements and CMFs supported by current compliance management frameworks those functionalities partially covered (CMFs 5 and 6). CEP also enables continuous monitoring and early detection of compliance violations (CMF 7) but violation prediction is not a goal of the framework (CMF 8). Carefully designed Compliance Governance Dashboards (CGDs) [40] show many details of the compliance status (CMFs 9 and 10). As for our requirements, the framework checks compliance only at run time so Req 2 is partially supported. The DSLs are template-based, hence rule definition adaptation is enabled by customising the placeholders in the templates. However, each language is inherently linked to a domain, which hinders the actual reuse of the rule definitions outside a limited scope. Consequently, we consider this provides partial support for Req 3. The framework takes data from event logs and relies on the Esper engine for CEP but it does not communicate with other systems of the organisation. Req 1 is thus also partially supported. Awad et al. introduced a framework for instant business process monitoring [16] that also makes use of CEP technologies taking into account the control flow, temporal constraints, data and resources (CMFs 1-3) and leveraging CEP advantages for considering non-atomic activities (CMF 4) divided into states (CMF 5) as well as multiple process instances executions (CMF 6). When a violation is detected, a recovery action is triggered in order to enforce compliance (CMF 7). Violation prediction and reasoning on detected violations are not addressed in the framework (CMFs 8- 10). Req 2 is partially covered because design-time aspects are disregarded. The authors suggest using Semantics of Business Vocabulary and Business Rules (SBVR) for rule definition but the framework does not enforce a specific compliance rule language so it cannot be properly evaluated against Req 3. Finally, the framework integrates with the IT infrastructure that enacts the processes as well as with the event logs and the CEP engine but is not flexible enough to interact with other systems, partially supporting Req 1. Knuplesch et al. developed a framework for visually monitoring business process compliance once the CMFs had been defined, targeting and addressing them all as described in [17]. The framework relies on the Extended Compliance Rule Graph (eCRG) language, an expressive graphical notation that enables the reuse of rule definitions (Req 3). Compliance checking is only done at run time (Req 2) with ad-hoc algorithms that assume that all the required input data are available in event logs. Therefore, the integration with further ISs of the organisation is not addressed (Req 1). Unlike the previous approaches, the OPAL framework [18] targets design-time compliance checking. Business processes and rules are modelled with Business Process Execution Language (BPEL) and Business Property Specification Language (BPSL), respectively. These models are transformed to finite state machines and LTL, respectively, and a model-checking technique is used to find rule violations, which are shown to the user with counterexamples on the BPEL model (CMF 9). As BPSL allows the definition of Domain-Specific (DS) templates with configuration parameters, these can be reused for compliance rule definition (Req 3). However, the specification of constraints related to data and resources is part of the envisioned future work (CMFs 2 and 3). Because of this limitation and the restriction to design time, we consider Req 2 not to have been addressed. The integration with different process modelling tools and model-checking engines is possible but the framework does not access ISs of the organisation (Req 1). Lastly, Schumm et al. developed a framework for modelling business processes that are likely to be compliant by design thanks to the reuse of compliance fragments (i.e., process fragments that are known to be compliant with specific rules) [2]. Process fragments modelled with Business Process Model and Notation (BPMN), BPEL or Unified Modeling Language (UML) are then formally represented in Reo [41]. LTL is preferred for rule definition, and controlflow, temporal, data and resource-aware constraints can be enforced (CMFs 1-3). However, Req 2 is only partially supported because run-time aspects are disregarded. A set of parameterised compliance patterns are specified for recurring rules, enabling rule definition reuse (Req 3). Model-checking tools are suggested for compliance checking so, like before, the counterexamples generated can help to understand the cause of the violations (CMF 9). Similarly to the OPAL framework, the integration with different process modelling tools and model-checking engines is possible but the framework does not access ISs of the company (Req 1). The main difference between those approaches and our mashup-based framework is that we put specific emphasis on satisfying real needs that appear in industrial settings in which data are distributed among several heterogeneous systems (Req 1) and the large variety of rules urge putting in place configuration means that enable rule definition adaptation and reuse (Req 3). Furthermore, our framework supports design-time and run-time compliance checking and provides explicit mechanisms to add an open-ended set of checks (Req 2). Using appropriate formalisms, CMFs 1 to 6 could be supported thanks to the ability of the framework JOURNAL OF L A T EX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 5 to use different formalisms (cf. Section 3.3.1). CMFs 7, 9 and 10 could be supported based on an MCC system with our implementation of the BPCMS as described in Section 5.3. Violation prediction (CMF 8) cannot currently be supported. 3 MASHUP-BASED COMPLIANCE CHECKING We call compliance mashups the mashups used for the purpose of compliance checking. As depicted in Figure 1, they are used to provide a way to automate the checking of a compliance rule at design time and/or run time. Although several alternative compliance mashups may exist to check the same compliance rule, one of them has to be selected to implement the checking of the rule. If no mashup is selected, the rule will not be automatically checked. 3.1 Preliminaries: Fundamentals of Mashups A mashup is a data-driven workflow (a.k.a. data flow) built with information from one or more data sources that might be transformed and propagated to produce a desired output in a reusable User Interface (UI) [19]. Mashups were developed to build new Web services or applications from existing data in an “easy” way, such that the end user did not need to have specific technical knowledge but only knowledge on the problem domain [20]. The original concept of Web mashup has evolved towards data mashup (for short mashup) and has already been used to address problems in a variety of domains, such as the analysis of molecular biology in bio-informatics [22] and the simplification of patient management in hospitals [23]. Intel Mash Maker, Yahoo! Pipes (now Pipes), IBM Mashup Center and Google Mashup Editor emerged as the first mashup builders to bring this technology to the end users. More recent and specialised mashup Application Programming Interfaces (APIs) can be found at www.programmableweb.com/category/mashups. To show mashup appearance and use we have created the mashup in Figure 2. It returns the last 25 international pieces of news of 2 digital newspapers. Researchers could be interested in having a similar mashup in order to be kept up to date about their research interests (e.g., a mashup that automatically places on a map the venue cities where the next editions of their favourite conferences will take place). As illustrated in the figure, mashup editors allow the definition of the dataflow with 4 types of components. Data sources provide the information that shall be processed in the mashup and they range from data warehouses to Uniform Resource Locators (URLs) pointing at Really Simple Syndication (RSS) feeds or any kind of accessible data. The data sources in Figure 2 are the RSS feeds of the New York Times and The Australian newspapers. Pipes are the elements in charge of operating on data, so they all have inputs and outputs that represent the streams of data going in and out of the pipe, respectively. The input data they receive can come from another pipe component or from a data source, whereas the output data stream they produce can go to another pipe or constitute the output of the mashup to the UI. Finally, data flows represent the connections between pipes, data sources and the UI in a mashup. Pipes can be General-Purpose (GP) components like those that handle collections of elements to sort or merge UI (output) News1, News2, … News40 getNews() OPERATOR subset(25) FILTER The Australian New York Times getNews() OPERATOR union() AGGREGATOR delDuplicates() OPERATOR sortByDate() SORTER N1, N2, … N63 News1, …, News 40, N1, …, N63 News1, …, News 40, N1, …, N63 News31, N20, N5, N49, News2, News26, N50, … N7 News31, N20, N5, N49, News2, News26, N50, … News14 Legend Data source Data flow Pipe UI Fig. 2: Mashup collecting the last 25 worldwide pieces of news from 2 digital newspapers them; and DS components that implement functions specific to the problem domain (e.g., handling geolocation data to enrich Google Maps with external information). Some frequently used pipes include operators, aggregators, sorters and filters. Operators extract, elaborate and transform the data, constituting a crucial part of the Extract-Transform- Load (ETL) process [42] from the input data source(s) to the output UI. They range from GP operators that implement well-known functions like count,min and max, to DS operators that, for instance, handle strings or extract and build geolocation information. In Figure 2, the operator getNews() extracts entries from an RSS feed, and delDuplicates() removes redundant entries from a set. Aggregators merge or group data according to some criteria. In Figure 2, union() merges entries from 2 sets into 1 set. Sorters return the input data in a specific order. In Figure 2, sortByDate() orders the entries in the input set by the value of the field date.Filters narrow down the flow of data, supporting the transformation of the information. In Figure 2, the pipe subset(25) retains only 25 items of the input set. 3.2 A Metamodel for Building Compliance Mashups Each mashup framework, tool or specification proposes a slightly different mashup metamodel. Figure 3 depicts a metamodel that includes all the elements that are necessary for building compliance mashups. A mashup is composed of Nodes (which can be Data Sources and Pipes) and Data Flows, with the same meaning as defined in Section 3.1. The pipes and data sources used are referred to by their name and are chosen from a catalogue of Pipe Components and Data Source Components, respectively. The characteristics of the input and output data streams of the components JOURNAL OF L A T EX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 6 Mashup + name: String Parameter + name: String + type: Any ParameterBinding + value [0..1]: Any Pipe DataSource NodeDataFlow Composite Pipe + scope: {stream, element} Connector + name: String + type: Any + cardinality: Integer + streamSize: Integer 1..* 0..* 1 target inputs 1 0..* source outputs 0..* exposedAs 0..1 1 refersTo 1 isOfType 1..* output 1..* 1..* inputs 1 isOfType 0..* Component + name: String 0..* Pipe Component Data Source Component 1..* 1..* Fig. 3: Metamodel for building compliance mashups andParameter() : returns true iff all the inputs are true AGGREGATOR n bool 1 bool and() : returns true iff all the inputs are true AGGREGATOR n bool implies() : returns true iff p0 implies p1 OPERATOR n bool loop(Pipe) : applies the pipe Pipe sep. to every element OPERATOR n any n any lesserThan() : returns false iff p0 >= p1 OPERATOR n bool n any toSet(String[]) : returns all the input values in a flat set AGGREGATOR n String 1 String[] filter(Filter) : removes the inputs for which Filter = true FILTER n any m any Pipe copySplit() : copies the inputs to several output pipes OPERATOR Filter n (bool) n (bool) … n (any) n (any) … n (bool) n (bool) p0 p1 n (int) n (int) p0 p1 Fig. 4: Example GP pipe components are defined by means of Connectors. Each connector has a name, a type that specifies the type of the data carried in the data stream, a cardinality that indicates the number of streams that go through the connector, and a stream size that indicates the expected number of elements in each of the data streams. The stream size of most connectors is n, meaning that they can carry data streams of any length. However, some connectors may have a stream size of 1 (e.g., a connector to specify the output of a component that counts the number of elements received in its input stream). Connectors are also used to specify the characteristics of the output streams of data source components. Figure 4 shows several pipe components that can be used in a compliance mashup. Each pipe is represented COMPOSITE copySplit() OPERATOR actualPerformer(a2, “complete”) OPERATOR trace1, trace2,, … Alex, Lydia, … actualPerformer(a1, “complete”) OPERATOR samePerson() OPERATOR true, false, … a1=“CreateResolutionProposal” a2=“AnalyseReports” Alex, NaN, …trace1, trace2,, … n trace n bool Fig. 5: Composite pipe to check binding of duties at run time with a box that includes the pipe type, its name and a small description of its functionality. The connectors that specify their inputs and outputs are the arrows going in and out of the box, respectively, and their stream size and type are specified above or under the arrow. Tags (pi) are used in pipes in which the input order matters (e.g., lesserThan()). Pipes and data sources may have Parameters to customise their behaviour (e.g., one can have a generic filter pipe whose filtering condition is specified by means of a parameter). In Figure 4 the parameters are specified as lollipops at the bottom of the box. Mashups must include a Parameter Binding for the parameterised components. These parameter bindings either provide specific values for pipes and data sources or expose those parameters as parameters of the mashup itself. This allows the external configuration of the mashup and hence, enables the reuse of mashups in different scenarios. Concerning composite pipes, they are a special type of pipe component aimed at creating new higher-level pipes based on the composition of lower-level pipe components. They are useful because of two reasons: (1) they enable abstraction, making complex mashups easier to understand; and (2) they facilitate the reuse of a complex structure of pipes in different mashups. Like mashups, a composite pipe groups several pipes connected with data flows and includes parameter bindings for the parameterised pipes it contains. However, unlike mashups, composite pipes cannot contain any data source. Instead, their inputs and outputs are determined by the pipes contained in them that do not have any input or output data flow, respectively. Finally, the scope of a composite pipe can be of type stream or element. In composite pipes whose scope is of type stream, the input is processed as a whole and their behaviour is the same as if their components were used in the mashup directly. In case of a scope of type element, the composition is applied to each element in the input stream separately (one by one). Graphically, the latter composite pipes have the component name surrounded by a threewaves symbol. To showcase the difference let us suppose that we have a composite pipe that contains just one pipe component that counts the number of elements received in the input data stream. If the scope of the composite pipe is of type stream and its input stream contains 5 elements, then its output stream contains just one element: the number 5. Instead, if the scope is of type element, its output stream contains 5 elements, each of them being the number 1. An example of a composite pipe with a scope of type JOURNAL OF L A T EX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 7 element is depicted in Figure 5. It receives nexecutions of a business process (traces) as input and 2 specific activities that are needed to perform the checks as parameters. The copySplit() operator copies the stream into 2 output flows, each of which serves as input of an actualPerformer(act,state) operator. This operator returns the resource allocated to activity act when the activity reached the state state for every trace4. The samePerson() operator checks whether the items in the 2 input streams are the same on a 1:1 basis, returning a stream of boolean values that is the output of the composite pipe. The true values indicate a binding of duties between the 2 given activities of the business process, meaning that they were allocated to the same resource [43]. In short, a metamodel suitable for building compliance mashups must include (i) mechanisms to enable the reuse of (parts of) mashups (i.e., composite pipes and parameters); and (ii) the ability to define the scope of a composite pipe to cover streams (useful at design time to provide a global evaluation of the rule) and elements (useful at run time to provide an evaluation of the rule for each process instance). 3.3 Compliance Mashups in Practice To illustrate the use of compliance mashups in practice, we use a real process frequently utilised in the Andalusian Public Administration (APA), which serves to more than 8 million end users. The process represents the procedure to create and process a resource resolution proposal for hiring people. Figure 6 shows its BPMN model. Once a resource resolution proposal is created at the Management Department (MD), it is concurrently evaluated by the Consultative Board (CB) and the Legal Department (LD). When both evaluations are finished, the MD analyses the generated reports and decides whether an external resolution is required. In case it is, a request is sent to an external committee, which must create and send a new resolution. Otherwise, the resolution proposal is reviewed and changes are applied to the initial document. In any case, the final resolution is signed and archived, and the result is appropriately notified. Figure 7 depicts the excerpt of the organisational model related to the process, which comprises 3 organisational units and 8 positions within them occupied by 11 people5. The positions are hierarchically structured. Figure 6 also illustrates the position-based resource assignments of the process activities. The assignment of several positions to an activity means that the resources occupying any of them can execute it (e.g., activity Review resolution proposal can be done by a technician of any of the 3 units). More complex assignments have been omitted in the figure for the sake of readability. Specifically, there is a binding of duties between Create resolution proposal and Analyse reports indicating that these activities must be executed by the same resource. Several approaches could be used to define such constraints, either textually (e.g., [43]) or graphically (e.g., [44]). As part of the compliance controls that affect this process, the Business Manager of the MD (the process owner) needs to know whether the following rule is met: “If the resolution proposal has been created and the respective 4. NaN is used for any undefined value. 5. Their names have been changed for privacy reasons. reports from the CB and the LD are available, then such reports must be eventually analysed by the same person who created the resolution proposal” (CR2). This rule involves checks related to several process perspectives, specifically: (i) that specific data objects (Report CB and Report LD) are created (informational perspective); (ii) that one activity (Analyse reports) is executed when certain conditions are met (in this case eventually after the execution of Create resolution proposal and the activities writing the two data objects) – behavioural perspective; and (iii) that the binding of duties between two activities (Create resolution proposal and Analyse reports) is fulfilled (organisational perspective). Next, we detail the considerations for the design of the mashup components and the mashups themselves to check CR2 at design time (Figure 8) and at run time (Figure 9). 3.3.1 Designing the Mashup Components In a compliance mashup, the data sources access the repositories and ISs where the organisation stores data that is relevant to the evidences. Examples of data sources that may exist are the repositories where business process, organisation and data models are stored; the DMS of the company necessary to check which documents have been created; or the Enterprise Resource Planning (ERP) system that provides access to financial information6. In our example, we are checking the compliance of a resource-aware process model (i.e., a model enriched with resource assignments) at design time, and a set of running process instances at run time. Therefore, the data sources are a repository of business process models and a log of running process instances. Regarding the pipe components, GP and DS pipes might be necessary to manipulate the data coming from the data sources. Figure 4 depicts representative examples of GP pipes. More GP pipes can be found in mashup development frameworks, tools and specifications [19], [20], [21]. The set of available DS pipes depends on the kinds of checks to be performed in a specific domain. Some might be specific to one organisation or even to a process and cannot be reused (e.g., a pipe that parses an ad-hoc document to retrieve the subprojects contained in one particular project). However, many DS pipes can be reused in different processes and/or organisations. For instance, one may have DS pipes that implement operations on BPMN models, such as obtaining all the activities defined in a process or all the resources assigned to an activity; or operations to deal with event logs, such as checking for precedence between 2 activities. The DS pipe components can be implemented in an adhoc manner or encapsulate existing solutions (cf. Section 2). If an existing technique is going to be encapsulated, the granularity of each pipe must be decided. One could have a coarse-grained pipe that encapsulates the whole technique (e.g., a MobuconLTL [33] component that uses an LTL specification as a parameter to check the LTL formula against the process instances in an event log); or several fine-grained pipes that implement specific steps (e.g., use MobuconLTL to implement several fine-grained pipes that carry out different checks that usually appear while monitoring the compliance of event logs, such as the occurrence 6. Note that the data sources do not need to provide access to the whole ERP system but they can be as specific as necessary. JOURNAL OF L A T EX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 8 Hacienda Process w/ Resources APA APA Resolution needed Create resolution proposal Review resolution proposal Analyse reports Resolution Generate consultative report Generate legal report External resolution required? External resolution received Resolution Resolution Proposal Resolution Proposal Request external resolution Report CB Report LD Sign, store and notify resolution Resolution produced Data warehouse Tech. MD [Position] Tech. MD [Position] Tech. CB [Position] Tech. LD [Position] Secretary MD [Position] Secretary [Position] Assistant CB [Position] Assistant LD [Position] EXTERNAL COMMITTEE No Yes Fig. 6: Simplified version of the process to generate a resource resolution proposal Hacienda OM Technician of the Management Department Technician of the Legal Department Technician of the Consultative Board Secretary of the Management Department Assistant of the Legal Department Assistant of the Management Department Assistant of the Consultative Board Alex Lydia Carol Samuel Anna Daniel Chris Diana Lucas David Business Manager Mario MD LD CB Fig. 7: Excerpt of the organisational model of the APA and co-occurrence of activities, or the ordering of execution between activities; in this case, the parameters of the pipe would be the activities instead of a whole LTL specification). The choice between using coarse-grained or fine-grained pipes depends on several factors. Coarse-grained pipes have the advantage of being able to exploit the logic languages in which they are usually built to optimise or reason about the checks in a manner that cannot be done if the logic of the compliance check is in the mashup. Instead, finegrained pipes have the advantage of making the logic of the compliance check more explicit in the mashup and allowing combining different techniques to implement the compliance checks. For instance, data-based checks could be implemented using [32], whereas temporal checks could be implemented using [11]. An example of this can be found in Figure 8, which combines one technique for checking resource assignments (bodDT(om,a1,a2)) with another for checking control-flow constraints (alwaysFollows(bp,a2)). Moreover, fine-grained pipes are also useful if the same type of check is used in many mashups since it avoids that the same customisation be spread through several mashups. Finally, besides combining different techniques, DS pipes can also be used to seamlessly integrate data from different ISs. For instance, if some data are not stored in the event log but in a document saved in a DMS, one could implement a pipe (or a composite pipe) that extracts the name of the document from the log, retrieves it from the DMS and checks its content. Figure 9 shows an example of this with components getUrl(D[1]),getDocument(), and lastModified(). 3.3.2 Composing the Compliance Mashup Using 1 data source, 3 GP pipes and 4 DS pipes, and receiving the ID of the resource-aware business process model to be checked (bp), the organisational model associated with the process (om), two activities (a1 and a2) and a set of data objects (D) as input parameters, the check of CR2 at design time can be done in the following steps (cf. Figure 8): 1) The model of the business process bp is extracted from the repository of business process models and copied into several streams to be processed by different pipes. 2) The activities of the process that write the input data objects are identified in the model since, according to CR2, both the activity a1 and these activities must be finished in order to check the rest of constraints. The second parameter of the writes(D,any) pipe used for this purpose indicates whether the activities that write any or all the data objects Dare selected. 3) A set is then created with the activities previously identified plus a1. 4) The next step is to check that the input activity a2 always follows the activities in that set as defined in the model bp. The result of that check is a boolean value. 5) The last constraint to be satisfied is the binding of duties between a1 and a2 also as specified in the process model bp against the organisational model om. JOURNAL OF L A T EX CLASS FILES, VOL. 14, NO. 8, AUGUST 2015 9 Mashup_CR2 UI (output) Business process models copySplit() OPERATOR writes(D, any) OPERATOR bp bodDT(om, a1, a2) COMPOSITE and() AGGREGATOR toSet({a1}) OPERATOR alwaysFollows(bp, a2) OPERATOR “GenerateConsultativeRe port”, ”GenerateLegalReport” true getBPModel(bp) FILTER bp om a1=“CreateResolutionProposal” a2=“AnalyseReports” D={“ReportCB”, ”ReportLD”} bp {“GenerateConsultative Report”, ”GenerateLegalReport”, a1} true true Fig. 8: Compliance mashup to check rule CR2 at design time Case Activity Time Resource Type 1 Create resolution... 2019-05-21T08:40... Alex complete 1 Create legal rep... 2019-05-22T14:03... Anna complete 1 Create consulta... 2019-05-23T11:20... Diana complete 1 Analyse reports 2019-05-25T14:51... Alex complete 2 Create resolution... 2019-06-11T09:15... Lydia complete 2 Create consulta... 2019-06-27T15:41... Diana complete ... ... ... ... ... TABLE 2: Event log of running process instances 6) Finally, the two boolean values obtained from (4) and (5) are aggregated with an and() pipe. The output indicates whether the setting is prepared to fulfill CR2. As depicted in Figure 8, in this concrete case the process is compliant with CR2 at design time. If we wanted to give a slightly different meaning to CR2, we could reconfigure the properties of the respective components in Figure 8 and reconnect them, or even insert new components to deal with the new interpretation (e.g., if the activity Analyse reports should immediately follow the activity Create resolution proposal). We assume that for every process there is a data source that provides an event log with ongoing instances (cases), where every event contains information about an activity, its state (where at least the transition type complete is stored), the temporal data specifying when it was stored, and an RTmashup_CR2 UI (output) bodRT(a1,a2) COMPOSITE lastTimestamp(a2) OPERATOR and() AGGREGATOR Running process instances (bp) copySplit() OPERATOR getURL(D[1]) OPERATOR lastTimestamp(a1) OPERATOR trace1, trace2,, … true, true, … true false, … hasActivity(a1, “complete”) OPERATOR and() AGGREGATOR implies() OPERATOR getDocument() OPERATOR copySplit() OPERATOR checkExists() OPERATOR lastModified() OPERATOR lesserThan() OPERATOR and() AGGREGATOR trace1, trace2, … lesserThan() OPERATOR c:/…, c:/…, … doc1, doc2, … doc1, doc2, … true, true, … 2019-05-21T08:4 0:12+00:00, 2019-06-11T09:1 5:12+00:00, … 2019-05-25T14:5 1:12+00:00, NaN, … true, false, … 2019-05-23T11:2 0:12+00:00, 2019-06-27T15:4 1:12+00:00, … true, false, … true, false, … true, false, … true, true, … true, false, … bp a1=“CreateResolutionProposal” a2=“AnalyseReports” D={“ReportCB”, ”ReportLD”} copySplit() OPERATOR 2019-05-25T14:5 1:12+00:00, NaN, … Fig. 9: Compliance mashup to check rule CR2 at run time associated resource. This is common information stored in real-life event logs [45]. An excerpt of an event log for the example scenario is shown in Table 2. Then, the check of CR2 at run time can be done in the next steps (cf. Figure 9): 1) The traces of the running instances of the process bp are extracted from the respective event log and copied into several streams to be processed by different pipes. 2) The first check that has to be done (in every trace) is that activity a1 has been completed. 3) Moreover, the 2 input data objects Dmust have been created. That implies obtaining the location of such files and retrieving them from the respective repositories. Note that for the sake of readability, only the operations corresponding to 1 of the data objects are illustrated. The respective components should be duplicated. 4) Several checks will be performed upon those documents, so the files are first copied into several streams to be processed separately. 5) To check the first part of rule CR2, activity a1 must have been finished and the documents must exist in the repositories. An and() pipe is in charge of that. 6) The second part of the rule states that activity a2 must be executed after a1 is completed and the doc-