1 Introduction

Process mining uses business process logs stored in information systems to gain better understanding about business processes and detect potential breaches between regulations and guidelines specified by process owners and actual execution. In process mining, logs of business event data are compared with the corresponding process model [1]. According to [2] business data are analyzed based on three different perspectives:

  • Process perspective: the control flow aspects of the process.

  • Organizational perspective: roles of people such as performers and originators of the business processes.

  • Case perspective: process-specific properties like location and timing.

The analytics performed on logs depends on the quality and richness of the available data. Activities involved in process mining can be categorized into three types [3]:

  • Cartography: includes discovering, enhancement, and diagnosis.

  • Auditing: includes detecting, checking, comparing and promoting activities.

  • Navigation: includes exploration, prediction and recommendation.

Conformance checking falls under the umbrella of anomaly detection because it provides information about mismatches (often called violations) between logs and process models and helps process owners to understand the causes. Business rules define constrains or guidelines that apply to an organization. Organizations use business rules to enforce policy, comply with legal obligations, communicate between various parties and perform process analysis. A simple example of a business rule expressed in natural language is “A customer can pay in cash or by credit card, but a commission of 3$ is applied to credit card payments less than 20$” . Another example is “Packages weighing over 20 kg must be shipped by sea”. In industrial practice, business rules are widely used to assert business structure or to control or influence business behavior [1]. They can apply to people, processes, corporate behavior and computing systems in an organization, and are put in place to help the organization achieve its goals [4].

In this paper, we deal with process-specific rules, i.e. rules that constrain the behavior of a business process in order to achieve a specific goal. These rules can be hidden in source code, inside use cases or in workflow descriptions [5]. Typically, business experts use controlled natural language to write rules based on stake-holders requirements or external regulations, and then compliance experts translate them into the syntax required by the compliance-checking tool used by the organization. Many approaches described in the literature require human intervention for this translation [1]. In this work, we use a simple language to extract logic constraints directly from BPMN models and then translate them into business rules. Using the language, any user can extract the rules easily since they are simple and tool-independent. We build a prototype to extract the logic rules automatically using the XML schema of the BPMN model. Our approach builds on previous work proposed by [6]. In their paper, the authors introduced a mechanism to translate BPMN models to Business Process Execution Language (BPEL), our technique, instead, focuses on the translation of BPMN model to business rulesFootnote 1. The rest of the paper is organized as follows. Section 2 highlights conformance checking approaches described in the literature. Section 3 includes various definitions for the BPMN model and its components as well as the logic rules we are proposing. Section 4 presents the case study used to validate our approach. Section 5 concludes the paper and highlights possible future works.

2 Literature Review

Conformance checking is used to detect violations and inconsistencies between a business process’ expected behavior and its real-life executions, providing alerts on detected deviations. Conformance checking can use various types of constraints originated from regulations, laws and business process guidelines [6]. Conformance and business concepts may vary according to business domains and scenarios. This variety has made it difficult to achieve a fully automated conformance checking approach.

Some research has been done on using logic for conformance checking [7, 8]. Di Ciccio et al. [7] define a declarative process modeling language called Declare, which utilizes Linear Temporal Logic (LTL) to define temporal rules to be verified using process logs. The Declare language focuses on the control-flow perspective by defining different constraints templates such as Existence(A), Absence(A) and Response(A, B). A pattern-based approach that uses LTL and Metric Temporal Logic (MTL) has been introduced in [9]. The authors define both detective and preventive compliance requirements, which can be used to find violations.

Standard BPMN models can be used to define process behavior as they contain decision logic hardwired in their control flow structure. Experience has shown that logic underlying BPMN models can be employed to express business rules. However, few academic papers have studied the extraction of business rules directly from BPMN models, due to the lack of a standard semantics for BPMN. Most process mining techniques studied in the literature represents processes as Petri nets for analysis and rule generation. In [10] the authors proposed the translation of BPMN models into the Object Management Group (OMG)’s standard Semantics of Business Vocabulary and Rules (SBVR) format, which is used to express business rules within OMG’s Model Driven Architecture. The authors map different elements of BPMN model into the SBVR metamodel to extract a SBVR vocabulary. The extracted vocabulary is mapped to controlled English in order to write business rules. In [12], the authors present a method for translating BPMN models into rules in a formalized language called XTT2, which is equipped with a simple partial semantics. Their translation technique is based on visual modeling where similar rules are grouped in a table and a process is divided into a network of tables. However, the XTT2 approach does not target automatic compliance checking. More recently, [13] defined an algorithm for business rules analysis that extracts a process schema from the BPMN model and then generates business rules in a syntax called Business Rule Language (BRL). BRL rules are then verified based on the process schema to detect violations. However, the BRL approach only cover a fragment of BPMN as it only deals with “IF” and “THEN” clauses with AND and OR logical operators. Some work is also available on automatic enforcement of business rules in the context of business process. To align business processes with organizations business strategies, the authors in [11] presented SAF, a strategic alignment framework for monitoring organizations. SAF implements monitoring probes, which control the performance of business processes and business strategies achievements. An approach combining BPMN models and logic rules is presented by Awad et al. in [14]. Their main contribution is enabling compliance checking regarding the ordering of activities. A major difference between the approach by Awad et al. and the one proposed in this paper is that they start with a set of externally defined rules and then translate them to temporal logic in order to check the generated model conformance while we start with a BPMN model and use it to generate business rules. Our choice allows the rule designer to exploit standard BPMN process patterns that are widely available for many industries.

3 Mapping BPMN to FOL

We start by extracting FOL constraints directly from BPMN models. Our constraints will be translated later into business rules. We rely on an initial graph transformation to achieve an implicit uniform task activation semantics; then, we apply the basic definitions given in [6] with some minor variationsFootnote 2.

3.1 Graph Transformation

We start by translating the BPMN model into a fully synchronous workflow. In BPMN, activity are by default performed synchronously in relation to the invoking process flow, i.e. the process waits for an activity to complete before the process can proceed. However, BPMN syntax allows specifying asynchronous activity execution, e.g. requiring an external event to take place for enabling the execution of an activity. Using asynchronous events (rather than the completion of a previous activity) to enable execution of activities provides a general way to express different enabling semantics. The gist of our transformation is to avoid this complexity by treating synchronization events as special case of ordinary activities, and always use activity enabling by-compilation (of previous activity). In other words, before any analysis, all intermediate events in a BPMN model are transformed to special tasks with double borders to distinguish them. While such transformation may decrease the expressive power of the language, it has the advantage of decreasing the complexity of the model. For the exclusive gateway (XOR), we exclude the default statement, which leads to nothing. The WHILE component will be replaced with REPEAT to avoid null activity. Summarizing, we perform the following transformations of the BPMN model:

  1. a.

    Conversion of events into activities.

  2. b.

    Elimination of DEFAULT in XOR component.

  3. c.

    Substitution of WHILE with REPEAT component.

As shown in Fig. 1, the intermdiate event \(e_{1}\) is transformed to a task \(t_{2}\). The DEFAULT sequence flow in the switch component is removed. At the end, the WHILE component is substituted with REPEAT component.

Fig. 1.
figure 1

Intermediate event, elimination of DEFAULT and substitution of WHILE transformation

Full size image

3.2 Business Process Diagram (BPD)

Business processes are expressed graphically using BPMN elements in a BPD. The model is composed of a set of different tasks, events and gateways referred as objects. A task is a single activity in the model while events can represent the start, intermediate, end, and termination of the process (graph transformation will exclude intermediate events), While the gateway represents parallel and XOR forks and joins. Figure 2 shows the graphical representation of some BPMN elements in a core BPD which is composed of set of objects that can be partitioned into disjoint sets of tasks \(\mathcal {T}\), events \(\mathcal {E}\) and gateways \(\mathcal {G}\) [6].

Fig. 2.
figure 2

A core subset of BPMN elements [6]

Full size image

In the remainder of the paper, we only consider well-formed core \(\mathcal {BPD}s\) as defined in [6]. Moreover, without losing generality we assume that both \(\mathcal {E^S}\,and\,\mathcal {E^E}\) are \(singletons, {i.e.}~\mathcal {E^S} = \{s\}\,and\,\mathcal {E^E} = \{e\}\).

3.3 Decomposing a BPD into Components

The notion of component is used to transform a graph structure into set of business rules. To facilitate this transformation, the BPD is decomposed into different components. Again according to [6] “A component is a subset of the BPD that has one entry and one exit point”. Each component will be mapped into a single logic rule. Each component should include a minimum number of two different objects (source and sink). A BPD with no component which only contain a single task between the start and end events is called a trivial BPD. Whenever we reach a trivial BPD, no rule can be extracted and therefore we stop the translation. Breaking down the BPD into set of components helps to define an iterative method to transform BPD into rules. A function Fold is defined in [6] which substitutes a component with single task. Fold function can be utilized to reduce the BPD iteratively until we reach a trivial BPD.

3.4 Structured Activity-Based Translation

In our approach, different components are mapped into a subset of FOL rules including AND, XOR and sequence operations. Paper [6] defines seven forms of well-structured components. Figure 3 represents the mapping of each component into the corresponding FOL rules [6].

Fig. 3.
figure 3

Folding a well-structured component \(\mathcal {C}\) into single task object \(t_c\) attached with the corresponding FOL rule translation of \(\mathcal {C}\) [6]

Full size image

Each rule corresponds to a specific position in the BPD. The position information can be utilized in different ways in the conformance checking process and introduces two different types of dependencies: sequential and hierarchal dependencies. Sequential order means rules extracted from earlier components should be checked before rules from later components. On the other hand, this technique presents the notion of hierarchy of constraints, which to the best of our knowledge, is not well found in the literature. One or more rules can depend on another rule and therefore executing high-level constraints plays critical role in the execution of other low-level constraints.

3.5 Translation Algorithm

After mapping each component to the corresponding rule, we introduce the algorithm used to translation a well-formed core BPD into FOL rule which is similar to the algorithm introduced in [6] with some modifications. The algorithm includes three different steps, selecting a well-structured component then providing its FOL rule and finally fold the component. This is done repeatedly until we reach a trivial BPD.

Definition 1

(Algorithm 1[6]). Let \(\mathcal {BPD=(O,F},Cond)\) be a well-formed core \(\mathcal {BPD} \) with one start event and one end event. \([X]_c\) is the set of components of BPD[X]

  1. 1.

    \( X := \mathcal {BPD}\)

  2. 2.

    if \([X]_c = \varnothing \) (i.e., X is initially a \(trivial\; \mathcal {BPD}\)), stop.

  3. 3.

    while \([X]_c \ne \varnothing \) (i.e., X is a non-trivial \(\mathcal {BPD}\))

    1. 3.a.

      if there is a maximal SEQUENCE component \(\mathcal {C} \in [X]_c\), select it and goto (3-c).

    2. 3.b.

      if there is a well-structured (non-sequence) component \(\mathcal {C} \in [X]_c\), select and goto (3-c).

    3. 3.c.

      Attach logic rule translation of \(\mathcal {C}\) to task object \(t_c\).

    4. 3.d.

      X := Fold\((X, \mathcal {C}, t_c\)) and return to (3).

  4. 4.

    Output the logic rule attached to the task object \(t_c\).

4 Case Study

4.1 BPMN Model to Logic Rules

To validate our approach, we targeted a reference business process in the telecom industrial domain. Processes in this field of industry have been the target of several interesting studies and research [4] because of the challenges they pose to business rules lifecycle management: telecommunication regulation and policies are frequently updated, while actors’ roles change over time. We focus on the telecom order fulfillment process in Fig. 4 provided by [16] with some modifications. The process starts whenever an order request is received and then the process initiator acknowledge order. Next, three tasks (Save order in CM, Send order details to Logistics and Obtain IMSI for ICCID) are executed in sequence. If the customer chooses to subscribe only then task Authentication flow will be fulfilled and if he/she chooses subscription with device then MNP wait time is executed. Depending on MNP and new voice/data conditions the sequence flow will branch to MNP process or proceed to choose new data or voice. The customer can choose between Voice subscription process or Data subscription process. Finally, Additional service provisioning is applied followed by Sending an email notification to customer.

Based on the algorithm discussed in Sect. 3 we show how to extract the logic rules from the order fulfillment model. Seven different components are identified as shown in Fig. 5 and the model is reduced to \(trivial BPD\). The components are labeled with number i indicating their order and each \(C_{i}\) is folded into a task \( t{_{C}^{i}}\).

Fig. 4.
figure 4

Order fulfillment process [16]

Full size image
Fig. 5.
figure 5

Translating the order fulfillment process model in Fig. 4 into logic rules

Full size image

1st Translation. The algorithm starts with recognizing the sequence component in the model. The component \(C_{1}\) with five different tasks is folded into task \( t{_{C}^{1}}\) with the following logic rule:

$$\begin{aligned} \mathbf{R1}{} \mathbf{:}~{(ROR \rightarrow AO) \wedge (AO \rightarrow SOC) \wedge (SOC \rightarrow SOD) \wedge (SOD \rightarrow OII) } \end{aligned}$$

2nd Translation. After the first fold, another sequence component is identified consisting of tasks Additional services provisioning and send email notification. The component \(C_{2}\) is folded into task: \( t{_{C}^{2}}\) attached with the following rule:

$$\begin{aligned} \mathbf{R2}\mathbf{:}~{ASP \rightarrow SEN } \end{aligned}$$

3rd Translation. As no sequence component can be identified in the model, the algorithm tries to allocate any well-structured (non-sequence) component. The switch component \(C_{3}\) is selected and folded into task \( t{_{C}^{3}}\). The following XOR rule is generated:

$$\begin{aligned}&\mathbf{R3}\mathbf{:}~{(Subscription\,\, only?/with\,\,Device?Only\,\, Subscription\wedge AF) \,\,\oplus }\\&(Subscription\,\,only?/with\,\, Device?Device\,+\,Subscription \wedge MWT) \end{aligned}$$

4th Translation. Component \(C_{4}\) containing the second switch is chosen and folded into task \( t{_{C}^{4}}\) with the corresponding rule:

$$\begin{aligned} \mathbf{R4}\mathbf{:}~{(New \,\,Voice/Data?Voice\,\wedge \,VSP) \,\,\oplus \,\, (New\,\, Voice/Data?Data\,\wedge \,DSP)} \end{aligned}$$

5th Translation. Translation 1 and 3 introduce new sequence component identified by the algorithm. The new component \(C_{5}\) is folded into task \( t{_{C}^{5}}\) creating the implication rule:

$$\begin{aligned} \mathbf{R5}\mathbf{:}~{ t{_{C}^{1}} \rightarrow t{_{C}^{3}} } \end{aligned}$$

6th Translation. Folding \(C_{4}\) simplifies the switch component identified as \(C_{6}\) that is folded into task \( t{_{C}^{6}}\) and rule 6 is extracted:

$$\begin{aligned} \mathbf{R6}\mathbf{:}~{(MNP\; or\; New \;Order?MNP\wedge MP) \oplus (MNP\; or \;New\; Order?New\wedge t{_{C}^{4}})} \end{aligned}$$

7th Translation. Finally, the sequence component consisting of \( t{_{C}^{5}}\) , \( t{_{C}^{6}}\) and \( t{_{C}^{2}}\) is folded into task \( t{_{C}^{7}}\) with the following rule:

$$\begin{aligned} \mathbf{R7}\mathbf{:}~{(t{_{C}^{5}} \rightarrow t{_{C}^{6}} ) \wedge (t{_{C}^{6}} \rightarrow t{_{C}^{2}} )} \end{aligned}$$

4.2 Evaluation

We implemented our translation algorithm as a Java program which takes as input the XML incarnation of the source BPMN model. The tool parses XML elements to produce a set of rules. We performed some testing to evaluate our translation tool. Namely, we extracted rules from 10 different BPMN models, obtaining a total of 36 business rules. Table 1 shows that the average recall (defined as the percentage of original business process’ components that are covered by the generated rules) is 86.1% while the average precision (defined as the percentage of rules that cover a component of the original business process) is 91.1%. We remark that missing rules are associated with folded components therefore the performance of the tool can be increased either by improving the components folding step or by limited human supervision in the translation process.

Table 1. Results of evaluation
Full size table

4.3 Translating FOL into Checkable Business Rules

Aperture [15] is a process mining tool developed by British Telecommunication (BT) group. Its main applications involve the creation of process models from logs of previous process executions, as well as computing Key Performance indicators (KPIs). Using the results of the previous sections, we now add a new feature to Aperture: the capability of checking process conformance. Aperture tool uses its own Workflow Expression language (WEL). WEL is equipped with different operations such as Arithmetic, Relational, Logical and Conditional operations to enable wide range of information extraction. The general format for WEL rules is:Footnote 3

$$\begin{aligned} {[task\text {-}name].selection\text {-}type@attribute\text {-}name} \end{aligned}$$

We need to prove that our language is abstract and independent therefore it can be applied to any tool. For that, we will use WEL to transform the logic rules extracted from the order fulfillment process into WEL business rules that can be directly applied to the tool. Without WHILE or REPEAT control flow structures, all tasks will be executed once and therefore we will use “first” as the selection type. Moreover, all tasks have startTime (sT), endTime (eT) and conditionValue (cV). We assume that there is One-to-One correspondence between the tasks in the BPMN model and Aperture’s tasks and therefore we do not need any log lifting. Below, we define our algorithm to translate FOL rules extracted from the BPMN model to Aperture’s WEL rules. We start by selecting a rule, finding its equivalent WEL rule and output it.

Definition 2

(Algorithm 2). Let \(\mathcal {BPD=(O,F},Cond)\) be a well-formed core \(\mathcal {BPD} \). \([X]_R\) is the set of logic rules of BPD[X].

  1. 1.

    \( X := \mathcal {BPD}\)

  2. 2.

    if \([X]_R = \varnothing \), stop.

  3. 3.

    while \([X]_R \ne \varnothing \)

    R-WEL: (Aperture rule corresponding to logic rule R)

    1. 3.a.

      if R \(\mathrel {\widehat{=}}\) SEQUENCE-component then

      for i = 1 \(\rightarrow |\)t| do

      $$\begin{aligned}{}[t{_{i}}].type@eT < [t{_{i+1}}].type@sT \end{aligned}$$
    2. 3.b.

      if R \(\mathrel {\widehat{=}}\) FLOW-component then

      for i = 1 \(\rightarrow |\)t| do

      $$ \begin{aligned}{}[t{_{i}}].type@sT<= [t{_{i+1}}].type@eT \, \& \, [t{_{i+1}}].type@sT <= [t{_{i}}].type@eT \end{aligned}$$
    3. 3.c.

      if R \(\mathrel {\widehat{=}}\) SWITCH-component then

      for i = 1 \(\rightarrow |\)t| do

      $$ \begin{aligned}&( ([PA].type@cV = f(t{_{i}})\, \& \, [t{_{i}}].type@sT>0)\, |\, ([PA].type@cV\\&\quad = f(t{_{i+1}})\, \& \, [t{_{i+1}}].type@sT>0) )\, \& !\, ( ([PA].type@cV\\&\quad = f(t{_{i}})\, \& \,[t{_{i}}].type@sT>0) \, \& \,([PA].type@cV\\&\quad = f(t{_{i+1}})\, \& \, [t{_{i+1}}].type@sT >0)) \end{aligned}$$
    4. 3.d.

      if R \(\mathrel {\widehat{=}}\) PICK-component then

      for k = 1 \(\rightarrow \) n do

      for i = 1 \(\rightarrow |t|\) do

      $$ \begin{aligned}&( ([t{_{k,i}}].type@eT< [t{_{k,(i+1)}}].type@sT) \,|\, ([t{_{k+1,i}}].type@eT\\&\quad<[t{_{k+1,(i+1)}}].type@sT) ) \,\, \& !\,\, ( ([t{_{k,i}}].type@eT< [t{_{k,(i+1)}}].type@sT)\, \& \,\\&\qquad ([t{_{k+1,i}}].type@eT < [t{_{k+1,(i+1)}}].type@sT) ) \end{aligned}$$
    5. 3.e.

      if R \(\mathrel {\widehat{=}}\) WHILE/REPEAT-component then

      for i = 0 \(\rightarrow \)* do

      $$ \begin{aligned}{}[t_{1}].type@eT < f(t_{1}) \, \& \, [t_{1}].type@sT \end{aligned}$$
    6. 3.f.

      if R \(\mathrel {\widehat{=}}\) REPEAT+WHILE-component then

      for i = 0 \(\rightarrow \)* do

      $$ \begin{aligned}{}[t_{1}].type@eT < ([t_{1}].type@cV =f(t_{2}) \, \& \, [t_{2}].type@sT \end{aligned}$$
  4. 4.

    Output Aperture WEL rule.

Using the above algorithm, we transform the rules found in Subsect. 4.1 into Aperture accepted format.

figure a
figure b
figure c
figure d
figure e
figure f
figure g

The translated business rules are independent from the log and therefore we kept tasks \(t{_{C}^{i}}\). These tasks represent temporary tasks and using the log later we will be able to replace them with the corresponding task. For example, \(t{_{C}^{3}}\) in R4-WEL will be replaced with either task AF or task MWT based on which tasks was executed and founded in the log.

5 Conclusion

In this paper, we introduced a pragmatic translation of BPMN models into simple FOL rules reflecting the control flow aspects of the model. Our strategy is based on uniform representation of asynchronous task activation via special synchronous tasks that correspond to checking event queues. The rules we obtain are independent from any software tool and can be used as a baseline to write conformance rules without the need of business expert intervention. In order to validate our approach we extracted business rules from sample BPMN models. These rules were transformed later into the syntax of Aperture, BT’s industrial process mining tool. We described and tested an implementation of our translation algorithm.

Future work will involve full automation of the translation process. Components’ information can be further utilized to explore the sequential and hierarchal dependencies. This will help ensure that conformance rules are applied in the right time and order.