Skip to Content

HTTP GET activity

Introduction

An HTTP GET activity, using its HTTP connection, retrieves information about a resource on a service accessible over the HTTP or HTTPS protocol, and can be used either as a source (to provide data in an operation) or a target (to consume data in an operation).

Important

With the release of the HTTP v2 connector, we recommend converting existing HTTP connections and activities to HTTP v2. Learn more about the benefits of the HTTP v2 connector in our HTTP v2 blog post or see a comparison of HTTP and HTTP v2 connector features.

Jitterbit's long-term intention is to deprecate the HTTP connector, which will be announced in accordance with Jitterbit's End-of-life policy. At present, there is no timeline for deprecation and the HTTP connector remains fully supported. We recommend that you convert existing HTTP connections and activities to HTTP v2 when possible.

Create an HTTP Get activity

An instance of an HTTP GET activity is created from an HTTP connection using its GET activity type.

To create an instance of an activity, drag the activity type to the design canvas or copy the activity type and paste it on the design canvas. For details, see Create an activity instance in Component reuse.

An existing HTTP GET activity can be edited from these locations:

Configure an HTTP Get activity

Follow these steps to configure an HTTP GET activity:

Step 1: Enter a name and specify settings

In this step, provide a name for the activity and specify the URL, request parameters, and request headers. Each user interface element of this step is described below.

HTTP Get activity configuration step 1

Tip

Fields with a variable icon support using global variables, project variables, and Jitterbit variables. Begin either by typing an open square bracket [ into the field or by clicking the variable icon to display a list of the existing variables to choose from.

Important

Fields in the tables display the variable icon only in edit mode. For these fields' variable values to be populated at runtime, the agent version must be at least 10.75 / 11.13.

  • Name: Enter a name to identify the activity. The name must be unique for each HTTP GET activity and must not contain forward slashes / or colons :.

  • HTTP Verb: The HTTP verb cannot be changed.

  • Path: Enter a path and/or query parameters that should be appended to the base URL that was specified in the configuration of the HTTP connection. If providing query parameters, specify them as you would in a web browser, such as /queryrecord?id=10.

  • URL: The URL created as a concatenation of the base URL and the path entered above is provided for reference. To edit the URL, make changes either to the base URL in the HTTP connection or to the path entered above.

  • Request Parameters: Click the Add button to add a line and then enter a specific Name and Value for requested parameters. Click the Remove button to remove an existing line. The provided request parameters will be automatically URL-encoded.

  • Request Headers: Click the Add button to add a line and then enter a specific Name and Value for requested header information. Click the Remove button to remove an existing line.

  • Save & Exit: If enabled, click to save the configuration for this step and close the activity configuration.

  • Next: Click to temporarily store the configuration for this step and continue to the next step. The configuration will not be saved until you click the Finished button on the last step.

  • Discard Changes: After making changes, click to close the configuration without saving changes made to any step. A message asks you to confirm that you want to discard changes.

Step 2: Provide the request schema

In this step, you can provide a custom request schema (optional).

HTTP Get activity configuration step 2

  • Provide Request Schema: The request schema defines the structure of request data that is used by the HTTP activity. Whether a request schema is required depends on if the activity is used as the target of a transformation and if the web service expects structured request data (see Schema usage). For instructions on completing this section of activity configuration, refer to Schemas defined in an activity.

  • Back: Click to temporarily store the configuration for this step and return to the previous step.

  • Next: Click to temporarily store the configuration for this step and continue to the next step. The configuration will not be saved until you click the Finished button on the last step.

  • Discard Changes: After making changes, click to close the configuration without saving changes made to any step. A message asks you to confirm that you want to discard changes.

Step 3: Provide the response schema

In this step, you can provide a custom response schema (optional).

HTTP Get activity configuration step 3

  • Provide Response Schema: The response schema defines the structure of response data that is used by the HTTP activity. Whether a response schema is required depends on if the activity is used as the source of a transformation and if the web service returns structured response data (see Schema usage). For instructions on completing this section of activity configuration, refer to Schemas defined in an activity.

  • Back: Click to temporarily store the configuration for this step and return to the previous step.

  • Next: Click to temporarily store the configuration for this step and continue to the next step. The configuration will not be saved until you click the Finished button on the last step.

  • Discard Changes: After making changes, click to close the configuration without saving changes made to any step. A message asks you to confirm that you want to discard changes.

Step 4: Review the data schemas

The configured request and response schemas (if provided) are displayed.

HTTP Get activity configuration step 4

  • Data Schema: If provided during activity configuration, the request and/or response data schemas are displayed. If the operation uses a transformation, the data schemas are displayed again later during the transformation mapping process, where you can map to target fields using source objects, scripts, variables, custom values, and more. You can also define schemas directly in a transformation.

  • Add Plugin(s): Plugins are Jitterbit- or user-provided applications that extend Harmony's native capabilities. To apply a plugin to the activity, click to expand this section and select the checkbox next to the plugin to be used. For additional instructions on using plugins, including details on setting any required variables used by the plugin, see Plugins added to an activity.

  • Back: Click to temporarily store the configuration for this step and return to the previous step.

  • Finished: Click to save the configuration for all steps and close the activity configuration.

  • Discard Changes: After making changes, click to close the configuration without saving changes made to any step. A message asks you to confirm that you want to discard changes.

Jitterbit variables affecting HTTP submission

The Harmony system defines certain global variables that are always available throughout a project, known as Jitterbit variables or as predefined global variables. The Jitterbit variables listed below are particularly useful for HTTP activities. For more information on using Jitterbit variables, see Jitterbit variables.

These Jitterbit variables affect the way HTTP source submissions are performed:

  • jitterbit.source.max_redirs
  • jitterbit.source.http.ssl_cert_id
  • jitterbit.source.http.transfer_timeout

These Jitterbit variables affect the way HTTP target submissions are performed:

  • jitterbit.target.http.form_data
  • jitterbit.target.http.form_data.ContentType
  • jitterbit.target.http.form_data.filename
  • jitterbit.target.http.form_data.name
  • jitterbit.target.http.max_redirs
  • jitterbit.target.http.remove_trailing_linebreaks
  • jitterbit.target.http.ssl_cert_id
  • jitterbit.target.http.transfer_timeout

Next steps

After configuring an HTTP GET activity, you can use it within an operation or script as described below. You may also want to configure chunking to split the data into smaller chunks for processing.

Complete the operation

After configuring an HTTP GET activity, complete the configuration of the operation by adding and configuring other activities, transformations, or scripts as operation steps. You can also configure an operation's operation settings, which include the ability to chain operations together that are in the same or different workflows.

Once an HTTP GET activity has been created, menu actions for that activity are accessible from the project pane in either the Workflows or the Components tabs, and from the design canvas. See Activity actions menu for details.

The operation patterns that HTTP GET activities can be used with depend on whether the activity provides data (as a source) or receives data (as a target) in an operation, as described below in Used as a source and Used as a target.

Though it is typical for HTTP GET activities to be used as a source, it is possible to use an HTTP GET activity as a target. Whether the specific web service provides request or response schemas for each method determines whether an activity can be used as a source or target, as described in Parts of an operation in Operation creation and configuration.

Note

When an HTTP GET activity is used as Target Activity 1 / Source Activity 2 in the Two-target HTTP archive pattern, the activity returns a message indicating success {"success": true} or failure {"success": false} instead of the actual response.

When ready, deploy and run the operation and validate behavior by checking the operation logs.

Used as a source

HTTP activities that are used as a source can be used with these operation patterns:

Other patterns are not valid using HTTP activities that are used as a source.

Used as a target

HTTP activities that are used as a target can be used with these operation patterns:

Other patterns are not valid using HTTP activities that are used as a target.

Using HTTP activities in scripts

HTTP activities can also be referenced in a script for use with script functions that use a sourceId or targetId as a parameter, including these:

Jitterbit functions

JavaScript Jitterbit functions

For more details on referencing activities in scripts, see Endpoints in Jitterbit Script or Endpoints in JavaScript.

Use chunking

Many web service APIs have size limitations. If you are running into record limits imposed by the API, you may want to use chunking to split the source data into multiple chunks. The transformation is then performed on each chunk separately, with each source chunk producing one target chunk. The resulting target chunks combine to produce the final target.

For instructions and best practices on using chunking, see Operation options.