Understanding Flow Patterns for Orchestration Jobs

Sequence is a basic usage pattern. A process is executed. When that execution is complete, the second process executes. Then, the job is complete.

Typically, you sequence processes when one process has a dependency on another. For example, one of the processes could consume data that the other produces. In the diagram, the lower process has a dependency on the upper process.

In the decision pattern, Process 1 executes. Then, a decision occurs (possibly related to the outcome of Process 1) and either Process 2 or Process 3 executes before the job completes.

In the repetition pattern, multiple processes are connected in a repetitive fashion. In the first repetition pattern, Process 1 executes, followed by Process 2. Execution then returns to Process 1 and continues indefinitely,

In the second repetition pattern, Process 1 executes, followed by Process 2. After a decision is made, execution either returns to Process 1 or continues to Process 3, In this case, the job ends after Process 3 finishes.

Processes that execute sequentially might have dependencies, as mentioned in Sequence Pattern. Process 3 depends on both Process 1 and Process 2. Therefore, it is sequenced after them. The dotted lines indicate a dependency. Process 1 and Process 2 need to be in a complete state before Process 3 can successfully execute. Ensure that these dependencies are correct so that you can handle looping situations when you cannot determine dependencies.

In this case, the iterator is set to iterate n times after Process 1 executes. Then, Process 2 is entered. After it completes, the iterator is incremented and checked against the threshold. If the threshold is not reached, Process 2 executes again. If the threshold is reached, Process 3 is entered.

In this pattern, Process 1 generates a set of data rows. The iterator depends on this data set. Therefore, it depends on Process 1. When the iterator is entered, it fetches the first row and stores its value as an output value of itself. Process 2 then executes. Typically, process 2 references this output value and uses it as a parameter for some action. When the process has finished, the iterator is entered again, and another row is fetched. If no more rows exist, Process 3 is entered.

This pattern is similar to the basic iteration pattern. After Process 2 completes, a new iterator is entered, which executes Process 3 n times. When complete, it exits and returns to the first iterator to continue. Finally, it executes Process 4 when that is complete.

In this pattern, either Process 2 or Process 3 is entered after a decision is made. Following that, Process 4 is always entered and the job completes.

Process 1 and “wait for event” both start executing. (See Implicit Fork or Join Pattern). Wait for event does not exit until it receives an event, which could come from inside the job or through an external factor. When the event is received, it exits, and the Process 3 runs. The job is complete when both Process 2 and Process 3 are complete or a terminate event is received by the job.

In this pattern, a job waits for some event such as a file appearing in a directory. Then, the job executes Process 3, which might take some action on that file. After Process 3 runs, control loops back to wait for event. This sequence happens indefinitely until the job is terminated.

In this pattern, Process 1 executes. Two execution contexts now exist at the fork, and Process 2 and Process 3 run simultaneously (as long as multiple threads are allocated for the job). When join is entered, it waits for both execution contexts to enter. Process 4 is then entered. Fork and join are implemented as a single node fork that has child nodes (Process 2 and Process 3). There is no join node in the implementation

In this pattern, Process 1 executes and creates a data set that indicates partitions such as a list of country codes. The fork loop has a parameter indicating number of threads. When it is entered, it creates n instances of the fork (in this case Process 2). It then begins iterating over the data set and handing each entry as a parameter to the next available thread. The thread executes Process 2. When finished, it returns to the fork for the next row in the data set (as a parameter). In this case, n instances of Process 2 execute simultaneously. When the data set is expended and all the threads are done, Process 4 is entered. Fork loop and join are implemented as a single fork loop node (with no join node). The fork loop node’s child in this case would be Process 2.

In this pattern, Process 3 is allowed to depend on Process 1. For example, Process 1 could produce data that Process 3 consumes. Also, Process 3 could depend on Process 2 (Process 2 produces data that Process 3 consumes). Similarly, Process 2b could depend on Process 1, and Process 4 could depend on Process 1. Finally, Process 4 could also depend on Process 2, Process 2b, and Process 3.

In this pattern, an implicit fork is created above Process 1 and Process 2. An implicit join is created below Process 1b and Process 2. All fork and join rules apply.

In this pattern, Process 1 can depend on Process 1b and the reverse can also be true. You must ensure that the job runs as desired. If a dependency on another node is not found, you can reconfigure in a number of ways.

In this unsupported pattern, Process 2b cannot depend on Process 2 because the two processes are in the branches of different forks.

In this unsupported pattern, Process 4 could not depend on process 3 because multiple instances of Process 3 would have run, and there is no way to reference which one. However, Process 4 could depend on Process 1.

In this unsupported pattern, Process 2 cannot enter Process 3 because Process 3 is on a different fork. (It follows Process 2.) Also, Process 2 cannot enter Process 4 because it is outside the fork or join.