Skip to Content

Process template best practices

Introduction

This page provides best practice guidance and recommendations for designing Cloud 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

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:

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:

Component Pattern Example
Project <action> + <endpoint> + <object> to <endpoint> + <object> Sync Salesforce Contacts to SAP Contacts
Operation <action> + <endpoint> + <object> Get Salesforce Contacts
Endpoint <endpoint> Salesforce
Endpoint Activity <action> + <object> Upsert Contacts
Transformation <action> + <object> + Request/Response Upsert Salesforce Contacts Request
Script <action> + <object> Send Error Email
Project Variables <endpoint>_<element> Salesforce_Security_Token
Global Variables Use camel case errorMessage

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

Note

Ensure there are no spelling errors when naming projects and their components.

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.