Ultimus®

Ultimus BPM Suite 7.0

BPM Engine Logic Guide

Ultimus BPM Engine Logic Guide i

Copyright Information
No part of this manual may be reproduced or transmitted in any form or
by any means, electronic or mechanical, including photocopying and
recording, for any purpose, without the express written consent of
Ultimus. The software described in this manual is furnished under a
license agreement or non-disclosure agreement and may be used or
copied only in accordance with the terms of the agreement. The
information contained in this manual is subject to change without notice
and does not represent a commitment on the part of Ultimus.
Copyright © 2005, Ultimus. All rights reserved.
Companies, names and data used in examples herein are fictitious unless
otherwise noted.
Ultimus™, Flobot™, FloStation™, Maplet™ are trademarks of Ultimus,
Inc.
Windows, MS, MS-DOS, Word, Excel, and Access are registered
trademarks of Microsoft Corp. All other names may be trademarks of their
respective owners and are used for reference only.
All Ultimus specifications contained in documentation and literature are
subject to change without notice.

Ultimus, Inc.
15200 Weston Parkway, Suite 106
Cary, North Carolina 27513
Phone: 919-678-0900
Fax: 919-678-0901
documents@ultimus.com
http://www.ultimus.com

ii Ultimus BPM Engine Logic Guide

 Ultimus BPM Engine Logic
The Ultimus BPM Server
The Ultimus BPM Server is the central application, the “brains” behind
Ultimus, that governs the flow of a process from one step to another in
an entire process. The purpose of this document is to clearly define all
the rules and logic for the Ultimus BPM Server (hereafter referred to as
the “Engine”) that dictate the flow of a process. The goal is to provide
you with a clear explanation of how the Engine makes decisions so that
processes take advantage of the full power of the Engine for implement-
ing real-life business workflows.

Terminology
The following terminology is used in this chapter:
Following Step: Step B is a Following Step to Step A if a link originates
from Step A and ends at Step B.
Preceding Step: Step B is a Preceding Step to Step A if a link origi-
nates from Step B and ends at Step A.
Active Step: An Active Step is a step that has been invoked and has
not yet been Completed, Aborted, or Returned.
Skipped Step: A Skipped Step is one that has been evaluated for acti-
vation but not activated because the Activate Conditions are false.
Undetermined Step: A step is Undetermined if it has never been evalu-
ated, or its current status is Returned or Aborted.
Completed: An Active Step is Completed after the User, Flobot or Ma-
plet “submits” or completes the task for that step.
Returned: An Active Step is Returned after the User “returns” the task
for that step.
Forced: A step is Forced when it is “jumped to” from another step based

Ultimus BPM Engine Logic Guide 1

 upon actions in the Event Conditions Tables. A “jumped to” step always
becomes Active when Forced (i.e., the Activate Conditions are ignored).
Aborted Step: A step is an Aborted Step if it was forced to become in-
active via actions in the Event Conditions Tables.
Resubmittable Step: A step that is allowed to resubmit the task is a
Resubmittable Step.

Basic Logic Rules

Every business process must follow certain general rules of logic to en-
sure consistency of behavior. At the lowest level, the Engine must pro-
vide consistent and repeatable behavior for its tasks based upon the
following rules:
• Every process flows in steps following the links that have been
specified between steps at design time. If conditions are attached
with a particular step, then the presence of the conditions overrides
the links, and the process flows according to the conditional logic,
skipping some steps and jumping to others.
• If a step is forced it must become active regardless of any links or
condition tables. Forcing a step overrides all other logic associated
with that step.
• The logic must not be time-sensitive. This means that the logic
should produce consistent results, irrespective of when any step is
executed. The timing of completing a step must not have any impact
on the logical flow of the workflow.
• The logic implemented by the Engine is not sensitive to the order in
which steps are evaluated. If a step has three paths going out to
other steps, the BPM Engine may evaluate the paths in any order
and produce identical results.

2 Ultimus BPM Engine Logic Guide

Event Condition Tables and Their Rules
In many situations, the manner in which work in a business flows from
one user to another may not follow a static pattern, but rather depend on
a number of inputs and factors. The Event Conditions Tables in BPM
Studio allows such logic to be specified. The BPM Engine reads these
conditions, and on the basis of these, dynamically computes the work-
flow path to be followed.
Event Condition Tables allow workflow designers to bypass the normal
logic of the Engine based upon exceptions and conditions in the work-
flow. Event Condition Tables use the rules specified below.

Activate Condition
• The Activate Event Condition Table specifies the conditions under
which the Step will become Active.
• This Conditions table is evaluated when the Engine determines that
it is time to invoke the step.
• Any action specified in the Event Conditions Table without a condi-
tion is automatically performed.
• If the table is blank, the step is assumed to be unconditional and is
activated.
• If the table is not blank and any ONE of the Activate Step conditions
is true, the step is activated.
• If ALL of the Activate Step conditions are false, the step is skipped.
• All conditions specified are evaluated before the step is skipped or
activated.
• The Activate Conditions Table is ignored if the step is forced.
• Call script or DLL conditions are evaluated independently and are
executed if true, even if the step is activated or not activated.

Complete Condition
The Complete Event Condition Table specifies what the Engine will do
when the step is Completed.

Ultimus BPM Engine Logic Guide 3

 • The Complete Event Condition Table is evaluated when the Step is
completed.
• If the Complete Condition Table is blank, then the actions specified
by the links are taken.
• If one or more conditions in the table associated with forcing Actions
(Jump To, Abort, Abort Incident) are true, the links going out from
the Step are ignored, and only the actions associated with the true
condition(s) are taken.

Note: If the only actions taken by the Complete Condition Table are
Call .NET Code/Call Web Service, then the links are followed.

• If none of the conditional rows for forcing Actions (Jump To, Abort,
Abort Incident) are true, then the links are followed.
• All conditions in the Table are always evaluated and the correspond-
ing actions taken if they are True.

Late Condition
The Late Event Condition specifies what the engine does when the step
becomes late.
• The Late Event Condition Table is evaluated when the step
becomes late (i.e., the sum of the Completion Time and Extension
Time specified for the step has expired).
• If the Late Condition Table is blank, nothing happens.
• If one or more conditions in the table are true, all the actions
associated with the true condition(s) are taken.
• All conditions in the Table are always evaluated and the
corresponding actions taken if they are true.

Return Condition
The Return Event Condition Table specifies what the engine does when
the Step is returned.
• The Return Event Condition Table is evaluated when the step is
returned.

4 Ultimus BPM Engine Logic Guide

 • If the Table is blank, the User Step(s) completed prior to the
activation of this step are forced (that step will be activated to the
User that last completed the task).
• If one or more conditional rows associated with forcing Actions
(Jump To, Abort, Abort Incident) in the table are true, only the
actions associated with the true condition(s) are taken.

Note: If the only true conditional rows are associated with Call .NET
Code/Call Web Service actions, then the step(s) that were
completed prior to the activation of this step are forced.

• If none of the conditional rows associated with forcing actions are

true, then the User Step(s) completed prior to the activation of this
step are forced.
• All conditions in the Table are always evaluated and the
corresponding actions taken if they are true.

Resubmit Condition
The Resubmit Event Condition Table specifies what the Engine does
when the step is re-submitted.
• The Resubmit Event Condition Table is evaluated when the step is
resubmitted.
• If the Resubmit Condition Table is blank, or NONE of the conditional
rows for forcing actions (Jump To, Abort, Abort Incident) are true,
then the actions specified by the links are taken.

Note: If the actions taken by the Resubmit Condition Table are

Call .NET Code/Call Web Service, then the links are followed.

• If one or more conditions in the table associated with forcing actions

(Jump To, Abort, Abort Incident) are true, the links going out from
the step are ignored and only the actions associated with the true
condition(s) are taken.
• All conditions in the Table are always evaluated and the

Ultimus BPM Engine Logic Guide 5

 corresponding actions taken if they are true.

Recipient Type Condition

This condition table allows the workflow designer to select a recipient(s)
on a conditional basis.
• The Recipient Event Condition Table is evaluated when the step is
activated.
• If this condition table is blank or none of the conditions are true, the
task is assigned to the Recipient(s) named in the step properties.
• If one or more conditions are true, the task is assigned to the
recipient associated with the first true condition, starting from the top
of the condition table.

Step Evaluation Logic

The Engine evaluates steps for activation using the following logic:
1. All Following Steps of a step are evaluated under the following
conditions:
a. If the step is Completed and NONE of the conditions in the
Complete Condition Table of the step are true.
b. If the Step is Resubmitted and NONE of the conditions in the
Resubmit Condition Table of the Step are True.
c. If the Step is Skipped.

Note: Call .NET Code/Call Web Service do not have any effect on the
Engine logic as mentioned in the previous section.

If a Step is Aborted or Returned, the following Steps are NOT

evaluated.

If the Following Step is Active, In-Queue, or Delayed, it is NOT

evaluated. Evaluation Logic cannot change the status of steps
that are Active, In-Queue, or Delayed.

6 Ultimus BPM Engine Logic Guide

 2. When a step is evaluated, the BPM Engine decides if it should be
made Active, Skipped, or stay Undetermined based on the following
rules that shall be applied in order:
a. If ANY Preceding Step is Undetermined, the step is also
Undetermined.
b. If ALL Preceding Steps are Skipped, the step is also skipped.
c. If ANY Preceding Step is Active, In-Queue, or Delayed, the
step is Undetermined.
d. If the Activate Event Condition Table for the Step evaluates
True, then the Step becomes Active.
e. If the Activate Event Condition Table for the Step evaluates
False, then the Step is Skipped.

Ultimus BPM Engine Logic Guide 7

 Other Logic Rules
1. If a Step is Forced then it MUST be activated; the Activate Event
Condition Table for the Step is ignored.
2. If a Step is currently in Delay mode, and it is Forced by the
Condition Table of another Step, the Step is activated immediately,
and the Delay time is ignored.
3. If a Queue Step is complete, then a Return to the Queue Step will
cause the task to be assigned to the user who completed the
Queue Step. It will not go into the queue.
4. For a Queue Step, the Completion/Extension/Delay Times applies
as soon as the step is assigned to the queue and are carried
forward to the user who pulls the task from the queue. That is, the
Completion/Extension/Delay Time calculation does not differentiate
between time in the queue and the time in the in-box of the user.
Thus, if the Completion+Extension Time is 3 days, the task sits in
the queue for 2.5 days and then the user pulls it, it will become late
unless the user completes it in 0.5 days.
5. Returning to a Step A from any Step B assigns the task to the user
who previously performed the Step A.
6. Users of a multiple recipient Step (Department/Group) cannot
return the Step.
7. If a Step “returns” to a previous Step and the previous Step(s) is a
Junction, Flobot, or Maplet step, the return “flows-through” i.e. it
goes through the previous Step(s) until it finds a User Step(s) in the
return path.

Note: This applies only for normal Returns that are implemented by
Engine logic. If the Return Event Condition Table is involved,
then only the actions in the Condition Table are taken and the
Engine logic is bypassed.
8. If a Queue Step that has never been invoked is Forced, then the
task will go into the queue. However, since the task is in the queue
and not assigned to a particular user, it will not be marked as
active.

8 Ultimus BPM Engine Logic Guide

 9. Any following Step of a Begin Step in a Maplet or an AutoLaunch
process is not allowed to Return (since the Begin Step is completed
automatically). Since it is not possible for the Engine to determine
the type of process, it is up to the process designer to make sure
that Returns in these conditions are handled according to user
requirements.
10. If a Step is “returned to,” it is Forced (i.e., the Activate Conditions
are not evaluated).
11. When a .NET/Web Service call on a Completed Event Condition of a
step fails, that step will not fail, but will be rolled back to Active.
12. Steps after parallel Steps will only activate once all incoming parallel
Step links to that Step have been completed. This logic applies for
End Steps too , they will only completed once all incoming parallel
Steps have been completed. If you want to ensure that all necessary
steps have been completed prior to an End Step completing, it is
suggested you place a Junction Step before the End Step, and use
Event Conditions on the Junction Step to assess whether it is the
appropriate time to drive the incident to completion.

Logic Scenarios
The process map below is used to illustrate how the logic of the BPM
Engine operates in a real-life process. The sequence of these steps is
being determined at run time by the Engine while evaluating the logic
that has been assigned to each step at design-time via BPM Studio. The
scenarios indicate the application of Engine logic., The following process
map is used in the various scenarios illustrated below:

Ultimus BPM Engine Logic Guide 9

 Scenario 1: Steps 2 and 4 Skipped
In the first example scenario, we consider an incident of the above
shown workflow process when its steps 2 and 4 are skipped. The
following transition diagram shows how the process moved forward

using the Engine Logic:

• Initially all steps are in an undetermined state.
• When the Begin Step is initiated, the Activate condition tables of
Steps 2, 3, and 4 are evaluated.
• Evaluation of the condition logic causes Steps 2 and 4 to be
skipped, and the task moves to Step 3.
• Step 5 is skipped because the preceding step, Step 2, is skipped.
However, it is possible for Step 5 to become active later by a forced
conditional jump from another step.
• When Step 3 is completed, Step 6 is evaluated and becomes
Active.

10 Ultimus BPM Engine Logic Guide

 • When Step 6 is completed, Step 7 is evaluated and becomes
Active.

Scenario 2: Step 4 Skipped and Steps 2 and 5 Completed before Step 3

This example illustrates that the Engine Logic is not time-sensitive. The
process flows as follows:

• Step 1 Completes to cause both Step 2 and Step 3 to become

Active. Step 4 is skipped.
• However, Step 6 is not skipped because Step 3 is Active.
• Step 2 and 5 complete and reach Step 7 before Step 3 is
completed; however, this does not affect the logic of the overall
process.
• When Step 3 finishes later, Step 6 is evaluated and becomes
Active.
• When Step 6 is completed, Step 7 is evaluated again and becomes
Active.

Ultimus BPM Engine Logic Guide 11

 Scenario 3:
Step 3
Skipped, Step 5
Completed
before Step 4

This scenario illustrates the completion of one step before another.

• Step 1 is completed and Activates Steps 2 and 4. Step 3 is skipped
due to the Event Conditions Tables.
• Step 2 completes to Activate Step 5.
• Step 4 takes a longer time to complete. When it does complete,
Step 6 is activated.
• When Step 6 Completes, Step 7 is evaluated and becomes Active.

Note: The relative timing of the completion of tasks between Steps 4

and 5 does not affect the logic of the workflow routing.

12 Ultimus BPM Engine Logic Guide

Scenario 4: Step 6
is Skipped after
Step 5 is
Completed

• Step 1 Completes and Activates Steps 2, 3, and 4.

• Step 2 completes its task first and causes Step 5 to Activate.
• Step 5 also completes while 3 and 4 are still Active.
• Completion of Step 5 does not activate Step 7, because Step 7 is
evaluated when all of its preceding steps (Steps 3 and 6) are
Completed or Skipped.
• Step 3 completes.
• Step 4 completes and causes Step 6 to be evaluated and Skipped.
• Skipping of Step 6 causes Step 7 to be evaluated and become
Active.

Ultimus BPM Engine Logic Guide 13

 Scenario 5: Step 6 is Skipped before Step 5 is Completed

• Step 1 Completes and causes Steps 2, 3 and 4 to become Active.

• Step 4 completes its task while Steps 2 and 3 are still in process.
• Step 4 does not submit its task to Step 6, resulting in Step 6 being
skipped.
• Step 3 completes, then Step 2 completes.
• Step 2 submits its task to step 5, which is its Following Step.
• The completion of Step 5 causes Step 7 to be evaluated and
become Active. This takes the process to completion.

14 Ultimus BPM Engine Logic Guide