Advanced Joining Techniques in Urbancode Deploy
One of IBM Urbancode Deploy’s most popular features is its graph-based process design system. It provides the user the means to create complex deployments with a simple drag-and-drop interface. However, as with any powerful tool, it comes with it’s own complexities – and joining multiple steps to a single step is one of the least-understood aspects of Urbancode Deploy’s design UI. If a step is being joined upon, when will it run, or be ignored? This guide will attempt to address these questions in detail.
This information is provided for the purpose of not only giving process designers the know-how for creating more versatile process designs, but also so that the designer may avoid unintended behavior.
First, a few quick notes:
- This document is intended for users of Urbancode Deploy 6.0.1 and up. Earlier versions of Deploy may present unpredictable behavior. If you have need to create a complexly-joined process in early versions, I suggest you exclusively use the Explicit-And type of join (described below).
- It’s difficult to graphically represent how a running process is behaving, so examples provided in this document describe a step’s behavior in its name. For example, you may assume a step named “Always Succeed” can be depended on to always complete successfully.
- Finally, this document assumes the user is familiar with basic process design concepts such as steps, edges, and conditional flags. Please consult Urbancode Deploy’s documentation for more on that subject.
While a process is running, an edge is assigned a special status which is based on a combination of its parent step’s outcome and its conditional flag. These statuses are:
Valid – An edge is Valid if it should be followed. For example, if a Success Edge’s parent step succeeds, or if a Failure Edge’s parent step fails. Example:
Invalid – An edge is Invalid if its parent step runs, but the edge should not be followed. For example, if a Success Edge’s parent step fails, or if a Failure Edge’s parent step Succeeds. An Always Edge will never receive this status.
Not Needed – An edge is marked as “Not Needed” if, and only if, its parent step does not run. This can occur in special situations, such as when using a Switch step. Note that the Both Edge can still receive this status.
In this example, the edge leading from “Will Run” to “Child A” can result to Valid or Invalid, as described above. On the other hand, the edge leading from “Never Runs” to “Child B” receives the status of “Not Needed”.
There are three different types of joins implemented by the system. They are called: Explicit-And, Implicit-And, and Implicit-Or. In all three cases, the step being joined upon will wait for each of its parents to completely resolve (and therefore assign their outgoing edges a status enumerated above), and then decide whether or not if it should run.
This case occurs when multiple edges converge upon a Join step. The Join step will only succeed if all incoming edges resolve as VALID. If a single edge is Invalid, or even Not Needed, the Join step will fail.
Exhibit A: In the following example, the Joins step fails. The edges going out of “Always Succeed” and “Always Fail” are marked as Valid; however, the edge coming out of the “Never Runs” step (which coincidentally never runs) would be marked as Not Needed. Since the Explicit-And scenario requires all edges to be marked as Valid, the Join step fails.
Exhibit B: This is similar to Exhibit A, but the center step is guaranteed to run. Its edge uses a “Both” conditional flag, which means it is marked as Valid no matter the outcome. The Join step succeeds.
This case occurs when multiple edges with the Success or Both conditional flags converge upon any step that is not a Join step. If any single incoming edge has a Failure conditional flag, then you have an Implicit-Or scenario (see below). In Implicit-And, the step will run as long as no edges are resolved as Invalid. Unlike the Explicit-And case, edges resolved as Not Needed are acceptable.
Exhibit C: Here, the status of the edges, from left to right, are: Valid, Not Needed. There are no Invalid edges, so the join is successful and the process continues.
Exhibit D: In this example, the status of the edges are (from left to right): Valid, Not Needed, and Invalid. The presence of the Invalid edge will cause the join to fail.
This case occurs when at least one incoming edge is a Failure edge, and the edges converge upon a step that is not a Join step. In this case, the step will run if we have at least one Valid edge. This means some incoming edges may actually resolve to Invalid, and the step will still run.
Exhibit E: The statuses of the edges in this example, from left to right, are: Invalid, Valid. However, the presence of the edge with the “Failure” conditional flag causes an Implicit-Or scenario. Therefore, having a single “Valid” edge is all that is required. The join succeeds, and the process continues.