WO2014035283A1

WO2014035283A1 - Method for workflow processing by a state machine

Info

Publication number: WO2014035283A1
Application number: PCT/RU2012/000719
Authority: WO
Inventors: Maxim Viktrovich TSYPLIAEV; Peter Evgenievich VOLYNSKY
Original assignee: Obschestvo S Ogranichennoy Otvetstvennostyu "Colloware"
Priority date: 2012-08-27
Filing date: 2012-08-30
Publication date: 2014-03-06
Also published as: EA201500176A1; RU2630383C2; RU2012136375A

Abstract

A computer-implemented method for workflow processing by a state machine, the method comprising: creating a workflow for a process; launching a state machine that reflects workflow states; determining the workflow states that require tasks; creating the tasks for the workflow states that require the tasks; specifying assignees for each task; assigning the tasks to the assignees; and executing the workflow, wherein: the tasks are auto-generated by the state machine upon transition from one state to another; a transition to a next state occurs only after a corresponding task is closed by the assignee; and a transition to a next state occurs when an assignee selects a next state.

Description

METHOD FOR WORKFLOW PROCESSI NG BY A STATE MACHINE

The present invention is related to state machine technology and, more particularly, to automated task generation by the state machine.

Operation of enterprises and individuals within the enterprises or organizations is based on execution of intermediate tasks. Large enterprise can have hundreds or even thousands of interconnected tasks that need to be executed. A large number of tasks can be connected to a particular project.

Thus, monitoring the execution of each task within a project can be difficult, because of a large number of people involved in the project. These people have limited responsibilities and execute only certain tasks. More often than not, they do not understand the execution of the entire project. For example, equipment purchasing requires approval of a manager, of a CFO or an accountant, ordering party, etc. Each of these individ uals needs a special task created specifically for him. This slows down the process and complicates and delays equipment order.

Typically, the tasks are assigned in a priority order and executed sequentially in this order. A state machine allows an execution of the tasks out of order when needed. In other words, task 1, 3 and then 7 can be executed in this order. Often, the execution of tasks out of sequence is needed when the tasks are applied to another project. The out-of-order task execution is provided by the state machine that allows task executions in any pre-set sequence.

While tasks can be interconnected, in some situations the project cannot be completed by execution of interdependent tasks. For example, a computer repair process includes a number of independent (or loosely dependent) tasks. Monitoring of the computer repair process includes a number of states such as, for example, "working", "discarded", "under repair", etc. Repair monitoring cannot be implemented by the execution of dependent tasks, because an open or closed task does not indicate a state of a computer repair.

Accordingly, there is a need in the art for a system and method for monitoring task execution states and automated task generation for particular project states.

A method for workflow processing by a state machine and automated task generation by the state machine, the method comprising: creating a workflow for a process; launching a state machine that reflects workflow states; determining the workflow states that require tasks; creating the tasks for the workflow states that require the tasks; specifying assignees for each task; assigning the tasks to the assignees; and executing the workflow, wherein: the tasks are auto-generated by the state machine upon transition from one state to another; a transition to a next state occurs only after a corresponding task is closed by the assignee; a nd a transition to a next state occurs when an assignee selects a next state. The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention.

In the drawings:

FIG. 1 illustrates an example of a conventional state transition diagram;

FIG. 2 illustrates an exemplary workflow example using state machine tasks;

FIG. 3 illustrates a flow chart of a method for auto-generation of tasks by the state machine, in accordance with the exemplary embodiment;

FIG. 4 illustrates exemplary state parameters;

FIG. 5 illustrates an exemplary state machine employing automated task generation, in accordance with the exemplary embodiment;

FIG. 6 illustrates another workflow example that employs a state machine and auto-generated tasks;

FIG. 7 shows an algorithm illustrating a transition from one state to a different state;

FIG. 8 illustrates a schematic of an exemplary computer system that can be used - for implementation of the invention.

A simple example of a state machine is a revolving gate that opens upon reading a user pass (i.e., a magnetic card). A state transition of this state machine is illustrated in FIG. 1. The state transition diagram reads as follows:

If the revolving gate is in a "locked" state and event "magnetic card" occurs, the revolving gate transitions into an "unlocked" state and invokes unlock action;

If the revolving gate is in an "unlocked" state and an event "Pass" takes place, the revolving gate transitions into a "locked" state and invokes lock action;

If the revolving gate is in a "locked" state and the event "Pass" takes place, the revolving gate does not change its "locked" state, but invokes alarm action;

If the revolving gate is in an "unlocked" state and "magnetic card" event occurs, the revolving gate does not change its "unlocked" state and invokes "Pass on, please" action.

However, the actions (or tasks) of this state machine are pre-determined. Large object may have hundreds or thousands of states and associated tasks within its complex workflow. This requires a state machine and an automated task generation.

In project management, a task is an activity that needs to be accomplished (or executed) within a defined period of time. A task can be assigned to a responsible person. The task has a start and end date (time).

A task is a unit that is used to track user activities in terms of completing certain objectives defined by the task description. An example of a task is a task within MS Outlook. Other examples of tasks can be the tasks such as fixing a bug in a computer code, report generation, replacing a car part, cargo transport, writing an executable computer module, etc.

The tasks can be created for different object states. For example, an object "computer" can have states such as "working," "out of order," "under repair," "missing parts," "repairable," "to discard," "discarded," etc. A state machine has several states. Upon one state being completed, the object transitions into another state.

For example, a computer code bug needs to be fixed. The process detects a bug and creates an object/item "bug." The object is processed according to a workflow that includes stages of object processing represented by states. An item within the workflow is a configurable unit that can be transitioned from state to state and used for tracking certain business process. Item transition through the workflow can generate tasks at required steps (states) and assign them to certain users.

The exemplary workflow for fixing bugs operates as follows. If a bug is detected, an order is given to a bug fixer to fix the bug. After that, the bug is considered fixed. The object "bug" can have several states such as "bug detected," "bug is under correction," "bug is corrected." When the bug is detected, the bug handling process moves to a "bug detected" step. The process orders the bug fixer (software developer) to fix the detected bug. A task for the bug fixer "fix bug" is generated, and the bug object is transitioned into "bug is under correction" state.

After the bug fixer (software developer) corrects the bug, the bug fixer closes his task, and the state of the bug object transitions into the state "bug is corrected." According to the exemplary embodiment, a state machine is used for workflow processing and handling object states. The tasks are generated automatically and used in the state machine. Those skilled in the art will appreciate that use of state machine with automated task generation is novel and provides for more efficient automated workflow processing.

A state machine, also called a finite-state machine (FSM) or finite-state automaton, is a mathematical model used to design computer programs and digital logic circuits. The state machine is as an abstract machine that can be in one of a finite number of states. The state machine can be in only one state at a time. The state of the machine at any given time is called the current state. The state machine can transition from one state to another when a triggering event or a condition occurs. A state machine is defined by a list of possible transition states (from each current state) and the triggering condition (event) for each state transition.

The state machines can model a large number of problems, among which are electronic design automation, communication protocol design, parsing and other engineering applications. The state machines (or hierarchies of the state machines) are used to describe neurological systems in biology research. The state machines can be used to describe the grammars of natural languages in an artificial intelligence research and in linguistics studies.

A state describes a behavioral node of a system. The node waits for a trigger event in order to execute a transition into another state. Typically, a state is introduced when the system does not react to the same trigger even in the same manner.

In some FSM representations, it is also possible to associate actions with a state:

An entry action is performed when entering the state; An exit action is performed when exiting the state.

A state transition is a set of actions to be executed when a condition is fulfilled or when an event is received. A state diagram is a type of a diagram used in computer science and related fields to describe the behavior of the systems. State diagrams require that the system is composed of a finite number of states. Note that in some cases this is a reasonable abstraction. Many forms of state diagrams exist that differ slightly and have different semantics.

State diagrams are used to give an abstract description of a behavior of a system. This behavior is analyzed and represented in series of events that can occur in one or more possible states. According to the exemplary embodiment, each diagram represents objects of a single class and tracks the different states of its objects through the system. State diagrams can be used to graphically represent finite state machines.

Another possible representation of the FSM is a state transition table. A classic form of a state diagram for the FSM or finite automaton (FA) is a directed graph. For a deterministic finite automaton (DFA), nondeterministic finite automaton (NFA), generalized nondeterministic finite automaton (GNFA), or Moore machine, the input is denoted on each edge.

For a Mealy machine, input and output are signified on each edge, separated with a slash "/": "1/0" denotes the state change upon encountering the symbol "1" causing the symbol "0" to be an output. For a Moore machine, the state's output is usually written inside the state's circle separated from the state's designator with a slash "/"· There are also variants that combine these two notations.

For example, if a state has a number of outputs (e.g., "a= motor counter-clockwise=l, b= caution light inactive=0") the diagram should reflect this: e.g. "q5/l,0" designates state q5 with outputs a=l, b=0. The designator is written inside the state's circle.

FIG. 2 illustrates an example of workflow processing by a state machine with an automated task generation. FIG. 2 depicts an example of task generation by a state machine for workflow of hiring a new employee by a company. Note that the workflow is represented by a process described by different states. Any state that can be connected to existing workflow states can be added to the workflow.

In FIG. 2, an object (item) 200 is hiring a new employee. A workflow for employee hiring 202 by a company is applied to the item 200. Note that the object 200 can have different parameters (i.e., for example name, age, gender, education, experience, marital status, etc.). The object parameters can be included in the workflow tasks, as discussed further below.

The workflow 202 begins at state 205, where a request for new hiring is generated. The parameters of the object 200 are set at state 205. Then, the process moves to state 210, where the process waits for approval (for example, from an HR manager or director).A task 215 is generated at state 210 for approval of the new hiring. This task can be assigned to one or several employees depending on the workflow 202. For example, if only the director can approve the hiring, the task is assigned to the director. If the director and HR manager can approve the hiring, then both of them are assigned the task 215. Also note a task can have one or more subtasks. For example, a task 215 can have two subtasks: Subtask 1 can be assigned to an accountant, and the accountant must check the availability of necessary funds to hire an employee. Subtask 2 can be assigned to a manager, and the manager must evaluate the productivity of current employees. So a task 215 can be closed after the Subtask 1 and the Subtask 2 will be closed. If the Subtask 1 or Subtask 2 is not closed, then the task 215 cannot be closed. So Subtask 1 and Subtask 2 are parallel subtasks. The workflow 202 remains in the same state until the task 215 is completed.

Note that the state 205 can be excluded and the hiring process can begin at state 210 that has already generated the task 215. The state 205 can be implemented, for example, as a menu or a button of a hiring interface. The menu or the button opens a window for entering the parameters of the item. This task can include opening a menu or a window described above, and after the entering the parameters for new hiring (such as Department, Target date, Job type, Name Item, Addition information), the task can be closed. If the director decides that new hiring is not needed at the moment, the director can close the task 215 and the workflow moves to state 220 "Cancelled." Alternatively, the director can choose to move to the state 220 and the task 215 closes automatically. Thus, the workflow 220 stops.

Note that transitions from state to state are implemented by closing the corresponding tasks. The task can be closed with a transition to one of available states chosen by a person who closed the task. If only one available state exists, the process moves to this state automatically after the task is closed. Additionally, when closing the task and moving to the next state, the person can add a comment.

Note that, if at state 220 hiring is not approved, the workflow also can return to state 210 (not shown on the FIG. 2), where the process remain in a suspended state until the director approves hiring of a new employee. If the director approves hiring by closing the task 215, the workflow moves to state "approved" 225. The director can close the task and choose to move to the state 225.

Note that the tasks may not be generated during the transition to the next state (i.e. for the next state). For example, transition from the state 210 into the state 220 or to state 225 does not require the task generation. However, the transition into the state 230 generates task 235, requiring for potential candidates to be approved. For example, this task can be assigned to a project manager.

If the project manager does not like a candidate, the project manager can close the task 235 and select transition into state 255 "rejected." The hiring workflow is stopped at this point. If the workflow is at as state 230 and the project manager likes the candidate, the manager can close the task 235 and move the workflow to state 232, where an interview with the candidate is conducted. The transition to the state 232 automatically generates a task 240 for interviewing the candidate. The task 240 can be assigned to the project manager or his assistant.

If the manager is not satisfied with the interview, he can close the task 240 and move the workflow to the state 255 "rejected." Then, the workflow 220 stops. If the manager is satisfied with the interview, he can close the task 240 and move to the next state 245 (i.e., hiring negotiations).

The transition to the state 245 automatically generates a task 250 for negotiations with the candidates. This task can be assigned, for example, to an HR manager or a CFO. If the negotiations were fruitless, the manager closes the task 250 and choose to move to the state 255. However, if agreement was reached, the manager closes the task 250 and choose to move to a state 260 "position filled." Subsequently, the workflow 202 is terminated.

FIG. 3 illustrates a flow chart of a method for auto-generation of tasks by the state machine, in accordance with the exemplary embodiment. A workflow begins in step 310. The workflow begins from an initial state defining an object. Then, the workflow moves to the next state in step 330. Subsequently, the process checks whether the workflow has reached a final state in step 340. If the state is final, the workflow stops in step 350. The initial and the final states are explicitly set prior to workflow configuration.

If, in step 340, the state is not final, the process moves to step 360, where it checks whether the task generation is required. If the task generation is required, the task is automatically generated in step 370. After the task is generated in step 370, the process moves to step 375. If the task generation is not required in step 360, the process moves to step 380.

If a transition to the next state is selected in step 380, the process moves to an optional step 320. If the task is closed by its assignee in step 375 and a transition to the next state is selected, the process moves to an optional step 320, where the process checks conditions of the task closing or state transition. A requirement for task generation is incorporated into the workflow for each state that needs a task to be generated.

Note that transition to the next state can be implemented by one of the methods: a task is closed by its assignee; a task is closed automatically by selecting a next state option; and a task is closed and transition to the next state is selected.

FIG. 4 illustrates exemplary state parameters. When a workflow is created, the state parameters are set. The state parameters can be a state name 405, a state type 410, and a task 420 (if the task needs to be generated for transition into another state). The parameters can include additional task and item fields.

The state name 405 identifies the state. The state type defines state hierarchy within the workflow. The state type can be initial 430, intermediate 435, and final 440. An intermediate state has transitions from the previous state and to the next state (for example state 210 in FIG. 2). A task state parameter provides for automatic generation of tasks during transitions from one state into another. The task fields can be "Do not assign" 450 (i.e., the task is not generated on transition from one state into another); task "assignee" 460, and task "assignment rule" 465. Note that the assignment rule can be implemented in any programming language.

According to the exemplary embodiment, special names can be used for transition rules for a business process. The name can be:

$property, that identifies an object;

$$now, indicating current data and time;

$$currentUser, identifying a current user;

For example, for the state 205 (see FIG. 2) the state name is "new hiring"; the state type is "Initial state"; the task "assignment" is director, the task is "Need approval of new hiring."

Also the assignment rule can be implemented in a rules of inference (inference rules, transformation rules). An inference rule is the act of drawing a conclusion based on the form of premises interpreted as a function which takes premises, analyses their syntax, and returns a conclusion (or conclusions). For example, the rule of inference modus ponens takes two premises, one in the form of "If p then q" and another in the form of "p" and returns the conclusion "q". The rule is valid with respect to the semantics of classical logic (as well as the semantics of many other non-classical logics), in the sense that if the premises are true (under an interpretation) then so is the conclusion.

Typically, a rule of inference preserves truth, a semantic property. In many-valued logic, it preserves a general designation. But a rule of inference's action is purely syntactic, and does not need to preserve any semantic property: any function from sets of formulae to formulae counts as a rule of inference. Usually only rules that are recursive are important; i.e. rules such that there is an effective procedure for determining whether any given formula is the conclusion of a given set of formulae according to the rule. An example of a rule that is not effective in this sense is the infinitary ω-rule.

Popular rules of inference include modus ponens, modus toilers from propositional logic and contraposition. First-order predicate logic uses rules of inference to deal with logical quantifiers.

FIG. 5 illustrates an exemplary state machine employing automated task generation, in accordance with the exemplary embodiment. The item 200 has its own template 710. The template 710 can contain template name and other fields depicted. For example, in a bug fixing process, the bugs have properties contained in the template. A state can be one of the template fields.

According to the exemplary embodiment, the template 710 has the workflow 202, a form 730 and fields 740. The form 730 is used for displaying (within GUI) data collected from the fields 740, the item 200 and from the task template. The fields 740 are displayed in order. The items 200 and tasks can be stored in item groups. Each item group can have its own template with special properties.

Each auto-generated task has a title that is derived from an item name and a state name. The state contains task assignment data defined by the workflow. Additionally, the task can contain object description and comments. Note that some task fields are auto-generated and some fields can be modified by the task assignee. According to the exemplary embodiment, the task can have parent property that contains a link to a parent object (i.e., item) that owns the task. Thus, the tasks with the same links to the parent object belong to the same item. A user can view all tasks for the parent object by using the link.

Each task can have at least one sub-task. The sub-tasks are created manually or automatically. In order to close the task, all the sub-tasks have to be closed. A sub-task can be created, if the entire task cannot be executed for some reason. For example, a bug cannot be fixed unless it is reviewed by a lead software developer. In this case, a sub-task is created for the lead software developer. Thus, the task cannot be closed until the lead software developer closes his sub-task.

According to the exemplary embodiment, workflow-related data, template data, item fields, tasks and other service data can be stored in a database in a form of triples (or in another format). The triples can be stored in a triplestore. The triplestore is a special database for the storage and retrieval of triples. The triple is a data entity composed of subject-predicate-object, such as, for example, "John is 35" or "John knows Helen."

Much like in a relational database, the information is stored a triplestore and can be retrieved using a query language. However, unlike a relational database, the triplestore is optimized for the storage and retrieval of triples. In addition to queries, the triples can be imported/exported using Resource Description Framework (RDF) and other formats.

The triplestores can store billions of triples. The triplestores can built as proprietary database engines or they can be built on top of existing commercial relational database engines. The RDF data model is similar to classic conceptual modeling approaches such as entity-relationship or class diagrams. The RDF is based upon making statements about resources (in particular Web resources) in the form of subject-predicate-object expressions.

These expressions are known as triples in RDF terminology. The subject denotes the resource, and the predicate denotes traits or aspects of the resource and expresses a relationship between the subject and the object. For example, one way to represent the notion "The sky has the color blue" in RDF is as the triple: a subject denotes "the sky," a predicate denotes "has the color", and an object denotes "blue."

Therefore, RDF swaps object for subject that would be used in the classical notation of an Entity- attribute-value model within object-orientated design. In this example, the object is "sky", the attribute is "color" and the value is "blue." RDF is an abstract model with several^' serialization formats (i.e., file formats), and so particular way in which a resource or triple is encoded varies from format to format.

FIG. 6 illustrates another workflow example that employs a state machine and auto-generated tasks. This example depicts a workflow reflecting purchasing a chair for a company office. A first state 810 is creating a purchase request. Then, the process transitions into state 820 and a task is generated automatically for a manager, who needs to verify a purchase order. If the manager decides that the chair is needed and verifies the purchase order, the manager can close the task and select a state 830 and a task for an accountant is automatically generated.

If, in state 820, the manager decides that purchase is not necessary, he can select next state 840, and the process moves into state 840 where the workflow ends. If the accountant, in state 830, decides that the purchase is not in the budget, he can select state 840, and the process moves into state 840 where the workflow ends. If the accountant approves the purchase of the chair, the accountant closes his task and select state 850, and the process moves to state 850. At this point, another task is generated for an employee of an acquisitions department. After the chair is paid for, an employee of an acquisitions department closes his task and selects state 860, so the process moves to state 860 where the workflow ends.

FIG. 7 illustrates a transition from one state to a different state, using the example of FIG. 6. Here, purchasing a chair is an Item. Consider transition from state 820 (Statel) to state 830 (State2). State 1 is a current state of the Item (and the Workflow). State2 is a future state of the Item, to which the Item needs to transition. As noted above, a user who is responsible for the particular state can select that state (for example, if a task needs to be closed in order to transition, then the user to whom the task is assigned can close the task and select the next state). .

Additional restrictions are placed on the Item upon transition to the next state (state2) ("state2_restrictions"), and the Item must satisfy those restrictions. "state2_triggers" are the changes in the fields, which need to occur upon transition to state2. "state2_task_triggers" are the changes in the subtask, formed upon transition to state2. "state2_need_create_task" defines whether a task needs to be generated in the current state. "state2_task_assignee" is a user expression for calculating the assignee of the task being generated, "transitionl" is the transition from statel to state2. "transitionl_restrictions" are the restrictions that the Item has to satisfy when transitioning according to "transitionl". "transitionl_triggers" are the changes in the fields that occur during the transition based on "transitionl". These variables, constants and expressions can be stored in the triplestore, which is read and processed during a transition from one state to another.

Restrictions are user expressions, written in expression language (see above), which can be processed, and which take as an input the ID of the Item, and as an output provide a notification of whether the Item can transition to the next state. The ID is an identifier (e.g., a string or alphanumeric), that identifies the Item.

The triggers are also user expressions written in expression language, which are processed and take as an input the ID of the Item, and provide, as an output, some field of the Item or task, and which value needs to be written in that field.

The user expression can use the properties of the Item or task (and Items related to that Item or task, as described above), and special variables, also described above.

As noted above, the user can select a transition from one state to the next one (e .g, from state 1 (820 in FIG. 6) to state2 (830 in FIG. 6). The transition process itself begins in step 902, where the state of the Item changes to State2. Then, in step 904, transitionl_restrictions are checked, i.e., the fields of the Item are checked. For example, there might be a requirement to fill out the "car type" when the Item "car purchase", and the state is transitioning from "select car" to "go to autodealer". If the restrictions are not satisfied in step 904, then, in step 906, the user is informed of an error, and the transition to the next state (State2) does not occur (the Item remains in the previous state, Statel). If in step 904 "transitionl_restrictions" are satisfied, then the process, in step 908, launches the transitionl_triggers, i.e., refreshes the fields of the Item with information read from the triplestore.

In step 910, state2_restrictions are checked, i.e., the fields of the Item are checked. If, in step 910, state2_restrictions are not satisfied, the process moves to step 906. Otherwise, if in step 910, "state2_restrictions" are satisfied, then, in step 912, "state2_triggers" are launched to refresh the fields of the Item.

In step 914 the process checks if it is necessary to create a task for the next state (event "state2_need_create_task"). If in step 914 there is no need to create a task, then the process moves to step 922.

If in step 914 a task needs to be created, then the process moves to step 916, where the assignee for the new task is checked. The user can specify the assignee explicitly (e.g., by pressing a button to transition to the next state (transitionl), in which case the process moves to step 924, where the assigned is one specified by the user, whom he selected upon transition to the next state. Then, process moves to step 930.

If the user does not explicitly specify the assignee, then, in step y 918, the process checks if an assignee was specified for the transition to the next task when the workflow was created (.e., the assignee can be calculated based on the rules for state2_task_assignee, contained in the workflow). If in step 918 the assignee was specified when the workflow was created, then, in step 926, the assignee will be one that was selected during creation of the workflow, i.e., using the predetermined rule that defines who owns the task when transitioning from Statel to State2. Then the process moves to step 930.

If in step 918 there is no assignee rule in the workflow, then the assignee of the task is the Item's creator, see 920, the process moves to step 930. Then, a title for the new task is defined. If, in step 930 the user explicitly specified the title, then, similar to the situation with the assignee, when the "transition.." button is pressed, then the process, in step 934, the title of the task becomes that specified by the user, and the process moves to step 936.

If in step 930 the user did not explicitly specify the title, then the title of the task can be created based on a template, e.g., Item title + State in step 932, after which, in step 936, the task is created with parameters: {group = Item.group, parent=ltem, creator=system user/none, status=notStarted, assignee, title }, where group is the group to which the Item belongs.

Then, in step 938, triggers for the new task are executed, e.g., state2_subtask_assignee, for example, the task can be given importance "High", if the Item is in the group VIP, i.e., when it is possible to change the fields of the task.

Then, in step 922, where the task from the previous state is closed (if there is one), and then step 928, which means that the Item is now in the next state, i.e., State2, and the process ends.

With reference to FIG. 8, an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer 20 or a server, including a processing unit 21, a system memory 22, and a system bus 23 that couples various system components including the system memory to the processing unit 21.

The system bus 23 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. The system memory includes read-only memory (ROM) 24 and random access memory (RAM) 25. A basic input/output system 26 (BIOS), containing the basic routines that help transfer information between elements within the computer 20, such as during start-up, is stored in ROM 24.

The computer 20 may further include a hard disk drive 27 for reading from and writing to a hard disk, not shown, a magnetic disk drive 28 for reading from or writing to a removable magnetic disk 29, and an optical disk drive 30 for reading from or writing to a removable optical disk 31 such as a CD-ROM, DVD-ROM or other optical media. The hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive interface 33, and an optical drive interface 34, respectively. The drives and their associated computer-readable media provide non-volatile storage of computer readable instructions, data structures, program modules and other data for the computer 20.

Although the exemplary environment described herein employs a hard disk, a removable magnetic disk 29 and a removable optical disk 31, it should be appreciated by those skilled in the art that other types of computer readable media that can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories (RAMs), read-only memories (ROMs) and the like may also be used in the exemplary operating environment.

A number of program modules may be stored on the hard disk, magnetic disk 29, optical disk 31, ROM 24 or RAM 25, including an operating system 35. The computer 20 includes a file system 36 associated with or included within the operating system 35, one or more application programs 37, 37', other program modules 38 and program data 39. A user may enter commands and information into the computer 20 through input devices such as a keyboard 40 and pointing device 42. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner or the like. These and other input devices are often connected to the processing unit 21 through a serial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface, such as a video adapter 48. In addition to the monitor 47, personal computers typically include other peripheral output devices (not shown), such as speakers and printers.

The computer 20 may operate in a networked environment using logical connections to one or more remote computers 49. The remote computer (or computers) 49 may be another computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 20, although only a memory storage device 50 has been illustrated. The logical connections include a local area network (LAN) 51 and a wide area network (WAN) 52. Such networking environments are commonplace in offices, enterprise-wide computer networks, Intranets and the Internet.

When used in a LAN networking environment, the computer 20 is connected to the local network 51 through a network interface or adapter 53. When used in a WAN networking environment, the computer 20 typically includes a modem 54 or other means for establishing communications over the wide area network 52, such as the Internet.

The modem 54, which may be internal or external, is connected to the system bus 23 via the serial port interface 46. In a networked environment, program modules depicted relative to the computer 20, 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.

Claims

Claims:

1. A computer-implemented method for workflow processing by a state machine, the method comprising:

creating a workflow for a process;

launching a state machine that reflects workflow states;

determining the workflow states that require tasks;

creating the tasks for the workflow states that require the tasks;

specifying assignees for each task;

assigning the tasks to the assignees; and

executing the workflow, wherein:

the tasks are auto-generated by the state machine upon transition from one state to another;

a transition to a next state occurs only after a corresponding task is closed by the assignee; and

a transition to a next state occurs when an assignee selects a next state.

2. The method of claim 1, wherein an initial and a final state of the state machine are explicitly set prior to a workflow configuration.

3. The method of claim 1, wherein the task is closed automatically after the assignee selects a next state.

4. The method of claim 1, wherein the workflow execution ends upon arriving at a final state of the state machine.

5. The method of claim 1, wherein the state includes:

a state name;

a state type;

state restrictions;

state triggers;

state subtask triggers;

state subtask assignee;

state task assignee; and

a task.

6. The method of claim 5, wherein the state type is any of:

an initial state;

an intermediate state; and

a final state.

7. The method of claim 1, wherein the task includes assignment rules.

8. The method of claim 7, wherein the assignment rules are written in expression language.

9. The method of claim 7, wherein the assignment rules are inference rules.

10. The method of claim 1, wherein the task includes comments.

11. The method of claim 1, wherein the sate machine implements transition rules for transitions from each state to a next.

12. The method of claim 1, wherein the sate machine implements transition restrictions for transitions from each state to a next.

13. The method of claim 1, wherein the sate machine implements transition triggers for transitions from each state to a next.

14. The method of claim 1, wherein the task comprises at least one sub-task.

15. The method of claim 14, wherein the task can only be closed after all sub-tasks are completed.

16. The method of claim 1, wherein a requirement for the automated task generation is incorporated into the workflow for each state.

17. The method of claim 1, wherein the wo rkf low-related data is stored in a triplestore database in a form of triples.

18. A system for workflow processing by a state machine comprising:

a processor;

a memory connected to the processor; a computer program logic stored in the memory and executed on the processor for implementing the steps of claim 1.