Joins and Junctions in Workflows

Overview

Joins and Junctions are system utilities that serve to process multiple branches of a workflow. Each usage scenario is very different and largely depends on how your workflow is designed and what business rules and processes you need to support.

Basic Workflow Engine Concepts

Here are a few basic concepts of the workflow engine. If you are already familiar with basic concepts, feel free to skip to the next section.

• The Task Engine processes workflow as a Task Tree or Routine.
• Each workflow represents a process by modeling it with a tree or branching structure.
• Workflows consist of nodes and connectors.
• A node represents an independent piece of code that processes data.
• A connector links the nodes together, allowing logic and qualifications to determine processing.

When the task engine is asked to process a workflow, it follows the path(s) of connectors and process nodes.

Join and Junction Concepts

With a basic understanding of workflow processing, now we can talk about Joins and Junction. Even a simple workflow can include multiple branches. Joins and Junctions let you bring the process back to a single branch. You also have the option to determine when that branch progresses.

Even though the workflow contains a deferred node (order product) and a branch to three nodes, it doesn't need a join or junction to bring branches back together.

In this workflow, you can see that three tasks process simultaneously, but only one operating system should be installed on the server. The join node must restrict processing based on rules (one operating system per server).

Joins

A Join node deals directly with the connectors that lead into it. As soon as the first connector reaches the Join, the Task Engine calculates whether it should complete the Join node and continue the tree or if it needs to wait for more connectors. The property that determines if the Task engine waits or not is the Type setting on the Join.

These are the options for Type:

• All. Every connector leading into the join must process before the join completes and then processing continues farther down the workflow.
• Any. As soon as one connector leading into the Join processes, the Join node completes and processing continues down the workflow.
• Some. When you select Some, you must also add a number to signify how many connectors it takes to process before the Join node completes and the process continues

As soon as any one of the connectors make it to the Join node, it will complete and continue processing.

Junctions

The difference between a Join and Junction is how far back up the workflow each utility looks to determine if it should be complete. A join only looks at the connectors that directly connect to it. A Junction looks back at each branch that connects to it, back to a common parent.

As you can see from the screenshot, a Junction node has no parameters to set. It relies entirely on evaluating the branches that lead into it.

In this case, all the branches that eventually lead to the Junction node start at the "select new employee software" node. The branch on the far right completes automatically (no qualifications on the connector and not a deferred node), but the junction will still evaluate the other branches to see if they are as complete as possible.

"Complete as possible" means that the Task Engine is not waiting for a deferred node to complete, and all connector qualifications on the branch (that can be evaluated) are evaluated.

In the above example, if the connector qualifications for all three branches are evaluated to false, the Junction node considers those branches complete and continues processing down the tree. The paths do not have to successfully reach the Junction by evaluating to true.

It can also be the case that the Junction will wait for a deferred node for as long as it takes. Be cautious about what processes you place on the branches leading to a junction.