Process template best practices¶

Introduction¶

This page provides best practice guidance and recommendations for designing Integration Studio process templates to be uploaded to Jitterbit Marketplace. This document is not comprehensive and does not cover all scenarios.

For general best practices, see Jitterbit iPaaS best practices.

Best practices¶

The following sections provide an overview of process template best practices:

• Projects
• Operations
• Scripts
• Project and Component Naming
• Process Template Structure

Projects¶

These are general guidelines for projects:

• Use project variables for values that change from user to user, such as usernames and passwords. In addition, when creating project variables, it is a best practice to prefix project variables so that they are easy to look up. For example, a project variable org_netsuite_auth_username is first prefixed with org, then netsuite, etc. to effectively organize it in a list among other project variables.

• Delete unused components from the project.

• Remove any auto-generated -Copy suffixes from project components and rename them logically.

Operations¶

These are general guidelines for operations:

• Use an application connector over the HTTP or HTTP v2 connectors when possible.

• Configure all operations for error handling. For error handling best practices, see the Error Handling Best Practices Tech Talk.

Scripts¶

These are general guidelines for scripts:

• Use out-of-box features instead of scripts wherever possible.

• Avoid calling operations within scripts.

• Avoid calling operations or including scripting logic within transformations.

Project and component naming¶

These are the recommendations on naming projects and their components:

In addition, the project name, description, and workflow should have matching names.

Process template structure¶

The following structure describes how each operation should function within a workflow’s operation chain:

• Operation 1: The first operation is used to configure common variables for the logging of information, such as success count, failure count, success summary, and file names. Using common variables, you can write the success and failure files and print a summary log containing the values the variables are set to. Once these are set up, you can configure an email notification that delivers this information to the recipient you define.

• Operation 2: The second operation retrieves data from the source endpoint.

• Operation 3: When a connector doesn’t support pagination, the third operation is used to paginate the data for target endpoints that support only a limited number of records.

• Operation 4: The fourth operation implements the remaining logic required to perform an action on the target endpoint.

• Operation 5: The final operation is configured to send a single email notification that delivers a compilation of error messages (from any of the operations) to the recipient you define.