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. Projects are the "container" for operations that are organized into workflows, as well as other project components that may be part of an operation or exist elsewhere in the project.
Cloud Studio projects can be shared by exporting and importing the project as a JSON file. These files contain all the metadata (operations, endpoints, etc.) of a project and are primarily used for easy archiving and redistribution of projects. For more information, see Project Exports and Imports and additional pages under Projects.
Project components are the discrete building blocks of a project. Some components, including activities, scripts, and transformations, can be added to operations that are 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 said to be dependent on Component B. Component B is said to be 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 said to be 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 said to be 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. Operation steps are the discrete components that make up an operation and are visually represented by blocks on the design canvas, created by adding activities, scripts, or transformations to the operation.
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. For more information, see Operation Validity and additional pages under Operations.
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 added to operations on the design canvas and configured as sources or targets. An endpoint refers to a specific connection and its activities. For additional information, see Connectors.
- Connectors: A connector provides the interface for entering user-provided input such as credentials to create an authenticated connection. The Connectors filter shows the types of connectors that can be configured. In addition, you can create custom connectors using Connector Builder or the Connector SDK.
- A connection is authenticated access to a data resource that has been configured using a connector. The Endpoints filter shows these configured connections. Existing connections can be edited by double-clicking on the connection in the palette.Connections:
- interaction with a connection that can be configured with user-provided input such as data structures that represent the "request" and "response" schemas for that action. The Endpoints filter shows the configured connections, which can be clicked to reveal the types of activities that can be added to an operation. Those activities are then able to be dragged to operations on the design canvas, where they can be configured by double-clicking on the activity within the operation. Configured activities can act as sources (providing data within an operation) or targets (receiving data within an operation).Activities: An activity is an
- An endpoint refers to a specific connection and its activities, which are added to an operation and then configured as sources or targets within the operation.Endpoints:
For more information, see Scripts.
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.
For more information, see Variables.
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. For more information, see Transformations.
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 will automatically appear, indicating that the transformation process will loop through the source data set. A transformation can have zero or more iterator lines.
Last updated: Dec 10, 2019
- No labels