Delta model processing logic representation and execution system

Abstract

The invention presents novel method, apparatus, and data structures for storing, maintaining, and executing processing logic on a computer system. Processing logic is encoded into its distinct, constituent elements that are flexibly linked, facilitating reuse and reconfiguration. Executable responses are selected for an input signal by identifying a correspondence between the input signal and an expression, evaluating the expression to a resulting value, and identifying a correspondence between the expression and its resulting value, and an executable response.

Claims

What is claimed is:

1. An article of manufacture for use in condition to action processing in a computer system, the apparatus comprising a computer readable medium with computer readable program code embodied therein for directing a computer system, the computer readable code in the article of manufacture comprising:

an event data store that can store at least one event identifier and at least one corresponding expression that indicates a corresponding predicate logic expression of condition that corresponds to an event identified by the at least one event identifier;

a task data store that can store at least one task identifier and corresponding response information that indicates a group of one or more command statements that corresponds to the at least one task;

a correspondence data store that can store at least one correspondence between the at least one event identifier and the at least one task identifier;

a notice data store that can store respective event data that corresponds to the at least one event identifier;

computer readable program code causing the computer to evaluate the indicated predicate logic expression using the event data so as to produce an evaluation result corresponding to the at least one identified event; and

computer readable program code causing the computer to execute the at least one or more command statements only if the produced evaluation result has a prescribed value.

2. The article of manufacture of claim 1 wherein the computer readable program code causing the computer to execute further includes:

computer readable program code to determine whether the evaluation result has a prescribed value;

computer readable program code causing the computer to identify in the correspondence data store a correspondence between the respective at least one event identifier and the at least one task identifier;

computer readable program code causing the computer to identify from the task data store the respective group of one or more command statements that correspond to the at least one identified task identifier; and

computer readable program code causing the computer to execute the one or more command statements that correspond to the identified task identifier.

3. A method of creating condition-to-action associations in computer readable program code embodied in a computer readable medium comprising:

providing an event data store tat can store at least one event identifier and at least one corresponding expression that indicates a corresponding predicate logic expression of condition that corresponds to an event identified byte at least one event identifier;

providing a task data store that can store at least one task identifier and corresponding response information that indicates a group of one or more command statements that corresponds to the at least one task;

providing a correspondence data store that can store at least one correspondence between the at least one event identifier and the at least one task identifier;

providing a notice data store that can store respective event data that corresponds to the at least one event identifier;

evaluating the indicated predicate logic expression using the event data so as to produce an evaluation result corresponding to the at least one identified event; and

executing the at least one or more command statements only if the produced evaluation result has a prescribed value.

4. The method of claim 3 wherein executing the at least one or more command statements only if the produced evaluation result has a prescribed value includes:

determining whether the evaluation result has a prescribed value;

identifying in the correspondence data store a correspondence between a respective at least one event identifier and the at least one task identifier;

identifying from the task data store the respective group of one or more command statements that correspond to the at least one identified task identifier; and

executing the one or more command statements that correspond to the identified task identifier.

5. An article of manufacture for use in condition to action processing in a computer system, the apparatus comprising a computer readable medium with computer readable program code embodied therein for directing a computer system, the computer readable code in the article of manufacture comprising:

an event data store that can store a plurality of respective event identifiers and respective corresponding expression that indicate respective corresponding predicate logic expressions of condition that respectively correspond to respective events identified by respective corresponding event identifiers;

a task data store that can store a plurality of respective task identifiers and respective corresponding response information that indicates groups of one or more command statements that respectively correspond to respective tasks;

a correspondence data store that can store a plurality of correspondences between respective event identifiers and respective one or more task identifiers;

a notice data store that can store respective event data that corresponds to respective event identifiers;

computer readable program code causing the computer to evaluate a respective predicate logic expression of condition corresponding to a respective event identifier corresponding to respective event data stored in, the native data store; and

computer readable program code to determine whether the evaluation result has a prescribed value;

computer readable program code causing the computer to execute the at least one or more command statements only if the produced evaluation result has a prescribed value;

computer readable program code causing the computer to identify in the correspondence data store a correspondence between the respective event identifier and a respective task identifier;

computer readable program code causing the computer to identify from the task data store a respective group of one or more command statements that correspond to the identified task identifier; and

computer readable program code causing the computer to execute the one or more command statements that correspond to the identified task identifier.

6. The method of claim 5,

wherein the computer readable program code causing the computer to execute the at least one or more command statements only if the produced evaluation result has a prescribed value invokes the computer readable program code causing the computer to identify in the correspondence data store a correspondence between the respective event identifier and a respective task identifier only if the produced evaluation result has a prescribed value and otherwise terminates condition to action processing.

Description

FIELD OF INVENTION

The invention relates generally to computer-based process execution systems, and more particularly, to the optimized representation of processing logic.

DESCRIPTION OF THE RELATED ART

In the earliest days of electronic data processing, jumper wires on plugboards contained the definition of the process a machine was supposed to execute. Humans could not easily read this processing logic contained on the plugboards, and that processing logic represented only a very small and very low-level portion of the rules used to conduct a business enterprise. For example, the entire processing logic contained on a plugboard may have said little more than that numeric values contained in punched cards read by the machine should be summed, but only for those cards having an "X" in the first column of the card.

As tabulating machinery gave way to general purpose, stored-program computers, the processing logic moved from plugboards to application programs. The application programs had both machine-readable and human-readable forms. Making the processing logic easily accessible to people, as well as to the computer, was a major advantage over the plugboard—responsible people need to continually create, identify, understand, and maintain the processing logic, and the computer needs to continually execute it.

Processing logic in an application program generally comprises both the functional data manipulations for the computer to perform and the conditions under which those manipulations should be performed. For example, the processing logic may state that under the condition a payment is being made late, then the amount of the payment should be calculated at 103% times the invoiced amount, otherwise the amount of the payment should be calculated at 100% times the invoiced amount.

The ability to evaluate a condition and then determine which, if any, course of action to take dependent on the outcome is known as conditional branching. The computer's ability to perform conditional branching is a key to its widespread success and its application to problems diverse in nature and complexity. Computer programming languages, e.g., FORTRAN, COBOL, BASIC, and C, provide a variety of means to achieve conditional branching and the sophistication of a programming language may be judged on the conditional branching alternatives it provides. For example, the C language provides IF . . . THEN, SWITCH . . . CASE, FOR . . . NEXT, and other statement constructs for achieving conditional branching. Newer languages, such as C++, are not designed to simplify conditional branching but may include features to further facilitate or refine conditional branching mechanisms. Examples include the private and protected methods of classes in C++ that may restrict the courses of action targeted by a conditional branch.

Regardless of the conditional branching construct used, the purpose is to associate a condition with a course of action. These associations fundamentally represent the processing logic embodied by the application program. Unfortunately, the many possible constructs available for representing these condition-to-action associations obscures their underlying similarity.

The lack of similarity in the representations of the processing logic in traditional programming languages makes it difficult to collect and analyze the processing logic as a whole. For example, a business enterprise may have its manufacturing software, contained in hundreds of individual program modules, written in C, BASIC, and FORTRAN. The same business enterprise may have its accounting software, also containing hundreds of modules, written in COBOL and BASIC. Moreover, the manufacturing software may reside and execute on machines and operating systems from one vendor, while the accounting software resides and executes on machines and operating systems from another vendor. Furthermore, the BASIC language used for accounting programs may be a different variant than the BASIC language used for manufacturing program. Considering the dissimilar languages employed, the dissimilar ways to represent condition-to-action associations within each language, the dissimilar locations where the application programs may reside, and the dissimilar operating systems and hardware, it would be very difficult to programmatically collect and analyze the processing logic contained in all of the manufacturing and accounting application programs together. The same may be true within either of the manufacturing software or accounting software systems, by itself.

So, in a collective sense, the processing logic of the business cannot be readily collected and analyzed with the aid of the computer, despite the fact that the processing logic embodied in application programs is machine-readable. Such analysis of the collective processing logic is highly desirable for performing business modeling and for identifying contradictions, conflicts, and relationships among individual elements of processing logic. Business modeling involves the symbolic representation of the objects, entities, and processes involved in the operation of the business for planning, analysis, modification, simulation, and reporting.

The lack of similarity in the representations of the processing logic in conventional programming languages also has disadvantages despite its being human-readable. At the core of the problem is that fact that the business people responsible for determining the processing logic for the operation of the business enterprise, e.g., supervisors, managers, and directors (managers, or management), generally do not have the technical training required to understand and use computer programming languages. Consequently, management relies on intermediaries, i.e., computer programmers, to translate its intentions into a programming language that the computer understands. For example, if an appropriate company manager decides that a new class of employee needs to be created that earns benefits according to a different set of criteria than other existing classes of employees, then the manager must relate the new criteria to a programmer who modifies an application program or programs accordingly. Besides the inherent delay, this brings with it the possibility that "something gets lost in the translation." Disconnects frequently result between the business model intended by the management and the business model embodied in the processing logic in the application programs.

One potential solution to the above problems may be to develop software tools allowing management to directly manipulate the application programs written in traditional programming languages. Such a tool could provide an interface that translates between the traditional programming language and some intermediate level of representation more easily understood by managers. Again, because of the diversity of programming languages, a generalized tool would be difficult to develop and any such tool would likely be restricted as a practical matter to particular programming languages, hardware, and operating systems.

Another potential solution to the above problems appears to be standardization on a single computing language within the business enterprise. First, this may not be practical because of a need to use multiple computing platforms, some of which may be incapable of supporting the standard language. Further, the business enterprise may purchase some of its applications from software vendors and have no control over the language in which it is written. Even if standardization is possible, representation of the condition-to-action associations may be dissimilar within the language, e.g., IF . . . THEN vs. SWITCH . . . CASE; and managers are unlikely to have or obtain the technical training required to understand and use the language.

Furthermore, traditional computer languages are targeted for representing only the detailed levels of business processing logic, e.g., the calculation of a particular value to be printed on a particular line of an invoice. The management, however, also generally works with business processing logic at higher levels of abstraction, e.g., the billing of customers with outstanding balances. The high-level abstraction of business processing logic, although integrally related to the detailed levels, is not typically embodied in the application programs of the business enterprise at all. Instead it may be embodied in written or unwritten manual procedures, or in automated scheduling or workflow systems. The automated scheduling and workflow systems may support the storage of rudimentary processing logic in machine-readable form, albeit typically in some proprietary fashion tailored to the specific abilities of the system.

Consequently, there is a need in the art for method, apparatus, and structure for simply and uniformly representing processing logic in terms of its condition-to-action associations, readily susceptible to direct manipulation by persons with limited technical training, and able to simultaneously represent processing logic at multiple levels of detail and abstraction. Such method, apparatus, and structure would have the further advantages of ease of portability and interoperability between and among various makes, models, and versions of computer hardware and operating systems; susceptibility to automated analysis; and support for incremental implementation. Such method, apparatus, and structure would not be limited to applications of business processing, but may be advantageously employed wherever computer-based representation of processing logic is desired. The present invention meets these needs.

SUMMARY OF THE INVENTION

The present invention involves method, apparatus, and data structures for representing and executing processing logic using a computer system. The processing logic may be as complex, for example, as the combined practices, procedures, and policies used to run an entire business enterprise, or, as simple, for example, as the process performed by a single machine using an embedded computer.

In the practice of the invention, the processing logic of a subject process is reduced to novel data structures containing its definition. A first data structure stores expressions for evaluating various aspects of the state of the subject process. The expression is a series of symbols that can be evaluated to have a particular value and represents a condition placed on subsequent processing. A second data structure stores information representing correspondences between expression results and tasks to perform. A third data structure stores task definitions. Tasks represent executable responses, i.e., a predefined set of one or more instructions that may be performed using a computer, e.g., a computer program module.

During the operation of the subject process, events occur that are signaled using the computer system. For example, in a manufacturing process, a machine jam may be a type of event that occurs. The particular type of the occurring event, the event-type, is used to identify an expression in the first data structure. The event-type is implicitly or explicitly contained in the input signal. Evaluation of the identified expression produces a resulting value, which together with the event-type, may identify one or more correspondences stored in the second data structure. The identified correspondence information is then used to identify task definitions stored in the third data structure. Execution of identified tasks is then initiated.

In other words, the expressions represent conditions placed on the execution of executable responses, the task definitions define a pool of executable responses, and the correspondences relate the conditions to particular executable responses. By separating the expressions from the executable responses, and relating them via the correspondences data structure entries, the processing logic may be easily reconfigured and existing definitions reused.

In a preferred embodiment, the data structures are maintained as relational tables. The expressions in the first data structure conform to a system of multi-valued predicate logic after the fashion discussed in E. F. Codd, The Relational Model for Database Management, Version 2 (Addison-Wesley 1990). Evaluation of an expression results in a "truth" value, e.g., true or false. In this preferred embodiment, only "true" results produce downstream activity (i.e., only an evaluation of an expression that produces a "true" result has task correspondence entries in the second data structure).

These and other objects, advantages, and features of the present invention will become apparent from the following detailed description when taken in conjunction with the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts a block diagram of processing logic element stores encoded in a memory medium.

FIG. 2 depicts processing logic element stores with representative entry data structures.

FIG. 3 depicts a functional block diagram of a Process Management Knowledgebase System (PMKBS) encoded in a memory medium.

FIGS. 4A and 4B depict representative computer hardware environments that may be used to implement a PMKBS.

FIGS. 5A-5B depict one method of defining processing logic to the process management knowledgebase (PMKB).

FIGS. 6A to 6D depict record layouts encoded in a memory medium for PMKBS catalog entries.

FIGS. 7A to 7D depict record layouts encoded in a memory medium for PMKBS operating data structure entries.

FIGS. 8A to 8D depict operational flowcharts of functional elements in the PMKBS.

FIGS. 9A-9B depict the software and data components residing on a storage device for illustrating the operation of the PMKBS in one embodiment of the invention.

FIGS. 10A to 10C depict abbreviated sample contents of PMKBS catalog tables encoded in a memory medium for purposes of illustration.

FIGS. 11A to 11B depict abbreviated sample contents of PMKBS process-independent data tables encoded in a memory medium useful for purposes of illustration.

FIGS. 12A to 12D depict abbreviated sample contents of PMKBS process-dependent data tables encoded in a memory medium useful for purposes of illustration.

FIGS. 13A to 13B depict sample contents of hypothetical data tables encoded in a memory medium as may be employed in an inventory management application of a manufacturing business.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention comprises novel method, apparatus, and data structures for representing and executing processing logic. The following description is presented to enable any person skilled in the art to make and use the invention, and is provided in the context of particular applications and their requirements. Various modifications to the preferred embodiment will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the invention. Thus, the present invention is not intended to be limited to the embodiment shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

PMKBS Structural Overview

FIG. 1 depicts a block diagram of data stores for processing logic elements encoded in a memory medium in one embodiment. Processing logic elements comprise individual memory-encoded representation of conditions, associations, and courses of action. Data stores for processing logic elements include a conditions data store 100, a correspondences data store 120, and a responses data store 140.

The processing logic in an embodiment practicing the present invention is defined in terms of conditions associated with courses of action. Unlike traditional programming languages, however, an embodiment practicing the present invention stores the conditions, associations, and courses-of-action elements of the processing logic as distinctly addressable data items. Nevertheless, the elements are linked in an overal structure. Conditions are stored in the conditions data store 100, associations are stored in the correspondences data store 120, and courses of action are stored in the responses data store 140.

Storage of processing logic elements in this fashion, and utilizing the associations as an intermediate link between conditions and responses, permits an embodiment to easily allow multiple use and reuse of individual processing logic elements. For example, a course of action that is executed under many conditions can be defined once and be referenced by as many associations as necessary. This represents a further advantage of the present invention.

FIG. 2 depicts processing logic element stores with representative entry data structures. The conditions data store 100 in one embodiment contains one or more entries. The purpose of each entry 210 is to represent a condition to be satisfied if a certain course of action is to be taken. Each entry 210 comprises an expression field 214. The expression field 214 may store an expression, itself, or a reference to another storage location where an expression can be found in a memory medium.

Each expression is a series of information that can be evaluated to have a particular value. Achieving a certain particular value can then be the condition on which taking a subsequent course of action is based. An expression generally tests the state or states of one or more data items that represent elements related to a subject process. The data items to be evaluated may be contained in or determined by an input signal 201. For example, an expression may test the state, e.g., value, of a numeric data item that represents the quantity of a particular part in the stockroom for an inventory process. This construction permits the linkages of different corresondences 220 to be utiilzed depending on the result of expression evaluation 242. That is, the link between the condition store, and the correspondnece store is determined (a resolved) based upon the result of the evaluation of the expression.

Each entry 210 in the conditions data store 100 may further comprise an identifier 212. The identifier 212 serves to uniquely identify the entry 210, i.e., the expression 214, from among any others in the conditions data store 100. The identifier 212 may be implicit or explicit. For example, the memory address where the entry is stored in a memory medium may be used as the implicit and unique identifier. Alternatively, the identifier 212 may be a field in the entry 210 that stores a value, e.g., a string of characters like "ABC123", which value is used to explicitly and uniquely identify the related expression field 214.

The responses data store 140 in one embodiment contains one or more entries that are associated with each other in the memory medium. Each entry 230 comprises an executable response field 234. The executable response field 234 may store an executable response, itself, or a reference to another storage location where an executable response can be found in a memory medium.

An executable response comprises a predefined set of instructions that may be performed using a computer. For example, an executable response may be a program, a program name, a program address, or a statement susceptible to execution by the operating system or a subsystem. As a specific example, an executable response may be a command line recognizable by the operating system that causes execution of a program that forecasts the usage rate and inventory level for a particular part.

Each entry 230 in the responses data store 140 may further comprise an identifier 232. The identifier 232 serves to uniquely identify the entry 230, i.e., the executable response 234, from among any others in the responses data store 140. The identifier 232 may be implicit or explicit. For example, the memory address where the entry is stored in a memory medium may be used as the implicit and unique identifier. Alternatively, the identifier 232 may be a field in the entry 230 that stores a value, e.g., a string of characters like "XYZ789", which value is used to explicitly and uniquely identify the related executable response field.

The correspondences data store 120 in one embodiment contains one or more entries. The role of each entry 220 is to link a condition to a course of action. Implementing those linkages as distinctly addressable processing logic elements facilitates reusability and reconfiguration which are farther advantages of the present invention. Each entry 220 comprises a field 224 containing an identifier for a particular entry in the responses data store 140, i.e., a course of action. Each entry 220 further comprises an identifier 222 corresponding to a particular combination of an expression 214 in the conditions data store 210 and a particular value that may result from an evaluation of the expression 242, i.e., a condition. This identifier 222 may be implicit or explicit. For example, the memory address where the entry is stored in a memory medium may be calculable using the conditions data store entry identifier 212 and the value resulting from evaluation of the expression 242. Alternatively, the identifier 222 may be a field or fields in the entry 220 that stores a value, e.g., a string of characters like "ABC123/TRUE."

As an example, a correspondence entry 220 may be identified by a less-than-ten value resulting from the evaluation of an expression that tests the state of a numeric data item that represents the quantity of a particular part in the stockroom for an inventory process, which expression is contained in a particular entry in the conditions data store. The same correspondence entry 220 may contain an identifier 224 for a responses table entry containing an executable response that is a command line recognizable by the operating system that causes execution of a program that forecasts the usage rate and inventory level for a particular part.

Using the examples described above, if during operation an input signal associated with the example entry in the conditions data store 100 prompts evaluation of the expression 214 contained therein, and the evaluation produces a less-than-ten resulting value 242, the resulting value 242 leads to the example entry in the correspondence data store 120 which, in turn, leads to the example entry in the responses data store 140, causing initiation of the program that forecasts usage and inventory level for the part.

The conditions 100, correspondences 120, and responses 140 data stores may together be referred to as a process management knowledgebase (PMKB) catalog. A system utilizing the processing logic represented in the PMKB catalog to facilitate execution of a subject process may be referred to as a process management knowledgebase system (PMKBS).

FIG. 3 depicts a functional block diagram of a Process Management Knowledgebase system encoded in a memory medium. The system comprises a signal source 330, an event discriminator 335, and expression correlator 340, an evaluator 345, a task correlator 350, a task initiator 355, an execution engine 360, an expressions data store 310, a correspondences data store 315, and a responses data store 320.

The Process Management Knowledgebase system is a data processing system for controlling and monitoring the execution of a subject process where the processing logic is defined in a process management knowledgebase. The PMKB comprises the expressions data store 310, the correspondences data store 315, and the responses data store 320. The expressions 310, correspondences 315 and responses 320 data stores correspond to the conditions 100, correspondences 120, and responses 140 data stores of FIG. 1, respectively.

The expressions data store 310 in this embodiment contains event-type identifiers and related expressions. An event-type identifier corresponds to the identifier 212 in the conditions data store 100 depicted in FIG. 2. It is called an event-type identifier because, in the present embodiment, a particular type of event that occurs in a subject process may have a corresponding entry in the expressions data store.

The related expressions are used to evaluate aspects of the state of the subject process that is being controlled and monitored by the PMKBS. Evaluation of the related expression generally occurs upon the occurrence of some event in the subject process signaled to the PMKBS.

The response data store 320 in this embodiment contains task-type identifiers and related responses. A task-type identifier corresponds to the identifier 232 in the responses data store 140 depicted in FIG. 2. The related responses in this embodiment are unordered sets of programmed instruction sequences that may be executed on a computing system using, for example, the operating system, a subsystem, a utility or application program, specialized hardware or a subcomponent of the PMKBS, itself.

The correspondences data store 315 contains representations for associating the result of the evaluation of an expression from the expression data store 310 with a response from the response data store 320. In one embodiment, an event-type identifier, alone, represents both the particular expression and the particular result, because in that embodiment, only a result of "TRUE" is permitted to have an associated response. The result value of "TRUE" is thus implied in every entry of the correspondences data store 315 and does not need explicit representation. A task-type identifier represents the response.

The signal source 330 actively or passively collects input signals containing information about events occurring in the process external to the PMKBS. For example, the signal source 330 may actively collect input signals by periodically scanning a database for specific types of changes. As an alternative example, the signal source 330 may passively collect input signals by providing an entry point in its programming code that programs external to the PMKBS can call to signal the PMKBS.

The event discriminator 335 analyzes information in and about the input signal 332 to identify it with an event-type represented in the expression data store 310. The expression correlator 340 uses the identified event-type to locate a corresponding expression in the expression data store 310. The expression correlator 340 may then process the stored expression, transforming it from a general form to a specific form, for example, by performing variable substitution. For instance, the stored expression may be of a general form saying "check the inventory quantity of a part" while the specific form may say "check the inventory quantity of part number Y123." Alternatively, this transformation could be performed by the evaluator 345.

The evaluator 345 analyzes the expression from the expression correlator 340 and resolves it to a resulting value. The task correlator 350 uses the resulting value to locate corresponding task-type identifiers in the correspondences data store 315. The task correlator 350 uses the identified task-types to locate corresponding responses in the responses data store 320. The task initiator 355 then takes the identified responses and submits them, after any preprocessing, to an execution engine 360. Preprocessing may involve, for example, the substitution of variables. The execution engine 360 then executes the responses that have been submitted to it.

Hardware Architecture

FIGS. 4A and 4B depict representative computer hardware environments that may be used to implement a PMKBS. FIG. 4A depicts a single computer system 400 comprising a CPU 410, memory 412, memory media 414, network interface 416, and input/output devices 418 all connected via a data and control signal bus 420. Such a computer configuration is widely known in the art. The CPU 410 executes instructions using instructions and data stored in the memory 412 and accessed by the CPU 410 using the signal bus 420. Memory 412 may comprise combinations of RAM and ROM. The CPU 410 in a multiprocessing or parallel processing computer system may comprise multiple individual CPU's, and likewise its memory 412 may comprise multiple sections, each accessible or inaccessible to some combination of the individual CPU's.

Instructions and data may transfer between the CPU 410 or memory 412, and the memory media 414, network interface 416, and I/O devices 418 using the signal bus 420. Memory media 414 may comprise devices employing, e.g., magnetic, optical, magneto-optical, or other recording techniques for reading and/or writing to tape, disk, cartridge or other media. I/O devices 418 may comprise keyboards, pointing devices, video displays, printers, speakers, scanners, cameras, accelerator cards, supplemental processor cards, or other peripherals through which a user may interface with the computer system or which may extend the processing functionality of the computer system. The network interface 416 may comprise, e.g., network interface cards or modems which permit the computer 400 to establish data communication with other computer systems.

FIG. 4B depicts multiple individual computer systems 401, 402, like the one 400 illustrated in FIG. 4A, coupled by an electronic data communications network 490. The network 490 allows the individual computer systems 401, 402 to exchange data. Further, software on the individual computer systems 401, 402 may employ exchanged data to represent service requests and responses, allowing the individual computers 401, 402 to cooperate in the processing of a workload. Such cooperative processing is well known in the art and may take many forms, e.g., peer-to-peer, client-server, multi-tiered, parallel-processing architecture, and combinations.

Defining Processing Logic

For the PMKBS to control and monitor a subject process, the processing logic, of that process must first be encoded in memory medium in a form the PMKBS accepts. FIGS. 5A-5B depict one method of defining processing logic into a process management knowledgebase (PMKB). In one embodiment, the PMKB is maintained using the services of a relational database management system (RDBMS). RDBMS's are widely known in the art. Many RDBMS products are available commercially. An advanced RDBMS product may contain many or all of the features described in E. F. Codd, The Relational Model for Database Management, Version 2 (Addison-Wesley 1990) and hereby incorporated by reference. Advanced features that may be employed to implement the presently described embodiment of the invention include, e.g., field-level triggering and access to a predicate logic expression evaluator via an RDBMS language.

In the embodiment depicted in FIGS. 5A-5B, conventional RDBMS software on the computer manages relations, or tables, designated TABLES 550, ET 555, TT 565, ETCORR 560, DTQ 575, NOTICE 580, and E10 570, on a memory media device 540. The TABLES table 550 is shown for illustrative purposes and represents an exemplary RDBMS conventional catalog structure. For purposes of illustration, the TABLES table 550 contains one record, or row, for each table managed by the RDBMS.

The Event-Type (ET) 555, Task-Type (TT) 565, and Event-to-Task Correspondence (ETCORR) 560 tables are part of a PMKBS catalog 546. Relating back to FIG. 3, the ET table 555 acts as the expression data store 310, the TT table 565 acts as the response data store 320; and the ETCORR table 560 acts as the correspondences data store 315. These tables 555, 560, 565 are defined to the RDBMS as part of the installation process for the PMKBS.

In the present embodiment, a computer user interfaces to the computer using a keyboard, monitor, and possibly a mouse 510. The computer user creates a file of statements 514. The statements in the file 515 codify elements of the processing logic of the subject process being defined to the PMKBS. Each statement defines a row to be inserted in one of the ET 555, TT 565, or ETCORR 560 tables. The file of statements 514 may be created directly by the user through the use of a text-editing program or a word processor. Alternatively, the computer user may employ a front-end utility program 512, such as a GUI-based development tool, that produces the file of statements 516 in response to user inputs.

The completed file of statements 514 is an input to a definition program 520. The definition program 520, in some embodiment, may be a software program of the PMKBS. The definition program 520 reads each statement from the input file 514 and inserts a row into the PMKBS catalog 546 table to which the statement pertains. In this embodiment, the definition program 520 creates additional tables in the PMKB. The additional tables are used to record activity during operation of the subject process under the PMKBS. To create the additional tables, the definition program 520 creates SQL statements 522. The definition program 520 then invokes the RDBMS 524, passing the SQL statements 522. In response to the SQL statements 522, the RDBMS 524 establishes the new tables.

An example of the defining process depicted in FIGS. 5A-5B assume the computer user wants to define a new event-type, E10. Using an editor or GUI-based development tool, the user creates a statement defining the event-type 516. The definition program 520 reads the statement and parses it to determine that it defines an event-type. Relevant information is extracted from the statement and inserted into a new row in the ET table 555 as indicated by arrow A 530. The definition program 520 also creates an SQL statement 523 compatible with the SQL language provided by the RDBMS 524, as indicated by arrow B 532, to define a new table to hold instances of the E10 event-type that occur during operation of the process. The definition program 520 invokes the RDBMS 524 as indicated by arrow C 534, passing the SQL statement 523 to it. The RDBMS 524 makes an entry 551 for the E10 table in its catalog 542 as indicated by arrow D 536, and creates an empty table 570 to hold E10 records as indicated by arrow E 538.

The operation of the definition program 520 is described above in terms of a batch/compiler mode of operation. One skilled in the art recognizes that other alternatives to populating the PMKBS catalog may be employed, e.g., interpreters, or transaction processors, without departing from the spirit of the invention. For example, a graphical user interface, such as the one contained in Microsoft ACCESS, may give a user fast and easy access to directly manipulate the data in the PMKBS catalog 546 tables.

PMKBS Catalog Data Structures

FIGS. 6A to 6D depict record layouts for PMKBS catalog 546 entries. FIG. 6A depicts the record layout for an event-type definition record 660 contained in the ET table 555. The record 600 comprises event-type identifier 601, time stamp 603, expression template 605, active time 607, end time 609, and source identifier 611 fields. The primary key 619 of the record 600 comprises the event-type identifier 601 plus the time stamp 603 fields. The combined contents of the fields in a primary key uniquely identify a particular record in a table, and may serve to define a default order in which records appear or are processed. The event-type identifier field 601 contains a unique name for a type of event that can occur in a subject process. The time stamp field 603 contains a representation of the date and time at which the record 600 is inserted into the table.

The expression template field 605 contains a template for an expression to be evaluated to determine some aspect of the state of the subject process when an event of event-type occurs during operation of the subject process. In the present embodiment, the expression template is a predicate logic expression conforming to a syntax supporting predicate logic. Predicate logic is known in the art and is discussed in references such as Donald Gillies, Artificial Intelligence and Scientific Method (Oxford University Press 1996), and Alonzo Church, Predicate Logic (Princeton). The expression template may contain names of variables that are substituted prior to evaluation. Variables used in the expression template in this embodiment may refer to any data item addressable using the RDBMS.

It is noted here that the ability to reference any data item addressable using the RDBMS gives the PMKBS extensive reach for the processes it manages when used in conjunction with a distributed RDBMS. If, for example, a company's distributed RDBMS connects companies nationwide, the PMKBS could make decisions, i.e., check conditions, based on factors not just in a local office, but around the nation.

The active time field 607 contains the earliest date and time that the event definition is to be considered active and valid during operation of the PMKBS. The end time field 609 contains the earliest date and time, after the time of its initial activation, that the event definition is to be considered inactive. The source identifier field 611 contains the identity of the computer user or system responsible for creating the instant event-type definition.

The inclusion of the active time 607 and end time 609 fields allows alternative definitions for event-types to be staged in anticipation of a planned change of the process model. Such fields may be similarly implemented with the other record types for tables in the PMKBS catalog. Implementing such fields provides flexibility in the PMKBS for use with relatively dynamic process models.

FIG. 6B depicts the record layout 620 for a task-type definition record contained in the TT table 565. The record 620 comprises task-type identifier 621, executable response template 623, and source identifier 625 fields. The primary key 639 comprises the task-type identifier field 621. The task-type identifier field 621 contains a unique name for an executable response.

The executable response template field 623 contains a set of command statements. In the present embodiment, a command statement is either a statement containing an SQL statement to be executed by the RDBMS, or a statement containing a program name and parameters to be executed by the operating system shell. The format of the statements in the preferred embodiment appears in Table 1. The "SQL:" statement permits processing of data maintained by the RDBMS via a language provided by the RDBMS. The "PRG:" statement permits execution of a named program recognized by the operating system. As such, the PMKBS can initiate virtually any type of processing supported by the operating system and subsystems, so long as a program has been created to perform the desired processing.

• Inventors
  Codd, Edgar F.; Codd, Sharon B.;
• Published
  Jan-10-2006
• Current US Classes:
  706/45
  706/47
  706/50
  706/56
  707/6
  717/114
  719/318
• Application #
  146449
• International Classes
  G06F 001/70.0
• Field of Search
  702/1-208 712/114 717/114-144 709/100-108 709/313-318 706/45-58 707/1-10 707/200 707/100-102 707/3-6 719/313-318 718/100-108
• Examiner
  Jung; David
• Agent
  Morrison & Foerster LLP
• US Patent References:
  5481700
  5499368
  5511186
  5548755
  5594638
  5615359
  5712960
  5819090