Token based control flow for workflow

[0001] The present invention relates to workflow, and in particular to token based control flow for workflow.

[0002] Workflow systems are used for modeling business processes, business to business interaction and business coordination. There are now large numbers of commercially available workflow management systems (WFMS) and Business process integrators (BPI). A typical example of workflow is that of approving a paper in an academic setting. Approval of the paper represents work to be done. Sometimes approval by more than one professor is required. Both internal and external reviews might be required, and review by a legal department for inventions may also be required. The approvals are referred to as activities or tasks, and the control of the order of execution of the activities is performed is referred to as a control-flow perspective.

[0003] The control-flow perspective of workflow concentrates on how to execute the activities and when to execute what activity. It mainly deals with sequencing, paralleling, iterating and synchronizing the activity execution. Data perspective deals about how the data flows from one task to another and what data is passed from one task to another task. Typical data flowing includes business documents and local variables of the workflow (workflow relevant data). The operational perspective deals with the actions associated with individual tasks and operating on actions. An action can be a database call to retrieve some data or it can be call on a component method etc.

[0004] Control flow is an essential building block of workflow engines. The control flow perspective is important to the success of a workflow management system product. As discussed above the control flow is essentially routing of tasks. The routing can be Sequential routing, parallel routing, conditional routing and iterative routing. A sequential routing routes the tasks one after another in a sequential manner. Parallel routing in the workflow context executes more than one task simultaneously. Usually interdependent tasks will get executed sequentially and independent tasks will get executed parallel.

[0005] Sometimes a set of tasks needs to be executed iteratively, this type of executing of tasks is called iterative routing. Sometimes execution of a task depends on the result of a condition, this type of task execution is called conditional routing. Sometimes iterative routing can depend on one or more conditions. Based on a condition, a set of tasks might get executed iteratively.

[0006] Almost every workflow product addresses the above routing concepts. Typically they use constructs such as splits and join to achieve the routing concepts. However there can be variations in their usage.

[0007] Splits are used for selective execution of tasks or for parallelism in the task execution. Splits can be of two kinds. A split will have one input and multiple outputs. If a split is thought of as a node in a graph then an in-degree of split is one and an out-degree can be any number greater than one.

[0008] An unconditional split does not contain any condition associated with it. Workflow engines interpret this construct to achieve parallelism. Whenever workflow control reaches this split, workflow engine executes activities associated with the split simultaneously. Usually independent activities are executed simultaneously. To achieve selective (conditional) routing a WFMS uses a conditional split. This split is associated with a condition. The workflow engine evaluates the condition associated with the construct. Based on the evaluation of the condition it will make a decision regarding execution of a particular activity.

[0009] Joins are used to synchronize activities that are executing. Using the nodes in the graph analogy, the join in-degree is more than one and the out-degree is one. It has multiple inputs and only one output similar to multiplexer. Based on synchronization needs joins are classified into four categories, AND joins, OR joins, partial joins and discriminative joins. An AND join is used to synchronize all the incoming activities, while OR joins wait for only one incoming activity to occur. A partial join waits for a predetermined number of incoming activities to occur, and a discriminative join waits for a condition, such as completion of incoming activities to become true.

[0010] Some times a set of tasks needs to be executed iteratively, this type of executing of tasks is called iterative routing. Some times executing of a task might depend on the result of a condition; this type of executing a task is called conditional routing. Sometimes iterative routing can depend on condition. Based on a condition a set of tasks might get executed iteratively.

[0011] An increase in the complexities of business and other processes has lead to more complex constructs required to model the resulting workflow. These constructs introduce a number of complexities that current workflow engines do not handle well; resulting in activities needlessly being performed more than once, and other activities incorrectly being blocked from being performed.

[0012] A workflow system utilizes tokens associated with work flowing through paths of activities or tasks under control of constructs. The token is representative of the path taken to reach the current activity. Tokens are given attributes for activities and constructs, such as token value and construct IDs. Rules are defined for activities and constructs to use when receiving, modifying and passing on the tokens.

[0013] The rules in one embodiment comprise algorithms for comparing tokens, consuming tokens, appending tokens, and generating tokens. The tokens provide the ability to control flow of the work, such as sequencing, paralleling, iterating and synchronizing activities.

[0014] The algorithms identify the role of split, activity and join in routing. With the token, the state of a process is identifiable at a given point of time. Also the join construct is able to synchronize the different flows successfully.

[0015] FIG. 1 is a flow diagram illustrating a split.

[0016] FIG. 2 is a flow diagram illustrating an unconditional split.

[0017] FIG. 3 is a flow diagram illustrating a conditional split.

[0018] FIG. 4 is a flow diagram illustrating a join.

[0019] FIG. 5 is a flow diagram illustrating an AND join.

[0020] FIG. 6 is a flow diagram illustrating an OR join.

[0021] FIG. 7 is a flow diagram illustrating a partial join.

[0022] FIG. 8 is a flow diagram illustrating a conditional join.

[0023] FIG. 9 is a flow diagram illustrating a loopback join.

[0024] FIG. 10 is a flow diagram illustrating a workflow for approval of a paper by three professors.

[0025] FIG. 11 is a flow diagram illustrating a workflow for approval of a paper by one of three professors.

[0026] FIG. 12 is a flow diagram illustrating a workflow for approval of a paper by one of three professors with two rounds of approval required.

[0027] FIG. 13 is a block diagram of a computer system implementing a workflow engine for executing the current invention.

[0028] FIG. 14 is a flow diagram of a test case illustrating token management during performance of work.

[0029] FIG. 15 is a flow diagram of an alternative test case illustrating token management during performance of work.

[0030] In the following description and the drawings illustrate specific embodiments of the invention sufficiently to enable those skilled in the art to practice it. Other embodiments may incorporate structural, logical, electrical, process, and other changes. Examples merely typify possible variations. Individual components and functions are optional unless explicitly required, and the sequence of operations may vary. Portions and features of some embodiments may be included in or substituted for those of others. The scope of the invention encompasses the full ambit of the claims and all available equivalents. The following description is, therefore, not to be taken in a limited sense, and the scope of the present invention is defined by the appended claims.

[0031] The functions described herein are implemented in software in one embodiment, where the software comprises computer executable instructions stored on computer readable media such as memory or other type of storage devices. The term computer readable media is also used to represent carrier waves on which the software is transmitted. Further, such functions correspond to modules, which are software, hardware, firmware or any combination thereof. Multiple functions are performed in one or more modules as desired, and the embodiments described are merely examples.

[0032] The detailed description is divided into several parts. A first part describes constructs such as splits and joins, and the variations of them. FIGS. 1-12 illustrate both known constructs, and are also used to represent the token flow management in accordance with the present invention. A second part describes tokens, and rules used at various constructs to utilize the tokens to control flow and identify the path of work. An algorithm that is implemented on a computer system in the form of a computer program is then described, followed by examples showing workflow paths and the state of the tokens at each node in the path.

[0033] A split construct is represented in block form in FIG. 1 at 110. The usage of splits is for selective execution of tasks or for parallelism in the task execution. Splits can of two kinds. A split will have one input 115 and multiple outputs 120. If you think split as node in the graph then the in-degree of split is one and out-degree can be any number greater than one.

[0034] An unconditional split construct is represented in block form in FIG. 2 at 210. This split doesn't contain any condition associated with it. Workflow engines interpret this construct to achieve parallelism. Whenever the control reaches this split workflow engine will execute the Activities associated with this split simultaneously. Usually independent activities are executed simultaneously. E.g.: Execute TASKS A, B, C.

[0035] A conditional split is represented in block form in FIG. 3 at 310. To achieve selective (conditional) routing WFMS use conditional split. This split is associated with the condition. Workflow engine when it encounters this construct evaluates the condition associated with it. Based on the evaluation of the condition it will take a decision of executing a particular Activity. E.g.: If (a>b) then execute Activity A Else execute Activity B. Conditon (a>b) is treated as a conditional split. On the result of the condition a>b if it is true then Activity A will be executed otherwise (else) Activity B will be executed.

[0036] A join construct is represented in block form in FIG. 4 at 410. Joins are used for synchronizing the activities that are executing. If analogized to a graph, the join in-degree is more than one and out-degree is one. It has multiple inputs and only one output similar to multiplexer.

[0037] Based on synchronization needs joins are classified into four categories. An attribute called cardinality is used to achieve synchrnonization.

[0038] Cardinality of a join will tell the workflow engine the number of incoming activities to synchronize. If cardinality is one then the workflow engine will wait until any one of the incoming activities gets completed.

[0039] When join is used to synchronize all the incoming activities then it is called AND Join, represented at 510 in FIG. 5. If the join has two inputs coming and your business process needs that the successive activity can only start after the completion of two incoming activities then you can use AND join to do that. Here the cardinality of join will become 2. Activity C will get executed only after completion of both the activities A and B.

[0040] An OR join indicated at 610 in FIG. 6 has a cardinality attribute of one. This tells the workflow engine if any one of the incoming activities gets completed then the successive activity can carry on. FIG. 6 illustrates a situation where activity C can start if any one of the incoming activities A and B gets completed.

[0041] A partial join indicated at 710 in FIG. 7 has a cardinality attribute of more than one but less than the incoming number of activities. This tells the workflow engine not to execute the activity succeeding join until the number of activities specified in cardinality attribute of join gets completed. In a situation where the incoming activities of join are A, B and C. Activity D should start only after the execution if any two of the incoming activities gets completed.

[0042] A discriminative join illustrated in FIG. 8 at 810 uses an attribute called condition 820. The condition 820 which is an attribute of join is satisfied exclusively on completion of activities. Usually workflow activity has a state. During execution, an activity changes its state from waiting to ready, ready to executing, and executing to completion. These are the most common states of the activity. Other states may occur in different workflow processes.

[0043] A discriminative join does not contain attribute cardinality. It has only one attribute called condition. For example, if a process needs that an activity(D) can execute only after a specific incoming activity gets completed out of n number of incoming activities.

[0044] All other types of joins can be represented using the condition attribute of join, but doing so requires a condition on n number of incoming activities. This becomes complex and costly during process execution evaluation of the condition.

[0045] Sometimes a set of activities needs to be executed iteratively based on a condition. This condition usually will be on the workflow relevant data or business process data. Splits and joins are used to achieve the iteration. A typical iterative construct illustrated at 910 in FIG. 9 has a join with inputs. One of the inputs is a loopback path 920 and the other will be direct path 930. The loopback path 920 usually comes from a split 940.

[0046] Having discussed about the different constructs in defining the business process implementation difficulties of the use of these constructs to handle workflow processes are described. In one example where the process is a technical paper review where the paper should be reviewed by all available professors. In this example, the number of professors are three, A, B and C, and the paper is submitted to all three professors at the same time.

[0047] The above process is composed of the following activities:

[0048] 1) Paper submissionThis event starts or triggers the process. The event is referred to as START Activity

[0049] 2) Professor A's review where professor with name A reviewing paper. We name this as PROFA

[0050] 3) Professor B's review where professor with name B reviewing paper. We name this as PROFB

[0051] 4) Professor C's review where professor with name C reviewing paper. We name this as PROFC

[0052] 5) END where paper gets reviewed. We name this as END

[0053] The process is illustrated in FIG. 10 using the above constructs split and join. Once the process starts 1005 (i.e., the paper gets submitted), workflow splits 1010 the flow into three activities (PROFA 1015, PROFB 1020, PROFC 1025) providing them each a copy of the submitted paper. Once any activity completes, the workflow engine will trigger the next activity ie after the completion of activity PROFA workflow engine will trigger a join construct 1030. At at this point the workflow engine finds the cardinality is 3, since approval of all professors is required, and waits for other activities to get completed. Similarly When PROFB gets completed workflow engine will trigger the join 1030 and using the cardinality finds that workflow should wait further. Only when the number of completed activities are equal to the cardinality an activity end 940 is executed or the process stops.

[0054] A second scenario slightly changes the process. If any of the activities are completed, i.e., any one professor reviews the paper the process is completed as illustrated in FIG. 11. The cardinality is originally set to one, so the activity END executes when PROFA finishes the review activity. If after some time PROFB completes the paper review the Activity END is again triggered. This is undesired behavior. To remove this behavior, the join can only get executed once.

[0055] The process definition is further changed in the next example by introdocuing one more activity called CHECK 210 as seen in FIG. 12. The process now is defined to ensure that the paper should go for review for 2 rounds minimum and in each round if any one professor accepts it, it will go for next round. After the secound round the paper is accepted. The activity CHECK 210 in this example is nothing but a split construct that checks the review round. With the above assumption that join can only execute once, there is a problem. Once any professor reviews and approves in the first round, it takes a false path and again goes and submits the paper for the second round. When any professor in the second round approves the workflow engine will try to execute the join. Since it is already executed once it won't.

[0056] This pattern, i.e., the combination of unconditional split and OR join (cardinality1) along with iteration has an implementation difficulty that is addressed by the use of a token. Tokens comprises a string of attributes that represent the state of the work as it progresses through the activities associated with the work. In cases where work is split, each portion of the work has an associated token. Constructs create, modify and combine tokens while work is progressing. Tokens flowing in the system represent the path taken to reach the current activity. Tokens also provide an audit trail in one embodiment.

[0057] Several conventions are used for tokens corresponding to activities and constructs. Those conventions are first described, followed by a description of the rules regarding creation, modification and combining of the tokens.

[0058] Activities use one attribute of tokens, a token value, to store the token value used previously. Initially, the token value, TokenValue0.

[0059] The join construct uses two attributes of the tokens, TokenValue, to store the token value used previously, and TokenStringPassed, to store the token string that is sent. Initially TokenValue0 and TokenStringPassed.

[0060] The split construct uses one attribute, TokenValue, to store the token value used previously. Initially TokenValue0. The split and join constructs have unique ids associated with them. Join is a producer of tokens, and also a consumer. Activities are carriers of tokens. Splits also are carriers of tokens. Further, the workflow engine is able to find out whether a token is from a loopback edge, or a non loopback edge.

[0061] Join constructs are capable of remember tokens it has allowed and is capable of generating a token. The generated token will have a value of one more than the previously generated token. Joins are also capable of consuming tokens as described in the rules outlined below. Initially, a token allowed and token generated values are zero.

[0062] Split constructs are capable of remember the last token it generated. Initially the value of the token is zero, and tokens generated have a value of one more than the last generated token incremented than one.

[0063] Activities remember the last token generated, and initially generate tokens with value of zero. Generated tokens have a value of the last generated token incremented by one.

[0064] Each token has a structure comprising two attributes, token value, and id of the split or join. Token values and ids are separated by a delimiter, such as a :, or any other symbol desired. A combination of a token value and id is referred to as an atomic token. Different atomic tokens are separated a delimiter such as . Notation used for tokens include LCToken: Last Consumed Token, GenToken: Generated Token ie LCToken1 E.g. for a split or activity node with identifier id and LCToken as a: id1b:id then LCToken1 is b1:id represented as GenToken(LCToken1). InTokens are nothing but incoming tokens.

[0065] TokenValueto store the token value used previously.

[0066] TokenStringPassedto store the token string that is sent.

[0067] TokenStringReceivedIncoming token

[0068] In one embodiment, several rules are used for handling tokens. a first rule of dealing with tokens includes comparison of two InTokens (incoming tokens) and finding the maximum is as follows

[0069] Rule.1.1: Comparing two InTokens and finding a maximum token value

[0070] 1) Take a sub string from both the tokens, such that all the ids of both the InTokens are equal.

[0071] E.g. InToken1 is a:id1b:id2

[0072] InToken2 is c:id1d:id2e:id3

[0073] Then for comparing take two InTokens as a:id1b:id2 and c:id1d:id2

[0074] 2) The resultant tokens are compared such that the individual atomic tokens are compared sequentially. Once the greatest atomic token is found, the respective InToken is modified to be the maximum among them.

[0075] E.g. InToken1 a:id1b:id2

[0076] InToken2 c:id1d:id2

[0077] Then a is compared with c

[0078] If a>c then InToken1 is maximum

[0079] If a<c then InToken2 is maximum

[0080] If ac then b is compared similarly with d

[0081] If a c and bd then arbitrary choice is made.

[0082] Note: This is denoted as MAXIMUM (InToken1 . . . InTokenn)

[0083] Rule.1.2: Consumption of two tokens is as follows

[0084] 1) From the InToken find the atomic token with the same Id

[0085] E.g. InToken a:id1b:id2c:id3 and the Join id is id2

[0086] 2) Out Going Token is the token until the atomic token with the same id

[0087] E.g. InToken a:id1b:id2c:id3 and the Join id is id2

[0088] Note: It is denoted as CONSUME (a:id1b:id2c:id3, id2)a:id1b1:id2

[0089] Rule.1.3: Appending of two tokens is as follows

[0090] 1) Generate the atomic token with GenToken associated with Id

[0091] E.g. Suppose GenToken is g and id of Split/Activityobject is Id then the atomic token will be g:Id.

[0092] 2) Append the generated atomic token with the InToken

[0093] E.g. Suppose InToken is a:id1b:id2 and generated atomic token is g:Id, Then the APPEND (a:id1b:id2, g:Id)a:id1Ib:id21g:Id

[0094] Note: It is denoted as APPEND (a:id1b:id2, g:Id)a:id1b:id2g:Id

[0095] Rule.2: If the incoming token is from a non-loop back edge, then

[0096] Rule 2.a (for JOIN):

[0097] Incoming Token: nothing

[0098] Last Consumed Token: 0

[0099] Generated Token: 1, that is Last Consumed Token 1 3

[0100] Outgoing Token: 1:id using Rule 1.3

[0101] Rule 2.b (for JOIN):

[0102] Incoming Token: Token strings (InToken)

[0103] Last Consumed Token: LCToken

[0104] Generated Token: GenToken (LCToken 1)

[0105] Outgoing Token: APPEND(MAXIMUM (InToken, LCToken) using Rule 1.1, GenToken) using Rule 1.3.

[0106] Rule 2.c (for Join):

[0107] Incoming Token: if there are n number of incoming tokens then the maximum of them according to Rule 1.1 is taken

[0108] MAXIMUM ((InToken1 . . . InTokenn)

[0109] Last Consumed Token: LCToken

[0110] Generated Token: GenToken (LCToken 1)

[0111] Outgoing Token: Similar as rule 2.2 that is APPEND(MAXIMUM (MAXIMUM (InToken1 . . . InTokenn), LCToken),GenToken)

[0112] Rule.3 (for Join): If the incoming token is from a loop back edge, then

[0113] Incoming Token: InToken

[0114] Last Consumed Token: LCToken

[0115] Generated Token: GenToken (LCToken 1)

[0116] Outgoing Token: CONSUME (Maximum(InToken, LcToken), using Rule 1.2, id)

[0117] Rule.4 (for Split and Activity):

[0118] Incoming Token: InToken

[0119] Last Consumed Token: LCToken

[0120] Generated Token: GenToken (LCToken 1)

[0121] Outgoing Token: APPEND (InToken, GenToken) using Rule 1.3

[0122] The following algorithm contains functions implemented in computer programming code executed on a computer system in one embodiment. In further embodiments, hardware, firmware or software, or combinations of the same are used to implement the algorithm. The algorithm is represented in a pseudocode listing, which is easily used by one skilled in the art to program a workflow engine:

Flow(TokenStringReceived)
Begin
Step.1:
	If the receiving node is of type Activity, then
	begin
TokenValue TokenValue 1
	TokenString TokenStringReceived
	TokenValue : id
	Send the TokenString.
	end
Step.2:
	Else if the receiving node is of type Split, then
	Begin
	TokenValue TokenValue 1
	TokenString TokenStringReceived
	TokenValue : id
	Send the TokenString.
	End
Step.3:
	Else if the receiving node is of type Join, then
	Begin
	If the incoming edge is a non-loop back edge, then
	Begin
	If TokenStringPassed , then
	Begin
	TokenValue TokenValue 1
	TokenStringPassed TokenStringReceived
	TokenValue : id
	Send TokenStringPassed.
	end
	Else
	Begin
	TokenSubString Take the leftmost substring of the
	TokenStringReceived upto the point where both
	TokenStringReceived and TokenStringPassed have the
	same identifiers.
	If TokenSubString is greater than TokenStringPassed,
	then
	Begin
	TokenValue TokenValue 1
	TokenStringPassed TokenSubString
	TokenValue : id.
	Send TokenStringPassed.
	End
	Else
	Block the TokenString.
	end
	end
	else if the incoming token string is from a loop back edge, then
	begin
	TokenSubString Take a substring from the
	TokenStringReceived skipping the characters from the
	point where the identifier of the current join is present.
	If TokenSubString TokenStringReceived, then
	Begin
	// It implies that the current join-id is not in
	TokenStringReceived.
	In the TokenStringReceived, increment the TokenValue of
	last token.
	TokenValue TokenValue 1
	TokenStringPassed TokenSubString
	TokenValue : id
	Send the TokenStringPassed
	end
	Else if TokenSubString is greater than TokenStringPassed,
	then TokenValue TokenValue 1
	TokenStringPassed TokenSubString
	TokenValue : id
	Send the TokenStringPassed
	Else
	Block the Token String
	End
	end
end.

[0123] The above algorithm identifies the role of split, activity and join in routing. With the token the state of a process is identifiable at a given point of time. Also join is able to synchronize the different flows successfully. Using this token management synchronization, identifying the state of a process becomes easy.

[0124] A block diagram of a workflow system is indicated generally at 1210 in FIG. 12. The workflow system comprises a computer system 2115 having a processor 2120, memory 2125, and input/output capabilities, such as a monitor 2130, keyboard/mouse 2135 and other input devices from which the completion of activities are input, such as wands, scanners, and other input devices. A workflow engine 2140 is stored in memory 2125 for execution on processor 2120. The workflow engine executes the above algorithm. The workflow engine comprises one or more modules of software that implement the functions of the algorithm and the rules for token management.

[0125] A first example of a process is shown in FIG. 14. FIG. 14 shows multiple nodes in a process defined with splits, labeled Sn, and joins, labeled Jn. Several iterations are included in this example. Token management by a workflow engine is illustrated for this example in the following table, Table 1. The table shows incoming and outgoing or passed tokens from each node, in addition to creation, modification and consumption of the tokens in accordance with the previous rules described.

TABLE 1
From Start to J0
Consumed Token null
Token passed from J0 1:J0using Rule 2.a.
From J0 to S0
Incoming Tokens 1:J0
Token passed from S0 1:J01:S0using Rule 4.
From S0 to J1	From S0 to J2
Incoming Tokens 1:J01:S0	Incoming Tokens 1:J01:S0
Consumed Token null	Consumed Token null
Token passed from J1 1:J01:S01:J1	Token passed from J2 1:J01:S01:J2
using Rule 2.b.	using Rule 2.b.
From J1 to S1	From J2 to S2
Incoming Token 1:J01:S01:J1	Incoming Token 1:J01:S01:J2
Token Passed from S1 1:J01:S01:J11:S1	Token Passed from S2 1:J01:S01:J21:S2
using Rule 4.	using Rule 4.
From S1 to J1	From S2 to J2
Incoming Tokens 1:J01:S01:J11:S1	Incoming Tokens 1:J01:S01:J21:S2
Consumed Token 1:J01:S01:J1	Consumed Token 1:J01:S01:J2
Token passed from J1 1:J01:S02:J1	Token passed from J2 1:J01:S02:J2
using Rule 3.	using Rule 3.
From J1 to S1	From J2 to S2
Incoming Token 1:J01:S02:J1	Incoming Token 1:J01:S02:J2
Token Passed from S1 1:J01:S02:J12:S1	Token Passed from S2 1:J01:S02:J22:S2
using Rule 4.	using Rule 4.
From S1 to J2, S2 to J3
Incoming Tokens:	1:J01:S02:J12:S1
	1:J01:S02:J22:S2
Consumed Token: null
Token passed from J3 1:J01:S02:J12:S11:J3using Rule 2.a.
From J3 to S3
Incoming Token 1:J01:S02:J12:S11:J3
Token Passed from S3 1:J01:S02:J12:S11:J31:S3
using Rule 4.
From S3 to J0
Incoming Tokens 1:J01:S02:J12:S11:J31:S3
Consumed Token 1:J0
Token passed from J0 2:J0
using Rule 3.
From J0 to S0
Incoming Tokens 2:J0
Token passed from S0 2:J02:S0using Rule 4.
From S0 to J1	From S0 to J2
Incoming Tokens 2:J02:S0	Incoming Tokens 2:J02:S0
Consumed Token 1:J01:S02:J1	Consumed Token 1:J01:S02:J2
Token passed from J1 2:J02:S03:J1	Token passed from J2 2:J02:S03:J2
using Rule 2.b.	using Rule 2.b.
From J1 to S1	From J2 to S2
Incoming Token 2:J02:S03:J1	Incoming Token 2:J02:S03:J2
Token Passed from S1 2:J02:S03:J13:S1	Token Passed from S2 2:J02:S03:J23:S2
using Rule 4.	using Rule 4.
From S1 to J1	From S2 to J2
Incoming Tokens 2:J02:S03:J13:S1	Incoming Tokens 2:J02:S03:J23:S2
Consumed Token 2:J02:S03:J1	Consumed Token 2:J02:S03:J2
Token passed from J1 2:J02:S04:J1	Token passed from J2 2:J02:S04:J2
using Rule 3.	using Rule 3.
From J1 to S1	From J2 to S2
Incoming Token 2:J02:S04:J1	Incoming Token 2:J02:S04:J2
Token Passed from S1 2:J02:S04:J14:S1	Token Passed from S2 2:J02:S04:J24:S2
using Rule 4.	using Rule 4.
From S1 to J3, S2 to J3
Incoming Tokens:	2:J02:S04:J14:S1
	2:J02:S04:J24:S2
Consumed Token: 1:J01:S02:J12:S11:J3
Token passed from J3 2:J02:S04:J14:S12:J3using Rule 2.c.
From J3 to S3
Incoming Token 2:J02:S04:J14:S12:J3
Token Passed from S3 2:J02:S04:J14:S12:J32:S3
using Rule 4.
From S3 to END
FLOW IS TERMINATED

[0126] A second example of a process is shown in FIG. 15. FIG. 15 shows multiple nodes in a process defined with splits, labeled Sn, and joins, labeled Jn. Activities are included in the second example and are labeled An. Several iterations are included in this example. Token management by a workflow engine is illustrated for this example in the following table, Table 2. The table shows incoming and outgoing or passed tokens from each node, in addition to creation, modification and consumption of the tokens in accordance with the previous rules described.

TABLE 2
From Start to J0
Consumed Token null
Token passed from J0 1:J0using Rule 2.a.
From J0 to A0
Incoming Token 1:J0
Token Passed from A0 1:J01:A0using Rule 4
From A0 to J1
Incoming Token 1:J01:A0
Consumed Token null
Token passed from J1 1:J01:A01:J1using Rule 2.a.
From J1 to S0
Incoming Token 1:J01:A01:J1
Token passed from S0 1:J01:A01:J11:S0using Rule 4
From S0 to J0
Incoming Token 1:J01:A01:J11:S0
Consumed Token 1:J0
Token Passed from J0 2:J0using Rule 3
From J0 to A0
Incoming Token 2:J0
Token Passed from A0 2:J02:A0using Rule 4
From A0 to J1
Incoming Token 2:J02:A0
Consumed Token 1:J01:A01:J1
Token passed from J1 2:J02:A02:J1using Rule 2.b.
From J1 to S0
Incoming Token 2:J02:A02:J1
Token passed from S0 2:J02:A02:J12:S0using Rule 4
From S0 to A1
Incoming Token 2:J02:A02:J12:S0
Token passed from A1 2:J02:A02:J12:S01:A1using Rule 5
From A1 to S1
Incoming Token 2:J02:A02:J12:S01:A1
Token passed from S1 2:J02:A02:J12:S01:A11:S1using Rule 4
From S1 to J1
Incoming Token 2:J02:A02:J12:S01:A11:S1
Consumed Token 2:J02:A02:J1
Token passed from J1 2:J02:A03:J1using Rule 3
From J1 to S0
Incoming Token 2:J02:A03:J1
Token passed from S0 2:J02:A03:J13:S0using Rule 4.
From S0 to J0
Incoming Token 2:J02:A03:J13:S0
Consumed Token 2:J0
Token Passed from J0 3:J0using Rule 3
From J0 to A0
Incoming Token 3:J0
Token Passed from A0 3:J03:A0using Rule 4.
From A0 to J1
Incoming Token 3:J03:A0
Consumed Token 2:J02:A03:J1
Token passed from J1 3:J03:A04:J1using Rule 2.b.
From J1 to S0
Incoming Token 3:J03:A04:J1
Token passed from S0 3:J03:A04:J14:S0using Rule 4.
From S0 to A1
Incoming Token 3:J03:A04:J14:S0
Token passed from A1 3:J03:A04:J14:S02:A1using Rule 4.
From A1 to S1
Incoming Token 3:J03:A04:J14:S02:A1
Token passed from S1 3:J03:A04:J14:S02:A12:S1using Rule 4.
From S1 to END
FLOW IS TERMINATED