Branch shape

Introduction

The branch shape allows you to add shapes to multiple, distinct paths in a process flow, which are executed sequentially. Paths are executed one at a time, in the configured sequence, using the same incoming payload.

For complex scenarios, branching allows you to split the logic in your flow, making it easier to build, understand, and manage. For example, a common scenario for syncing orders between two systems is to:

[1] Pull orders from the source system [2] Check if the customer record exists in the destination system [3] If not, create it [4] Check if the address exists in the destination system [5] If not, create it [6] Decrement stock record in the destination system [7] Send order info to the destination system

This can all be achieved using one long process flow; however, the branch shape provides the ability to organise the steps logically. So:

• Branch 1 creates/updates customer records

• Branch 2 creates/updates address records

• Branch 3 updates stock records

• Branch 4 sends the orders to a warehouse system

A single incoming payload for any process flow shape should not exceed 500MB.

We recommend processing multiple, smaller payloads rather than one single payload (1000 x 0.5MB payloads are more efficient than 1 x 500MB payload!).

For payloads up to 500MB, consider adding a flow control shape to batch data into multiple, smaller payloads. Payloads exceeding 500MB should be batched at source.

Need to know

• By default, the same data - i.e. any payloads that the branch shape receives - flow down every branch. For more information, see How data flows through a branch shape.

• All steps in a branch must be completed before the next branch starts.

• If one branch fails, any subsequent branches will not start.

• Nested branch shapes are permitted - so you can have a branch shape within a branch.

• If a branch includes a run process flow shape, the required sub-flow is triggered immediately, and subsequent branch steps continue. The branch shape does NOT wait for the sub-flow to complete.

• If a branch includes a try/catch shape, the catch steps are processed at the end of the flow, not at the end of the branch.

• A branch shape should never include a route shape. Instead, use filter shapes to achieve the same result - for example:

• There is no limit on the number of branches that can be added for a branch shape.

How data flows through a branch shape

By default, any payload that a branch shape receives passes through each branch, sequentially. Consider the example below:

Here, the branch shape receives five payloads from the preceding flow control shape. First, these five payloads are processed by branch 1, then the same five payloads are processed by branch 2, followed by branch 3.

However, what if we wanted to pass data from one branch to another? For example, suppose that branch 1 includes a series of steps to prepare data for onward processing in branches 2, 3, and 4. For example:

In this case, we can add branch 1 data to a cache, and then either:

• Load cached data in any subsequent branches using a load from cache shape

• Reference cached data in any subsequent branches using a cache lookup transform

Loading branch data from a cache

If you use the add to cache shape in a branch, the cached data can be loaded later in the same branch and/or in subsequent branches. Placing a load from cache shape at the very start of a branch results in the cached data being loaded into the branch and processed by subsequent shapes - i.e. this branch does NOT process the data received by the parent branch shape.

In the example below, branch 1 prepares and filters five incoming payloads. At the end of this branch, one payload is filtered out, and four payloads are cached. At the start of branch 2, we load the cached data (four payloads) and these are processed by all subsequent shapes in this branch. Next, branch 3 and branch 4 do not load cached data, so these go on to process the original incoming payloads.

Referencing branch data from a cache

You can use the cache lookup transform function to map field values from an existing cache. In this scenario, we aren't loading the cached data into the branch for onward processing - data coming through will be payloads that the parent branch shape received. This is show in the example below:

Adding a branch shape

1

Add a branch shape

In your process flow, add the branch shape in the usual way:

The shape is added to your flow with two path stubs - for example:

2

Configure branches

Click the settings icon for the branch shape:

Branch names are shown for the two placeholders:

...you can change these names as appropriate - for example:

...and add more branches if needed:

Having added new branches, the branch shape must be saved before they can be re-sequenced. Save the shape, and then return to settings to resequence the new branches.

3

Save changes

Once all branches have been added, save changes:

The branch shape is updated, and you'll see a placeholder stub for each branch you added in the previous step:

4

Build branches

Now you can add shapes to each branch in the normal way. As soon as you add your first shape to a branch, empty shapes are added to the others - for example:

Click on these placeholders to replace them with the required shape from the shapes palette:

Nested branch shapes are allowed - so if required, you can have a branch shape within a branch:

There are no limitations on the number of nested levels; however, nesting too deeply will have an impact on flow clarity.

Managing branches

Having added branches to a branch shape, you may wish to:

• Rename a branch

• Re-sequence a branch

• Delete a branch

These tasks are completed from branch shape settings:

Renaming a branch

You can rename a branch at any time - simply overwrite the existing name and save shape settings:

Re-sequencing branches

Before re-sequencing branches, ensure that any new branches have been saved (save the shape and re-access shape settings). Then it's just a matter of using up/down arrows to move branches to the right place:

Deleting a branch

When a branch is deleted, it's removed entirely - any shapes currently defined in its path are also removed. To delete a branch, click the associated delete button:

Managing branch paths

Shapes are added to branch paths in the normal way - add shapes from the shapes palette and configure them as needed.

If you remove the only shape in a branch path, the empty branch 'stub' remains in place, so sequencing doesn't change. If you don't need the branch anymore, access branch shape settings and remove it.