SDA: Understanding process JOINs

0 Likes
SDA: Understanding process JOIN
SDA utilizes a graph-based system to represent the steps in a deployment process.  This allows the creation of some complex deployments with a drag and drop interface.  Within a process, there are times when we must connect one process step to another.  These connections are represented within the graphical tool with a directional flow (or an arrow).  Whenever a process step has 2 or more inbound connections, we have created a join.   To be effective at process development, we need to understand the implications of several types of join operations.  We may need to understand when the process step will run, if the step will run when some inputs (or inbound connections) are missing, or if the status (success or failure) of an inbound connection will have any effect on whether the step will run?
Some Definitions
In the following descriptions, a connection is invalid if the parent step runs but the outbound connection is not used.  Therefore any process step that succeeds, the outbound connections marked with the green check or the grey circle for both are valid.  If the step succeeds only outbound connections marked with the red check mark will be invalid.
Further, a connection is not needed if the parent step does not run.  In the following example, let’s assume that the tomcat version installed on this resource is tomcat 8.  The first step depicted, is the switch set to check the version.  After this, the flow followed would be down the left-hand side of the graph.  The center and right-hand outbound connections from the Switch are now Invalid.  This is because the parent step executed, but the connection is not followed.  Further down, the outbound step from “Check Tomcat 7 Online” is not needed.  The parent step was not executed, therefore the remainder of this execution path is not needed.

Types of Joins
Explicit
In the case of an Explicit join, the process step named Join is utilized.  All inbound connection paths must be valid.  In the example below, the Join will only be executed in cases when the “Check Win or Unux” switch step resolves to “Win”.  In all other cases, the outbound connection from that process step is not valid and therefore, the join will fail and no further execution along that path will be undertaken.  Also the process steps “Check Free Diskspace” and “Check Privs” must also have a SUCCESS status as written in order for the Join to execute and continue execution.

The Join step may also accept inbound connections of fail status so long as the appropriate connection is marked with the fail or both conditional flag (meaning instead of the green check mark, it has a red mark or a grey open circle).
Implicit Joins
An implicit join can be made with any process step that is not a join.  The implicit join occurs whenever a process step has more than one inbound connection.  The process step with the implicit join will not execute until all input connections can be evaluated as to status and validity.  A process step with an implicit join will execute if the following are true: 
  • All inbound connections are valid (invalid connections will cause the join to fail, not needed connections are acceptable).
  • The status from the previous step on the connection must match the flag on the connection.  Therefore, a connection with a green check mark must have a status of success.  A connection with a status of failure will match a red mark or a grey “both” circle on the connection diagram.

Labels:

How To-Best Practice
Comment List
Anonymous
Related Discussions
Recommended