Connectors are documented individually but can be classified by their use:
- Short-Term Storage: Use the Local Storage, Temporary Storage, or Variable connectors for temporary storage of files.
- Long-Term Storage: Use the File Share, FTP, or Database connectors for long-term or permanent storage of files.
- Service-Based: Use the HTTP or SOAP connectors for connecting to web services that don't already have an application connector or that you want to connect to using a standards-based web service.
- Application: Use these connectors as the recommended way to connect to a specific application, such as NetSuite, Salesforce, ServiceNow, or Workday.
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).
These connector classifications are by the type of use of the connector.
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.
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.
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.
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.
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.
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.
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:
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.
A file-based endpoint refers to an endpoint whose schemas are provided by the user, such as API, File Share, FTP, HTTP, Local Storage, SOAP, Temporary 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.