Reuse endpoints and scripts in Jitterbit Integration Studio
Introduction
Reusability can be incorporated into the design of an Integration Studio project by using a starter project, reusing endpoints, and reusing scripts.
Starter project
A typical scenario for reusing a project involves the development of a starter project with the extensive use of global variables and — especially — project variables.
Configurable items — such as endpoint credentials, optional field mappings, parameterized queries, email addresses, and filenames — can be exposed as project variables.
The starter project can also contain common functions such as error handling or the use of environment-wide caches.
The starter project is exported and then imported into new projects to form a consistent basis for development.
Endpoint reuse
Endpoints, created by configuring a connection and associated activities using connectors, are frequently used in operations. However, a unique endpoint doesn't necessarily need to be built for each operation. Since activity configurations accept variables for paths and filenames, generic endpoints can be built one time and then dynamically configured using global and project variables.
For example, assume an HTTP connection and an associated activity are created, and the activity configuration specifies a path defined by a global variable, such as $gv_http_path
. A controller script can be used to populate the $gv_http_path
as required.
Another example is a Database Query activity with a condition. Its WHERE
condition can be assigned to a global variable, such as $gv_database_condition
.
Most endpoints have the capability to be configured using variables.
Script reuse
Stand-alone scripts that perform a specific function, such as returning a database lookup or calculating a result from a series of arguments, can be candidates for reuse, particularly if used in multiple operations.
For example, if a script uses the DBLookup
function against a database table, and this function is used throughout the project, then a stand-alone script (separate from an operation) can be built. Using the ArgumentList
function or simple global variables, the script can accept arguments and return a result. Since every operation chain is a different scope, the same script can safely be called from multiple simultaneous operations.