Run-Time Auditing for Business Processes Data Using Constraints

Run-Time Auditing for Business Processes Data Using Constraints Mar´ıa Teresa G´omez-L´opez and Rafael M. Gasca Departamento de Lenguajes y Sistemas Inform´aticos, Universidad de Sevilla, Spain {maytegomez,gasca}@us.es http://www.lsi.us.es/~quivir Abstract. Business processes involve data that can be modified or updated by various activities. These data must satisfy the business rules associated to the process. These data are normally stored in a relational database, and hence the database has to be analyzed to determine whether the business rules can be satisfied. This paper presents a framework including a run-time auditing layer where the correctness of a database can be analyzed at different checkpoints of a business process according to the data flow. It provides an early detection of incorrect action on stored data. Furthermore, in order to manage the current business rules, the use of the constraint programming paradigm is proposed and the enlargement of the Constraint Database Management Systems to support business rules. Keywords: Reasoning related to business processes, business rules, Constraint Programming. 1 Introduction Organizations currently need to manage a great deal of data. This data must be conveniently gathered, transformed and stored according to a business data model. The evaluation of the correctness of data is very important since none of the activities of a process can work correctly using incorrect data. For the design of a whole business process management (BPM) [1], it is necessary to design the database, the model of activities, and the causal and temporal relationships between them. Business rules can help to complete this information, since they can be used to validate business data [2]. In [3] there is a depth analysis about the integration of rule and process modelling and the shortcomings of the existing solutions. Our work is based on [4], although we propose to separate the evaluation into an independent layer that checks the business rules oriented to databases as a contract that describes the behaviour of the activities in different moments of the business process instance and only for involved data. This paper takes a new data-oriented view of business rules engines, when there is greatest number of requirements, vast amount of data and rules. It makes necessary to search new solutions and to define higher expressiveness for business rules. Due to the complexity of business rules and data relations, it has become necessary to create a new way to represent, store and validate business rules in function of data stored in a relational database. This paper is based on to validate Business Data Objects, that are defined by the set of data stored in a relational database that are updated in a business process instance. This Business Data Object is changed for the different tasks of the process, passing through different Business Object States. Based on these ideas, the contributions of this paper are: – To define a business rules language based on Constraints. When we mention the world Constraint in this paper, we are talking about the constraint programming paradigm, a way to represent the correct values of a set of variables related by equations and inequations. To the best of our knowledge, no constraint satisfaction problems have been used to represent and validate business rules. Current business rules engines use the if ... then format to represent business rules. However by using constraints the information is represented at a more abstract level, since languages based on constraints include and improve all the capacity of representation of current rules engines, such us Drools, Fair Isaac Blaze Advisor, ILOG JRules and Jess. – To redefine a repository to store business rules. If business rules are stored and well structured in a database, it will be easier to support continuous evolution of the rules in accordance with business demands, and to select which rules can be validated at any moment. To this end, we propose the use of Constraint Databases. – To propose a run-time auditing framework to check the conformity of the persistent data managed and data flow in a business process. Not all the business rules are activated in the whole business process [5]. We propose a framework where it is possible to validate a set of data from a database depending on the data flow. The combination of Constraint Databases and an audit layer permits the determination of unsatisfiable rules as soon as possible. Auditing the stored information and data flow is very important since data are normally introduced by hand. Hence, this type of population of databases produces numerous errors and inconsistent information that fluctuate. When a software activity works incorrectly, for the same input it will produce the same output, but this axiom is not true for human tasks. This paper is organized as follows: Section 2 gives a motivating example where constraints can be used to validate relational databases. Section 3 presents the most interesting aspects related to Business Rules and the new orientation to constraints. Section 4 explains how business rules can be stored in an efficient way. Section 5 sets out the proposed framework. Section 6 presents an extension of the constraint language for aggregate operators, and shows an example of it. Finally, conclusions and future work are presented. 2 Motivating Example of Business Process and Business Rules The use of business rules represented as constraints has been applied to a real business process where the goal is to negotiate the collaboration projects between private companies and research groups. The persistent layer of the business process is formed of a database with 86 tables, 900 fields within these tables, more than 112.200.000 tuples, 224 triggers and 107 integrity constraints. A total of 25 employees belonging to 6 separate departments modify the stored information. In this case, the audit layer must analyze 23 states. The business process for the example is shown in Figure 1. In the given example, 270 business rules have been created where 435 variables are involved. Application project Add research groups Add companies Request quantity for research group Request quantity for companies Application end Technical checking Approved Project? External Evaluation Internal Evaluation Resolution Estimate resolution Acceptation of contract Add Addenda Add Contracts Register modifications Add Addenda Final resolution Monitoring External auditing Economic justification Recovers and payments Refunds Royalty bills Overhead bills Add auditor Add branch Fig. 1. Example of a real business process This process is formed of a set of tasks which are related through various sets of business rules. Each task is in charge of a state of the project. Business rules are not described in a global way, since each task modifies certain data of a relational database and it will be necessary to evaluate different business rules. 3 Business Rules by Constraints Business rules represent a natural step in the application of computer technology aimed at enhancing productivity in the workplace. When administrators of a business process want to change some functionality of the business, they have to wait for the reprogramming of the system. The adoption of business rules adds another tier to systems that automate business processes. Compared to traditional systems, this approach presents major advantages, as analyzed in depth in [6], and includes: A lower cost incurred in the modification of business logic; a shorter development time; externalization of the rules and ease of sharing among multiple applications; faster changes and with less risk. If the expressiveness of business rules is improved, the above mentioned characteristics are also improved. For this reason, we propose the use of constraints instance of the if ... then axiom. The constraints proposed for the definition of business rules can be expressed as a Boolean combination with and/or operators of numerical equations and inequations for Integer, Natural and Float domains. The use of constraints to represent business rules extends their formal semantics, since more knowledge can be represented and the description is less limited than when decision trees or a set of facts are employed. The use of constraints enables Integrity Rules, Derivation Rules, Reaction Rules and Production Rules to be represented, and the evaluation of whether a set of data is correct for an organization policy. For example, after the Resolution task of Figure 1, it is necessary to check that: whether the summation of hardware cost, software cost and human cost is equal to the total cost of the project, then the human cost is less or equal than 10% of the software cost; and whether the summation of these three values is smaller than the total cost, then the human cost has to be less or equal than 15% of the hardware cost. These business rules can be expressed with the constraints: (hardCost +softCost + humanCost =totalCost ∧humanCost ≤hardCost ∗0.10) ∨(hardCost + softCost +humanCost < totalCost ∧humanCost ≤hardCost ∗0.15) where hardCost[1..100],softCost[1..150],humanCost[1..100],totalCost[5..250] for Float domain. By using constraints to represent business rules, it is possible to validate tuples with business rules that are not explicitly described. Some examples of the inferred business rules for the above constraints can be: –hardCost ≤totalCost,softCost ≤totalCost,humanCost ≤totalCost –humanCost ≤totalCost ∗0.10 –if hardCost =10thentotalCost[12..161] ∧humanCost =1 By using constraints and depending on the instantiation of the variables, it is possible to evaluate a tuple even if some values are not still instantiated (stored in the database), that it is equivalent to say that the value of the variable in the tuple is null. Hence, it permits an early detection of errors, before the whole tuple of values of variables is fixed. In order to infer these unknown values, a Constraint Satisfaction Problem (CSP) can be created. The CSPs represent a reasoning framework consisting of variables, domains and constraints. Formally, it is defined as a triple <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. A constraint Ci=(Vi,Ri) specifies the possible values of the variables in Vsimultaneously to satisfy R[7]. When an objective function f has to be optimized (maximized or minimized), then a Constraint Optimization Problem (COP) is used, which is a CSP and an objective function f. By using the constraint programming paradigm, when the values of variables related to a business rule are determined in various tasks of a business process, it is not necessary to wait until all the variables are instantiated to determine whether the business rules are satisfiable. Through solving the CSP, the possible values for the variables will be found, although they are not stored in the database and cannot be inferred using only classic business rule management. 4 Database Management and Business Rules Most computer applications read and update data from databases. Therefore, data (the stored representation of facts in databases) is a fundamental component of information technology. Improvements in the integration of data in business processes are necessary, since it is common that not all information is transferred by means of data flow, but is modified via a database. Business data is data that is directly used in business operations and would be used even in the absence of computerized systems. Metadata is additional data that describes what these computerized systems contain and how they work. Metadata also describes the business data, such as definitions of business terms. In order to define the equivalence between the business rules layer and data persistence layer, the BOM (Business Object Model) was introduced [8], although not the relation between persistence layer and business layer was defined. In order to add business rules to a business process related to its data, it is necessary to add semantic information to business rules to support database correctness. Current architectures contain no data flow integrity and audit trail since all business logics are hard-coded. This means that business processes cannot be easily related to any which involves complete data flow traceability. The data model and the database are not the same thing, and the data model cannot simply be derived from the database by automated reverse engineering, something that is often postulated as a solution where no data model exists. For instance, the database contains only physical column names, but the rules engine will inevitably need the names of these columns. Hence, each business rule has to be transformed into a query evaluation over real tables and columns with a condition. The relation between business rules variables and database fields has to be stored. We propose the use of a system based on a wrapper over a database management system to store it and to transform business rules into query evaluations. We propose supporting the relation between business rules and persistence data through the use of Constraint Databases. These constraints can be associated to different moments of business process, in order to avoid the evaluation of all business rules, and the whole database. 4.1 Constraint Database Management System When a great deal of business rules have to be handled, the use of a database is a mandatory decision, especially when not all the business rules are established for the whole business process. The storage of business rules also implies storing all the details related to its variables, the domain of variables and data persistence relationships. These types of information and business rules expressed by constraints can be supported by Constraint Database Management Systems (CDBMS). Constraint Databases (CDBs) were initially developed in 1990 with a paper by Kanellakis, Kuper and Revesz [9]. The basic idea behind the CDB model is to generalize the notion of a tuple in a relational database to a conjunction of constraints, since a tuple in relational algebra can be represented as an equality constraint between an attribute of the database and a constant. In real business process, a great quantity of business rules must be defined, hence a repository is necessary in order to evaluate them as soon as possible, and to render updating easy and efficient [10]. The CDB used in this paper is based on Labelled Object-Relational Constraint Database Architecture (LORCDB Architecture) [11] with an extension to represent data business object and database model relations. LORCDB Architecture stores numerical constraints as objects indexed by the variables contained within, hence, when a CDB is created, three auxiliary tables are also automatically created (Constraints,Variables and Constraints/Variables)which relate each constraint with its variables (Figure 2). The table Variables stores the names of the variables, their identification and their type (Integer, Natural or Float), and for business rules, two new fields have been included in the Variables table (Table and Field) to store the relation between metadata and persistence data layer. This design enables to update the business rules according to the persistence layer modifying the value in the tables of the CDBs. Constraints/Variables (k)IdConstraint: int (k)IdVariable: int Range_Inf: number Range_Sup: number Variables (k)IdVariable: int Name: String Type: String Table: String Field: String Constraints (k)IdConstraint: int Constraint: Object Label: String 1..1 1..n 1..n 1..1 BusinessRules IdState: int rule: Constraint 1..1 1..1 Fig. 2. CDB tables to index business rules with constraints and variables 5 Run-Time Auditing Framework In order to permit the validation of business data in different states, and to represent and store business rules using constraints, we propose an extension of the classic Process Aware Information System (PAIS) framework [6]. Increasingly, business rules are also considered as a critical component of BPM solutions, due to the need to ensure flexibility. Some analysts believe the combination of business rules technology with BMP offers an agile approach to workflow and enterprise integration. The definition of an auditor of business data objects into separated layers enables the updating of processes or rules. In this context, the notion of PAIS provides a guiding framework to understand and deliberate on the above developments [12], [13]. In general, a PAIS architecture Audit Layer Process Layer RDB CSP Solver CDB Presentation Layer Application Layer Persistence Layer Fig. 3. Framework for Run-time Auditing can be viewed as a 4-tier system as presented in [6], 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. We propose a new framework shown in Figure 3, where a new layer is added to validate the business data objects, and where the persistence layer can also be accessed from the Audit Layer in order to facilitate database auditing. This framework enables the relational database to be audited according to an associated set of business rules and according to the data flow. Audit and business process layers are two parallel and “independent” systems. They are independent since they can be executed in separate machines, for different applications, and at the same time. This independence is breaking from the point of view of data flow information, since the Auditor uses data flow information of the process layer to detect the non-satisfiable business rules. The Audit layer is called from the process layer, and depends on the business state or activity and the data flow instances of each moment. In order to determine how the communication between these layers is done, it is necessary to describe the Audit Layer in a deeper way. Audit Layer The function of the Audit layer is to capture the identification of the state to determine which business rules have to be analyzed, and the data flow values to delimit the tuples of the database. The behaviour of the auditor enables the determination of whether a business data object satisfies a set of rules from several points of view. The use of the audit layer implies: –For reasons of complexity in time, it is neither possible nor necessary to analyze all the tuples of the database. In the different instances of the business process, only a set of tuples is modified. For example, if a business process is in charge of updating the information related to a project, then it is only necessary to analyze the tuples where this project is involved. This information is transferred to the Audit layer by means of the data flow. As presented in Data Flow CDB RDB ------- ------- Business Rules Tuples CSP Select T.a,T.b,… from T where T.c=[dataflow].c 1 2 3 4 Fig. 4. Audit Layer Procedure Section 4.1, the constraints, variables and fields of the relational database are indexed, hence a query can be created using the data flow (query condition parameters) and business rules variables. –We propose that business rules are related to a temporal aspect [14], which means that business rules depend on the state of the business object, hence the auditor has to be informed about which business object state to evaluate. This information is used by the auditor to establish which set of rules stored in the Constraint Database has to be analyzed and combined with the tuples of the relational database to build a CSP. Audit Layer Procedure Steps: The steps (represented in Figure 4) to audit the data of a relational database, which depend on the data flow values and the business rules stored in the CDB, are to: 1. Select the business rules related to the state from the CDB,therebyobtaining the tables and field of relational database that are involved in the audit process. 2. Build a query where the attributes of the “projection” are the related attributes obtained in the previous step, and the condition (where) is defined by the values of the data flow. 3. Obtain the tuples that have to be evaluated, by executing the query of the previous step in the relational database. 4. Create and solve the CSPs for each tuple obtained from Step 3 and the business rules obtained from Step 1. Applying the process to the example presented in Section 3, where the table of the database that has to be validated is presented in Table 1, the steps for the procedure become: 1. The constraints obtained to create the CSP are: Float var hardCost[1..100], softCost[1..150], humanCost[1..100], totalCost[5..250] (hardCost +softCost +humanCost =totalCost ∧humanCost ≤hardCost ∗0.10) ∨(hardCost +softCost +humanCost <humanCost ∧humanCost ≤hardCost∗0.15) 2. Using the table Variables of the CDB to know that the fields of the variables hardCost,softCost,humanCost,totalCost are respectively FhaC , FsC ,FhuC and FtC , then the following query is created: Select T.FhaC ,T.FsC ,T.FhuC ,T.FtC from Twhere T.ID=[dataflow] and where it is supposed that the data flow has the value for identification equal to 430, and there is no condition about year. 3. The result of this step is the four first tuples of Table 1. 4. Each obtained tuple is evaluated by building a CSP. For the example of Table 1, the business rules are satisfiable for the first and fourth tuples. In this example, it is known that the third tuple is not satisfiable although not all its values are instantiated. Table 1. Example of tuples to evaluate ID Year haC sC huC tC 430 2007 20 8 1 29 430 2008 20 7 1 15 430 2009 100 150 null null 430 2010 100 null 4null 431 ... ... ... ... ... 6 Extending Constraint Business Rule Language with Aggregate Operators The use of constraints to represent business rules can be extended with aggregate operators. Although other proposals exist which are oriented towards the definition of a monitoring language [15], they are not related to monitoring data flow to audit database information depending on business rules. We propose the addition of new types of business rules that can be defined over a set of tuples of relational databases: Minimum(min(v)), Maximum(max(v)), Count(count(v)), Summation(sum(v)) or Average(avg(v)), where vrepresents any variable involved in a business rule. Going back to the example of Table 1, it is possible to define a business rule where the summation of hardCost for an ID has to be equal to the summation of softCost for the same ID. We have adapted the existing operators in SQL, using them to represent business rules: sum, avg, min, max and count. For each type, the creation of the model is: – Sum(v): The summation will obtain the ntuples that satisfy the condition of the query. With the variables involved in the rule, and with the domain of v, the following CSP is built where iand jrepresent the domain of vstored in the CDB: