Skip to end of metadata
Go to start of metadata

Introduction

Connectors are documented individually but can be classified by their use:

Connectors can also be differentiated by how their schemas are defined:

  • Server-Based versus File-Based: These terms are used in addition to the classifications listed above to refer to connectors that automatically fetch a schema from the endpoint (server-based) versus those where you provide the schema yourself (file-based).

Connector Use

These connector classifications are by the type of use of the connector.

API

This connector is used in conjunction with a Jitterbit Custom API that is configured through the API Manager. Unlike other connectors, the API connection is a preconfigured endpoint whose associated activities include Request and Response activities. Schemas are defined by files provided by the user.

Short-Term Storage

These connectors are typically used when you want to store files temporarily for use in a downstream operation. Associated activities include Read and Write activities. However, written files cannot be relied on to be present after operation execution, with the exception of Local Storage with some additional configuration. Schemas are defined by files provided by the user.

Long-Term Storage

These connectors are typically used for long-term or permanent storage of files. Associated activities include Read and Write activities. Schemas are defined by files provided by the user.

The Database connector can also be considered a long-term storage connector but offers more functionality than the other long-term storage connectors. The Database connector is used to access relational database management systems (RDMS) using third-party drivers. Activities include Query, Insert, and Update (Jitterbit Harmony also supports an Upsert activity through a combination of these). Schemas are queried from the database using the chosen driver.

Service-Based

These connectors are used with a service that provides the metadata needed for the connection and activities. In the case of HTTP/REST services, you research and test the service, and then you provide the schemas within each activity. In the case of SOAP services, this metadata is provided in a Web Service Definition Language (WSDL) file and schemas are queried from the service.

Application

These connectors are used for interaction with specific applications, incorporating application-specific logic for connecting to the endpoint and for various activities that are unique to each endpoint. Schemas are queried from each application.

In addition, these connectors are application connectors:

Additional application-specific connectors are being added with each new Harmony release and are updated here over time.

Connector Schema Definition

In addition to the above connector classifications by use, connectors can also be referred to based on how their schemas are defined.

Server-based Versus File-based

Connectors can be referred to as server-based or file-based depending on how their schemas are defined.

For more about schema caching and refreshing for both server-based and file-based schemas, see Schema Regeneration.

Server-based

A server-based endpoint refers to an endpoint whose schemas are generated directly from the endpoint, such as is the case with Database, NetSuite, and Salesforce endpoints, as well as many application-specific endpoints and some custom endpoints. Server-based schemas are always defined in an activity. Server-based schemas have an automatically generated name that depends on whether the schema is a request or response:

User-Defined Endpoint Name→User-Defined Activity Name→Request
User-Defined Endpoint Name→User-Defined Activity Name→Response

This transformation shows the names of server-based schemas being inherited from activities on both its source and target sides:

The names of server-based schemas and their structures cannot be edited directly. Depending on the endpoint, the structure may dynamically change based on user input provided during activity configuration or based on changes in the endpoint itself.

File-based

A file-based endpoint refers to an endpoint whose schemas are provided by the user, such as API, File Share, FTP, HTTP, Local Storage, SOAPTemporary Storage, and Variable endpoints. File-based schemas can be defined in an activity or defined in a transformation. The names of file-based schemas are based on the name of the provided file or are user-defined.

  • No labels