Ultimus Engine Logic Guide: For Ultimus BPM Suite 7.1

Ultimus Engine Logic Guide
for Ultimus BPM Suite 7.1
Ultimus Engine Logic Guide

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, Inc. 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, Inc.
Copyright © 1999-2005 Ultimus, Inc. All rights reserved.
Companies, names, and data used in examples herein are fictitious unless otherwise noted.
Ultimus™, Adaptive Discovery™, Flobot™, FloPort™, FloStation™, Maplet™, U2Net™, and Unruly
Event™ are trademarks of Ultimus, Inc.
Windows, MS-DOS, Word, Excel, InfoPath and SQL Server 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.
This document was last updated on June 21, 2005.
Contents
Overview
Introduction_______________________________________________________________________ 2
Contacting Ultimus_________________________________________________________________ 2
Conventions used in this document ____________________________________________________ 3
Overview of this document___________________________________________________________ 3
Chapter 1
Ultimus engine logic guidelines
Terminology used in the Ultimus Engine Logic Guide _____________________________________ 4
Basic logic rules ___________________________________________________________________ 5
Event node parameters ______________________________________________________________ 5
Activate event node _____________________________________________________________ 6
Completed event node ___________________________________________________________ 6
Late event node ________________________________________________________________ 7
Recipient event node ____________________________________________________________ 7
Resubmitted event node __________________________________________________________ 8
Returned event node_____________________________________________________________ 8
Additional logic guidelines___________________________________________________________ 9
Chapter 2
Logic scenarios
Scenario 1: Step 2 and Step 4 are skipped _______________________________________________ 12
Scenario 2: Step 4 is skipped; Step 2 and Step 5 complete before Step 3 _______________________ 13
Scenario 3: Step 3 is skipped; Step 5 completes before Step 4 _______________________________ 14
Scenario 4: Step 6 is skipped after Step 5 is completed _____________________________________ 15
Scenario 5: Step 6 is skipped before Step 5 is completed ___________________________________ 16
ultimus.com 1 Ultimus Engine Logic Guide

Overview
Introduction
Ultimus BPM Server is the central module, the “brains” behind Ultimus BPM Suite, that governs the
flow of a process from one step to another in an Ultimus process. The purpose of this document is to
clearly define all the rules and logic of Ultimus BPM Server (hereafter referred to as the “Ultimus
engine”) that dictate the flow of a process. This document provides a clear explanation of how the
Ultimus engine makes decisions, so that processes take advantage of the Ultimus engine’s full power to
implement real-time business workflows.
Contacting Ultimus
Ultimus is always striving to improve its product and support services. Furthermore, Ultimus offers a
number of ways to find answers or to submit feedback.
You may use the following ways to find answers to your Ultimus-related questions or to submit feedback
to Ultimus:
• Ultimus Support: At Ultimus Support, you can access technical experts to resolve your
technical issues, use the KnowledgeBase to get answers to common and specific questions, and
download the latest product builds and documentation. You can reach Ultimus Support at:
http://www.ultimussupport.com/.
• Ultimus Education: Ultimus Education provides technical training and certification on the
latest Ultimus BPM Suite to ensure you possess up-to-date knowledge of the latest product
releases. Ultimus Enterprise Integration Kit (EIK) training is provided on an as-needed basis.
For more information, contact training@ultimus.com.
• Product enhancement: Ultimus strives to improve our product. If you would like to submit a
product enhancement or feature concept, go to:
http://www.ultimussupport.com/ultweb/ultisapi/FormAccess.dll?
LaunchProcess?PER%20Process.
• Documentation feedback: Ultimus strives to improve technical documentation and online help.
If you would like to submit documentation feedback, contact documents@ultimus.com.

Overview
Conventions used in this document
Conventions used in this document
The following conventions are used throughout this document:
bold Bold text denotes items that you must select or click on in an application,
such as menu options, dialog box options, and dialog box output. Bold text
is also used to designate labels within table columns.
italic Italic text denotes variables, emphasis, and document, chapter, and section
titles. This also denotes text that is a place holder for a word or value that
you must supply.
monospace Text in this font denotes text or characters that you should input to an
application, application output, sections of code, programming examples,
and syntax examples. This is also used for the proper names of disk drives,
paths, directories, device names, file names, file extensions, code excerpts,
and URLs.
» This icon denotes a tip, which alerts you to advisory information.
This icon denotes a note, which alerts you to important information.
Overview of this document
The Ultimus Engine Logic Guide consists of the following chapters:

• Chapter 1, Ultimus engine logic guidelines: This chapter outlines terminology used in this
document, basic Ultimus engine logic rules, and event type behavior guidelines.
• Chapter 2, Logic scenarios: This chapter outlines logic scenarios to demonstrate how the
Ultimus engine logic is applied to a simple process map.
ultimus.com Ultimus Engine Logic Guide 3

1
This chapter introduces the following topics regarding Ultimus engine logic:
• Terminology: The Ultimus terminology used throughout this guide is introduced.
• Basic logic rules: In overview, there are four basic logic rules that the Ultimus engine follows.
These will be discussed.
• Event type behavior: This section introduces event types, then describes the behaviorial
guidelines for each.
• Additional logic guidelines: This section outlines additional logic guidelines not specified by
event type behavior.
Each of these sections will be discussed below.
Terminology used in the Ultimus Engine Logic Guide
This section outlines the terminology used throughout the Ultimus Engine Logic Guide. These are listed
in alphabetical order.
• Aborted step: An aborted step is a step which is forced to become inactive. It is forced inactive
because an Abort Step action was called upon it.
• Active step: An active step is a step which has been invoked, but has not yet been completed,
aborted, or returned.
• Completed step: A completed step is a step which was active, but the user, Flobot, or Maplet
“submits” (or completes) the task assigned for that step.
• Following step: Step B is a following step to Step A if a link originates from Step A and ends
at Step B.
• Forced step: A forced step is a step which is activated because of a condition(s) from another
step.
• Preceding step: Step B is a preceding step to Step A if a link originates from Step B and ends
at Step A.
• Resubmitted step: A resubmitted step is a completed step that has been submitted again from
the Completed view in an Ultimus client. Resubmitting a step has the effect of rolling back a
process to the state that it was in when the step was originally submitted.

Basic logic rules
• Returned step: A returned step is a step which was once active, but is no longer active because
workflow has routed to a previous step in the process.
• Skipped step: A skipped step is a step which has been evaluated for activation, but is not
activated because the conditions to activate the step are FALSE.
• Undetermined step: An undetermined step is a step which has not been evaluated in the process
incident.
Basic logic rules
The Ultimus engine determines the workflow routing of an Ultimus process based on the following
conditions (in this order of priority for evaluation):
1. Rules: Rules designed in Ultimus Director are evaluated first.
2. Event conditions: If no rule evaluates TRUE (or if Ultimus Director is not licensed in the
Ultimus BPM environment), then event conditions specified in a given step are evaluated to
determine the route of flow.
Note: This is not necessarily true for all event nodes. The section Event node parameters,
below, explains how event conditions may or may not be considered for each event
node.
3. Links within the Ultimus process: Links set in the process are last to be evaluated to determine
the route of flow.
This implies that with the presence of rules and event conditions, the process flows according to
conditional logic, possibly skipping steps and/or forcing others not in the order as linked in the process
map.
Event node parameters
Ultimus engine logic uses six possible event states for most steps in Ultimus BPM Suite (with the
exception of Begin and End steps). Below (in alphabetical order) are explanations of when each event
occurs in Ultimus BPM Suite:
• Activate: An activate event represents when a step is being evaluated for activation. This occurs
before the actual activation of the step in a process incident.
• Completed: A completed event represents when a step has completed in a process incident.
• Late: A late event represents when a step’s completion and extension times have been reached:
that is, it represents when a user has been given a specific allocated time to perform a task, and
did not complete that task in that allotted time frame.
• Recipient: A recipient event represents when a step becomes active and the Ultimus engine
determines to which user or group the step should become activated.

Activate event node
• Resubmitted: A resubmitted event represents when a step is resubmitted. The Resubmit

function in Ultimus BPM Suite allows users to open completed steps of active incidents and
resubmit them.
• Returned: A returned event represents when a step is returned. The Return function in Ultimus
BPM Suite allows users to return active steps to the previous steps in the Ultimus process.
These event states are used in both Ultimus Director (as events nodes in the Rules pane) and in Ultimus
BPM Studio Client (as event conditions within each step of a process map). Event nodes/event
conditions follow the same logic. This logic is in compliance with the basic logic rules outlined in the
Basic logic rules section, above. The parameters outlined below are described as event nodes, because
some parameters affect whether event conditions are evaluated or not. The descriptions of these
parameters assume that the event node affects the step to which the event node is within.
Tip: It is best not to use both business rules and event conditions on a step. Use either
business rules or event conditions. Because business rules are more flexible to design,
modify, and publish, Ultimus recommends using business rules. For more information
how to use business rules in the Ultimus BPM environment, refer to the Ultimus
Director User Guide.
Activate event node

The Activate event node follows these parameters:
• An Activate event node specifies the conditions under which the step will become active.
• Rules within an Activate event node are evaluated when the Ultimus engine determines that
it is time to invoke the step.
• Rules are evaluated in an Activate event node from top to bottom in the node.
• When the first rule with an Activate Step action evaluates as TRUE, the step is activated. No
other rules in the event node will be evaluated.
• All rules within an Activate event node are ignored if the step is forced (activated from
another step using an Activate Step action or a returned step).
• If no rules evaluate as TRUE within the Activate event node, event conditions will not be
evaluated. The step will not be activated; the step will be skipped.
• If there are no rules in the Activate event node, then event conditions will be evaluated.
Completed event node

The Completed event node follows these parameters:
• Rules within a Completed event node are evaluated when the step has completed.
• All rules within a Completed event node are always evaluated (in order from top to bottom
in the node). Actions associated with rules that evaluate as TRUE will be executed.
6 Ultimus Engine Logic Guide ultimus.com

Late event node
• If the only rules that evaluate as TRUE are rules that have Abort Step or custom actions
associated with them, then these actions will be executed; links associated with the step will
also be followed.
• If any rules evaluate as TRUE that have Evaluate Step, Activate Step, or Abort Incident
actions, then these actions will be executed; links associated with the step will not be
followed.
• If no rules evaluate as TRUE within the Completed event node, event conditions will be
evaluated, then links associated with the step. If no event conditions evaluate as TRUE or no
links exist, an Unruly Event will be generated.
Unruly Events are generated only when Ultimus Director is licensed as part of the Ultimus BPM
environment. If Ultimus Director is not licensed in the Ultimus BPM environment, the incident
will be designated as “stalled” in Ultimus Administrator.
Late event node

The Late event node follows these parameters:
• Rules in a Late event node are evaluated when the step becomes late.
• All rules within a Late event node are always evaluated (in order from top to bottom in the
node). Actions associated with rules that evaluate as TRUE will be executed.
• If no rules within a Late event node evaluate as TRUE, event conditions will be evaluated.
If no event conditions evaluate as TRUE, an Unruly Event will be generated.
environment. If Ultimus Director is not licensed in the Ultimus BPM environment, the task will
be designated as “late” Ultimus Administrator. That is, if a step filter has been created in
Ultimus Administrator to monitor a step, it will be designated as “late” if that step becomes late.
Recipient event node

The Recipient event node follows these parameters:
• Rules in a Recipient event node are evaluated when a step is activated.
• All rules within a Recipient event node are always evaluated (in order from top to bottom
in the node). When the first rule evaluates as TRUE, the recipient for that step will be set to
the value specified by that action; no other rules in the event node will be evaluated.
• If no rules evaluate as TRUE within a Recipient event node, event conditions will be
evaluated. If no event conditions evaluate as TRUE, then the Ultimus engine will check the
step properties to find a recipient. If no recipient is specified for the step, an Unruly Event
will be generated.
will be assigned to SYSTEMUSER in Ultimus Administrator.

Resubmitted event node
Resubmitted event node

The Resubmitted event node follows these parameters:
• Rules within a Resubmitted event node are evaluated when the step has been resubmitted.
• All rules within a Resubmitted event node are always evaluated (in order from top to bottom
also be followed.
followed.
• If no rules evaluate as TRUE within the Resubmitted event node, event conditions will be
evaluated, then links associated with the step. If no event conditions evaluate as TRUE or no
links exist, an Unruly Event will be generated.
Returned event node

The Returned event node follows these parameters:
• Rules within a Returned event node are evaluated when the step has been returned.
• All rules within a Returned event node are always evaluated (in order from top to bottom
also be followed.
followed.
• If no rules evaluate as TRUE within the Returned event node, event conditions will be
evaluated. If no event conditions evaluate as TRUE, the Ultimus engine will follow links
associated for that step. If no links exist, the Ultimus engine will try to determine which was
the previous User step that performed a task; that step will be forced. If the Ultimus engine
cannot determine which User step last performed a task, an Unruly Event will be generated.

Additional logic guidelines
Returned event node
This section outlines additional logic guidelines not specified by event type behavior. These are listed
in no particular order.
• If a step is forced, then it must be activated; any business rules in the Activate event node or the
Activate event conditions table for that step are ignored.
• If a step is “returned to,” it is forced (meaning, any business rules in its Activate event node or
Activate event condition tables are not evaluated).
• If a step is currently in “delay” mode and it is forced by evaluation of another step’s business
rules or event conditions, the step is activated immediately; the delay time is ignored.
• If a Queue step is completed, 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.
• For a Queue step, the completion/extension/delay times apply as soon as the step is assigned to
the queue and are carried forward to the user who withdraws 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 users’s in-box. For example, if the completion plus extension time is three
days and the task sits in the queue for 2.5 days before a user withdraws it from the queue, that
task will become late unless the user completes it in 0.5 days.
• Returning to Step A from any Step B assigns the task to the user who previously performed
Step A.
• Users of a multi-recipient step (such as a department or group) cannot return the step.
• If a step “returns” to a previous step when the previous step(s) is a Junction, Flobot, or Maplet
step, the return “flows-through” (meaning, it goes through the previous step(s)) until it finds a
User step in the return path.
Note: This applies only for normal returns that are implemented by Ultimus engine logic. If
the Return event node or Return event condition table for that step is involved, then
only the actions in the event node/event condition table are taken into account and the
Ultimus engine logic is bypassed.
• 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.
• Any following step of a Begin step in a Maplet or an auto-launched process is not allowed to
return (since the Begin step is completed automatically). Since it is not possible for the Ultimus
engine to determine the type of process, it is up to the process designer to verify that returns in
these conditions are handled according to user requirements.

Returned event node
• If a .NET or Web service call on a step’s Completed event node or Completed event condition
table fails, that step will not fail. Ultimus engine logic will evaluate the next step as determined
by conditional business rules, event conditions, and/or links.
• Steps that come after parallel steps (or tasks performed concurrently) will only activate once all
incoming parallel step links to that step have been completed. This logic applies for the End step
as well. To ensure that all necessary steps have been completed prior to the End step completing,
place a Junction step before the End step, then use business rules or event conditions on the
Junction step to assess whether it is the appropriate time to drive the incident to completion.

2
Logic scenarios
This chapter outlines logic scenarios using the Ultimus engine logic guidelines discussed in Chapter 1,
Ultimus engine logic guidelines.
The process map shown in Figure 1 is used to illustrate how Ultimus engine logic operates in a simple
process. The sequence of these steps is being determined at run-time by the Ultimus engine while
evaluating the logic that has been assigned to each step at design-time through Ultimus Director business
rules.
Figure 1. Simple process map to demonstrate Ultimus engine logic functionality
This sample process map will be used to demonstrate Ultimus engine logic functionality in five
scenarios. In each of these scenarios, an illustration will depict the workflow path of scenario incident
due to the assumed conditions of each scenario. Then a brief description outlining how the Ultimus
engine evaluated these conditions based on Ultimus engine logic.
Each of these scenarios are outlined below.

Logic scenarios
Scenario 1: Step 2 and Step 4 are skipped
Scenario 1: Step 2 and Step 4 are skipped
In the first scenario, conditions in this incident cause Step 2 and Step 4 to be skipped. The heavy lines
in Figure 2 represent the workflow path in this process using Ultimus engine logic.
Figure 2. Workflow path of Scenario 1
Below is a short description of how the Ultimus engine logic determined the workflow path for this
scenario:
1. Initially, all steps in the process are in an undetermined state.
2. When the Begin step is initiated, any rules in the Activate event nodes of Step 2, Step 3, and Step
4 are evaluated.
3. Evaluation of the conditional logic causes Step 2 and Step 4 to be skipped (as the scenario
assumes), and the workflow moves to Step 3 for evaluation.
4. 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.
5. When Step 3 is completed, Step 6 and Step 7 are evaluated, then Step 6 becomes active. This is
because the Ultimus engine is evaluating Step 6 as the preceding step for Step 7 (which is still
active).
6. When Step 6 is completed, Step 7 is evaluated, then becomes active.
7. Step 7 completes. Workflow is routed to the End step.

Logic scenarios
Scenario 2: Step 4 is skipped; Step 2 and Step 5 complete before Step 3
Scenario 2: Step 4 is skipped; Step 2 and Step 5 complete before Step 3
The second scenario demonstrates that the Ultimus engine logic is not time sensitive. In this scenario,
conditions in this incident cause Step 4 to be skipped. Furthermore, Step 2 and Step 5 complete before
Step 3. The heavy lines in Figure 3 represent the workflow path in this process using Ultimus engine
logic.
scenario:
2. Begin step completes to cause both Step 2 and Step 3 to become active. Step 4 is skipped (as is
assumed in this scenario).
3. Step 6 is not skipped because Step 3 is active.
4. Step 2 and Step 5 complete (as per the assumptions in this scenario), then evaluates Step 7 before
Step 3 is completed (which is also part of the scenario).
5. When Step 3 is completed, Step 6 is evaluated, then becomes active.
6. When Step 6 is completed, Step 7 is evaluated again. It is only now that Step 7 becomes active.
This is because Step 7 can only activate once it can be determined the final event status of Step 6.
Because Step 3, Step 5 and Step 6 are parallel tasks (tasks which take place concurrently), Step 7
cannot be activated until all immediate steps preceding it have either been skipped or completed.
7. Once Step 7 completes, workflow is routed to the End step.

Logic scenarios
Scenario 3: Step 3 is skipped; Step 5 completes before Step 4
Scenario 3: Step 3 is skipped; Step 5 completes before Step 4
The third scenario demonstrates the relative time of the completion of steps does not affect Ultimus
engine logic in workflow routing. In this scenario, conditions in this incident cause Step 3 to be skipped.
Furthermore, Step 5 completes before Step 4. The heavy lines in Figure 4 represent the workflow path
in this process using Ultimus engine logic.
scenario:
2. Begin step is completed, then activates Step 2 and Step 4. Step 3 is skipped (as assumed in this
scenario).
3. Step 2 completes, then activates Step 5. Step 4 is not yet completed (as assumed in this scenario).
4. Step 5 completes.
5. Step 4 eventually completes. Step 6 is then evaluated, then activated.
6. When Step 6 completes, Step 7 is evaluated, then becomes active. Step 7 could not become active
after Step 5 completed, because Step 7’s activation depends on the event status of Step 5 and
Step 6.

Logic scenarios
Scenario 4: Step 6 is skipped after Step 5 is completed
Scenario 4: Step 6 is skipped after Step 5 is completed
In this scenario, conditions in this incident cause Step 6 to be skipped, but only after Step 5 is completed.
The heavy lines in Figure 5 represent the workflow path in this process using Ultimus engine logic.
scenario:
2. Begin step completes, then activates Step 2, Step 3, and Step 4.
3. Step 2 completes its task first. Step 5 is evaluated, then activated.
4. Step 5 completes while Step 3 and Step 4 are still active.
5. Step 7 is evaluated, but does not activate. Step 7’s activation depends on the event status of Step
3, Step 5, and Step 6. At this time, Step 6 has not been evaluated, and Step 3 and Step 4 are still
active.
6. Step 3 completes. This causes Step 6 to be evaluated, then skipped (as assumed by the scenario).
7. Step 4 completes. This again causes Step 6 to be evaluated, then skipped (as assumed by the
scenario).
8. The skipping of Step 6 allows Step 7 to be evaluated again. Now that the event status of its
preceding steps are known, Step 7 will become active.

Logic scenarios
Scenario 5: Step 6 is skipped before Step 5 is completed
Scenario 5: Step 6 is skipped before Step 5 is completed
In this scenario, conditions in this incident cause Step 6 to be skipped, but before Step 5 is completed.
The heavy lines in Figure 6 represent the workflow path in this process using Ultimus engine logic.
scenario:
2. Begin step completes, then activates Step 2, Step 3, and Step 4.
3. Step 4 completes its task while Step 2 and Step 3 are still active.
4. Step 4 does not submit its task to Step 6, resulting Step 6 to be skipped (as assumed in this
scenario).
5. Step 3 completes. Step 3 does not submit its task to Step 6, resulting in Step 6 to be skipped again
(as assumed in this scenario). Step 7 is evaluated, but cannot be activated because Step 5 remains
in an undetermined state.
6. Step 2 completes. Step 5 is evaluated, then activated.
7. Step 5 completes. Step 7 is evaluated again, then activates.

Ultimus Engine Logic Guide: For Ultimus BPM Suite 7.1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ultimus Engine Logic Guide: For Ultimus BPM Suite 7.1

Uploaded by

Copyright:

Available Formats

Ultimus Engine Logic Guide

for Ultimus BPM Suite 7.1

Ultimus Engine Logic Guide

ultimus.com 1 Ultimus Engine Logic Guide

ultimus.com 2 Ultimus Engine Logic Guide

Conventions used in this document

The following conventions are used throughout this document:

» This icon denotes a tip, which alerts you to advisory information.

This icon denotes a note, which alerts you to important information.

Overview of this document

The Ultimus Engine Logic Guide consists of the following chapters:

ultimus.com Ultimus Engine Logic Guide 3

Terminology used in the Ultimus Engine Logic Guide

ultimus.com 4 Ultimus Engine Logic Guide

Basic logic rules

Event node parameters

ultimus.com Ultimus Engine Logic Guide 5

• Resubmitted: A resubmitted event represents when a step is resubmitted. The Resubmit

Activate event node

Completed event node

6 Ultimus Engine Logic Guide ultimus.com

Late event node

Recipient event node

ultimus.com Ultimus Engine Logic Guide 7

Resubmitted event node

Returned event node

8 Ultimus Engine Logic Guide ultimus.com

Additional logic guidelines

ultimus.com Ultimus Engine Logic Guide 9

10 Ultimus Engine Logic Guide ultimus.com

Figure 1. Simple process map to demonstrate Ultimus engine logic functionality

ultimus.com 11 Ultimus Engine Logic Guide

Scenario 1: Step 2 and Step 4 are skipped

Figure 2. Workflow path of Scenario 1

12 Ultimus Engine Logic Guide ultimus.com

Scenario 2: Step 4 is skipped; Step 2 and Step 5 complete before Step 3

Figure 3. Workflow path of Scenario 2

ultimus.com Ultimus Engine Logic Guide 13

Scenario 3: Step 3 is skipped; Step 5 completes before Step 4

Figure 4. Workflow path of Scenario 3

14 Ultimus Engine Logic Guide ultimus.com

Scenario 4: Step 6 is skipped after Step 5 is completed

Figure 5. Workflow path of Scenario 4

ultimus.com Ultimus Engine Logic Guide 15

9. Once Step 7 completes, workflow is routed to the End step.

Scenario 5: Step 6 is skipped before Step 5 is completed

Figure 6. Workflow path of Scenario 5

16 Ultimus Engine Logic Guide ultimus.com

You might also like