Skip to Content

Run the Next Operations Conditionally Using Operation Chains

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.

Note

This design pattern uses Design Studio as an example; you may apply the same concepts in Cloud Studio using similar steps.

Example 1

attachment

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

attachment

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.

attachment

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

attachment

A condition node is used to evaluate each incoming record.

attachment

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

attachment

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

attachment

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

attachment

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.

attachment

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:

attachment

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

attachment

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.

attachment

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

attachment

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.

attachment

Note that 'no response' is selected.