HK40009505A - Integrated workflow and database transactions - Google Patents

Description

Integrated workflow and database transactions

Technical Field

The present invention relates generally to the field of business process management ("BPM") and workflow management, computer software industry, and relational database technology.

Background

Most business applications run on relational databases such as Oracle DB2 or Microsoft SQL Server. Business process management ("BPM"), also known as workflow management, is a rapidly evolving concept employed by organizations to plan process-oriented approaches to accomplish tasks. Several software solutions implementing BPM solutions work as separate programs or in conjunction with other software platforms (e.g., databases, operating systems, and third party software) in an n-tier architecture by using Application Program Interfaces (APIs), Command Line Interfaces (CLIs), and other interfaces. Many BPM software solutions evolve from document, image and mail management systems, all of which involve the concept that when a topic is created ("document" or "file" or "mail" or "record"), a process controls the topic from start to finish. Attempts to integrate database and workflow solutions have involved loosely coupling different software platforms as customer solutions to specific business needs.

Disclosure of Invention

It is to be understood that: the following summary and detailed description are exemplary and explanatory and are intended to provide further explanation of the invention as claimed. The following summary and description are not intended to limit or restrict the scope of the invention to the particular features mentioned in this summary or description.

In particular embodiments, the disclosed embodiments can include one or more features described herein.

In one embodiment of the invention, a computer-implemented method is provided. The computer-implemented method includes assigning a data structure stored in a database to one or more workflow processes. The computer-implemented method also includes automatically creating an instance of the workflow in response to the data structure being populated with new records.

In another embodiment of the present invention, a computer-readable storage medium comprising a program which, when executed on a processor, performs an operation is provided. The operations include assigning a data structure stored in a database to one or more workflow processes. The operations also include automatically creating an instance of the workflow in response to the data structure being populated with new records.

In yet another embodiment of the present invention, a system is provided. The system may include: a processor and a memory including a program, which when executed by the processor is configured to perform an operation. The operations include assigning a data structure stored in a database to one or more workflow processes. The operations also include automatically creating an instance of the workflow in response to the data structure being populated with new records.

These and other objects and features of the present invention will be apparent in the disclosure including the above and following description.

Drawings

The invention may be understood by reference to the following description taken in conjunction with the accompanying drawings, in which the left-most reference numeral indicates the first figure in which the corresponding reference numeral appears, and in which:

FIG. 1 shows a block diagram illustrating an exemplary computing environment, according to one embodiment of the invention;

FIG. 2 shows a block diagram of an exemplary implementation of a workflow engine according to one embodiment of the invention;

FIG. 3 illustrates a block diagram of exemplary base and sub-tables, according to one embodiment of the invention;

FIG. 4 illustrates a graphical user interface for designing and managing workflow processes according to one embodiment of the invention; and is

FIG. 5 illustrates a block diagram of two tables showing relationships between database transactions and workflow transactions, according to one embodiment of the invention;

FIG. 6 illustrates a flow diagram for workflow engine enablement and creation of a flow design in a database according to one embodiment of the invention;

FIG. 7 illustrates a flow diagram for performing a database-workflow integration transaction in accordance with one embodiment of the invention;

FIG. 8 illustrates a flow diagram for executing a workflow unique transaction according to one embodiment of the invention;

FIG. 9 illustrates a flow diagram for executing a workflow event associated with a workflow transaction according to one embodiment of the invention;

FIG. 10 illustrates a flow diagram for executing a workflow event using a service agent in a workflow transaction according to one embodiment of the invention.

While the invention is amenable to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail herein. It should be understood, however, that the description herein of specific embodiments is not intended to limit the invention to the particular forms disclosed, but on the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

Detailed Description

Exemplary embodiments of the present invention are described below. In the interest of clarity, not all features of an actual implementation are described in this specification. It will of course be appreciated that in the development of any such actual embodiment, numerous implementation-specific decisions may be made to achieve the developers' specific goals, such as compliance with system-related and business-related constraints, which will vary from one implementation to another. Moreover, it will be appreciated that such an extension attempt may be complex and time-consuming, but may be a routine undertaking for those of ordinary skill in the art having the benefit of this disclosure.

Embodiments of the present invention will now be described with reference to the accompanying drawings. Various structures, connections, systems and devices are schematically depicted in the drawings for purposes of explanation only and so as to not obscure the disclosed subject matter with details that are well known to those skilled in the art. The attached drawings, however, are included to describe and explain illustrative examples of the present invention. The words and phrases used herein should be understood and interpreted to have a meaning consistent with the understanding of those words and phrases by those skilled in the relevant art. Specific definitions of terms or phrases, i.e., definitions that differ from the ordinary and customary meaning as understood by those skilled in the art, are not intended to be implied by consistent usage of the term or phrase herein. To the extent that a term or phrase is intended to have a special meaning, i.e., a meaning other than that understood by skilled artisans, such a special definition will be expressly set forth in the specification in a definitional manner that directly and unequivocally provides the special definition for the term or phrase.

One embodiment of the invention is implemented as a program product for use with a computer system, such as the computing environment 100 illustrated in FIG. 1 and described below. The program(s) of the program product defines functions of the embodiments (including the methods described herein) and can be contained on a variety of signal-bearing media. Exemplary signal-bearing media include, but are not limited to: (i) information permanently stored on non-writable storage media (read-only memory devices within a computer such as CD-ROM disks readable by a CD-ROM drive); (ii) writable storage media (e.g., floppy disks within a diskette drive or hard-disk drive); and (iii) information conveyed to a computer by a communications medium, such as through a computer or cellular network, including wireless communications. The (iii) embodiment includes, among other things, information downloaded from the internet and other networks. Such signal-bearing media, when carrying computer-readable instructions that direct the functions of the present invention, represent embodiments of the present invention.

In general, the routines executed to implement the embodiments of the invention, may be part of an operating system or a specific application, database, component, program, model, object, or series of instructions. The computer program of the present invention typically is comprised of a multitude of instructions that will be translated by the native computer into a machine-readable format and hence executable instructions. Also, programs are comprised of variables and data structures that either reside locally to the program or are found in memory or on storage devices. In addition, various programs described hereinafter may be identified based upon the application for which they are implemented in a specific embodiment of the invention. However, it should be appreciated that any particular program nomenclature that follows is used merely for convenience, and thus the invention should not be limited to use solely in any specific application identified and/or implied by such nomenclature. In this regard, references to specific definition languages and programming languages (e.g., HTML, XML, SQL,. NET, C #, etc.) are exemplary only. It is broadly contemplated that the present invention can be applied regardless of the particular schema or language used to define the content of the network resource.

Turning now to FIG. 1, a block diagram illustrating an exemplary computing environment 100 is shown, according to an embodiment of the invention. In general, the computing environment 100 includes client (e.g., user-side) computers 102 and server computers 104. The client computer 102 and the server computer 104 may be components of the same computer system or may be connected via a network 106 (e.g., the internet).

As shown, client computer 102 includes a Central Processing Unit (CPU)108, which is connected to a memory 110, a storage device 112, and a network interface 114 via a bus 116. The included CPU108 represents a single CPU, multiple CPUs, a single CPU having multiple processing cores, and the like. The storage device 112 stores applications and data used by the client computer 102. Examples of storage device 112 include one or more hard disk drives, flash memory devices, optical media, and the like. The client computer 102 may connect to a communication network 106 (e.g., a local area network, which may itself be connected to other networks such as the internet) using a network interface 114. Memory 110 may be one or a group of memory devices including random access memory, non-volatile or backup memory (e.g., programmable or flash memory, read only memory, etc.). Illustratively, the memory 110 of the client computer 102 stores an operating system 118 for managing the hardware and software executing on the client computer 102. As shown, the memory 110 also includes a browser program 120 that, when executed by the CPU108, provides support for navigating between the various servers and the local network address of one or more servers (e.g., server computer 104).

The client computer 102 may be connected to one or more display units 122, input devices 120, output devices 126, and peripheral devices 128. The display unit 122 may be an internal or external monitor, television screen, handheld device display, or the like. The input device 124 may be any one of a keyboard, mouse, trackball, stylus, mouse pad, mouse button, joystick, scanner, or the like. The output device 126 may be any one of a monitor, printer, plotter, copier or other output device. The peripheral device 128 may be any other device capable of being coupled to a computer: CD/DVD drives, USB devices, pole disk drives, external floppy drives, external hard drives, telephone and/or broadband modems, routers/gateways, access points, etc. capable of reading and/or writing to physical digital media.

Similar to the client computer 102, the server computer 104 may include a CPU 130, a memory 132, a network interface device 134, and a storage device 136 coupled via a bus 138. The memory 132 may be random access memory large enough to accommodate the necessary programming and data structures located on the server computer 104. As shown, the memory 132 stores an operating system 142 for managing server hardware and software executing on the server computer 104. Illustratively, the memory 132 also includes a hypertext transfer protocol (http) server 144 configured to maintain requests from the client computers 102. For example, the http server 144 may respond to requests to access electronic resources (e.g., HTML documents, network information, etc.) located on the server computer 104. Memory 132 may also include database server 143, which may respond to requests to access database application queries, and the like. However, those of ordinary skill in the art will appreciate that the database server 143 or the http server 144 are merely exemplary and that embodiments of the present invention may be adapted to support known and unknown protocols. The programming and data structures of http server 144 may be accessed and executed by CPU 130 during operation as needed. The server computer 104 may be connected to the network 106 using a network interface device 134, such as an analog modem, a limited network card, or a wireless network device.

In one embodiment, a user may interact with the server computer 104 using a Graphical User Interface (GUI). In particular embodiments, the GUI content may include HTML files (i.e., web pages) that are presented using browser 120 on a display unit 122 coupled to client computer 102. In one embodiment, the web pages may include pages that allow a user to design, manipulate, execute, and monitor the execution of various business processes (i.e., workflows).

Database server 143 may include a plurality of databases 145₁、145₂. Database 145₁May host the workflow engine 146. The workflow engine 146 may include a software application configured to enable modeling of workflows (e.g., defining procedures, states, tasks, actions, events, rules, etc.) to control activities associated with one or more databases (e.g., via a GUI). Database 145₁、145₂Relational database 145, which may include queries using SQL queries₁Or XML database 145 queried using XML queries₂. However, the invention is not limited to any particular physical numberThe database storage mechanism, and can be readily extended to operate on other such mechanisms, currently known or unknown. Although database 145₁、145₂Illustratively located within the server system, it is noted that database 145₁、145₂May exist on an external storage device (e.g., storage device 136) of the server computer 104 or may be accessed via the network 106.

Turning now to FIG. 2, a diagram illustrating an exemplary implementation of the workflow engine 146 according to an embodiment of the invention is illustrated. The workflow Engine 146 resides in the database 145₁In (1). Database 145₁Located in database server 143. As shown, workflow designer 204, business software application 206, database query tool 207, database reporting tool 208, and other database tools 209 are coupled to database 145₁. In one embodiment, database server 143 may be a database management system (DBMS) that controls database 145₁、145₂Creation, maintenance and use of. Database 145₁、145₂Associated with a logical unit in which data, procedures, and security are independently used by one or more associated applications. Database server 143 may also be coupled to external system 148₁、148₂It can be a third party system that utilizes a database 145₁Programmable features within and/or utilizing software features available in the database server 143 or features available in the O/S142 (as shown in fig. 1) are directly controlled or programmed by the workflow engine 146. In one embodiment, service broker features (not shown) available in many leading database servers known in the art are used for orchestration.

It may be noted that orchestration involves automatically orchestrating, coordinating, and managing complex computer systems, intermediate devices, and services. In orchestration operations, messages are exchanged between loosely connected systems that work together to complete a task. As an example, a third party delivery company may be sent a message to ship a product to an address. The payment company independently performs the delivery and confirms the payment details to the requester. The company requesting the payment is not concerned with the logistics of the payment and the payment company is not concerned with the purpose of the payment. Messages are simply exchanged between the two corporate systems to independently complete the delivery task.

The flow designer 204 allows a user (e.g., a GUI presented via the browser 120 (shown in FIG. 1)) to create and modify workflow flows. Using the GUI, the user can define, edit, review and manage workflow processes. Database 145 when a workflow process is created by flow designer 204₁A table (or data structure) in (1) is defined as a control table for the flow (the "base table"). The flow of data into the base table triggers the workflow engine 146. An instance of data flowing into the base table (record of table) initiates an instance of the workflow. The base table may be a control table for more than one flow, so an instance flowing into the base table may initiate many instances of the workflow for each flow. In other words, the workflow transaction is initiated as part of a database transaction to the base table.

In general, a workflow includes three basic elements: flow, state, and transition. A workflow process is a sequence of workflow for completing a task. The flow may take different routes at different points depending on the conditions set by the flow designer 204. A large task may be logically divided into many interconnected sub-processes. The states are static steps in the workflow process. A transition to an action that moves the workflow instance from one state to the next. A transition to a specific user action, or an automatic flow based on a specific condition set by the user. Using the GUI, the user can define the states and associated transitions of the workflow being modeled. In one embodiment, the workflow may be modeled as a high-level flow diagram (shown in FIG. 4) that enables a user to logically describe the activity as a flow. In one embodiment, the user may create the flowchart by performing a "drag" operation of the icon. The flow designer 204 interacts with the workflow engine 146. All workflow process definitions ("workflow metadata") are made as data by database 145₁And (5) storing.

The application 206 is a business application for handling the business that the software is designed to support. By way of example, the software of the customer order management application for mail order operations is a business application. It may have screens for creating orders, paying orders, and paying customers. Such applications may be established with or without workflow capabilities. Non-workflow applications may be found, for example, at 145₂Does not have a workflow engine 146 within the database of (a). The workflow enabled application operates like any software application but with the control of an additional workflow engine 146. The application may be modified to be a workflow-aware application when the application 206 interacts with the workflow engine 146 and utilizes workflow characteristics. As an example, an application in which workflow is improved may display the workflow status of all open orders. Applications in which workflow is improved may delegate and prioritize work to users. Applications in which workflow is improved may also control which users may do which work and coordinate among users, etc.

As previously mentioned, the workflow Engine 146 resides in the database 145₁And database 145₁Integrated with database server 143. The integration is achieved by implementing the workflow Engine 146 as being located in the database 145₁Is implemented by the program in the database layer of (1). This integration allows the workflow Engine 146 to have the ability to enter new data into the database 145₁The ability to control workflow flow when in progress or when data is modified and/or deleted. This integration provides transparent use of the database functionality (i.e., without knowledge of the presence of the workflow engine 146). However, this integration includes workflow control. Workflow process is on site in database 145₁Is instantiated, booted and controlled under changes to the data in the base table in (1). Database 145 is accessed through application 206, database query tool 207, database reporting tool 208, and many other database tools 209₁Any changes to the data in (a) are automatically detected and controlled by the workflow engine 146. This integration provides a database 145₁A seamless implementation of workflow engine 146 within a layer.

The workflow engine 146 may provide for the creation and management of workflow processes, models to interpret workflows, and manage workflow execution. The workflow engine 146 may also route and synchronize activities for flow, assign resources to activities, notify individuals, invoke events and applications, transfer data and files to applications and individuals, control user security and privileges, maintain information for various states of various workflow instances, and maintain a log of workflow transactions.

Turning now to FIG. 3, a block diagram of exemplary base and sub-tables is shown, according to an embodiment of the present invention. In general, data for businesses, organizations, entities, etc. may be stored in an appropriate database 145₁、145₂In a number of relationship tables 302, 304, 306. One such table is a base table 302, which typically contains multiple rows, each row containing records. If the base table is placed in the context of an order management application, each record in the base table may represent an order placed using the application. As shown, each record may contain an order identifier for each placed order. The base table 302 may have N numbers with associated child tables 302, 304. Each sub-table 302, 304 may contain information about each placed order. As shown, sub-table 304 contains the name of each customer placing an order, and sub-table 306 contains the number of items purchased for each order. In one embodiment, once the base table 302 is populated with new records, a workflow is initiated. Thus, each row of the base table 302 may also represent the occurrence of a workflow process (e.g., an order management process as defined by the workflow). The application 206 may be configured to create or modify data stored within the base table 302 (or one of its sub-tables 304, 306). The application 206 may use a user interface to enter or modify data, provide reporting capabilities, and the like.

Workflow may also be associated with internal and external systems 148₁And 148₂And (6) associating. For example, consider a business model in which customers are trusted to have frequent points of buyers for purchases. In this case, the customer frequent buyer point system that is trusted to have points may be an internal system. However, it is the usage database 145₂Different applications of (2). In another example, a third party delivery company may be used for direct shipment of customer orders. Payment company system (e.g., external system 148)₁And/or 148₂) May be notified of payment details. The payment company may perform the payment task and send the information details. Interaction with internal and external systems is accomplished through workflow events. The workflow events may be specified in the script using a programmable language (e.g., C #, Java, etc.). The event script may be executed by the workflow engine 146 as part of a database workflow integration transaction or just as part of a workflow transaction. An event may be set to be performed in a suitable place, for example when entering a state, leaving a state or when a user performs an action. Events include, but are not limited to: create files, initiate actions in other systems and/or applications, send email notifications, and the like.

Turning now to FIG. 4, a graphical user interface panel 402 for a design and management workflow process 404 according to an embodiment of the present invention is illustrated. For purposes of illustration, the workflow process 404 is shown for an order management process. As shown, the order management process may include a number of states: start 406, make order 408, pay order 410, invoice order 412, and end 414. States 406, 408, 410, 412, 141 may be coupled to each other through a number of transitions: order placement 416, payment 418, invoicing 420, cancellation 422, and completion 424. The workflow process 404 may be configured such that when a buyer places an order for a product (e.g., via a web form), it enters the order-in-process state 408. Depending on the actions taken during this state, the workflow 404 may transition from the make order state 408 to an end state 414 or a pay order state 410. For example, if the order is cancelled (e.g., by the supplier), the workflow process 404 may transition from the in-order state 408 to the end state 414 via a cancel transition 422. In this case, the vendor may use a user form that initiates an event that causes the workflow to comply with cancel transition 422 when the order is cancelled. However, if the product is in stock, the workflow process 404 may transition from the make order state 408 to the pay order state 410. In this case, the user form may initiate an interaction that causes the workflow to perform a payment conversion 418 when the order has been paid. When an order is invoiced (e.g., using a user form), the workflow process 404 may transition from the pay order state 410 to the invoiced order state 412 via an invoicing transition 420. Upon completion of the order, the invoiced order state may transition to an end state via a completion transition 424.

The states 406, 408, 410, 412, 414 and transitions 416, 418, 420, 422, 424 may be implemented as part of the workflow 402 by dragging the states and transitions with icons in the state 526 and icons in the transition box 428.

As previously described, the workflow process 404 is associated with a database 145₁、145₂The data in the base table in (1) are correlated. In one embodiment, the user may select the appropriate database 145 using the select database button 430₁、145₂. Using the above example, the workflow process 404 for the order management process may be created using a select base table button 432 that associates a base table 302 (shown in FIG. 3) containing order information (e.g., an order identification number). The order (workflow instance) may be created through a variety of tools, including an order processing application 206, a query tool, or any other compatible application. Workflow instances are created regardless of which tool is used.

In one embodiment, during the association of the base table 302 to the workflow process 404, the workflow engine 146 creates a table-level trigger on the base table. Such triggers serve as gateways (gateways) to the workflow engine 146. The workflow engine 146 is controlled by table triggers as records are added, updated, and deleted in the base table. When the workflow engine 146 gains control, it identifies the record using its primary key and completes the workflow transaction. Thus, the workflow transaction is completed as part of the database transaction. Once the base table 302 is populated with a record of a new order, an instance of the workflow process 404 may be automatically created for the order. In this case, when the workflow process 404 is initiated, the base table 302 may be configured to automatically and/or conditionally transition from the start state 406 to the in-process order state 408 once it is inserted by a newly placed order.

Once the user designs the desired workflow process 404, the workflow capabilities can be incorporated into existing or new applications (e.g., web-based order-placing applications). For example, a user may create a web form (e.g., using Microsoft visual basic. net) and associate the web form with database 145₁、145₂And (6) associating. Using browser 122, multiple netlists can be created, each with a different purpose. For example, a special grid may be used to transmit orders for products. As such, the web form may contain various fields that receive information about the order (e.g., a shipping address, a payment address, a product name, a quantity, etc.). When used to transfer forms, input representing a newly placed order is created in the same base table 302 selected for the created workflow process 404. Thus, once the input is created in the base table 302, a workflow flow instance can be automatically created for the order. A workflow instance may or may not be created based on the conditions set for the flow. As an example, the condition may be set to create a workflow only for mail orders and not for orders purchased in-store. Order placement conversion may also be initiated when a line is created. Accordingly, the start state 406 may transition to the in-process order state 408. Instances of the workflow are identified by a primary or unique key of the base table. The primary key of a table is a unique identifier for a row of the table. The workflow engine 146 independently maintains information for each record in a base table in its own data store that includes multiple tables. For example, the workflow engine 146 has information that ORDER _ ID 0001 (primary key) is now in state 408.

Another type of form that may be created is an order fulfillment and payment form, which may be used by the supplier of the product. The supplier may cancel the order using the form or fulfill the ordered product or products (i.e., a delivery order). Upon submission, the form may initiate an event that notifies the workflow engine 146 to move the workflow process 404 from the in-process order state 408 to the appropriate state. For example, if the supplier cancels the order, a cancel transition event may be initiated that causes the workflow process 404 to move from the order-in-preparation state 408 to the end state 414. In one embodiment, upon submission of the order fulfillment and payment form, a function may be invoked that signals execution of a cancel switch 422 that directs the workflow engine 146 to move the workflow 404 from the in-process order 408 to the end state 414. On the other hand, if the supplier fulfills the order, a pay-to-order transition 418 may be initiated which results in the workflow process 404 moving from the in-preparation order state 408 to the pay-to-order state 410. In one embodiment, upon submitting an order fulfillment and payment form, a function may be invoked that directs the workflow engine 146 to move the workflow process 404 from the in-preparation order state 408 to the payment order state 410.

The records in the base table and the data in the base table are independent of the workflow engine 146. In one embodiment, the workflow engine 146 does not control which data may be entered into the base table. In this case, the workflow engine 146 uses the primary key to independently direct and monitor the recorded state information of the base table. This state information is stored separately within the data store of the workflow engine 146. By separating workflow data from base table data, application 206 and database 145₁Operates independently and transparently to the workflow. However, the full functionality of the workflow is provided by the workflow engine 146.

The workflow engine 146 is active on records of the base table that are currently in any state in the flow (408, 410, and 412). The start state 406 and end state 414 are transitional states, and base table records may not "rest" in that state. When the base table record reaches the end state 414, the record is removed from the workflow queue and the workflow engine 146 stops tracking the record. Upon reaching the end state, the order is completed (or cancelled), requiring no further work for the order. The base table continues to have data about the completed order. Base table data is maintained under the control of application 206. In another embodiment, the completed record may also be restored into the workflow by "restore" a request to the workflow engine 146 using the primary key of the base table and the current state in which the record should be placed.

When the data of the base table records is updated by application 206 or query tool 207 or other database tool 209, changes to the recorded data other than the primary key may not affect the workflow instance. In one embodiment, when a primary key is used in the workflow engine to track the current state, the workflow engine 206 may not have the ability to update the primary key if the record is active in the workflow (e.g., if the current state of the record is 408 or 410 or 412). In another embodiment, the workflow engine 146 automatically adjusts the workflow instance key to match the changed database primary key, thereby allowing updates to the primary key. Regardless of the method used, the records can be updated without restriction, completely independent of the application 206 with limited intervention by the workflow engine 146.

When a base table record is deleted by application 206 or query tool 207 or other database tool 209, if it remains active in the workflow (e.g., if the current state of the record is 408 or 410 or 412), the workflow engine 146 checks the primary key of the record and also deletes it from the workflow queue.

Base table insertion starts workflow instances and transactions. However, there may be many subsequent workflow transactions without changing the base table records. Workflow transactions occur when there is a change from one state to another.

The above description is summarized in fig. 5. Turning now to FIG. 5, a block diagram of two tables 502, 504 showing the relationship between a database and a workflow transaction is shown. Table 502 shows the effect of database transactions on workflow transactions. Table 504 shows the effect of workflow transactions on database transactions. As shown in table 502, a database transaction on base table 502 initiates a workflow transaction. For example, the database transaction is an insert transaction, and the insert transaction executes on the workflow transaction when the base table conditions are satisfied. If the database transaction is an update transaction to the primary key of the base table, the database transaction will be forced to fail. However, if the update transaction is an update transaction to a non-primary key, there is no effect on the workflow transaction. If the database transaction is a delete transaction, the primary key of the corresponding record is also deleted from the workflow.

However, as shown in table 504, workflow transactions (e.g., insert, update, or delete transactions) do not create any database transactions on the base table. This facilitates the introduction of a minimally invasive workflow engine 146 within an existing or new application without changing the architecture of the database-based application development.

In another embodiment, the integrated database-workflow transaction may be implemented as a database-deferred workflow transaction. From the perspective of a database transaction, the database engine typically sets a row-level lock or sets a table-level lock when a row is inserted into a table. The lock implementation differs between database vendors. The triggers (created by the workflow engine 146) can execute very quickly to maintain reasonable capabilities. The trigger may be fast enough to allow hundreds or even thousands of orders to be entered in parallel. Many embodiments of the present invention allow integration with internal and external systems 148. Such integration may slow or not explicitly wait for a response from other systems. In addition, the flow from one state to another can be set such that several states flow automatically in one cycle, and many workflow sub-flows can be created automatically. Such long flows can lock down the system, which can slow the overall system. Many database implementations have limitations on nesting level triggers and can prevent long-term nested automatic flow of several steps. These problems can be solved in general by a good workflow design. Referring to tables 502 and 504, database-workflow integration transactions may be related in inserting and deleting database transactions. Most database systems provide row-level locks for these transactions, and it is possible that other users (e.g., other order transactions) may be locked or slowed down. However, there is a possibility that the limit for nested database transactions expires and that transactions involving external systems are waited indefinitely, etc. Such problems may be addressed using database-deferred workflow transactions.

To implement the database-deferred workflow mechanism, the workflow engine 146 may use a service agent or any Service Oriented Architecture (SOA) (not shown). Service broker or SOA implementations are available using many modern databases known in the art. This provides the ability to release tasks and independently complete tasks in an unlocked manner. When the workflow engine 146 receives control from a database transaction, the workflow engine 146 may selectively choose to authorize some or all workflow transactions to the service agent. After authorizing the service agent, the workflow engine 146 may signal to the database engine that the workflow transaction is pending or complete, which then allows the database transaction to be completed, thereby unlocking all database locks. However, the workflow engine 146 marks the workflow transaction as pending and prevents the base table record from being moved to other states. When the service agent successfully completes the work and notifies the workflow engine 146, the workflow engine 146 unlocks the record for further workflow transactions. If the service agent does not complete the job (e.g., does not reach the external system 148), the service agent may wait and retry. Under some conditions, previously completed database transactions (associated with the faulting database-workflow transaction) are programmably re-run to a level where the initial database transaction did not occur.

Turning now to FIG. 6, a flow diagram for enabling a database of workflows and creating a workflow flow is shown, according to an embodiment of the invention. These operations begin at step 602 when the database is selected for use under a workflow. At step 604, the database is checked to see if it has been enabled for workflow. If the database is already enabled, then the base table stored in the database is selected for the flow at step 608. This creates a new flow on the base table (e.g., start 406 state, as shown in FIG. 4). The flow is then modified at step 610 to have a number of states, transitions, end states, conditions, events, security, etc. If it is determined at step 604 that the database is not enabled for workflow, then at step 606 the workflow capability is enabled by installing the workflow engine 146.

Turning now to FIG. 7, a flow diagram of a transaction for database-workflow integration is shown, according to an embodiment of the invention. Fig. 7 is a flow chart showing in detail the transactions shown in table 502 of fig. 5. The flow diagram illustrates possible database-workflow integrated transactions with database transactions initiated on a base table. The flow diagram begins with a database transaction as at step 702, which is examined by the workflow 146 for inserting, updating, and/or deleting database transactions. At step 704, after determining that the database transaction is an insert record transaction, a determination is made as to whether the database transaction qualifies for creating a workflow instance. If it does, then the child-old instance is created at step 708 and the insert record database transaction is signaled to be processed by the workflow engine 146 at step 710. If it is not eligible, a workflow instance is not created at step 706 and a database insertion transaction is signaled for processing by the workflow engine 146 at step 710.

At step 712, after determining that the database transaction is an update record transaction, the database transaction is checked to determine if the update relates to the primary key of the record. If the primary key is updated, it is further checked to determine if the record has a workflow instance at step 714. If a workflow instance exists at the primary key, the workflow engine 146 signals the database engine to invalidate the transaction at step 716. When the workflow engine 146 tracks a workflow instance with a primary key, the primary key cannot be updated. In another embodiment, the workflow engine 146 automatically adjusts the workflow instance to match the changed database primary key (not shown in the flow chart). If the primary key field is not updated, or if the record is not in the workflow, the workflow engine 146 signals the database to allow and complete the database transaction at step 718.

At step 720, after determining that the database transaction is a delete record transaction, the database transaction is checked to determine if a workflow instance exists for the primary key. If it does, the workflow engine 146 deletes the workflow instance at step 722, then signals the database engine to complete the delete database transaction at step 724. If a workflow transaction does not exist, the workflow engine 146 signals the database engine to complete the delete database transaction at step 724.

Turning now to FIG. 8, a flow diagram for workflow transactions is shown, according to an embodiment of the invention. Fig. 8 is a flowchart showing in detail the transaction shown in table 504 of fig. 5. The flow diagram illustrates possible workflow transactions that are not initiated by a database transaction on the base table. At step 802, a workflow instance 804 can be created using existing records in a base table that are not currently in the workflow. This may be possible when a work record (e.g., order) is restored to redo the workflow. As an example, customer orders that were not executed correctly may be restored to the workflow for re-execution. At step 806, during the insert transaction, the workflow engine 146 flows to a recovery state as defined by the user.

At step 808, during the update transaction, the workflow instance is updated. When a workflow instance is updated, one state moves to another state when a user or machine performs a transition. At step 810, the workflow engine 146 checks the transition and determines if the next state is an end state. If the next state is determined to be the end state, the workflow instance is deleted at step 812. Deletion of the workflow instance does not affect the database base table records. The data is maintained in the base table. In the absence of a workflow instance for this record, it signals that there is a job pending. If the next state is not the end state, then at step 814, the current state of the workflow instance is updated by the next state.

At step 816, during the delete transaction, the workflow instance is deleted. When a workflow instance is deleted, records from the base table are removed.

Turning now to FIG. 9, a flow diagram for events in a workflow transaction is shown, according to an embodiment of the invention. In the workflow engine 146, a number of workflow events may be executed as the order flows from the state "in-process order" 408 to the state "pay order" 410 through the use of the transition "pay" 418. The conversion "pay" 418 may be initiated by a user or by the system. In the example events 922, 924, 926, these events represent programming code written in any programming language to execute code on any internal or external system 148. In this flow, a "leaving" type event 922 may exist and be executed upon leaving state 408. An "executing" type event 924 may exist and be executed when the transition 418 is executed. A "positive input" type event 926 may exist and be executed upon entry of the state 410. By way of example, the event 926 communicates 928 in a synchronized manner to the mail server 940 to send a payment notification to the recipient of the order. When a successful transition is performed, the workflow instance leaves one state and enters another state; so all three events in this example can be executed in the order 922, 924, and 926. There may be multiple types of events that may be established while the workflow is in motion. Many event types provide larger granularity and environment.

Turning now to FIG. 10, a flow diagram of using a service agent in the context of an event in a workflow transaction is shown, according to an embodiment of the invention. The flow is the same as in fig. 9, except that the service broker 1030 acts as a broker between the workflow engine 146 and the mail server 940. Event 1026 differs from 926 in that it communicates 1028 to service agent 1030 located in database 145 using a delegation message to send the mail without waiting whether the message is actually received by mail server 940. The service agent 1030 communicates to the mail server 940, obtains a response from the mail server 940 and communicates 1030 back to the workflow engine 146. The method has the advantages that: if the mail server temporarily stops running, the database transaction component of the database-workflow transaction may not have to wait. The workflow transaction may have to wait until the service agent completes the work. This eliminates any slowing down or locking of the system by using workflow events.

It should also be noted that the embodiments described herein may have a wide range of applications, other than those specifically described herein, that would be apparent to one of ordinary skill in the art having the benefit of this disclosure.

The particular embodiments disclosed above are illustrative only, as the invention may be modified and practiced in different but equivalent manners apparent to those skilled in the art having the benefit of the teachings herein. Furthermore, no limitations are intended to the details of construction or design herein shown, other than as described in the claims below. It is therefore evident that the particular embodiments disclosed above may be altered or modified and all such variations are considered within the scope and spirit of the invention as claimed.

Accordingly, the scope of protection claimed herein is set forth in the claims appended hereto.

Claims (17)

1. A computer-implemented method, comprising:

assigning a data structure stored in a database to one or more workflow processes, the database including a workflow engine; and

as part of an integrated database workflow transaction that is populating a data structure with new records, creating, by the workflow engine, an instance of at least one of the one or more workflow processes, wherein the workflow engine controls database transactions through one or more table-level triggers as part of populating a data structure with new records, performs workflow steps and signals the database to complete or invalidate the database transactions upon completion of the workflow transactions, and/or as part of an integrated database workflow deletion record transaction, removing an instance of at least one of the one or more workflow processes, wherein the workflow engine controls database transactions via the table-level trigger as part of deleting recorded transactions, executes workflow steps, and signals completion of database transactions upon completion of the workflow transactions.

2. The computer-implemented method of claim 1, further comprising:

an application is assigned to the one or more workflow processes, wherein the application performs operations on the data structure.

3. The computer-implemented method of one of the preceding claims, wherein the data structure is a base table comprising a plurality of rows, and wherein each row represents an instance of one or more workflow flows, and the database transactions on the base table initiate corresponding workflow transactions due to insert transactions, update transactions, or delete transactions, but the workflow transactions do not create any database transactions on the base table due to changes in workflow status.

4. The computer-implemented method of claim 1, wherein the one or more workflow processes are controlled by changes to data in a data structure.

5. The computer-implemented method of claim 3, wherein the workflow transaction is completed by activating the one or more triggers when a record is added, updated, or deleted in the data structure.

6. A computer readable storage medium comprising a program which, when executed on a processor, performs operations comprising:

assigning a data structure stored in a database to one or more workflow processes, the database including a workflow engine; and

as part of an integrated database workflow transaction that is populating a data structure with new records, creating, by the workflow engine, an instance of at least one of the one or more workflow processes, the workflow engine controls database transactions through table level triggers, executes workflow steps and signals the database to complete or invalidate the database transactions upon completion of the workflow transactions, and/or as part of an integrated database workflow deletion record transaction, removing instances of the one or more workflow processes, wherein the workflow engine controls the database transaction through the table-level trigger as part of a delete record transaction, executes workflow steps, and signals the database to complete the database transaction upon completion of the workflow transaction.

7. The computer-readable storage medium of claim 6, further comprising:

an application is assigned to the one or more workflow processes, wherein the application performs operations on the data structure.

8. The computer-readable storage medium of one of claims 6 and 7, wherein the data structure is a base table comprising a plurality of rows, and wherein each row represents an instance of one or more of the one or more workflow flows, and database transactions on the base table initiate corresponding workflow transactions due to insert transactions, update transactions, or delete transactions, but workflow transactions do not create any database transactions on the base table due to changes in workflow status.

9. The computer-readable storage medium of claim 8, wherein the workflow transaction is completed by activating the one or more triggers when a record is added, updated, or deleted in the data structure.

10. A system, comprising:

a processor; and

a memory comprising a database, wherein the database comprises a workflow engine layer, and wherein the memory further comprises a program that, when executed by the processor, is configured to perform operations comprising:

assigning a data structure stored in a database to one or more workflow processes; and

creating an instance of the one or more workflow processes as part of an integrated database workflow transaction that is populating a data structure with new records, wherein the workflow engine controls database transactions through a table-level trigger as part of populating a data structure with new records, performs workflow steps and signals the database to complete or invalidate the database transactions upon completion of the workflow transactions, and/or removes an instance of the one or more workflow processes as part of an integrated database workflow delete record transaction, the workflow engine controls database transactions through the table-level trigger, performs workflow steps and signals the database to complete database transactions upon completion of the workflow transactions.

11. The system of claim 10, further comprising:

an application is assigned to one or more workflow processes, wherein the application performs operations on the data structure.

12. The system of one of claims 10 and 11, wherein the data structure is a base table comprising a plurality of rows, and wherein each row represents an instance of one or more of the one or more workflow flows, and database transactions on the base table initiate corresponding workflow transactions due to insert transactions, update transactions, or delete transactions, but workflow transactions do not create any database transactions on the base table due to changes in workflow status.

13. The system of claim 12, wherein a workflow transaction is completed by activating the one or more triggers when a record is added, updated, or deleted in the data structure.

14. The system of claim 10, wherein at least one database front-end application tool operates without knowledge of the presence of a workflow engine.

15. The system of claim 10, wherein at least one of the application and the database front-end application tool operates with a workflow engine Application Program Interface (API) with knowledge of the workflow engine.

16. The system of claim 10, wherein the workflow engine creates one or more event types, wherein each of the one or more event types represents a workflow-motion type, wherein each workflow-motion type is associated with one or more workflow elements, wherein each of the one or more workflow elements executes program code associated with at least one or more databases, thereby providing integrated workflows and database transactions.

17. The system of claim 16, wherein the memory further comprises at least one of a Service Oriented Architecture (SOA) or a service agent that enables integrated database-deferred workflow transactions.