Business process modeling has become a popular method for improving organizational efficiency and quality. Automatic validation of process models is one of the most valuable features of modeling tools, in face of the increasing complexity of enterprise business processes and the richness of modeling languages. This paper proposes a formal language, Event-Condition-Action-Event (ECAE), for integrating Colored Petri Nets (CPN)-based business process with a set of business rules. We automate the integration process for validating the business process model. The ECAE language has several important features: its reasoning capabilities, its ability to express complex actions and events, and its declarative semantics. By enabling simulation of business process behavior, the reasoning capabilities facilitate the early detection of flaws
The widespread use of business process modeling has helped enterprises to design, control and analyze many operational processes. Unfortunately, syntactic and semantic inconsistencies often appear in business process models, especially as the complexity of the models increases. Flaw detection and automation are essential for ensuring costeffective and correct process models.
The challenge for system designers is to build a flexible intelligent system, which accepts and verifies the change on business process and business rules automatically. The business process must be integrated with a set of business rules, and a correspondence between the process and the rules must be created. This must be flexible since the business process and the business rules may be modified during runtime. The verification should be a rule-based system, which can reason and deduce new knowledge or a new decision based on a set of rules and facts.
This paper proposes a formal language ECAE for business process modeling, which takes advantage of both the graphical representation of colored Petri nets and the easy to represent ECA rule. It designs a business process model through CPN and translates the model into a set of ECA rules, derivation rules and inhibition rules, it will be explained in more detail in section 5. This language can be used also for representing business rules and checking the respect of a business process to the business rules automatically when a user modifies a workflow.
Our main contributions in this paper are: Modeling a business process in a formal way. Representing a set of business rules in the same formal way with the business processes. Integrating the business process and a set of business rules. Checking the semantic aspect of business process automatically during runtime.
The rest of the paper is organized as follows. Section 2 presents a comparison with previous work. Section 3 introduces the research methodology. Section 4 provides an overview of both the Color Petri Nets and the ECA language. Section 5 presents the language ECAE through a case study. Finally, some conclusions and future research directions are presented in Section 6. 2
The most widely used languages for describing business process today are the
Business Process Execution Language (BPEL) [
Several authors have proposed using ECA rules for business process modeling and
execution, e.g., [
In this paper, a Coloured Petri Net (CPN) is used to design a business process model.
A CPN is a tuple CPN = (Σ, P, T, A, N, C, G, E, IN) [
The advantage of CPN is that color sets are used to distinguish different tokens, which will be treated in different ways, while arc expression function and guard function are used to control token’s flow path.
Example 1: in Fig. 2, we design a CPN graph to represent bank account operations. color Account = int with 1..1000; color Balance = int; color Amount = int with 1..5000; color AB = product Account * Balance; color AA = product Account * Amount; var a:Account; var x:Amount; var y:Balance;
A (a,x) (a,y-x) (a,y) (a,y) (a,x+y) (a,x)
AA Withdraw
Withdraw
Database
Deposit
Deposit
This provides a simple example. There are two main transitions in the CPN graph. The first transition allows the user to deposit the money to their bank account while the second action allows the user to withdraw the money from their bank account.
The event specifies a condition for triggering the rule. The condition is a query, which determines if the information system is in a particular state, in which case the rule fires. Finally the action states the actions to be performed if the rule is met. These actions may in turn cause further events to occur, which may in turn cause more ECA rules to fire.
In Fig 3, there are three main steps of our solution. First of all, a business process (CPN graph) is designed by a user; it contains all the properties of CPN (Places, Transitions, Input Arcs, Output Arcs, GuardFunctions, InputArc Expressions, OutputArcExpressions, Colour Sets). The business process can be modified and reused by the user. The second step is compilation; the business process which was designed in step 1, will be translated into a set of ECAE language rules, an extension of Event Condition Action language. This language and the compilation step will be introduced in sections 4.2 and 4.3. Finally, in the execution step, the ECAE language will be executed with the ECA engine.
• Business process by Coloured Petri Nets (Places, Transitions, Input Arcs, Output Arcs, GuardFunctions, InputArc Expressions, OutputArcExpressions, Colour sets) Design Step Execution • Event: transition • Condition: Place, GuardFunction, Colour Set, Input Arc Expression • Action: Output Arc Expression, Colour Set Compilation • Event: next transition • ECAE Execution Engine
We start this section by informally introducing the various constructs of the
language. Our solution is inspired by previous work [
2. Definitions: object, event and action
Reactive rules are as usual in ECA languages, and have the form (1), where: Event is a basic or a complex event expressed in algebra; Condition is a conjunction of (positive or negative) literals and Action is a basic or a complex action. Inference rules are Logic Programing rules with default negation, where default negated heads are allowed. Finally, ECAE also includes inhibition rules of the form:
Where condition is a conjunction of literals and events. Such an expression intuitively means: if Condition is true, do not execute Action. Inhibition rules are useful for updating the behavior of reactive rules. If the inhibition rule above is asserted all the rules with Action in the head are updated with the extra condition that Condition must not be satisfied in order to execute Action.
ECAE allows basic events to be combined to obtain complex ones using event algebra. The operators we use are: | | S | not. Intuitively, e1 e2 occurs at an instant i if both e1 and e2 occur at i; e1 e2 occurs at instant i if either e1 or e2 occur at instant i; not e occurs at instant i if e does not occur i. S (e1, e2, e3) occurs at the same instant of e3, in case e1 occurred before, and e2 in the middle. Operator S is very important since it allows combining and reasoning with events occurring at different time points.
Actions can be basic or complex. Basic external actions are related to the specific application of the language. Basic internal actions are for adding or retracting facts and rules (inference, reactive or inhibition rules), of the form assert(τ) and retract(τ) respectively, for raising basic events, of the form raise(e). There is also an internal action defined (d) for adding new definitions of actions and events (see more on these definitions below).
Complex actions are obtained by applying algebraic operators on basic actions. Such operators are: | | IF, the first for executing actions sequentially, and the second for executing them concurrently. Executing IF (C, a1, a2) amounts to executing a1 in case C is true, or executing a2 otherwise.
To enable modular definition of both complex actions and events, ECAE allows for event and action definition expressions. These are of the form edef is e and adef is a where edef (resp. adef) is an atom representing a new event and e (resp. a) is an event (resp. an action) obtained by the event (resp. action) algebra above. It is also possible to use defined events (resp. actions) in the definition of other events (resp. actions). 5.3
As mentioned in section 4.1, a business process is represented by a CPN graph; the idea of our solution is to translate a CPN graph to a set of ECAE rules. We propose an algorithm for CPN-ECAE translation:
The ECAE rules, translated from Coloured Petri Net-based business process model is used to realize business process execution. The translation algorithm has 4 steps as follows: 1. The condition part of ECAE reactive rule is a collection of color sets, guard function related to a transition. 2. Translate each transition to ECAE rule 3. Add starting condition and ending condition. 4. Connect all ECAE rule transition as their triggered sequence.
With this algorithm, we can translate a business process model into a set of ECAE rules. Example 2 illustrates this algorithm.
Example 2: the CPN graph from Example 1 will be translated into a set of ECAE rules.
BPR1:If Withdraw&AA(a,x)Do Withdraw&AB(a,y-x) BPR2:On Withdraw&AB(a,y-x) If Done Do AB(a,y) BPR3:If Deposit&AA(a,x) Do Deposit&AB(a,y+x) BPR4:On Deposit&AB(a,y+x) If Done Do AB(a,y) BPR5:On AB(a,y) If Done Do EndWorkflow BPR6:If Account>5000&Account<0 Do EndWorkflow BPR7:If Amount>1000&Amount<0 Do EndWorkflow
In this example, R1 and R3 are the rules to begin the business process for two cases, Withdraw and Deposit, respectively. R5 is the rule for quitting the business process. 5.4
One of the main objectives of ECAE is to build a set of business rules. When a business process is executed, it must respect a set of business rules. A rule set consists two parts: 1. Definitions: this part contains all definitions of actions, events and color set in a specific domain. 2. Inhibition rules: this part consists a set of inhibition rules which are useful for updating the behavior of reactive rules Example 3: we extend Example 2 by adding some actions and simple inhibition rules. BRR1:Withdraw(a,x) is Login(user,pass) Amount(a,y-x) BRR2:Deposit(a,x) is Login(user,pass) Amount(a,y+x) BRR3:If y-x<0 Do Not Withdraw(a,x) BRR4:If Not Login(user,pass) Do EndWorkflow
When these inhibition rules are integrated with the set of ECAE rules in Example 2, the balance of bank account will never be negative. We can use ECAE to define this more complex business rule. 5.5
This section introduces our method for integrating and verifying a business process and business rules. As presented above, the set of business rules and business processes are represented by ECAE language. Therefore, in order to verify the compliance between them, we merge two sets of ECAE rules into a single knowledge base and reason on it. Let us continue our Example 3 we have a knowledge base as follow: BPR1:If Withdraw&AA(a,x)Do Withdraw&AB(a,y-x) BPR2:On Withdraw&AB(a,y-x) If Done Do AB(a,y) BPR3:If Deposit&AA(a,x) Do Deposit&AB(a,y+x) BPR4:On Deposit&AB(a,y+x) If Done Do AB(a,y) BPR5:On AB(a,y) If Done Do EndWorkflow BPR6:If Account>5000&Account<0 Do EndWorkflow BPR7:If Amount>1000&Amount<0 Do EndWorkflow BRR1:Withdraw(a,x) is Login(user,pass) Amount(a,y-x) BRR2:Deposit(a,x) is Login(user,pass) Amount(a,y+x) BRR3:If y-x<0 Do Not Withdraw(a,x) BRR4:If Not Login(user,pass) Do EndWorkflow We can see that the business process and the business rules are represented in ECAE syntax (this is a set of rules). Therefore, we can easily check the compliance of business process with a set of business rules by detecting the conflict between the rules in one knowledge base using reasoning and a reasoner. 6
CPNs and ECA rules have a very important role in designing a business process management system. Colored Petri nets, inherited from the traditional Petri nets, have a better ability on expressiveness because of their color sets and guard function. Meanwhile ECA rules are based on the event-trigger feature, which is an easy-to-implement software initiative.
In this paper, we propose a formal language ECAE, which exhibits the advantages of both ECA languages and Logic Programing updates. Further, we design a common business process model for bank account operations using a colored Petri net, and translate it into a set of ECAE rules
In future work, we will focus on enhancing the expressiveness and exception processing ability of ECA rules, which will make our method more suitable for developing a useful business process management system. We will also consider the transaction problem for business process execution, and how to implement and evaluate the proposed approach based on process agents and ECA rules.