Run the next operations conditionally using operation chains in Jitterbit Design Studio

Use case

A common integration design objective is to activate operation flows based on a condition. The most common is to perform an operation and, if successful, perform a second one, and so on. Jitterbit supports this very easily, since operations can be linked together using an On Success path (as well as an On Failure path). But frequently, an operation should be called based on a data value, such as a result that is true or false or based on a returned value from a query.

Example 1

The 'On Success' Path is shown between the 020 Query Items operation and the 021 NetSuite Upsert NonInventorySalesItem operation.

The Conditional Path is between the 020 operation and Update Jitterbit Syncs. In this case, a post-operation script calls another operation. It is conditional in the sense that it will not execute if the 020 query fails, and also executes after the operation has finished, but before it runs the 021 operation.

In this example, a query is executed and depending on the values, two other operations are executed.

A condition node is used to evaluate each incoming record.

A script is called, and source values are passed to it.

ArgumentList is used to assign the incoming values to local variables and check if they apply in the Case statement

Returning control back to the condition, if "Error" is passed back, then an operation is invoked, otherwise it is skipped. Back to the transformation ...

There is also another operation call that is embedded within RTS_Status. Note that Jitterbit executes formula builder scripts from the top down, so this script is executed last.

Here the RunOperation is called to capture a status in the target system.

Example 2

A different example shows using a script to organize the operation flows:

You can see that there is a mix-n-match pattern. A series of operations are called that, in turn, call other operations.

The script only calls four operations. Note that RunOperation(), by default, will execute synchronously. That is, it will wait for the operation (and all its chained operations) to finish before executing the next one. The other option is to execute asynchronously.

This orchestration involves the Jitterbit API Platform being called by an external web service, and inserting data into SFDC.

The script launches the operation asynchronously ("false"). This is done so that the web service response is as fast as possible, since this is a high-volume data flow. Otherwise the response has to wait for the salesforce insert, which would take too long.

Note that 'no response' is selected.