Cloud Studio Process Templates¶
Cloud Studio process templates, available through Jitterbit Marketplace, are pre-built integration use cases that execute a specific business process using objects across multiple applications or systems.
A process template consists of one or more projects using multiple endpoints. It may include customization files and comes with its own documentation in PDF format.
Before exporting a Cloud Studio project, review the project carefully and ensure that no information is left in it that should not be there. Inspect all password fields for their values. Check any schemas used in transformation mappings for the presence of confidential or personally identifiable information (PII) or protected health information (PHI).
Once a project has been exported, search the exported JSON file to confirm that there is no information that you would not want to be disclosed, such as email addresses. Extra metadata may be present in projects that were created and exported from earlier versions of Cloud Studio.
For each process template, these items are required for submission:
One or more exported Jitterbit Harmony Cloud Studio projects required for the process template.
A metadata manifest file in YAML format describing the process template and providing the details that are used at Jitterbit Marketplace when the template is displayed. The name of the manifest file is to be the same name as the process template with the extension
A PDF file documenting the process template, its configuration, its operation, and information necessary to use the process template. This file will be listed in the
DOCUMENTATIONentry in the manifest.
Any customization files that are required for the configuration of the process template. Though multiple customization files are supported in Marketplace, we recommend for ease of use by all (for you as a developer, for Jitterbit as a service provider, and most importantly for the process template user) that the required customizations be combined into a single ZIP file. An appropriate README file with any instructions should be placed in the archive with the required customizations.
By having a single ZIP file at the Download Customizations step of the initialization of a process template, a user has only one download item to deal with. They can then pass that (with the documentation PDF, described above) to the party charged with configuring the endpoint.
This package will be listed in the
PACKAGESentry in the manifest.
A metadata manifest file, in YAML format, is required to provide details of the process template and its constituents. This example shows the fields required to be completed:
# Process Template Manifest File NAME: Salesforce-NetSuite CPQ-to-Billing Process Template TYPE: template # Description can be multi-line or multi-paragraph # Indent each succeeding line or paragraph DESCRIPTION: This process template automatically process your orders and invoices in Salesforce CPQ and Billing and NetSuite. Synchronizes contacts, products, price books, orders, and invoices between systems. AUTHOR: Jitterbit, Inc. # A list of the projects included in the process template PROJECTS: - Salesforce_NetSuite_Contacts_Accounts_Bidirectional.json - Sync_NetSuite_Inventory-Items_to_Salesforce_Price-Book-Entry.json - Sync_NetSuite_Inventory-Items_to_Salesforce_Products.json - Sync_Salesforce_Invoices_to_NetSuite_Invoices.json - Sync_Salesforce_Orders_to_NetSuite_Sales-Orders.json # A list of all the documents in the process template # Currently, a single PDF is supported DOCUMENTATION: - Jitterbit Salesforce-NetSuite CPQ-to-Billing Process Template.pdf # A list of all the customization packages in the process template PACKAGES: - Salesforce-NetSuite CPQ-to-Billing Process Template Package.zip # Endpoints # Place each endpoint on its own line beginning with a hyphen # in order of source to target ENDPOINTS: - Salesforce - NetSuite # Sources: A list of dictionaries, with each source by name SOURCES: - NAME: NetSuite OBJECTS: - Accounts - Contacts - Customers - Inventory Items - NAME: Salesforce OBJECTS: - Accounts - Contacts - Invoices - Orders # Target: A list of dictionaries, with each target by name TARGETS: - NAME: NetSuite OBJECTS: - Accounts - Customers - Invoices - Sales Orders - NAME: Salesforce OBJECTS: - Contacts - Price Book Entry - Products # Categories # Place each category on a line beginning with a hyphen CATEGORIES: - ERP - Finance - Sales & CRM
The endpoints specified in an integration recipe or a process template are used to filter the assets shown in Marketplace. The list of endpoints shown in Marketplace is not fixed, but is instead built from those used by the assets in Marketplace. We encourage you to use the existing endpoints whenever possible, though you are free to add additional endpoints as required or appropriate.
If you do add new endpoints, be mindful that similar-sounding or stemmed names are not aggregated. To have a collection of distinct assets appear under the same endpoint, they must all use an identical endpoint name. Endpoints are listed in order of the number of assets in each particular endpoint. As the top five endpoints (as determined by the number of assets with that endpoint) are what appears when Marketplace is loaded, additional endpoints are not visible until the user clicks the Show More button.
The categories attached to an integration recipe or a process template are used to filter assets shown in Marketplace. The list of categories shown in Marketplace is not fixed, but is instead built from those used by the assets in Marketplace. We encourage you to use the existing categories whenever possible, though you are free to add additional categories as required or appropriate.
Categories are listed in order of the number of assets in each particular category. As the top five categories (as determined by the number of assets in a category) are what appears when Marketplace is loaded, additional categories are not visible until the user clicks the Show More button.
Many standard endpoint icons are available in Jitterbit Marketplace and are matched using the names in the
ENDPOINTS field of the manifest YAML file. To determine if an icon is available, use the Marketplace endpoint filters to see the available names.
The icon should be such that it is readable and recognizable at a small size, such as 40 by 40 pixels.
If an endpoint icon is not currently available, submit the icon as a square SVG format image. All icons are a white logo on a colored gradient background that goes from the primary brand color at the top to a darker shade of the same color at the bottom. If the primary brand color is such that a gradient would not work or is not permitted, use a solid of the primary brand color instead of a gradient.
An alternative submission is a square white SVG image with color specified either as a single color or as a pair of colors (top and bottom) for the background gradient.
The submitted icon, once verified as acceptable and installed in a Marketplace release, will become available for use. Until then, we will substitute a blank icon in its place.