Decision-Making Support for the Correctness of Input Data at Runtime in Business Processes

DECISION-MAKING SUPPORT FOR THE CORRECTNESS OF INPUT DATA AT RUNTIME IN BUSINESS PROCESSES MAR´IA TERESA G ´OMEZ-L ´OPEZ and RAFAEL M. GASCA ∗ Departmento de Lenguajes y Sistemas Informticos, University of Seville Seville, Spain JOSE ´ MIGUEL P´EREZ- ´ALVAREZ † Intelliment Security Tomares, Seville, Spain In a business process, the information that flows between the activities can be introduced by those users who interact with the process. This introduced information could be incorrect due to a lack of knowledge or a mistake. For this reason and to make the business process execution consistent, we propose a Decision Support System (DSS) to inform the user about the possible and correct values that the input data can take. The DSS takes into account the business process model and the policy of the company. The policy concerning the input data and dataflow that the company manages can be represented by constraints (called Business Data Constraints). In order to ascertain all the possible values of the input data that permit the execution of the process following the defined goals, the DSS analyses the business process model and the Business Data Constraints, using the constraint programming paradigm. Keywords: Business processes; Input Data; Decision-making support; Numerical tech-niques; Process Instance Conformity. 1. Introduction A business process consists of a set of activities that are performed in coordination within an organizational and technical environment 1. In a business process, the information that flows between the activities can be introduced by the users. Sometimes, the user must decide the value to introduce while taking into account the potential actions in order to make the process instance correct. In the business process scenario, this implies the analysis of all the possible branches that can be executed, and the decisions that can be taken in the future. If the decision made is incorrect, it will affect other decisions in the future, or it may even make it impos- ∗{maytegomez, gasca}@us.es. www.lsi.us.es/∼quivir †[email protected], http://www.intellimentsec.com/ 1 sible to finish the instance correctly (following the goals defined for the company). The requirement for decision support frequently arises when decisions have to be made in complex, uncertain, and/or dynamic environments 36. For this reason, we propose a solution where the decision-making support for input data can be integrated into the business process instances to inform the user about the possible values of the input variables, thereby making the instance of the business process consistent. From the point of view of input data values, the correctness of a business process is based on the correctness of the compliance rules that describe the policy of the company; a correct input value is therefore the value of a variable that satisfies all the rules defined by the company. Numerous studies propose a variety of taxonomies to classify the definition of business compliance rules 2, 3, 4, 5, such as a specification, a policy or a standardized procedure, that represent a natural step towards the inclusion of semantic requirements between business functionality and data. However if the relation between the values of the dataflow variables has to be described, then Business Data Constraints (henceforth referred to as BDCs) have the capacity to describe Business Compliance Rules 6. These BDCs are understood as a type of business compliance rules, which represent the semantic relation between the data values that are introduced, read and modified during the execution of the business process instances 7. The use of BDCs in decision-making support can be decisive, since humans must often make decisions about the input data in a business process instance that may result in being incorrect for the working order of the process. If all the potential scenarios in the future are taken into account in the decision-making support for input data, then late identification of non-conformities of input data with respect to the BDCs can be prevented. Therefore, we propose the use of BDCs to assist in the decisions of the users, despite the complication that the BDCs can be associated with one activity, a set of activities, or to the whole business process, and hence the assistance must integrate the model of the business process. The BDCs respond to the demand for the processing of data by providing more semantic content in the business process, which leads to a better understanding of the properties of the data used in the business process. In order to explain our proposal, an example of web services selection is depicted in Figure 1, where a very simple business process model is shown. We have used the BPMN 2.0 notation 13 for input and output data. The BDCs are represented by means of annotations in BPMN associated to the activities. In this process, the values of data items DE (Data Encryption) and NR (max Number of Requests) are decided and introduced by a human into different activities, since they are variables that can participate in a decision-making process. The value of TS (Throughput Saturation) is derived by Select Service Level, and hence cannot be defined as an objective of the decision-making process. Depending on the value of DE (DE≤2 or DE>2), one of the branches of the process is executed (XOR gateway for the different providers of services). An example of input data decision could in- Select Service Level Select Provider A Select Provider B DE<=2 DE>2 Data Encryption (DE) Throughput Saturation (TS) Max Number of Requests (NR) Option 1 Option 2 0<=DE<=3 300<=TS<=2000 TS<=400*DE DE:1..3 (0<=DE<=3 300<=TS<=2000 TS<=400*DE) AND (DE>=2  NR<=TS 500<=NR<=2000) OR (NR<=1.3*TS 600<=NR<=2000) DE:2..3 NR<=TS 500<=NR<=2000 NR<=1.3*TS 600<=NR<=2000 0<=DE<=3 300<=TS<=2000 TS<=400*DE Fig. 1. Simple example of Business Process Instance for decision-making support for input data support volve the determination of the possible correct values of DE in Select Service Level activity. As mentioned above, each BDC can be associated with one activity, a set of activities, or to the whole process: therefore each activity has several BDCs associated, for example Select Service Level is associated to {0≤DE≤3, 300≤TS≤2000, TS≤400*DE}. In order to decide the correct values that the variable DE can take to satisfy all the BDCs in the future, either those BDCs related with only Select Service Level (Option 1 of Figure 1) can be taken into account, or all the BDCs related directly or indirectly with DE. This implies analysing all the possible paths from Select Service Level, while considering the conditions associated with the control flows and evaluated at runtime (DE in the example), and the BDCs of Select Provider A and Select Provider B (Option 2 of Figure 1). Option 1 presents an interval with the possible values of the variable DE ([1..3]) when solely the BDCs related to the activity Select Provider A are analysed; and Option 2 shows how the interval with possible correct values of DE are reduced ([2..3]) if the BDCs related to the variable NR are also included in the analysis. For example, in Option 1 it is possible to introduce the value 1 for the variable DE, and to assign 350 to the variable NR ({TS ≤400 ∗DE}). The problem arises when the activity Select Provider Ais executed, and it is discovered that there are no valid values for the variable NR to satisfy the BDC {NR ≤TS}. From the previous example, it can be observed that the BDCs could help to introduce consistent data in business process instances. These BDCs constitute the basic knowledge for a Decision Support System (DSS). This knowledge can be enriched by including the analysis of the business process model, and the conditions associated with the sequence flows. This decision-making support for input data can also be used to guarantee the existence of a correct instance of the process, thereby obtaining a more fault-tolerant process. In order to support this assistance with the DSS for input data, the following aspects have been considered: •The use of Business Data Constraints to help in the decisionmaking support for input data. BDCs can assist in the decision-making support by reporting on the possible correct values of the data introduced in each instance; however not all of the values of the BDC variables are yet known and instantiated. •The development of an algorithm to traverse the process model. To bring the relevant parts of the business process together and allow them to contribute towards decision-making support, an analysis of the process model and the BDCs of each activity is necessary. We propose an algorithm that traverses the business process model and combines the BDCs related to each activity in order to obtain a representation of the correct values that the variables can assume. •The generation of the Numerical representation of the possible correct values of the input data. To generate a set of qualified solution alternatives, instead of providing only one solution, we propose obtaining the possible ranges of the decision variables by means of Constraint Programming. •The implementation of an application to integrate our proposal into business process modeller software. In order to facilitate the decision-making process description, we have developed an application for the DSS (called MARTIN: MAking Reasoning for daTa INput) that allows the user to define the BDCs for each activity, and connect the symbolic and numerical solvers with the process in order to obtain the possible correct values for the input data in each instance. This application offers the required agility and flexibility to the organizations so that they can comply with changes in policy and legislation, and apply them in the DSS. For these reasons, this paper is organized as follows: Section 2 explains the grammar of BDC used in this paper. Section 3 presents a motivating example where decision-making support for input data is used. Section 4 states the necessary definitions to formalize the proposal. Section 5 analyses how to traverse a business process model to study all the possible correct values of a variable, and to propose an algorithm for its development. Once the BDCs involved in the decision-making support are known, how Constraint Programming is applied to Decision-Making support is analysed in Section 6. In Section 7, the details of the DSS that we propose, the implemented application to include BDCs in the decision-making support, and a case of study are explained. Section 8 discusses previous work related to our proposal. Finally, conclusions are drawn and future work is presented. 2. Representation of the Decision-Making Objectives As mentioned above, BDCs are a subset of the business compliance rules, oriented to dataflow values. BDCs can be used to represent the relation between the values of the variables that flow in a business process instance, by helping in the description of the policy of the company and in the decision-making support for input data. Although there are several language constructs for the design of business compliance rules, most are based on the use of IF-THEN rules or their derived extensions of ECA rules (event-condition-action rules) or ECAA rules (event-condition-actionalternative rules). The languages for representing business rules vary between research prototypes (e.g. N3), vendor specific formats (e.g. Drools, Fair Isaac Blaze Advisor, ILOG JRules and Jess), and proposals for the XML-based exchange of business rules (e.g. SRML, PRR, and SBVR). Another possibility is the Business Process Compliance Language (BPCL) 8, which defines inclusion, precedence, and existence conditions for business rules by means of Object Constraint Language (OCL) expressions, which specify correctness and compliance checks. That version of BPCL was improved in 6 to develop a semantic approach to business rule management that allows intuitive modelling and analysis of business process compliance. In 7, a grammar for BDCs is presented. In this paper, we extend this grammar to include new operators that can facilitate the description of the policy of the companies. This extension is inspired by the idea of viewing a BDC as a Constraint: a Boolean combination of equations and inequations that follows the metamodel of Figure 2 based on that presented in 9. A BDC can be an atomic constraint, a negation of a constraint, or a binary constraint formed by two constraints joined with a Boolean operator (AND, OR, IMPLY). An atomic constraint is formed by two functions and a comparator (<, ≤, ≥, . . .). Each function can be a unary function (a variable), a constant, or a binary function joined with an operator (+, ∗, −, /). The metamodel is based on the recursive definition of Constraint, since two constraints can be combined into a new one, by using one of the Logic Operators or a Negation. For example, the constraints: {a+b ≤ c ∧ c > 8} and {a*b ≥ 5 ∨ ¬(c ≤ 15)}, can be combined into a new constraint, for example by using the ∨ operator, thereby obtaining the new constraint: {(a+b ≤ c ∧ c > 8) ∨ (a*b ≥ 5 ∨ ¬(c ≤ 15))}. We therefore define four methods for the combination of a BDC (c) with another (c’): •c.and(BDC c’) returns a new constraint: {c∧c’} •c.or(BDC c’) returns a new constraint: {c∨c’} •c.not() returns a new constraint: {¬ c} •c.imply(BDC c’) a new constraint: {c→c’} These methods will be used in Algorithm 5.2 to build the BDC that will represent all possible values of a variable in accordance with the model of the business process. Constraint - domain : VariableType - name : String Variable - FLOAT - INTEGER - NATURAL <<enum>> VariableType - isDefinedBy *1 - NOT_EQUAL - EQUAL - GREATER_EQUAL - GREATER - LESS_EQUAL - LESS <<enum>> Comparator - comparator : Comparator AtomicConstraint NegationConstraint - booleanOp : LogicOperator BinaryConstraint - IMPLY - OR - AND <<enum>> LogicOperator Function - isFormedBy 2 1 UnaryFunction - has 1 - value : String Constant - funcOperator : FunctionOperator BinaryFunction - DIVIDE - MULTIPLY - MINUS - PLUS <<enum>> FunctionOperator - has 2 1 - relates 2 - negates 1 Fig. 2. Constraint Metamodel 3. A motivating example The motivating example used in this paper is the well-known example of the organization of a conference, for which a reduced model is presented in Figure 3. This business process shows an example where decisions about input data must be made at various points of the business process, where the future values of several variables remain unknown, since they are introduced into activities that have yet to be executed. First of all, the organizing committee has to determine the early and late registration fees several months before the number of participants is known, and this decision cannot be changed after the call for papers has been made. A similar situation exists when deciding the number of proceedings that will be printed, but although the final number of participants remains unknown until the conference ends, there is a significant relationship between the number of accepted papers and the number of participants. Other decisions, such as which restaurant to book for the gala dinner and lunches, have to be made although the number of participants can influence the determination of the price and the choice of restaurant. Although this information is unknown, it is necessary to make many decisions before the conference starts. In the example, nine different input data variables participate in the data decision-making process (early registration fee, late registration fee, lunch price, dinner price, number of proceedings to print, local speaker cost, international speaker cost, publicity and venue cost). There are other input variables, but their Establish Conference Rate Contact Partner Print Proceedings Final report and make payments Invite Local Speaker Invite International Speaker Author Notification Regsiter Early Income-totalCost<4000 / Book Dinner Book Lunch Paper Submission Sent Paper Accepted Paper Num Early registrations Num Late Registrations Hold Conference Sponsorship AND 1 AND 2 XOR1 OR 1 Early Registration Fees Late Registration Fees Venue Cost publicity Proceeding Price NumberOfProceedings Conference lunch price Conference dinner price sponsorship>=5000 sponsorship>=8000 interSpeakerCost localSpeakerCost Fig. 3. Example of a conference organization process values are determined in a mandatory way, for example the number of accepted papers, or the final number of participants that belong as part of the data flow. Since decisions have to be made by the organizing committee, two questions arise: Would it be more conducive towards the success of the conference to take into account all the potential facts in the future, and the possible branches that will be executed depending on the specific values of each process instantiation? How it can be done? Obviously, if there is no information about the relationship between the variables earlyRegistrationFee,lateRegistrationFee,lunchPrice, etc, no type of inference about the possible correct values can be taken. For this reason, BDCs are necessary. Examples include: • {sentPaper*0.3 ≤acceptedPapers ≤sentPaper*0.8}associated with the activity Paper Submission. • {numEarlyParticipant*0.8 ≤acceptedPapers ≤numEarlyParticipant * 1.2}associated with the activity Author Notification. • {numOfProceedings ≥1.1 * numberOfParticipants}associated with the activity Print Proceedings. • {Income*0.80 ≤TotalCost ≤Income*0.9}associated with the activity Hold Conference. These BDCs, combined with the process model and the conditional sequence flows presented in Figure 3, can be applied in order to ascertain the decision variables, for example lunchPrice in the activity Book Lunch. All the variables and BDCs are explained in detail in the Appendix of the paper. 4. Formalization of the Decision-making support for input data in Business Processes In this section, basic notation and concepts are introduced and the formalism used to express our problem is briefly described. A DSS for input data in business processes undertakes tasks such as an evaluation of alternatives, and communicates its conclusions by taking into account the BDCs that must be consistent in future decisions and in the process model. Therefore, the same model can be involved at different points of decision-making according to the decision variables that the user needs to ascertain, and to the specific values instantiated for the variables of the dataflow. Therefore, two aspects are combined in the decision-making support: the model M(<P,BDC,DF>), formed by activities and control flows, the BDCs associated to each activity, and the dataflow variables; and the decision point DP, formed by the decision variables (whose possible values need to be ascertained) and all the instances of the dataflow variables until the moment <DV,DFI>. According to these two descriptors, the decision-making support can be performed by obtaining all the possible DVI tuples of values for DV that satisfy DBC and the DFI. A DSS for the input data of a business process can therefore be specified by means of the Decision Process Model: Definition of Decision Process Model: This is formed by means of the business process model (M), and the decision points (DP). Each of these parts are defined at the same time as: M=<P,BDC,DF> DP =<DV,DFI> By using these two parts of the description, the decision-making support for input data obtains the DVI, which is a set of correct tuples of instantiation of DV: <M,DP>→DVI | ∀ vdi∈DVI,{BDC ∪DFI ∪vdi}`> The following subsections formalize the model, the decision points, and specify how to obtain the decision-making support in detail. 4.1. Business Process Model (M) A part of the Decision Process Model is the process model P, and is composed of: •SE, one start event to initialize the process. •EE, a set of end events, with at least one element. •A, a set of activities that defines the model of the process. •CF, a set of control flow patterns (AND, OR, XOR) that describes the possible branches to execute. •Cond, a set of conditions associated with the control flows OR and XOR, that describes the paths that the process can take depending on the values of the variables in the dataflow. These conditions are evaluated at runtime, A1 A2 A3 A4 BDC1 BDC2 BDC3 BDC4 BDC5 BDC6 BDC7 Activities Business Data Constraints Fig. 4. Function relation between Activities and BDCs when the values of the variables are known. The BDCs associated to each activity of the process (BDC) are defined with the dataflow variables DF; the DF can then be defined for a range of possible values to assist in the decision support (DFR). The relationship between activities and BDCs is presented in Figure 4, where there is a surjective correspondence between the Activity and the Business Data Constraint sets. The importance of the integration of business rules and business processes was analysed in 33. Every BDCiin a Business Data Constraint set has a corresponding element Ajin the Activity set, such that f(Aj) = BDCi, whereby multiple activities might be turned into the same BDC by applying f, although not all the Activity elements must have a relation with the elements of the Business Data Constraint set. Therefore, the BDC is described by means of the tuple: BDC =<DFR,f:A→BDCs>. The BDCs that describe the range of the possible values for each dataflow variable are assigned to the whole process. For the process example presented in Figure 3, the components of the process according the definitions above are: •A={Establish Conference Rate, Contact Contribution, Paper submission, Author Notification, ...}. •CF ={AND1, AND2, XOR1, OR1}. •Cond of the control flow pattern XOR1is {Income-totalCost <4000}, and for the control flow pattern OR1are {sponsorship ≥5000, sponsorship ≥ 8000}. •BDC is composed of: –DFR ={5000 ≤totalCost ≤50000},{5000 ≤income ≤60000},{50 ≤numEarlyParticipants ≤200}, ... –f:A→BDCs =Establish Conference Rate→ {1.2 * earlyRegistrationFee ≤lateRegistrationFees ≤1.5 * earlyRegistrationFee, fix- Algorithm 5.2 Recursive Algorithm to t a process graph 1: function GraphTraversal(Graph g, Node n, Constraint c) 2: while n is not an END node do 3: if n is an Activity then 4: if c == new Constraint() then 5: c = n.obtainConstraint(); 6: else 7: c.and(n.obtainConstraint()); 8: end if 9: n = g.obtainNeighbour(n); 10: .A single node is returned (for line 3 of Process Graph definition). 11: else if n.type is a Split Control Flow then 12: Set nodes = g.obtainNeighbour(n); 13: .Several neighbours are obtained, one for each branch. 14: Node n1 = nodes.get(); 15: Constraint c1 = new Constraint(); 16: Array ArrayNodes[] = new Nodes[nodes.size()]; 17: ArrayNodes[0] = GraphTraversal(g, n1, c1); 18: c1.add(g.label(n,n1)); 19: integer i = 1; 20: while nodes.next() do 21: Node n2 = nodes.get(); 22: Constraint c2 = new Constraint(); 23: ArrayNodes[i++] = GraphTraversal(g, n2, c2); 24: c2.and(g.label(n, n2)); 25: if n is an OR or an XOR control flow then 26: c1.OR(c2); 27: else 28: c1.AND(c2) 29: end if 30: end while 31: c.and(c1); 32: n = theNodeDistinctOfEnd(ArrayNodes); 33: else .Any join control flow 34: n = g.obtainNeighbours(n); 35: .A single node is returned (for line 2 of Process Graph definition). 36: return n; 37: end if 38: end while 39: return n 40: end function Final report and make payments Any BDCs defined for the whole process, and not just for a specific activity, will be included with an AND Boolean relation with the BDCs obtained from the execution of the algorithm. If there is an activity without any associated BDC, it will be equal to not including a constraint or including a true constraint in the BDC obtained. 6. Evaluating the Decision Process Model at the Decision Points As mentioned in Section 4, an important key to the decision-making support for input data is how to present the information so that it is useful to the user. In order to obtain a numerical representation by means of intervals, we propose the use of the Constraint Programming paradigm to assure that the decision model can be evaluated in an efficient way. This assurance is thanks to the CSP formal representation being very similar to the formal representation of the decision model presented in this paper. Therefore, we propose modelling and evaluating a Constraint Satisfaction Problem with the BDC obtained from Algorithm 5.2, and for the instantiated variables of dataflow. A Constraint Satisfaction Problem (CSP) represents a reasoning framework consisting of variables, domains and constraints. Formally, it is defined as a tuple <X, D,C>, where X={x1,x2,. . .,xn}is a finite set of variables, D={d(x1), d(x2), . . .,d(xn)}is a set of domains of the values of the variables, and C={C1,C2, . . .,Cm}is a set of constraints. Each constraint Ciis defined as a relation Ron a subset of variables V={xi,xj,. . .,xl}, called the constraint scope. The relation Rmay be represented as a subset of the Cartesian product d(xi)×d(xj)×. . . × d(xl). A constraint Ci= (Vi,Ri) simultaneously specifies the possible values of the variables in Vin order to satisfy R. Let Vk={xk1,xk2,. . .,xkl}be a subset of X, and an l-tuple (xk1,xk2,. . .,xkl) from d(xk1), d(xk2), . . .,d(xkl) can therefore be called an instantiation of the variables in Vk. An instantiation is a solution if and only if it satisfies the constraints C. In order to solve a CSP, a combination of search and consistency techniques is commonly used 11. The consistency techniques remove inconsistent values from the domains of the variables during or before the search. During the search, a propagation process is executed which analyses the combination of values of variables where the constraints are satisfiable. Several local consistency and optimization techniques have been proposed as ways of improving the efficiency of search algorithms. In a CSP, the inclusion of a constraint in the set Chas the same effect as including this constraint with an ∧relation with the set C. For this reason, in this case the CSP will be composed of the variables of the dataflow, both instantiated and non-instantiated, of the BDC obtained from Algorithm 5.2, and of the BDCs defined for the whole process. The parts of the CSP according to the definition of Decision Process Model are therefore: •X:DF •D:DFI •C:{BDCs defined for the whole process} ∪ {BDC obtained from the execution of the algorithm GraphTraversal} Since the CSP returns all the possible values of the variables (DF in this case), it is necessary to reduce it to present only the values of the decision variables (DV). To this end, the decision variables are defined as objectives during the propagation process where the variables are instantiated. This enables the search to stop the instantiation in the branches where no new values of decision variables can be found, thereby bounding the unnecessary combinations of values. For each solution found, each value of the decision variables is stored in a sorted list. Each of these sorted lists is treated in order to return the list of intervals for each variable of decision. For example if the values {1, 2, 3, 5, 8, 9, 10} are found for the variable x, the list of intervals built is {[1, 3], [5, 5], [8, 10]}. For the example of Figure 3, the CSP built to analyse the possible valid values of the variable of decision NumberOfProceedings in the activity PrintProceeding (which uses the variables and BDCs presented in the Appendix) is: //All the variables of the dataflow totalCost, numEarlyParticipant, numLateParticipant, ... Integer //The variables instantiated until the decision point EarlyRegistrationFee = 500 LateRegistrationFee = 750 .. . //Range of the dataflow variables and BDCs for the whole process totalCost[5000..50000]Integer numEarlyParticipants[50..200]Integer numLateParticipants[10..100]Integer numParticipants[60..300]Integer CostPerParticipant = 3*lunchPrice+dinnerPrice+proceedingsPrice .. . //BDCs obtained from the algorithm GraphTraversal BDCs of the Activity Establish Conference Rate BDCs of the Activity Contact Partner ... (((Income-totalCost<4000) ∧(true)) ∨(¬(Income-totalCost<4000) ∧ (sponsorship≥5000)∧(Local invitation) ∨ ((sponsorship≥8000) ∧(International invitation)))) //BDCs of the Activity Hold Conference //BDCs of the Activity Final report and make payments Goal for branching(numOfProceedings) The CSP solver used in our proposal is ChocoT M 12. Once the resolution of the CSP has finished, the list of intervals obtained is used to inform the user about the possible correct values. For the example, once earlyRegistrationFees,lateRegistrationFees,venueCost,sponsorship,sentPapers and acceptedPapers have been instantiated in the process with the values {500, 750, 2500, 8500, 150}respectively, in the activity Print Proceedings the interval {[67, 123]}is obtained in order to ascertain Process Layer Business Data Constraints Repository Presentation Layer Application Layer Persistence Layer Data Input Decision Making Support Layer Numerical Solver Symbolic Solver Fig. 7. DSS for Decision-making support for Input Data the possible values of the decision variable numberOfProceedings. 7. Implementation details in a Case of Study In order to show the benefits of the decision-making support for input data in business process instances, we have implemented a solution based on the Process Aware Information System (PAIS) framework and illustrated how to facilitate the input data support into a commercial solution. 7.1. Decision Support System for Input Data in Business Processes In order to permit the decision-making support for input data at various points of the process based on the BDCs, this paper is based on an extension of the classic PAIS framework 16, as presented in 17, and shown in Figure 7. In general, a PAIS architecture 18 can be viewed as a 4-tier system as presented in 16, where, from top to bottom, the layers are: Presentation Layer, Process Layer, Application Layer and Persistency Layer. As a fundamental characteristic, PAIS provides the means to separate process logic from application code. Data decision-making support and business process layers are two parallel and ”independent” systems. They are considered independent since they can be simultaneously executed in separate machines, for different applications. However, this independence fails from the point of view of dataflow information, since, for the various decision points, the Data Input Decision layer uses the instantiated vari- ables in the dataflow and uses the decision variables that the process needs. With the presented DSS, it is possible to design both the business process model and the BDCs, thereby achieving higher levels of flexibility and agility in the business process management. One of the items that also needs to be studied is how to store the BDCs, and how to define the relation between each of them and the activities of the process. When a great deal of BDCs have to be handled, the use of a database to store and manage these constraints is mandatory, especially when not all the BDCs are established for the whole business process, and the relation between activities and BDCs has to be defined. The necessity to store the business compliance rules was analysed in 19, but failed to take data semantics into account. However, BDCs cannot be stored in a classic relational database, since storing a BDC also implies storing all the details related to its variables, the domain of variables, and data persistence relationships. The difficulty in storing BDCs arises due to the problem of how to store the constraints themselves as data, since they do not belong to a type supported by commercial databases. In order to manage constraints, we propose the use of Constraint Database Management Systems (CDBMS) as explained in 20. That proposal is based on an envelope for a database management system to manage Constraints as a classic type, which has been proposed for the description of the BDCs. A similar way to store BDCs was used in previous work 7. This solution shields the user from unnecessary details on how the BDCs are stored and queried. Once how to store the BDCs is ascertained, the next question is how each BDC is related to each activity and with the rest of the process. Figure 8 represents the relations necessary to describe that a Process has a set of Dataflow variables, available for the Activities. Each BusinessDataConstraint can be associated with a set of activities or to the whole process, while each Activity can have several associated BDCs. These associations are established in the table Activity/BDC. Activities (pk) IdActivity: int Name: String Activity/BDC (pk) IdBR: int (pk) IdActivity: int 1..1 0..n Business Data Constraints (pk) IdBDC: int rule: Constraint 0..n 1..1 Business Processes (pk) IdProcess: int Name: String bpmn2.0: XML DataFlowVars (pk) IdVariable: int Name: String Type: String 1..1 0..n 1..1 1..n 0..n 0..1 Fig. 8. Relations between BDCs and Activities Presentation Layer } Connector MARTIN (MAking Reasoning for daTa INput) Process Layer Data Input Decision-Making Support Layer 1 4 2 3 Fig. 9. DSS for the decision-making support for input data with tools 7.2. Computational application for the Decision-Making support for Input Data In order to facilitate the creation of BDCs and the decision-making of the process, we have implemented an application and a connector that follow the DSS presented in Section 7.1. This solution uses a specific set of technologies that could be replaced by another set. The specific configuration that we have implemented is presented in Figure 9, which describes a possible combination of tools to execute the decisionmaking support for input data. We have prepared a video 21 where the steps for the design and execution of the decision support are shown. The steps to configure and use the application are: (1) Modelling the business process and defining the dataflow variables (P, DF): The business process and the dataflow variables can be modelled in any Business Process Management System, for example: IntalioT M , ActivitiT M , and Bonita Open SolutionT M . In the case of study presented, we have used Bonita Open SolutionT M since it is an open-code application with free distribution, and is commonly used in the private company sector. Once the process is modelled, the designer of the process must decide on the decision points associated with any activity. (2) Locating the decision points and decision variables (DV): If a designer considers allocating a decision point into a determined activity, then a connector must be added in the activity to relate it with the software that executes the decision. We have implemented a connector (as shown in the video 21) to facilitate the relation between the decision point and the reasoning software (MARTIN) that obtains the possible and correct values of the decision variables. When a connector is included in an activity, it is necessary to define the decision variables. In the connector, called ”Data Decision-Making Connector”, all the dataflow values and the decision data variables are sent at runtime to the software that executes the evaluation of the decision-making support for the model obtained at design time, as explained in Section 6. (3) Creating the BDCs (BDC): Once the process model is defined, it is necessary to create the BDCs and associate them to each activity, using the solution of Figure 8. The decision-making process uses all the variables instantiated in the dataflow at runtime, and the BDCs that represent the possible correct values in the future. To this end, we have implemented an application called MARTIN: MAking Reasoning for daTa INput, to facilitate the creation of BDCs, and the association of the BDCs to the activities. Most commercial tools provide an XML representation of the created process that follows the BPMN 2.0 13. For this reason, we have implemented a transformation from a .bpmn file that represents the type models described in this paper (formed by activities and control flows), into our Process Graph. When the XML of the process is analysed, the tables Business Process,Activities, and DataflowVar shown in Figure 8 are filled in automatically, since the XML of the process holds all this information. It is then possible to create and/or assign BDCs to the various activities. In order to provide a simple way for the business expert to add BDCs, the interface (shown in Figure 10.a) enables the business process model to be viewed, and BDCs to be assigned to the activities that belong to the business process (Figure 10.b). a) Creating BDCs b) Assigning BDCs Fig. 10. Connector to create and assign BDCs to activities (4) Instantiating the business process model (DFI) and obtaining the decision variables instantiation (DVI). Once the business process model has been designed in a Business Process Management System, the execution process can be performed. When a business process instance executes an activity with a Data Decision-Making Connector, the dataflow values of that instance and data decision are sent to the Data Input Decision-Making Support layer which implements the evaluation of models, as explained in Section 6. Figure 11 presents an example of the form that shows the possible intervals for each decision variable. Fig. 11. Form of Activity Establish Conference Rate at runtime 8. Related Work Decision-making support in business processes carries significant contributions related to how to model the process, which in turn help the designer to decide the best combination of activities to achieve an objective. A simulation-based approach to decision-making support is proposed in 22 with respect to complex dynamic systems, and includes uncertain data. A methodology to optimize a process where the description is not clear (fuzzy) is put forward in 23. However, in both papers, the help in the business process has been oriented towards the design of the model, or the redesign of the business process 24, by looking at the quality of the process at design time, but not how this process works at runtime, thereby missing the importance of the variables of the dataflow. Data has also been involved in other studies related to decision support; for example 25 proposes an operational decision support for the construction of process models based on historical data to simulate processes. That proposal includes a generic approach to a business process for operational decision support, and includes business process modelling and workflow simulation with the models generated, by using process mining. Other work related to how to model the processes, such as that in 26, proposes a framework of assistance to create models which take the necessary resources involved in the process into account. In that paper, the data that describe the resources of the execution of the process are used, but not the data that flows at runtime, nor does it consider how this assistance can help at runtime. In general, papers found in the literature related to decision-making support are not focused on the assistance of the user for the input data. Although work such as 27 is oriented towards auditing the process in order to detect gaps between the information system process flow and the internal control flow in the business process, the quality of the data values at runtime is not a cause of concern for the authors. This detection can be derived from the existence of an oversight in the description of the semantics of data in the business processes. The use of compliance rules has traditionally been used for the validation of the business process, not for user assistance. The validation of business process traces has been a field of intense research over recent years using business compliance rules: see 28 as an entry point into this literature. However, these types of proposal cannot be used in the decisionmaking support for input data, since they are focused on the compliance of the process model structure 29, 30. Regarding how to model data-aware compliance rules, studies such as 10, 31, 32, and 34, have defined graphical notations to represent the relationship between data and compliance rules by means of data conditions. These types of compliance rules cannot therefore be used to infer the possible values of the variables that are involved in the decisions. In 35, ”semantic constraints” and the SeaFlows framework for enabling integrated compliance support are proposed. Furthermore, in 37, a preprocessing step to enable data-aware compliance checking in an efficient manner is presented: the data describe under what conditions the activities can be executed. In general, many examples can be found where data objects are used for compliance verification, for instance, the semantically annotating activities with preconditions and effects that may refer to data objects are introduced in 38, but none of these factors assist the user with this information at runtime. Summarizing, to the best of our knowledge, only one preliminary study 17 exists that uses the knowledge of the business process model and the BDCs for decisionmaking support for input data, while the rest of the proposals are focused on the design or re-design of the business process model. The current paper constitutes an improvement on the previous paper by: including the process graph definition to represent the model; defining the algorithm to traverse the graph; and by implementing an application that can be integrated with commercial tools. 9. Conclusions and Future work In this paper, the use of BDCs is proposed to infer the possible input data values in a business process instance, by taking into account the model of the process and the decision points where the assistance must be executed. In order to meet this challenge, two different parts have been distinguished: an analysis of the process model at design-time, by means of an algorithm to traverse the business process model; and an evaluation of the decision model at runtime, to obtain the possible values of the decision variables using constraint programming. In order to implement this proposal, a case of study has been developed using Bonita Soft and an application called MARTIN has been included in order to create, include, and evaluate the BDCs in the business process model. One aspect that can be improved in this work is the presentation of the possible and correct values of the decision variables to the user. In the case of numerical decision support, this improvement could be attained by showing the user the possible combinations for various decision variables simultaneously, instead of solely presenting the intervals for each variable. As future work, we also plan to include a symbolic representation of the possible correct variables instead of interval values. Further research could be analysed in greater depth, such as: a) In the current proposal, all the BDCs are defined for all instances, but it would be possible, depending on the values of the dataflow or the moment where the instance is executed, that a different set of BCDs could be involved in the decision support. b) Related to the above proposal, there is also the possibility of including new BDCs for the user at runtime, which would render the decision-making support for input data more customized. This would help the user to include, for example, reductions of the domains for determined decision variables associated with future decision points, even before the final value is introduced. If, at a decision point, there are no possible values for a decision variable, it implies that no BDC is consistent. For future work, we propose reinforcing the detection of the minimum set of BDCs that are not satisfiable, and ascertaining how this situation can be fixed by means of input data decisions. Acknowledgement This work has been partially funded by the Junta de Andaluc´ıa by means of la Consejer´ıa de Innovaci´on, Ciencia y Empresa (P08-TIC-04095) and by the Ministry of Science and Technology of Spain (TIN2009-13714) and the European Regional Development Fund (ERDF/FEDER). Appendix Dataflow Variables: •totalCost,income is the total cost and income of the conference respectively •numEarlyParticipants is the number of people attending, registered in the early period •numLateParticipants is the number of people attending, registered in the late period •numParticipants is the final number of participants •costPerParticipant is the cost per participant, and includes lunch and dinner, cost of proceedings, etc. •earlyRegistrationFee is the cost of early registration •lateRegistrationFee is the cost of late registration •sponsorship is the income from the companies that sponsor the event •dinnerPrice is the price of the gala dinner