Variable Scope is a term used to explain the “lifetime” of a variable. There are three formal variable scopes within Jitterbit – local, custom global and cached. (The custom global distinction is to set apart from Jitterbit’s pre-defined variables.) Below, we discuss each. You are using local variables when possible to minimize global variables within Jitterbit. Remember, all Jitterbit variable names are case-insensitive.

Local

Local variables imply they exist (their lifetime) only within a Jitterbit Script or Transformation field map. They are used only within individual Scripts or a Transformation field map and should be used to reduce global variables (an important best practice!). They are many times distinguished from a global variable by the name “not beginning with a dollar-sign ($).” (Although one can also read/write global variables using Get()/Set() without using a dollar-sign). More on global variables below.

I like to use a naming convention for Script input parameters. Local variables such as _1, _2 and others are the Script input parameters. Today, Scripts accept only strings as parameters and can only return one linear sequence of characters (a string!) as a result. I like to keep the leading underscore and use ArgumentList() to reassign to more useful names.

For example, if the script parameters are _1 (a name line) and _2 (an age integer), I assign it to a local variable, at the start of the script. I use IfEmpty() or ArgumentList(_name, _age) so I know these are script input parameters and their purpose.

Many times, I like to send “optional” parameters to Scripts. In this case, rather than using ArgumentList(), I will reassign each with a default using IfEmpty(). For example,

_name=IfEmpty(_1,"UNAVAILABLE");
_age=IfEmpty(_2,0);

Global

You want to cut your use of Global variables as you would in any programming environment. One could argue that data integration is unique in that there are good reasons for using Global variables. Often you have no choice, but striving to cut Global variables is the best practice.

One instrumental value of Global variables is when entering Component Definition field values. In most cases, one can enter a Global variable in the following format for various field values. (There are exceptions, so confirmation is necessary)

[gvarName{defaultVal}] where gvarname is the global variable name (without the $ sign). An optional default value (defaultVal) is within the braces ({}). For example, along with an Email Text, the Email subject line could vary depending upon the message content. One can use the square-bracket format for Email fields such as To, From, Subject and Text.

In this context, Jitterbit ignores any leading dollar-sign but, one can keep the dollar-sign for a particular variable containing SQL or Salesforce SOQL statements. They appear in the Formula Builder with the leading $ if used. Not sure this is an intentional feature, but it does call-out this unique global variable use in the Formula Builder Data Elements tab.

Cached

Global variables exist for the execution lifetime of an Operation. Values are available to read or change in any chained or called Operations. There is a third type of variable whose values exist beyond an Operation execution time but are accessed uniquely. Known as “cached” variables, these variables need the ReadCache() and WriteCache() functions to use. These cached variable values persist between executions and can persist within Jitterbit environments or projects. Their values expire after a specified number of seconds. For example, a cached variable might hold the last execution time of an Operation as this might be useful to an endpoint polling query.

Review Variable Types or Continue with Variable Purpose or Intention