WO1999056193A2 - Method and system for routing data based on a business rule stored in a relational database - Google Patents

Abstract

A method and system for routing data based on one or more business rules stored in a relational database is disclosed. A method according to one aspect of the invention includes the steps of creating a first table for storing business rules; storing a first business rule in a first record of the first table; storing a second business rule in a second record of the first table; and storing a third business rule in a third record of the first table, wherein the third business rule references the first and second business rules. The method also includes the steps of reading the third business rule from the third record of the first table; reading the first and second business rules from the first and second records of the first table, respectively; evaluating the first and second business rules; evaluating the third business rule based on the evaluation of the first and second business rules; and routing the data based on the evaluation of the third business rule.

Description

METHOD AND SYSTEM FOR ROUTING

DATA BASED ON A BUSINESS RULE STORED IN A RELATIONAL DATABASE

CROSS-REFERENCE TO RELATED APPLICATION

This application claims priority to U.S. Provisional Patent No. 60/083,716, filed April 30, 1998, which is incorporated herein by reference.

BACKGROUND OF THE INVENTION

The present invention relates to a method and system for routing data based on one or more business rules that are stored in a relational database.

A business typically operates according to a number of business processes, which may be made up of one or more tasks. For example, a computer manufacturer may procure materials indirectly through channels in order to fulfill its Maintenance, Repair, and Operations ("MRO") requirements. In this case, the computer manufacturer may implement a computer-based MRO procurement approval process to obtain the materials, which process may include tasks such as creation of a purchase order document, submission of the document to a purchasing department, etc.

A business rule is logic that is used to control the routing of data so that tasks for a particular business process can be executed. For example, within an MRO procurement approval process, a business rule may dictate that a purchase order document must be routed from a purchasing agent to his supervisor for final approval before being transmitted to a supplier. In another scenario, the business rule may include conditional task execution. Thus, another business rule may state that if the amount of the purchase order is less than some predetermined amount, then the purchase order may be routed from a purchasing agent directly to a supplier without the need for a supervisor's final approval.

Automated systems have been developed for routing data according to business rules. For example. U.S. Patent No. 5.734,837 describes a software-based method and system for building business process applications in terms of the tasks that make up the business process. The software system has two functional sets. The first is a set of graphical tools that can be used by a developer or business analyst to map out a business process. The second is a set of tools that can be used to document and specify the attributes of each task. The business process and task definition structures are stored in a definitions database.

U.S. Patent No. 5,799,297 describes workflow software, which handles processing by routing items and managing workflow based on a set of user-defined organization-specific rules. The rules are configured such that an activity is associated with a variable and constant by way of a comparison operator. A workflow engine routes tasks to one or more workers. A rule evaluator, which is operatively coupled to the workflow engine, evaluates a plurality of organization-specific rules and provides instructions to the workflow engine for routing the tasks in a predetermined sequence.

The rule evaluator is operatively coupled to an external program execution mechanism to execute a program instruction external to the workflow management system. In this way, the functionality of the workflow management system can be extended beyond a core workflow management feature set in the workflow engine.

The prior art described above suffers from several drawbacks. More specifically, due to the way that the business rules are stored in memory, the user interfaces are quite cumbersome. Thus, a user must often enter data that is a part of one business rule, even though the same data may have been previously entered for another business rule.

Similarly, the input of complex or nested business rules typically mandates the entry of more basic business rules. In the prior art, the basic business rules are typically entered multiple times - that is, one time for each complex business rule of which they are a part. These multiple entries significantly increase the probability of erroneous input and complicate the implementation of the business process. Further, the prior art typically uses complicated data processing protocols for adjudging compliance with a business rule. This tends to result in less than optimum data processing speeds and increased memory storage space requirements.

In view of the foregoing, there is a need for a method and system that permits less cumbersome input and storage of business rules and that employs programming techniques of limited complexity to resolve such rules.

SUMMARY OF THE INVENTION

A first aspect of this invention is directed to a method for facilitating the routing of data. The method includes the step of creating a record in a first table for storing a business rule. The business rule comprises a source component, a target component, and an operator indicating a relation between the source component and the target component. The method also includes the steps of receiving the source component of the business rule; storing the source component of the business rule in the record of the first table; receiving the target component of the business rule; storing the target component of the business rule in the record of the first table; receiving the operator of the business rule; and storing the operator of the business rule in the record of the first table.

A second aspect of the present invention relates to a system for facilitating the routing of data. The system includes a memory comprising a first table having a record for storing a business rule, wherein the business rule comprises a source component, a target component, and an operator indicating a relation between the source component and the target component. The system also includes a processor in communication with the memory, wherein the processor is operative to receive the source component of the business rule; store the source component of the business rule in the record of the first table; receive the target component of the business rule; store the target component of the business rule in the record of the first table; receive the operator of the business rule; and store the operator of the business rule in the record of the first table.

A third aspect of this invention is directed to a method for facilitating the routing of data. The method includes the step of reading a first business rule from a first record of a first table, wherein the first business rule comprises a first source component, a first target component, and a first operator indicating a relation between the first source component and the first target component. The method also includes the steps of evaluating the first source component of the first business rule; evaluating the first target component of the first business rule; determining whether the relation between the first source component and the first target component indicated by the operator exists; and transmitting a result indicating the determination.

A fourth aspect of this invention relates to a system for facilitating the routing of data. The system includes a memory comprising a first table having a first record for storing a first business rule, wherein the first business rule comprises a first source component, a first target component, and a first operator indicating a relation between the first source component and the first target component. The system also includes a processor in communication with the memory, wherein the processor is operative to read the first business rule from the first record of the first table; evaluate the first source component of the first business rule; evaluate the first target component of the first business rule; determine whether the relation between the first source component and the first target component indicated by the operator exists; and transmit a result indicating the determination.

A fifth aspect of the present invention is directed to a method for routing data. The method includes the steps of creating a first table having a plurality of records for storing business rules; storing a first business rule in a first record of the first table; storing a second business rule in a second record of the first table; storing a third business rule in a third record of the first table, wherein the third business rule references the first and second business rules; reading the third business rule from the third record of the first table; reading the first and second business rules from the first and second records of the first table, respectively; evaluating the first business rule; evaluating the second business rule; evaluating the third business rule based on the evaluation of the first and second business rules; and routing the data based on the evaluation of the third business rule.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A depicts an exemplary business rule BRO that may be used to route data in connection with a business process. FIG. IB is a diagrammatic representation of a business process that includes the exemplary business rule BRO depicted in FIG. 1A.

FIG. 2A illustrate embodiments of Tables 1 and 2 for storing attributes and business rules, respectively.

FIG. 2B illustrates embodiments Tables 1 and 2, which have been populated with data and configured in a relational manner.

FIG. 3 is a flow chart depicting a process for storing attributes in a table.

FIG. 4 is a flow chart depicting a process for storing an embodiment of a basic business rule in a table.

FIG. 5 is a flow chart depicting a process for storing another embodiment of a basic business rule in a table.

FIG. 6 is a flow chart depicting a process for storing an embodiment of a complex business rule in a table.

FIGS. 7A and 7B are flow charts depicting a process for evaluating complex and basic business rules, respectively.

FIG. 8 depicts an exemplary e-commerce system architecture. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

Reference is now made to the accompanying Figures for the purpose of describing, in detail, the preferred embodiments of the present invention. The Figures and accompanying detailed description are provided as examples of the invention and are not intended to limit the scope of the claims appended hereto.

The present invention, as defined by the claims, provides a novel and unique method and system for routing data based on one or more business rules that are stored in a relational database. In so doing, the method and system facilitates input of such business rules with minimal effort by a user and employs programming techniques of limited complexity for evaluating such rules.

The following detailed description will refer to "attributes," "business rules,"

"basic business rules," and "complex business rules." As used herein, an "attribute" is data that is considered in the conduct of a business process. A "business rule" is logic that governs the routing of data in a business process. A "basic business rule" is a business rule that does not reference another business rule. A "complex business rule" is a business rule that references at least one other basic business rule and/or complex business rule.

For the purpose of illustrating the various aspects of the present invention, the following detailed description will be set forth with regard to a procurement approval process. This process may be used by a computer manufacturer to procure materials indirectly through channels in order to fulfill its Maintenance, Repair, and Operations ("MRO") requirements.

The computer manufacturer may use an e-commerce system architecture, such as that shown in FIG. 8. This exemplary e-commerce architecture includes a plurality of workstations WS1-WSN and a server S, each of which communicate with the Internet 1 in a well-known manner. Server S communicates with a relational database management system

("RDBMS") 3 in a well-known manner. Server S is programmed with work router software that allows a processor within server S to communicate with RDBMS 3 so as to execute the functionality of the present invention.

The business rules may be programmed by a user using a workstation WS. Although not shown, a supplier of materials to the computer manufacturer is also connected to the Internet 1.

FIG. 1 A depicts an exemplary complex business rule BRO that may be used to route data (e.g., a purchase order document) in connection with the procurement approval process. As will be described in more detail below, complex business rule BRO references complex and basic business rules BR1 and BR2, respectively, wherein complex business rule BR1 references basic business rules BR3 and BR4.

As will be described in more detail below, business rule BRO states that supervisor approval of a purchase order must be obtained if: (i) the Unit Price of the item to be purchased is greater than $1000.00; or (ii) the Quantity of the item(s) to be purchased is greater than 100 units; or (iii) the Purchase Amount (i.e.. Unit Price * Quantity) is greater than the Approval Limit of the employee making the purchase.

FIG. IB is a diagrammatic representation of the procurement approval process. Block 10 represents an employee who prepares and submits a purchase order. The purchase request typically would include a description of an item to be purchased, a unit price for the item, and a quantity of the item. Decision block 20 represents the work router software run by server S that determines how to route the purchase request based on complex business rule BRO. The routing of the purchase request may be based on a name of an employee or a person's role in the organization (e.g., Purchasing Manager), each of which may be stored in RDBMS 3 or other memory of server S.

If the purchase order does not satisfy business rules BR1 or BR2, then business rule BRO is not TRUE. In this case, the purchase order would be processed as not requiring supervisor approval, and may be transmitted to the purchase department by the employee directly as represented by block 30. In this case, the purchasing department may take appropriate action (e.g., issue the purchase order to a supplier over the Internet 1).

If complex business rule BRO is determined to be TRUE at decision block 20, then the purchase order is transmitted to a supervisor of the employee for approval (or rejection) as represented by block 40. In this example, the supervisor approves the purchase order, which is then submitted to the purchasing department for appropriate action (block 30) as described above.

In business rule BRO, the Unit Price, Quantity, Purchase Amount, and Approval Limit are attributes that are stored in a table of a relational database (FIG. 2) according to the process illustrated in FIG. 3. BR3 and BR4 are basic business rules that are stored in a table of a relational database according to the process of FIG. 4; BR2 represents a basic business rule that is stored in a table of a relational database according to the process of FIG. 5; and BR1 represents a complex business rule that is stored in a table of a relational database according to the process of FIG. 6. The business rules are evaluated according to the process of FIGS. 7A and 7B.

In the described embodiments, the relational database includes Table 1 and Table 2 as shown in FIG. 2. Table 1 illustrates an embodiment of a table that stores data representing one or more attributes. Referring to header R0, each row (or record) of Table 1 has an Attribute ID column that stores an identifier (e.g., a number) that uniquely identifies an attribute; an Attribute Name column that stores the name of the attribute; and an Attribute Data Type column that stores the type of the attribute stored in the Attribute Name column. The number and various types of attributes that may be stored in Table 1 are numerous. For example, an attribute "Cost" may be stored, which has a data type equal to a value (e.g., "100"), a minimum value (e.g., "> 100"), or a maximum value (e.g., "< 100"). Similarly, an attribute "Size" may be stored, which has a data type equal to a descriptor, such as "small," "medium." or "large."

As shown, records of Rl - R4 of Table 1 include the "Unit Price" "Quantity" "Purchase Amount," and "Approval Limit" attributes, each of which have data types "Numeric." While the attributes are used for business rule BRO, they may also be used for other business rules that may be stored in Table 2, without requiring re-entry of such attributes.

Table 2 illustrates an embodiment of a table that stores data representing one or more basic and/or complex business rules. In the described embodiments, a business rule has a source component, a target component, and an operator component indicating a relation between the source component and the target component. These three components may be illustrated as follows: <Source> <Operator> <Target>. For example, a business rule that would route data to a particular person if the cost of goods exceeds $100.00 may be represented as <Cost> <GREATER THAN> <100>. Referring to header R10, a row (or record) of Table 2 has a Business Rule ID column that stores an identifier (e.g., a number) that uniquely identifies a business rule. Table 2 also includes a Source ID column that identifies a source component of the business rule and a Source Type column that indicates the type of source component. In the described embodiments, the Source Type column may identify the source component as an attribute, basic business rule, or complex business rule.

If the Source Type is equal to "Attribute," then the Source ID column refers to the Attribute ID (Table 1) of the attribute. For example, the Source ID of record Rl 1 stores the value "1," which indicates the "Unit Price" attribute of record Rl of Table 1. If the Source Type is equal to "Basic Business Rule" or "Complex Business Rule," then the Source ID column refers to the Business Rule ID (Table 2) of the business rule. For example, the Source ID of record R15 stores the value "3," which indicates the basic business rule of record R13.

Table 2 also includes a Target ID column that stores a target component of the business rule and a Target Type column that indicates the type of target component. In the described embodiments, the Target Type column may identify the target component as an attribute, basic business rule, complex business rule, or value. The Target ID column refers to attributes and business rules in a manner similar to that of the Source ID column.

An Operator column stores an operator that defines a relationship between the data stored in the Source ID and Target ID columns. The Operator may be an arithmetic or logical operator as described above.

Still referring to FIG. 2, records Rl 1-R15 of Table 2 store business rules BR3, BR4, BR2, BR1, and BRO, respectively. These business rules BRO - BR4 may be used by other business rules that may be stored in Table 2, without requiring re-entry of all or portions of business rules BRO - BR4. FIG. 3 is a flow chart illustrating an embodiment of a process for storing an attribute in Table 1. The process is executed by the work router software of server S. At step 110, a user operating a workstation WS inputs (enters text, selects or otherwise indicates) a name and data type for the attribute to be stored in Table 1. For example, to store the attribute of record Rl in Table 1, the user would enter "Unit Price" and "Numeric" as the name and data type, respectively.

At step 120, the software generates a unique identifier for the attribute to be stored in Table 1. At step 130, the software stores the generated unique identifier, and the name and data type for the attribute in the Attribute ID, Attribute, and Attribute Data Type columns of Table 1 , respectively. The "Quantity," "Purchase Amount," and "Approval Limit" attributes may be stored in a similar manner. Rows R1-R4 of FIG. 2 illustrate the state of Table 1 after this process is executed for the attributes of business rules BR3, BR4, and BR2.

Referring now to FIG. 4, there is shown a flow chart of an embodiment of a process for storing a basic business rule in Table 2. In this embodiment, the basic business rule has the form <Attribute> <Operator> <Value>.

The process illustrated in FIG. 4 is executed by the work router software of server S. At step 210, a user operating a workstation WS inputs a source attribute for the basic business rule to be stored in Table 2. The source attribute is processed and stored in the Source ID column of Table 2. The software stores the value "Attribute" in the Source Type column.

For example, to store business rule BR3 (FIG. 1) in record Rl 1 of Table 2, the user may enter or otherwise indicate (e.g., by pointing and clicking) "Unit Price." The software determines and stores the corresponding Attribute ID (e.g. "1 ") in the Source ID column. In this case, the software also stores the value "Attribute" in the corresponding Source Type column.

At step 220, a user inputs an operator for the basic business rule to be stored in Table 2. The software determines whether the operator is compatible with the source attribute inputted at step 210. If it is compatible, then the operator is stored in the operator column of Table 2. If it is not compatible, then the user may be prompted to enter another operator. For example, to store business rule BR3 (FIG. 1) in record Rl 1 of Table 2, the user may enter the greater than sign " >." The software determines that this is a compatible operator and stores the greater than sign " > " in the operator column of record Rl 1 of Table 2. At step 230, a user inputs a target value for the basic business rule to be stored in Table 2. The software determines whether the target value is compatible with the source attribute and operator inputted at steps 210 and 220, respectively. If it is compatible, then the target value is stored in the Target ID column of Table 2. If it is not compatible, then the user may enter another target value. The software stores the value "Value" in the Target Type column.

For example, to store business rule BR3 (FIG. 1) in record Rl 1 of Table 2, the user may enter " 1000" in response to the prompt. The software determines that the value " 1000" is compatible and stores it in the Target ID column. In this case, the software also stores "Value" in the corresponding Target Type column.

At step 240, the software generates a unique identifier for the basic business rule. At step 250, the software processes and stores the basic business rule. This process may be repeated to store other basic business rules having the form <Attribute> <Operator>

<Value>. Thus, the software would be used to store business rule BR4 in record R12 of Table 2 in a similar manner.

Referring now to FIG. 5, there is shown a flow chart of an embodiment of a process for storing a basic business rule in Table 2. wherein the basic business rule has the form <Attribute> <Operator> <Attribute>. In the described embodiments, this form of basic business rule is defined by specifying a first attribute, an operator that is compatible with the type of the attribute, and a second attribute against which the first attribute will be compared.

The process illustrated in FIG. 5 is executed by the work router software of server S. At step 310, a user operating a workstation WS inputs a source attribute for the basic business rule to be stored in Table 2. The source attribute is processed and stored in the Source ID column of Table 2. The software stores the value "Attribute" in the Source Type column.

For example, to store business rule BR2 (FIG. 1) in record R13 of Table 2, the user may enter "Purchase Amount." The software determines and stores the corresponding Attribute ID (here, "3") in the Source ID column. In this case, the software also stores "Attribute" in the Source Type column.

At step 320, a user inputs an operator for the basic business rule to be stored in Table 2. The software determines whether the operator is compatible with the source attribute inputted at step 310. If it is compatible, then the operator is stored in the operator column of Table 2. If it is not compatible, then the user may be prompted to enter another operator.

For example, to store business rule BR2 (FIG. 1) in record R13 of Table 2, the user may enter the greater than sign " > " in response to the prompt. The software determines that this is a compatible operator and stores the greater than sign " > " in the operator column of Table 2.

At step 330, a user inputs a target attribute for the basic business rule to be stored in Table 2. The software determines whether the target attribute is compatible with the source attribute and operator inputted at steps 310 and 320, respectively. If it is compatible, then the target attribute is stored in the Target ID column of Table 2. If it is not compatible, then the user may be prompted to enter another target attribute. The software stores the value "Attribute" in the Target Type column.

For example, to store business rule BR2 (FIG. 1) in record R13 of Table 2, the user may enter "Approval Limit." The software determines that the "Approval Limit" is compatible and stores the Attribute ID for this attribute (here, "4") in the Target ID column. In this case, the software also stores "Attribute" in the Target Type column.

At step 340, the software generates a unique identifier for the basic business rule. At step 350, the software processes and stores the basic business rule. This process may be repeated to store other basic business rules having the form <Attribute> <Operator> <Attribute>. Referring now to FIG. 6, there is shown a flow chart of an embodiment of a process for storing a complex business rule in Table 2, wherein the Complex Business Rule has one of the following forms: (i) <Basic Business Rule> <Operator> <Basic Business Rule>; (ii) <Basic Business Rule> <Operator> <Complex Business Rule>; (iii) <Complex Business Rule> <Operator> <Complex Business Rule>; or (iv) <NOT> <Basic/Complex Business Rule>. The storage of form (i) is now described. The storage of forms (ii) and (iii) is similar to the storage of form (i), as is the storage of form (iv) except that it does not utilize a source component.

The process illustrated in FIG. 6 is executed by the work router software of server S. At step 410, a user operating a workstation WS inputs a source business rule to be stored in Table 2. The source business rule is processed and stored in the Source ID column of Table 2. The software stores the type of business rule in the Source Type column.

For example, to store basic business rule BR1 (FIG. 1) in record R14 of Table 2, the user may enter Business Rule ID 1. The software determines and stores this Business Rule ID 1 in the Source ID column of record R14. In this case, the software also stores "Basic Business Rule" in the Source Type column.

At step 420, a user inputs an operator for the complex business rule to be stored in Table 2. The software determines whether the operator is compatible with the source business rule indicated at step 410. If it is compatible, then the operator is stored in the Operator column of Table 2. If it is not compatible, then the user may be prompted to enter another operator.

For example, to store business rule BR1 (FIG. 1) in record R14 of Table 2, the user may enter the operator "OR" in response to the prompt. The software determines that this is a compatible operator and stores the operator "OR" in the corresponding Operator column. At step 430, a user inputs a target business rule for the complex business rule to be stored in Table 2. The software determines whether the target business rule is compatible with the source business rule and operator inputted at steps 410 and 420, respectively. If they are compatible, then the target business rule is stored in the Target ID column of Table 2. If it is not compatible, then the user may be prompted to enter another target business rule.

For example, to store business rule BR1 (FIG. 1) in record R14 of Table 2, the user may enter or otherwise indicate Business Rule ID 2 in response to the prompt. The software determines and stores this Business Rule ID 2 in the Target ID column. In this case, the software also stores "Basic Business Rule" in the Target Type column.

At step 440, the software generates a unique identifier for the complex business rule. At step 450, the software processes and stores the complex business rule. This process may be repeated to store business rule BRO in record R15, as well as other complex business rules. FIGS. 7A and 7B are flowcharts illustrating a process for evaluating complex and basic business rules. The process uses recursion, a technique well known in the art, to break any complex rule into its basic components and to evaluate the components to arrive at a result. Of course, other non-recursive techniques may be used as desired.

First referring to FIG. 7A, at step 505, the work router software reads each of the records storing the business rules to be evaluated from Table 2. At step 510, the work router software reads the record storing the current business rule and breaks it down into its source and target components. The source and target components are the left and right hand sides of the current business rule, respectively. To break down the rule into the source and target components, the work router software reads the Source ID and Target ID fields, respectively, from the current record storing the current business rule. At step 520, the work router software determines whether the source component of the current business rule is a complex business rule. To accomplish this, the work router software reads the Source Type field from the current record storing the current business rule. If the source component is a complex business rule, then processing continues at step 515. If it is not, then processing proceeds to step 530.

At step 515, the source component of the current business rule is set as the current business rule. The source component is passed back to step 510 for processing. The recursive process of steps 510, 515, and 520 eventually results in a source component of the then current business rule being a basic business rule. The work router software evaluates this basic business rule at step 530 according to the flowchart of FIG. 7B.

At step 605 of FIG. 7B, the software obtains a value from a user for the attribute on the left side (source component) of the basic business rule. At step 610, the software determines if the right side (target component) of the basic business rule is an attribute or a value. If the right side is an attribute, then processing continues at step 615. If the right side is not an attribute, then processing continues at step 620.

At step 615, the software obtains a value from the user for the attribute on right side of the basic business rule. At step 620, the software evaluates the basic business rule using the value for the source component obtained at step 605 and the value for the target component (that is, either the value read from Table 1 or the value obtained at step 615). If the basic business rule evaluates to be "true," then processing continues at step 630 where the software returns the result of the basic business rule (here, TRUE). If the basic business rule evaluates to be "false," then processing continues at step 625 where the software returns the result of the basic business rule (here, FALSE). In both TRUE and FALSE situations, processing returns to step 533. At step 533. the work router software reads the target component of the current business rule. At step 540, the work router software determines whether the target component of the current business rule is a complex business rule. To do so, it reads the Target ID field from the record storing the current business rule. If the target component is a complex business rule, then processing branches to step 535 for processing. If it is not, then process continues at step 545.

At step 533, the target component of the current business rule is set as the current business rule. The target component is passed back to step 510 for processing. The recursive process of steps 510, 515, and 520 eventually results in a source component of the then current business rule being a basic business rule. The work router software evaluates this basic business rule at step 530 according to the flowchart of FIG. 7B.

At step 545, the work router software evaluates this basic business rule according to the process depicted in FIG. 7B as described above. At step 555, the software evaluates the source and target components of the current business rule (the values obtained and steps 530 and 545) in view of the current operator, which is obtained from the Operator field of the record storing the current business rule.

At step 560, the result of the evaluation at step 555 is returned. Once each of the previous business rules has been evaluated, the result of the first business rule may be used to route data in connection with the business process of which business rule is a part. In the procurement approval process of the described example, the processes of

FIGS. 7A and 7B are executed such that the work router software initially reads complex business rule BRO stored in record R15. The software evaluates the source component of record R15, which is embodied in the basic business rule of record R13, according to the process of FIG. 7B. Thus, the software determines, for a purchase order that is part of this process, whether the purchase amount is greater than the approval limit. In this example, the Target Type of record R15 indicates that the target component is a complex business rule. Thus, the complex business rule of record R14 is evaluated, which entails evaluating the business rules of records Rl 1 and R12. Once the business rules of records Rl 1 and R12 are evaluated according to the process of FIG. 7B, the business rule of record R14 is evaluated. Once the business rules of record R14 is evaluated, the business rule of record R15 can be evaluated. The result of the complex business rule of record R15 may be used to route data in connection with the procurement approval process as described with reference to FIG. IB.

In view of the foregoing, a novel and unique method and system for routing data based on one or more business rules that are stored in a relational database has been described. The method and system facilitates input of the business rules with minimal effort by a user and employs programming techniques of limited complexity for evaluating such rules.

It is noted that while the foregoing description has referred to specific individual databases, formats, records, and fields, those skilled in the art will readily appreciate that various modifications and substitutions may be made thereto without departing from the spirit and scope of the present invention as defined by the appended claims.

Claims

WHAT IS CLAIMED IS:

1. A method for facilitating the routing of data, comprising:

(a) creating a record in a first table for storing a business rule, wherein the business rule comprises a source component, a target component, and an operator indicating a relation between the source component and the target component;

(b) receiving the source component of the business rule;

(c) storing the source component of the business rule in the record of the first table; (d) receiving the target component of the business rule;

(e) storing the target component of the business rule in the record of the first table;

(f) receiving the operator of the business rule; and

(g) storing the operator of the business rule in the record of the first table.

2. The method of Claim 1, wherein the source component is selected from the group consisting of: an attribute, a basic business rule, or a complex business rule.

3. The method of Claim 1 , wherein the target component is selected from the group consisting of: an attribute, a basic business rule, a complex business rule, or a value.

4. The method of Claim 1 , wherein the operator is selected from the group consisting of: an arithmetic operator or a logical operator.

5. The method of Claim 1 , wherein the source component comprises a first attribute, and wherein the method further comprises the steps of

(h) receiving the first attribute;

(i) generating a first unique identifier for the first attribute; (j) creating a first record in a second table; and

(k) storing the first attribute and the first unique identifier in the first record of the second table.

6. The method of Claim 5, wherein step (c) comprises storing the first unique identifier for the first attribute in the record of the first table.

7. The method of Claim 6, wherein the target component comprises a second attribute, and wherein the method further comprises the steps of

(1) receiving the second attribute; (m) generating a second unique identifier for the second attribute;

(n) creating a second record in the second table; and (o) storing the second attribute and the second unique identifier in the second record of the second table.

8. The method of Claim 7, wherein step (e) comprises storing the second unique identifier for the second attribute in the record of t ie first table.

. The method of Claim 1, wherein the source component comprises a second business rule, wherein the target component comprises a third business rule, and wherein the method further comprises the steps of

(h) generating a first unique identifier for the second business rule; and (i) generating a second unique identifier for the third business rule.

10. The method of Claim 9, wherein step (c) comprises storing the first unique identifier for the second business rule in the record of the first table.

11. The method of Claim 10, wherein step (e) comprises storing the second unique identifier for the third business rule in the record of the first table.

2. A system for facilitating the routing of data, comprising:

(a) a memory comprising a first table having a record for storing a business rule, wherein the business rule comprises a source component, a target component, and an operator indicating a relation between the source component and the target component; and

(b) a processor in communication with the memory, wherein the processor is operative to

(i) receive the source component of the business rule; (ii) store the source component of the business rule in the record of the first table;

(iii) receive the target component of the business rule;

(iv) store the target component of the business rule in the record of the first table; (v) receive the operator of the business rule; and (vi) store the operator of the business rule in the record of the first table.

13. A method for facilitating the routing of data, comprising:

(a) reading a first business rule from a first record of a first table, wherein the first business rule comprises a first source component, a first target component, and a first operator indicating a relation between the first source component and the first target component;

(b) evaluating the first source component of the first business rule;

(c) evaluating the first target component of the first business rule;

(d) determining whether the relation between the first source component and the first target component indicated by the operator exists; and (e) transmitting a result indicating the determination made in step (d).

14. The method of Claim 13, wherein the source component references a second business rule, and wherein step (b) comprises:

(b-1) reading the second business rule from a second record of the first table, wherein the second business rule comprises a second source component, a second target component, and a second operator indicating a relation between the second source component and the second target component; (b-2) evaluating the second source component of the second business rule; (b-3) evaluating the second target component of the second business rule;

(b-4) determining whether the relation between the second source component and the second target component indicated by the second operator exists; and (b-5) assigning a result indicating the determination made in step (b-4) to the first source component.

15. The method of Claim 14, wherein the target component references a third business rule, and wherein step (c) comprises:

(c-1) reading the third business rule from the relational database, wherein the third business rule comprises a third source component, a third target component, and a third operator indicating a relation between the third source component and the third target component;

(c-2) evaluating the third source component of the third business rule;

(c-3) evaluating the third target component of the third business rule;

(c-4) determining whether the relation between the third source component and the third target component indicated by the operator exists; and

(c-5) assigning a result indicating the determination made in step (c-4) to the first target component.

16. The method of Claim 13, wherein the source component is selected from the group consisting of: an attribute, a basic business rule, or a complex business rule.

17. The method of Claim 13, wherein the target component is selected from the group consisting of: an attribute, a basic business rule, a complex business rule, or a value.

18. The method of Claim 13, wherein the operator is selected from the group consisting of: an arithmetic operator or a logical operator.

9. A system for facilitating the routing of data, comprising:

(a) a memory comprising a first table having a first record for storing a first business rule, wherein the first business rule comprises a first source component, a first target component, and a first operator indicating a relation between the first source component and the first target component; and

(b) a processor in communication with the memory, wherein the processor is operative to

(i) read the first business rule from the first record of the first table, (ii) evaluate the first source component of the first business rule;

(iii) evaluate the first target component of the first business rule; (iv) determine whether the relation between the first source component and the first target component indicated by the operator exists; and (v) transmit a result indicating the determination made in (iv).

0. A method for routing data, comprising:

(a) creating a first table having a plurality of records for storing business rules;

(b) storing a first business rule in a first record of the first table; (c) storing a second business rule in a second record of the first table;

(d) storing a third business rule in a third record of the first table, wherein the third business rule references the first and second business rules;

(e) reading the third business rule from the third record of the first table;

(f) reading the first and second business rules from the first and second records of the first table, respectively;

(g) evaluating the first business rule; (h) evaluating the second business rule;

(i) evaluating the third business rule based on the evaluation of the first and second business rules; and G) routing the data based on the evaluation of the third business rule.

21. The method of Claim 20, wherein the first business rule comprises a first source component, a first target component, and a first operator indicating a relation between the first source component and the first target component, and wherein step (g) comprises (g- 1 ) evaluating the first source component of the first business rule;

(g-2) evaluating the first target component of the first business rule; (g-3) determining whether the relation between the first source component and the first target component indicated by the first operator exists; and (g-4) transmitting a first result indicating the determination made in step (g- 3).

22. The method of Claim 21 , wherein the second business rule comprises a second source component, a second target component, and a second operator indicating a relation between the second source component and the second target component, and wherein step (h) comprises

(h-1) evaluating the second source component of the second business rule; (h-2) evaluating the second target component of the second business rule; (h-3) determining whether the relation between the second source component and the second target component of the second business rule indicated by the second operator exists; and

(h-4) transmitting a second result indicating the determination made in step (h-3).

3. The method of Claim 22, wherein the third business rule comprises a third source component, a third target component, and a third operator indicating a relation between the third source component and the third target component, and wherein step (i) comprises

(i-1) assigning the first result to the third source component; (i-2) assigning the second result to the third target component; and (i-3) determining whether the relation between the third source component and the third target component indicated by the third operator exists.