This page defines important technical terms and concepts used in Cloud Studio.
A project is a collection of one or more workflows that comprise and execute an integration use case. A project contains operations as well as other project components that may be part of an operation or used to support operations. A project can be shared, archived, or redistributed by exporting and importing the project as a JSON file.
Project components are the discrete building blocks of a project. Some components, including activities, transformations, and scripts, can be added to operations and executed as a sequence of steps. Other components can be used in support of those operations, such as variables, schedules, file schemas, notifications, and plugins. Operations themselves are also project components.
Some project components may depend on other components to function properly. Two distinct phrases are used to discuss dependencies: dependent on and dependency of. In the following examples, Component A is dependent on Component B. Component B is a dependency of Component A:
- Dependent on: If a component is dependent on another component, it needs that component in order to function properly. A component that is dependent on another component cannot stand alone without that component. When Component A needs Component B in order to execute successfully, Component A is dependent on Component B. Another way to say this is that Component A depends on Component B.
- Dependency of: If a component is a dependency of another component, it is needed by the first component in order for the first component to function properly. A component that is a dependency of another component is the component that is needed by another. When Component A needs Component B in order to execute successfully, Component B is a dependency of Component A.
A workflow is a collection of operations used as tool to help segregate different parts of the project for the convenience of the user.
Workflows are created from along the top of the design canvas:
When you create a new workflow, a blank canvas opens, ready for you to design the workflow by creating operations.
Workflows cannot be executed; only the operations within them can be executed. If the workflow is configured such that one operation leads to the chain execution of all the other operations in a workflow, you can effectively run all operations in the workflow.
You can also execute individual operations within workflows, which may lead to execution of operations in the same or other workflows. That is, if any operations are upstream of other operations in an operation chain, within or outside the workflow, the downstream operations will be kicked off accordingly. In this way, you can effectively run all operations within a project.
An operation is the smallest unit within a workflow that is independently executed on an agent and recorded by Harmony (start and run time, success, failure, errors, debug log files, etc.). Operations are used to define what an integration should do and when it should be done.
An operation consists of at least one operation step, and often contains multiple operation steps consisting of activities, transformations, or scripts. Operation steps are the discrete components that make up an operation and are visually represented within an operation on the design canvas:
Operations must follow a valid operation pattern. Combinations that are not allowed in a single operation may be functionally possible by chaining together multiple operations using operation actions. Once they are created, operations can be executed manually, triggered by an API, or scheduled.
Connectivity resources are accessed within the Connectivity tab of the design component palette. Within this tab, connectors are first configured to create connections. Activities associated with those connections can then be instantiated using the activity types and configured as sources or targets in a project. An endpoint refers to a specific connection and its activities.
- Connectors: A connector provides the interface for entering user-provided input such as credentials to create a connection. The Connectors filter shows the available connectors. You can also create custom connectors.
- Connections: A connection is a component that is created from a connector and provides access to a data resource. The Endpoints filter shows the available connections.
- Activities: An activity is a component that is created from a connection and configured to interact with an endpoint. The Endpoints filter shows the connections, which can be clicked to reveal the activity types. The activity types are used to create an instance of an activity in a project. Activity instances can act as sources (providing data) or targets (receiving data).
- Endpoints: An endpoint refers to a specific connection and its activities.
Variables are used throughout a project to make integrations more flexible and dynamic. They allow for the dynamic configuration of endpoints, support passing of data between operations, and are used in transformation scripts to drive detailed integration logic.
Jitterbit Harmony supports multiple types of variables with varying scope:
- Local Variables: Limited to the current script.
- Global Variables: Available to current and downstream scripts.
- Project Variables: Available across all project workflows, and accessible outside of Cloud Studio through the Management Console and Citizen Integrator.
- Jitterbit Variables: Predefined by Harmony and available to current and downstream scripts.
In addition, filename keywords can be used to generate unique filenames for configurable fields that take filenames as input.
Integration best practice suggests that you use the variable that is most limited in scope, in order to minimize the risk of changing variable values across multiple components in the project.
A transformation is a project component that is used as a step in an operation to map or transform inputs to a resulting output by moving data, cleaning data, or applying business logic.
A transformation consists of source and target schemas that have been defined in the transformation and the transformation mapping that generates the output. A source schema is required only when an adjacent source activity provides input data that needs to be transformed. A target schema is always required.
Source and target schemas can be either defined within the transformation or provided by an adjacent activity, with schemas defined within the transformation taking precedence. Schemas provided by adjacent activities are not part of the transformation. In addition, a transformation does not include the input or output data itself.
The configuration of a transformation can take place in either mapping mode or script mode.
In addition, while configuring a transformation, you should also be familiar with these terms:
Mapping: A transformation mapping consists of target fields or nodes and their corresponding scripts. These scripts may contain references to source fields or nodes or to project components, use functions, or contain other valid script logic. A mapping does not include target fields that are not mapped.
Condition: A condition, as used in a transformation, is a script applied on the target to determine if the source record being processed should be output to the target. If the script evaluates to true, then the record is output. If the script result evaluates to false, then the record is skipped.
Loop Node: A loop node is a source or target node with repeating data values, such as line items in an invoice or a set of customer records. When loop node fields are mapped, a solid black iterator line automatically appears, indicating that the transformation process will loop through the source data set. A transformation can have zero or more iterator lines.
A Cloud Studio integration recipe, available through Jitterbit Marketplace, is a single, pre-built integration project that moves data in one direction between objects across two applications or systems. Integration recipes are available to all Jitterbit Harmony subscribers.
A Cloud Studio process template, available through Jitterbit Marketplace, is a group of pre-built integration use cases that accelerates the execution of a specific business process using numerous objects across multiple applications or systems.
Process templates are designed to reduce the time to deployment by 50 to 80 percent and can be either self-implemented, delivered by Jitterbit Professional Services, or delivered by an implementation partner.
A process template consists of one or more projects using multiple endpoints, may include customization files, and has its own documentation in PDF format. After the projects are created, you must enter appropriate values in the project variables that set credentials and other information for the project in each project individually.