Skip to end of metadata
Go to start of metadata

Introduction

An HTTP activity retrieves data from or sends data to an HTTP endpoint and is intended to be used as either a source to provide data to an operation or a target to consume data in an operation. HTTP activities can also be called in scripts. After configuring an HTTP connection, you can configure as many HTTP activities as you like for each HTTP connection. HTTP activities can be configured to use standard methods such as GET, PUT, POST, or DELETE, or they can be configured to use a custom action. 

Whether the activity can be used as a source or a target in an operation or a script depends on the specific web service and the request and response structures, if present. For more information about what determines if an activity can be used as a source or target, see Parts of an Operation in Operation Creation and Configuration.

Creating an HTTP Activity

From the design canvas, open the Connectivity tab of the design component palette:

Use the Show dropdown to filter on Endpoints, and then click the HTTP connection block to display activities that are available to be used with an HTTP connection:

To create an activity that can be configured, drag the activity block from the palette to the operation.

For more information about the parts of an operation and adding activities to operations, see Operation Creation and Configuration.

Configuring an HTTP Activity

Follow these steps to configure an HTTP activity, including GET, PUT, POST, DELETE, or Custom activities:

Step 1: Enter a Name, Select the HTTP Verb, and Specify Settings

TIP: Fields with a variable icon support using global variablesproject 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.

  • Name: Enter a name to use to identify the HTTP activity. The name must be unique for each HTTP GET, PUT, POST, DELETE, or Custom activity and must not contain forward slashes (/) or colons (:).
  • HTTP Verb: Use the dropdown to select from GET, PUT, POST, or DELETE. This dropdown is not present for an HTTP Custom activity.

    NOTE: For an HTTP POST used as a source, an empty request is posted to the URL and the response is used as the source. 

    For an HTTP POST used as a target, virtually any type of payload can be included, but must be understood by the web server that is receiving it. A response is returned based on the HTTP request and is parsed by Jitterbit Harmony. If the response indicates success, nothing more is done. If an error message is received, it is used as part of the error logging process for the operation and is reported in operation logs.

  • Custom Verb: Enter the custom verb (for example, PATCH) into the text box. This field is present only for an HTTP Custom activity.
  • 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.
  • 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

  • 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 When to Use a Schema). 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

  • 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 When to Use a Schema). 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

  • 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 Jitterbit 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:

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

Next Steps

After configuring an HTTP 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.

Completing the Operation 

After configuring an HTTP 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 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 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 GET activities to be used as a source, and for PUT, POST, and DELETE activities to be used as a target, it is possible to use a GET activity as a target and to use PUT, POST, and DELETE activities as sources. 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 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.

A typical use case using an HTTP activity as a source is to use a HTTP GET activity in the Transformation Pattern. In this example, the HTTP GET activity (GET Request) provides the data within the operation, which is then received by the transformation (HTTP to Variable). The Variable Write activity (Write Responseis used as the target, receiving data within the operation. A message is then logged by the Write to Operation Log script:

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.

A typical use case using an HTTP activity as a target is to use a HTTP POST activity to retrieve a REST token and write that response to a global variable for use in a downstream operation. 

In this example, in the operation Get Token, the transformation (Format JSONcreates a request structure that is passed to the HTTP POST activity (POST), which is then written to a variable by a Variable Write activity (Write Token).

On success of the operation Inbound Get Token, the operation Parse Token runs. A Variable Read activity (Read Token) generates a response structure that is received by the transformation (Parse Response JSON).

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 Script Functions

JavaScript Jitterbit Functions

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

Using 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.

  • No labels