Method for persisting a schedule and database schema

The invention provides a database schema for representing a workflow process definition (e.g., a schedule). The database schema may also include one or more bindings associated with the schedule, as well as persisted state information and data. The invention further includes a method for storing schedule information in a storage medium, as well as a computer-readable medium having a data structure stored thereon. The storage of schedule-related information provides for ease of version control, and ease of distribution, for example, where several engines point to the same database as a single source of transaction processing or workflow schedule definitions. The definitional database schema may be advantageously employed to reconstruct the schedule definition language solely from information in a database. In addition, the schema may be used for storing instances of running schedules and data associated therewith. This allows ease of schedule state and data monitoring using existing database query tools.

TECHNICAL FIELD

The present invention relates to transaction processing in computer systems. More particularly, the invention relates to a method for storing and monitoring a transaction schedule and information related thereto in a database, and a database schema therefor.

BACKGROUND OF THE INVENTION

Schedules are applications which may be defined for transaction processing systems, such as computer systems. A schedule instance may be executed in such a system, whereby one or more transactions within the schedule are executed. In executing an instance of such a schedule and its component transactions, information associated therewith may need to be stored or persisted in a storage medium, such as a memory system.

Storage of information in a storage medium may be facilitated using a database in conjunction with a database management system (DBMS). A database is a collection of related data that may be stored on a nonvolatile memory medium. Data in the database is commonly organized in a two-dimensional row and column form called a table. A database typically includes multiple tables.

A table is an object in the database having at least one record and at least one field within each record. Thus, a table may be thought of as an object having two-dimensional record and field organization. A record is a row of data in the table that is identified by a unique numeric called a record number. A field is a subdivision of a record to the extent that a column of data in the table represents the same field for each record in the table. Each field in a record is identified by a unique field name and a field name remains the same for the same field in each record of the table. Therefore, a specific datum in a table is referenced by identifying a record number and a field name.

A database management system (DBMS) is a control system that supports database features including, but not limited to, storing data on a memory medium, and retrieving data from the memory medium. Data in the database is typically organized among a plurality of objects that include, but are not limited to, tables and queries. An individual table or query may be referred to as a record source because it is a source of data or records from the database. A query object is an executable database interrogation statement, command, and/or instruction that communicates to the database management system the identity and location of data being extracted from the database. The product of an executed query is called a result set. A result set may be stored and/or manipulated as a two-dimensional object similar to the table discussed previously.

A relational database is a common database type managed by a database management system. Data in a relational database is distributed among multiple record sources that are typically related, or normalized, in a manner designed to minimize redundant data in the database, minimize the space required to store data in the database, and maximize data accessibility. Record sources in a database may be related to one another via key fields. A normalized database is one where each record source in the database is directly related to at least one other record source in the rd same database by key fields.

A key field can be a primary key or a foreign key. A primary key is a field or combination of fields in a record source that includes unique data for each record in the table. A foreign key is any non-primary key in a record source that is the basis for a direct relation with any other record source. A database remains a relational database regardless of the degree of normalization that exists. Record sources in a normalized relational database are typically related. However, a relational database may be normalized even if the database is disconnected in that at least one record source in the database is not related to any other record source by a key field.

Relationships between any two record sources in a relational database may be either direct or indirect. Such a relationship may also be referred to as a relation or join. A direct relationship exists between two record sources if there is no intervening record source in the relationship path therebetween. An indirect relationship exists if there is at least one intervening record source in the relationship path between two record sources.

The record sources in a relational database and the relationships therebetween define the geography of a database, which may be called a database schema. A sub-schema of the database is any subset of the full database schema that is defined by a query, a result set of a query, or any other subset of record sources from the database. A database schema and database sub-schema may be displayed visually in graphic form as a graph having edges or arrows representing relationships between record sources, and vertices, also known as nodes or tables, representing the record sources at either end of a relationship.

Queries are used to access data in a database. A query may be constructed in a Structured Query Language (SQL) that may or may not be based on the American National Standards Institute (ANSI) standard SQL definition. To access data in a database, a user may construct a query using an SQL. Executing a query is called a join or joining wherein each relation identified in the query is joined during execution to retrieve the desired data from a database.

Schedule-related information comprises many diverse types of data. Prior transaction processing systems do not provide an effective mechanism for the storage any retrieval of such schedule-related information and data to and from a storage medium, such as a database. It is desirable to store information relating to a schedule definition in an efficient manner where the specifics of the definitional language may be easily reconstructed solely from information in a database. At the same time, updates to the database with runtime information may need to be fast, possibly at the expense of storage efficiency. Thus, fully normalized database structures are not an optimal match for the requirements of schedule information storage. In addition, schedule-related information may include binding information. One or more bindings may be associated with a schedule, to allow instances of a single schedule to be executed on different machines or systems with different hardware technologies. Conventional database structures and schemas do not provide efficient, easily-portable storage solutions for schedule-related information storage. Moreover, current schedule storage methods and systems do not provide for ease of querying and monitoring schedule-related information and data.

SUMMARY OF THE INVENTION

The present invention relates to a first (e.g., definitional) database schema for representing a process definition (e.g., a schedule), and a second (e.g., runtime) schema for representing the process definition, one or more bindings associated therewith, and persisted state information and data. The invention further includes a method for storing schedule information and/or data associated therewith in a storage medium, as well as a computer-readable medium having a data structure stored thereon. Database storage of the process definition information allows for ease of version control, and ease of distribution, for example, where several runtime engines or systems point to the same database as a single source of definitions. The table or tables in the database schema corresponding to the process definition include class level information. In this regard, the definitional database schema may be advantageously employed to reconstruct the schedule definition language solely from information in a database.

In addition to the definitional information, the second (e.g., runtime) schema may be used for storing instances of running schedules. The schema accordingly includes one or more tables related to instance information. The instance tables may comprise, for example, information describing what instances of a schedule are running and what definitions they correspond to, as well as positional information, such as what actions are currently live, how many messages are currently pending, and other schedule state information. Moreover, the schedule definition and binding information portions or tables of the schema may be normalized to a higher degree than are those relating to runtime information. In this way, an efficient storage methodology and system are provided for less frequently accessed tables (e.g., tables related to schedule definition and binding information), while fast access is provided to runtime information. Thus, the invention provides for optimal storage or persistence of the diverse types of schedule-related information.

The runtime database schema may also include data associated with one or more schedule instances. This data may include the value of specific messages, etc. For example, the schedule state information and data may be persisted to the database during execution at transaction boundaries. Schedule data and state information may also be persisted to the database during dehydration operations based on latency hints or attributes. The database schema provides a format for storing the persisted information in a relational database for ease of access and monitoring by a user.

The runtime schema may be fixed, thus allowing the use of monitoring and other tools to query against the database. Such database queries may be employed to indicate the status of a running workflow process, how specific instances of the process are running, (e.g., for each instance of the process, the current position in the schedule, etc.), and the data associated therewith. The ability to use common tools for obtaining this information is enabled by the use of overlapping schemas for definitional purposes and to describe runtime instances and information associated therewith.

The runtime schema may be a superset of the definitional schema, including all the information therefrom, as well as the instance related tables and runtime data tables. Because the runtime schema includes both static definitional information, as well as instance information (which may be accessed frequently), these different portions of the schema may be normalized differently. Accordingly, the definitional information may be normalized to minimize storage space requirements by reducing redundant information storage, whereas the instance information may be normalized to a lesser degree (or not at all) to allow for fast access thereto. This flexibility in normalization provides for runtime efficiency when data and state information is persisted to disk, for example, where persistence at transaction boundaries, and/or dehydration (and rehydration) are employed.

In accordance with one aspect of the invention, there is provided a database schema for storage of process information in a database, comprising a table representing process definition information derived from a process definition language representation of a process.

In accordance with another aspect of the invention, there is provided a database schema for storage of process information in a database. The database schema comprises a definitional element with at least one definition table for storing a process definition, and a runtime element with at least one instance table for storing instance information and at least one data table for storing runtime data.

In accordance with yet another aspect of the present invention, there is provided a method for storing process information in a database. The method comprises providing a database schema, having a definitional element with a definition table for storing a process definition, and a runtime element with at least one instance table for storing instance information and at least one data table for storing runtime data. The method further comprises storing a process definition in the database according to the definition table, storing instance information in the database according to the instance table, and storing runtime data in the database according to the data table. Another aspect of the invention provides for a computer-readable medium having computer-executable instructions for carrying out the steps of the above method.

In accordance with still another aspect of the invention, there is provided a computer-readable medium having stored thereon a data structure. The data structure comprises a first data component with data representing a definition of a process, a second data component with data representing instance information relating to one or more instances of the process, and a third data component with data representing runtime data relating to the process. The data structure thus includes all aspects of a schedule, including the schedule definition elements, and runtime elements. This data structure allows for efficient recreation of definitional language representations of the schedule, and monitoring of schedule status information and data using existing database query tools.

In accordance with yet another aspect of the invention, there is provided a method of monitoring a schedule having schedule-related information associated therewith. The method comprises querying a database having schedule-related information stored therein according to a schema to obtain a result set, wherein the schema comprises a definitional element with at least one definition table for storing a process definition, and a runtime element with at least one instance table for storing instance information and at least one data table for storing runtime data. The result set may comprise at least a portion of the schedule-related information. The method may further comprise providing the result set to a monitoring device, and monitoring the result set via the monitoring device. The invention thus enables a user to monitor the progress of one or more instances of a schedule using existing database query tools, which is advantageous in diagnostic and troubleshooting applications. According to another aspect of the invention, the method may further include storing schedule-related information in the database according to the database schema. In addition, the invention includes a computer-readable medium having computer-executable instructions for performing the above methodology.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing and other aspects of the invention will become apparent from the following detailed description of the invention and the attached drawings in which:

FIG. 1Ais a schematic diagram illustrating an exemplary database schema in accordance with an aspect of the present invention;

FIG. 1Bis a schematic diagram illustrating another exemplary database schema in accordance with the invention;

FIG. 2Ais a schematic diagram illustrating yet another exemplary database schema in accordance with the invention;

FIG. 2Bis a schematic diagram further illustrating the exemplary database schema ofFIG. 2A;

FIG. 2Cis a schematic diagram further illustrating the exemplary database schema ofFIGS. 2A-2B;

FIG. 2Dis a schematic diagram further illustrating the database schema ofFIGS. 2A-2C;

FIG. 2Eis a schematic diagram further illustrating the database schema ofFIGS. 2A-2D;

FIG. 2Fis a schematic diagram further illustrating the database schema ofFIGS. 2A-2E;

FIG. 3is a flow diagram illustrating an exemplary method for storing process information in a database in accordance with the invention;

FIG. 4is a flow diagram illustrating an exemplary method of monitoring process information in a database according to the invention; and

FIG. 5is a schematic diagram illustrating an exemplary environment in which the various aspects of the invention may be carried out.

DETAILED DESCRIPTION OF THE INVENTION

The following is a detailed description of the present invention made in conjunction with the attached figures, wherein like reference numerals will refer to like elements throughout. According to one aspect of the invention, a database schema is provided, having a definitional element or component with at least one table representing process definition information derived from a process definition language representation of a process. The schema may further comprise a runtime element with at least one instance table for storing instance information and at least one data table for storing runtime data.

FIG. 1Aillustrates one exemplary database schema2for storage of process information in a database (not shown) in accordance with the invention. The schema2includes a table4having process definition information6therein. A user may advantageously extract or reconstruct a definitional language representation of a schedule or other process from the process definition information6in the database.

Another exemplary database schema8is illustrated inFIG. 1B, which may be a superset of the schema2of FIG.1A. Schema8comprises a definitional element10with at least one definition table12for storing a process definition14. Like the database schema2ofFIG. 1A, the process definition14may be employed to extract or reconstruct a definitional language representation of a schedule or other process. The schema8further comprises a runtime element16with at least one instance table18for storing instance information20, as well as at least one data table22for storing runtime data24.

The exemplary schemas2and8ofFIGS. 1A and 1Bprovide a complete definition of a transaction processing or workflow schedule. Thus, it is possible to reconstruct the schedule definition language representation of a schedule solely from the information in the database. The schema8, moreover, provides a data structure (e.g., runtime element16) for storing and managing runtime data24related to one or more instances of a schedule in a database. The runtime information or data24may comprise, for example, schedule state information, data, and/or messages (not shown) associated with a running schedule application. This runtime data24may be accessed using existing database query tools and database management systems (DBMSs) to provide a user with status and/or data associated with one or more processes. This allows users to easily monitor schedule execution progress, which is advantageous in diagnostic or debugging situations.

FIGS. 2A-2Fgraphically illustrate another exemplary database schema28in accordance with the invention. The schema28comprises various tables and relationships therebetween, as described hereinafter. The various tables of database schema28are described now, after which the fields within the tables and the relationships between tables are discussed.

Schema Tables

FIG. 2Aillustrates a portion of schema28having a Schedule table30, a Context Table31, a Module table32, a Message table33, a Case Rule table34, a Port table35, and a GroupTbl table36. Referring also toFIG. 2B, the database schema28further comprises a Sequence table40, a Task table41, a SourceSink table42, a Block table43, an Action table44, and a ContextInvocation table45.

FIG. 2Cillustrates another portion of the schema28comprising a RunCOMObjects table50, a RunCOMField table51, a RunContexts table53, and a RunInstances table54. The schema28further comprises a RunContextStatus table55, a Process table56, and a Parts table57. Referring toFIG. 2D, the schema28also includes a Call table60, a CallMsgTable table61, a CallPortTable table62, a SwitchTbl table63, a CaseTbl64, and a Copy table65. Referring also toFIG. 2E, schema28includes a Cut table70, a MapTbl table71, an Assignment table72, a Connection table73, a Partition table74, a Connect table75, and a PartitionElem table76. As illustrated inFIG. 2F, the database schema28further comprises a Binding table80, a COMPortBinding table81, a COMMsgBinding table82, a COMFieldBinding table83, a ContextBinding table84, a RuleBindingAll table85, and a Match table86.

Schema Table Fields

The various tables of the database schema28illustrated inFIGS. 2A-2Fcomprise fields having field names, exemplary data types, and exemplary field sizes as described hereinafter. It will be appreciated that other field names, data types and25field sizes are possible and are contemplated as within the scope of the present invention. Referring now toFIG. 2A, the Schedule table30includes the following fields: ScheduleID: char(36); ScheduleName: varchar(100); ContextID: int; ModuleID: char(36); and ProcessID: int. The Schedule table30has a primary key Scheduleld and foreign keys FK1 ModuleID and FK2 ProcessID.

The Context table31comprises the following fields: ContextID: integer (identity); ContextName: varchar(100); ScheduleID: char(36); CompProcessID: integer, (null allowed); and TransactOpt: bit. In the Context table31, the TransactOpt Boolean field specifies a transaction or a try-catch like construct. Since the context may be applied to multiple processes and actions, the tables that define actions and processes contain a reference to the context of which they are a part. The CompProcessID field of table31refers to a compensation process. Compensation is a process whereby an action may be taken upon failure or abortion of an action or transaction. Such an action may include, for example, rolling-back or otherwise modifying data associated with an action or transaction, sending a message, etc. A compensation process may refer to a specific action, message, etc. which is to be executed when it has been determined that the data or work associated with an action or transaction needs to be compensated. The Context table31further comprises a primary key ContextID and foreign keys FK1 ScheduleID and FK2 CompProcessID. The Module table32comprises ModuleID: char(36), and Module Name: varchar(100) fields. The Module table32further includes a primary key ModuleID. It will be noted that foreign keys in the binding and schedule tables refer to module. Message table33comprises fields MessageID: integer (identity); MessageName: varchar(100); and ScheduleID: char(36). The Message table33also comprises a primary key Message ID and a foreign key FK1 ScheduleID. CaseRule table34includes fields for RuleID, RuleName, and ScheduleID: char(36), with a primary key RuleID and a foreign key FK1 ScheduleID. Port table35includes fields PortID: integer (identity); PortName: varchar(100); and ScheduleID: char(36). The Port table35further includes a primary key PortID and a foreign key FK1 ScheduleID.

GroupTbl table36comprises the following fields: GroupID: char (16); Group Name: varchar(100); and SystemName: varchar(100). The GroupTbl table36further comprises a primary key GroupID. The GroupID may be passed by a runtime engine, and may be a COM+ app id assigned while creating a group. It will be appreciated that other schemas are possible within the scope of the invention in which users may define associations between groups and modules.

Referring also toFIG. 2B, the Sequence table40comprises fields ProcessID: integer; ScheduleID: char(36); ContextID: integer, (null allowed); and cProcessID: integer, (null allowed). The ProcessID field is a primary key as well as a foreign key into the Process table, as the process table contains all processes. The cProcessID field is the id of an optional tail process in a schedule sequence. The Action table44may have an entry pointing back to the Sequence table40for actions that are part of a sequence. The Sequence table40further comprises a primary key ProcessID, and foreign keys FK1 ProicessID, FK2 ScheduleID, FK3 ContextID, and FK4 cProcessID.

The Task table41comprises the following fields: ActionID: integer; ContextID: integer, (null allowed); and ChoiceIsAll: bit. The ChoiceIsAll field is true when all actions which are part of a task need to execute in parallel. The ActionID ill field is both a primary key and a foreign key (e.g., FK1) of the Task table41. In the Task table41, the ChoiceIsAll field determines whether task property is, for example, All or None. The SourceSink table42comprises: ActionID: integer; ContextID: integer, (null allowed); IsSource: bit; MessageID: integer; and PortID: integer fields, in which the IsSource field is true if the action is of source type and false if the action is of sink type. The SourceSink table42includes a primary key ActionID and foreign keys FK ActionID, FK2 MessageID, and FK3 PortRefID.

The Block table43comprises fields for BlockID; ScheduleID: char(36); ContextID: integer, (null allowed); and pSequenceID. The Block table43includes a primary key BlockID and foreign keys FK1 pSequenceID and FK2 ContextID. The Action table44comprises Action: integer (identity); ContextID: integer, (null allowed); pSequence: integer, (null allowed); SortID: smallint, (null allowed); pTaskID: integer, (null allowed); and ActionType: varchar(10) fields. This table44has a primary key Action, and a foreign key FK1 BlockID. An action may be part of a sequence or task, in which case, one of the fields pSequence and pTaskID may have a value, however both of them will not. The ActionType field may have one of the following values: ‘call’, ‘source’, ‘sink’, ‘return’, or ‘release’. In the Action table44, the ActionType field may be an enum that identifies the type of action. Note that the ActionID may be the key for the tables corresponding to different types of actions. The pSequence field is a sequence id in the container sequence. The pTaskID field is the container task if it is part of the task. The ContextInvocation table45includes fields ActionID: integer; ContextID: integer; and IsReturn: bit; where the IsReturn field value determines whether an action is a return or release. Table45further includes a primary key ActionID and foreign keys FK1 ActionID and FK2 ContextID.

InFIG. 2C, the RunCOMObjects table50comprises RunID: char(36); PortRef: integer; Time: datetime; and ObjectData: image fields, and may be used to persist objects that support an IPersistable interface. The ObjectData field is of image type which can store data BLOBs. The RunCOMObjects table primary keys RunID and PortRef, as well as foreign keys FK1 RunID and FK2 PortRef. The RunCOMField table51comprises the following fields: RunCOMFieldID: integer (identity); MsgID: integer; RunID: char (36); FieldLocation: varchar (100); BindingID: integer; Value: text; and Time: datetime. The table51has a primary key RunCOMFieldID, as well as foreign keys FK1 RunID, FK2 FieldLocation, FK2 BindingID, and FK2 MsgID. The RunCOMFieldID field of table51may be used as an identity field. None of the other fields can be combined to form a key since multiple calls could be made to the same method in the context of a schedule instance. The BindingID field may be used to identify a particular binding as there could be multiple bindings for the same schedule. In this case, the MsGID field alone is not enough to identify a binding. The Value field is of type text, which allows it to store content of an arbitrarily large size.

The table52may be used to store the runtime state of actions and processes (e.g., transactions) when a schedule instance is persisted. Each row may have the ActionID or ProcessID fields set but not both. Since the entries to the RunProcessActions table52are added while a schedule is running, fast access thereto may be provided thereto. The ContextID field is included in the table52to make it easy to query for the actions executed in the scope of a particular transaction. While it may be possible to obtain this information by querying the other tables, this information may need to be accessed frequently by a monitoring tool and the query to get the information may be complex. Thus, the ContextID field is provided in the table52in order to assure fast querying capabilities. In the RunProcessActions table52, each row may include either the ProcessID or ActionID to give the status on that action or process.

The RunContexts table53fields comprise RunID: char(36); ContextID: integer; RetryCnt: integer, (null allowed); and NextRetryTime: datetime, (null allowed). The table53includes primary keys RunID and ContextID, as well as foreign keys FK1 ContextID and FK2 RunID. This table53may be used to track information about how many times a transactional context was retried. In this regard, a runtime engine may store information in the field NextRetryTime on when the transaction should be retried.

In the RunInstances table54, the following fields are provided: RunID: char(36); ModuleID: char(36); Owner: varchar(50); Status: varchar(30); DeHydrationCnt: integer, (null allowed); LastDehydrated: datetime, (null allowed); LastRehydrated: datetime, (null allowed); StartTime: datetime; and EndTime: datetime, (null allowed). The Owner field value may indicate the person (e.g., NT login) who started the schedule. The table54may contain an entry for each module that was executed. In addition, the status field value may have one of the values: Running, Done, Paused or Dehydrated. The RunInstances table includes a primary key RunID and a foreign key FK1 Module ID.

The RunContextStatus table55fields include: RunID: char (36); ContextID: integer; Time: datetime; and Status: varchar(20). This table55may track the state of transactions in a schedule. Any time a transaction is aborted or committed, an entry may be added to the table55. The possible values for the Status field include: Pending, Committed, Aborted, Compensating, and Compensated. As an example, the “Pending” state will be set when a compensation process, which needs to be executed for an aborted transaction, is started. This table55includes primary keys Time, Status, ContextID, and RunID, as well as foreign keys FK1 ContextID and FK1 RunID.

In the Process table56, ProcessID: integer (identity), and Type: varchar(0) fields are provided, wherein ProcessID is a primary key. The ProcessTable may be an enumeration table of types of elements. For example, in any row, only one of the columns may contain valid data. This data may indicate what kind of element that the corresponding row represents, and ID for the type which is a foreign key to the table of that type. Recursion is possible because the type table may refer back to the ProcessTable56using the ProcessID field. Possible values for the Type field include: Sequence, Map, Partition, Connect, Switch, Cut, and Copy. In the Parts table57, ScheduleID: char(36), and Tablename fields are provided. This table57has a primary key ScheduleID and a foreign key Tablename.

InFIG. 2E, the Cut table70comprises fields ProcessID: integer; ScheduleID: char (36); ContextID: integer, (null allowed); ProcessID1: integer; ProcessID2: integer; and ProcessID3: integer. The Cut table70has a primary key ProcessID and foreign keys FK1 ScheduleID and ProcessID. The Cut table70comprises a list of components or elements which communicate with each other, and which are included in the Process table56.

The MapTbl table71comprises fields ProcessID: integer; ScheduleID: char (36); ContextID: integer, (null allowed); and mProcessID: integer. MapTbl table71has a primary key ProcessID and a foreign key FK1 ScheduleID. The Assignment table72comprises fields ProcessID: integer; MessageID: integer; and PortID: integer. The table72further includes primary keys ProcessID, MessageID, and PortID, as well as foreign keys ProcessID, MessageID and PortID. The ProcessID field in the Assignment table72points to the ID of Map process, and the Assignment table72comprises port and message information related to the map.

The Connection table73comprises fields ConnectionID: integer (identity); ProcessID: integer; PortRef1: integer; and PortRef2: integer. Table73also comprises a primary key ConnectionID and foreign keys FK1 ProcessID, FK2 PortRef1, and FK3 PortRef2. The Partition table74includes fields. ProcessID: integer; ScheduleID: char (36); and ContextID: integer, (null allowed). In addition, table74includes a primary key ProcessID and a foreign key FK1 ScheduleID. The Partition table74comprises a list of independent components or elements, which are included in the Process table56.

The Connect table75comprises fields ProcessID: integer; ScheduleID: char (36); ContextID: integer, (null allowed); ProcessID1: integer; and ProcessID2: integer. Table75also has a primary key ProcessID, and foreign keys FK1 ProcessID2, FK2 ProcessID1, FK3 ScheduleID, and FK4 ProcessID. The ports that are connected as per this connect process may be specified in the Connection table73. The PartitionElem table76includes fields ProcessID: integer and pProcessID: integer. The ProcessID field is the id of the processes that are part of partitions. The pProcessID field is the id of the corresponding partition process. PartitionElem table76includes primary keys ProcessID and pProcessID, and in addition, foreign keys ProcessID and pProcessID.

Schema Table Relationships

The exemplary database schema28illustrated inFIGS. 2A-2Fcomprises various tables as illustrated and described supra, as well as relationships between the schema tables, which are illustrated and described in greater detail hereinafter. One or more of the schema tables include information relating to the definition of a schedule, which may be advantageously employed to reconstruct the schedule definition language solely from information in a database. In addition, the schema28may include one or more tables related to instance information having, for example, information describing what instances of a schedule are running and what definitions they correspond to, as well as positional information, such as what actions are currently live, how many messages are currently pending, and other schedule state information. Moreover, the schedule definition and binding information portions or tables of the schema may be normalized to a higher degree than are those relating to runtime information. In this way, an efficient storage methodology and system are provided for less frequently used tables (e.g., schedule definition and binding information), while fast access is provided to runtime information.

The database schema may also include runtime data associated with a schedule instance. Such data may include the value of specific messages, etc. According to one aspect of the invention, the schedule state information and data may be persisted to the database during execution at transaction boundaries. Schedule data and state information may also be persisted to the database during dehydration operations based on latency hints or attributes. The database schema provides a format for storing the persisted information in a relational database.

Because the schema may be fixed, the invention also allows the use of monitoring and other tools to query against the database, in order to indicate the status of a running workflow process, as well as how specific instances of the process are running. The use of existing or common database tools (e.g., from database management systems or DBMSs) for obtaining this information is enabled by the use of overlapping schemas for definitional purposes and to describe runtime instances and data.

The schema28ofFIGS. 2A-2Fprovides a complete definition of a transaction processing schedule, as well as one or more bindings for specific hardware applications thereof. Thus, it is possible to reconstruct the schedule definition language representation of a schedule, and the binding for the schedule solely from the information in the database. The schema28, moreover, provides a data structure for storing and managing runtime information related to instances of a schedule in a database. The runtime information may comprise, for example, schedule state information, data, and messages associated with a running schedule application.

In order to make updates to the database by the runtime engine fast, the schema28may not be fully normalized and some tables contain redundant information. At the same time, the tables of the schema28for storing schedule and binding definition should be efficient. As such, these tables are normalized with clearly defined foreign key relationships to make storage optimal. Accordingly, the tables designed to contain non-runtime information in the exemplary schema28have been normalized to the third normal form. Thus, most of the schema is normalized to third normal form. In some instances, especially in the case of tables that will be accessed frequently by the runtime engine (e.g., RunProcActions52) some redundant information may be stored in the interest of simplifying and increasing the speed of queries.

In addition, the database schema according to the invention is portable to multiple database systems. This allows users to employ many different relational database management systems (RDBMS) to store and access the schedule-related information. Accordingly, the schema28may not use any data types or constructs unique to any particular SQL server.

Prior to executing schedules, a runtime engine or system may create data set names (DSNs), create a database and associated tables therein according to the schema28, and obtain read/modify access to the login-id of the runtime engine. For the sake of simplicity, a group manager may assume that a file DSN with the same name as the name of its COM+ application has been configured by the administrator on the system in which the group manager is installed. This DSN may point to an appropriate SQL server to use and be configured to use, for example, Windows NT authentication. In this case, in the property page under a workflow tab, for the group manager the DSN name will be listed (the COM+application name). Next to the DSN name, there will be a “Test Data Source” button, which may test access to the database pointed to by the DSN. In addition, a “Configure data source” button may be provided which will help a user configure the DSN and create the tables, stored processes, and access accounts on the database.

The login id of the user (e.g., the administrator) will be passed to the SQL to open a connection. Thus, the administrator using the MMC may need, for example, dbcreator (a system role in SQL server) level (or higher) permissions in the SQL server. The configure operation may also allow the user to specify the login id of users who will have read/modify privileges to the database. The userid of the group manager process may either be on this list or otherwise configured to allow access to the database. When a user runs a schedule, the group manager may use its login id to access the database.

In addition, a cleanup utility may be provided that can be used to remove data related to old schedules and instances. Such a utility may be run periodically to cleanup the database. As an example, a cleanup utility may allow a user to remove instances whose schedules don't exist, remove schedules (or instances) that were not executed for a certain period of time, remove schedule instances executed before a certain date, and/or remove schedule instances owned by someone.

The exemplary schema28illustrated inFIGS. 2A-2Fand described hereinabove is one example of a database schema in accordance with the present invention. It will be appreciated by those skilled in the art that other schemas are possible within the scope of the invention beyond those specifically illustrated and described herein. For example, the invention contemplates database schemas wherein one or more of the tables illustrated in the exemplary schema28are combined into a single table. Moreover, other variations are possible, wherein one or more of the tables in the exemplary schema28are divided into two or more such tables, with corresponding relationships. The invention thus comprises all such variations within the scope of the appended claims.

Method of Storing Process Information in a Database

As illustrated and described supra, the present invention provides a database schema for storage of process information in a database, with one or more tables therein representing process definition information derived from a process definition language representation of a process. A process or schedule may be defined by a user graphically or using a schedule definition language. The schedule is then represented in one or more tables in a database schema (e.g., schema28of FIGS.2A-2F). In accordance with another aspect of the invention, the database schema may comprise both a definitional element with at least one definition table for storing a process definition, and a runtime element with at least one instance table for storing instance information and at least one data table for storing runtime data.

The invention further provides a method for storing process information in a database. The method comprises providing a database schema, having a definitional element with a definition table for storing a process definition, and a runtime element with at least one instance table for storing instance information and at least one data table for storing runtime data. The method further comprises storing a process definition in the database according to the definition table, storing instance information in the database according to the instance table, and storing runtime data in the database according to the data table.

A runtime engine executing a schedule may store or persist data or information relating to the schedule instance in a storage medium for various reasons. Persistence of data is required, for example, to enable dehydration and rehydration of a schedule instance, particularly for long running transactions or schedules. According to this process, binding information may include latency hints or attributes for individual actions and/or transactions within a schedule. These attributes or hints may be used at runtime to decide whether to suspend execution of a schedule and dehydrate the schedule to a storage medium during the pendency of a long running action or transaction. The schedule may then be reawakened or rehydrated (e.g., read from the storage medium) upon the occurrence of an event (e.g., message), after which execution thereof may proceed.

Another reason for persisting schedule-related information is to provide for recovery of a schedule instance when the runtime system goes down. For example, a runtime engine or system may fail during execution of a schedule instance. When the engine comes back up, it will need to determine where to resume execution of the transaction. In such a case, the exemplary schema28provides a database structure from which a runtime engine may determine the state of a schedule instance. Similarly, where a transaction or action within a schedule fails or aborts, the runtime engine needs a way of determining what has completed prior to the failure, in order to carry out compensation routines or processes.

In addition to the above reasons, schedule-related information may be persisted to a storage medium periodically or at transaction boundaries, in order to enable or support debugging and/or monitoring of running schedules. The schema28provides a structure by which schedule state information (e.g., pending, completed, or aborted actions and/or transactions), messages, and/or data associated with actions or processes that are in the context of a transaction. Database management system query tools may be employed to monitor such information according to the schema28. This allows a user to determine the current state of actions and/or transactions within a schedule using existing tools. As a result, troubleshooting or debugging a schedule may be facilitated.

Referring now toFIG. 3, an exemplary method300for storing process information in a database in accordance with the invention is illustrated. Beginning at step302, a database schema is provided having a definitional element with a definition table and a runtime element with an instance table and a data table. At step304, a process definition is stored in the database according to the schema definition table. Instance information is stored in the database at step306according to the instance table of the schema. At step308, runtime data is stored in the database according to the data table of the database schema.

Method of Monitoring Process Information in a Database

Referring now toFIG. 4, an exemplary method350of monitoring process information in a database is illustrated in accordance with the invention. The method350begins at step352, wherein schedule-related information is stored in the database according to a database schema The schema (e.g., schemas2,8, and28described supra) may have a definitional element with at least one definition table for storing a process definition, and a runtime element with at least one instance table for storing instance information and at least one data table for storing runtime data. At step354, the database is queried according to the database schema to obtain a result set which comprises at least a portion of the schedule-related information. The result set is provided to a monitoring device at step356, and monitored at step358. The method provides a user with status information and data associated with a running process, allowing progress monitoring and debugging of running schedules. The method of the present invention may be implemented in existing computer systems. Moreover, the queries of the method may be accomplished with query tools of existing database management systems.

Exemplary Operating Environment

In order to provide a context for the various aspects of the invention, FIG.5and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the various aspects of the present invention may be implemented. While the invention has been described above in the general context of computer-executable instructions of a computer program that runs on a computer, those skilled in the art will recognize that the invention also may be implemented in combination with other program modules. Generally, program modules include routines, programs, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the inventive methods may be practiced with other computer system configurations, including single-processor or multi-processor computer systems, minicomputers, mainframe computers, as well as personal computers, hand-held computing devices, microprocessor-based or programmable consumer electronics, and the like. The illustrated aspects of the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. However, some, if not all aspects of the invention can be practiced on stand-alone computers. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

With reference toFIG. 5, an exemplary system for implementing the various aspects of the invention includes a conventional server computer420, including a processing unit421, a system memory422, and a system bus423that couples various system components including the system memory to the processing unit421. The processing unit may be any of various commercially available processors, including but not limited to Intel x86, Pentium and compatible microprocessors from Intel and others, including Cyrix, AMD and Nexgen; Alpha from Digital; MIPS from MIPS Technology, NEC, IDT, Siemens, and others; and the PowerPC from IBM and Motorola. Dual microprocessors and other multi-processor architectures also can be used as the processing unit421.

The system bus may be any of several types of bus structure including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of conventional bus architectures such as PCI, VESA, Microchannel, ISA and EISA, to name a few. The system memory includes read only memory (ROM)424and random access memory (RAM)425. A basic input/output system (BIOS), containing the basic routines that help to transfer information between elements within the server computer420, such as during start-up, is stored in ROM424.

The server computer420further includes a hard disk drive427, a magnetic disk drive428, e.g., to read from or write to a removable disk429, and an optical disk drive430, e.g., for reading a CD-ROM disk431or to read from or write to other optical media. The hard disk drive427, magnetic disk drive428, and optical disk drive430are connected to the system bus423by a hard disk drive interface432, a magnetic disk drive interface433, and an optical drive interface434, respectively. The drives and their associated computer-readable media provide nonvolatile storage of data, data structures, computer-executable instructions, etc. for the server computer420. Although the description of computer-readable media above refers to a hard disk, a removable magnetic disk and a CD, it should be appreciated by those skilled in the art that other types of media which are readable by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, and the like, may also be used in the exemplary operating environment, and further that any such media may contain computer-executable instructions for performing the methods of the present invention.

A number of program modules may be stored in the drives and RAM425, including an operating system435, one or more application programs436, other program modules437, and program data438. The operating system435in the illustrated computer is the Microsoft Windows NT Server operating system, together with the before mentioned Microsoft Transaction Server.

A user may enter commands and information into the server computer420through a keyboard440and a pointing device, such as a mouse442. Other input devices (not shown) may include a microphone, a joystick, a game pad, a satellite dish, a scanner, or the like. These and other input devices are often connected to the processing unit421through a serial port interface446that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, a game port or a universal serial bus (USB). A monitor447or other type of display device is also connected to the system bus423via an interface, such as a video adapter448. In addition to the monitor, computers typically include other peripheral output devices (not shown), such as speakers and printers.

The server computer420may operate in a networked environment using logical connections to one or more remote computers, such as a remote client computer449. The remote computer449may be a workstation, a server computer, a router, a peer device or other common network node, and typically includes many or all of the elements described relative to the server computer420, although only a memory storage device450is illustrated in FIG.5. The logical connections depicted inFIG. 5include a local area network (LAN)451and a wide area network (WAN)452. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the server computer420is connected to the local network451through a network interface or adapter453. When used in a WAN networking environment, the server computer420typically includes a modem454, or is connected to a communications server on the LAN, or has other means for establishing communications over the wide area network452, such as the Internet. The modem454, which may be internal or external, is connected to the system bus423via the serial port interface446. In a networked environment, program modules depicted relative to the server computer420, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

In accordance with the practices of persons skilled in the art of computer programming, the present invention has been described with reference to acts and symbolic representations of operations that are performed by a computer, such as the server computer420, unless otherwise indicated. Such acts and operations are sometimes referred to as being computer-executed. It will be appreciated that the acts and symbolically represented operations include the manipulation by the processing unit421of electrical signals representing data bits which causes a resulting transformation or reduction of the electrical signal representation, and the maintenance of data bits at memory locations in the memory system (including the system memory422, hard drive427, floppy disks429, and CD-ROM431) to thereby reconfigure or otherwise alter the computer system's operation, as well as other processing of signals. The memory locations where such data bits are maintained are physical locations that have particular electrical, magnetic, or optical properties corresponding to the data bits.

Although the invention has been shown and described with respect to a certain embodiments, it will be appreciated that equivalent alterations and modifications will occur to others skilled in the art upon the reading and understanding of this specification and the annexed drawings. In particular regard to the various functions performed by the above described components (assemblies, devices, circuits, systems, etc.), the terms (including a reference to a “means”) used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (i.e., that is functionally equivalent), even though not structurally equivalent to the disclosed structure, which performs the function in the herein illustrated exemplary embodiments of the invention.

It will also be recognized that the invention includes a computer-readable medium having computer-executable instructions for performing the steps of the various methods of the invention. In addition, while a particular feature of the invention may have been disclosed with respect to only one of several embodiments, such feature may be combined with one or more other features of the other embodiments as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the terms “includes”, “including”, “has”, “having”, and variants thereof are used in either the detailed description or the claims, these terms are intended to be inclusive in a manner similar to the term “comprising” and its variants.