Skip to Content

HTTP v2 (Beta) GET Activity

Introduction

An HTTP v2 (Beta) GET activity, using its HTTP v2 (Beta) connection, retrieves information about a resource on an HTTP server, and can be used either a source (to provide data in an operation) or a target (to consume data in an operation).

Note

This connector is currently released as a beta version. Feedback on bugs and suggested enhancements can be provided through your Customer Success Manager (CSM).

Create an HTTP v2 (Beta) GET Activity

An instance of an HTTP v2 (Beta) GET activity is created from an HTTP v2 (Beta) 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 Creating an Activity Instance in Component Reuse.

An existing HTTP v2 (Beta) GET activity can be edited from these locations:

Configure an HTTP v2 (Beta) GET Activity

Follow these steps to configure an HTTP v2 (Beta) 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, request headers, and additional settings. Each user interface element of this step is described below.

HTTP v2 (Beta) GET Activity Configuration Step 1

Tip

Fields with a variable icon 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.

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

  • Path: Enter a URL to use for the activity:

    Request parameters can be included by enclosing them within curly brackets { }. Query parameters (such as /queryrecord?id=10) can also be used.

    • URL: Displays the complete URL to be used at runtime.
  • Request Parameters: Click the add icon add icon to add a row to the table below and enter a Name and Value for each request parameter. The provided request parameters will be automatically URL-encoded.

    Alternatively, request parameters can be provided in the request transformation. Request parameters that do not share a key are sent cumulatively, regardless of where they are specified. If the same parameter key is specified both in this field and in the request, that specified in the request takes precedence.

    To save the row, click the submit icon submit icon in the rightmost column.

    To edit or delete a single row, hover over the rightmost column and use the edit icon edit icon or delete icon delete icon.

    To delete all rows, click Clear All.

  • Request Headers: Click the add icon add icon to add a row to the table below and enter a Name and Value for each request header.

    Alternatively, headers can be defined in other UI configuration fields or provided in the request transformation. Headers that do not share a key are sent cumulatively, regardless of where they are specified.

    If the same header key is specified in multiple places, this order of precedence is followed:

    1. A header provided in the request transformation overrides all fields below.
    2. A header provided in the Request Headers field of an HTTP v2 (Beta) GET activity (this field) overrides the remaining field below.
    3. A header provided in the Request Headers field of an HTTP v2 (Beta) connection has the least precedence.

    To save the row, click the submit icon submit icon in the rightmost column.

    To edit or delete a single row, hover over the rightmost column and use the edit icon edit icon or delete icon delete icon.

    To delete all rows, click Clear All.

  • Additional Settings: Click the add icon add icon to add a row to the table below and enter a Name and Value for each additional setting.

    These additional settings are supported:

    Key
    Default Value Data Type Description
    connection-timeout 30000 Integer The transfer timeout in milliseconds. If this setting is not specified, the default transfer timeout is 30000 milliseconds (30 seconds). Set to 0 for an unlimited timeout.
    content-type String The content-type of the request structure that is expected by the particular API. For example, text/plain, application/json, application/x-www-form-urlencoded, etc. If this setting is not specified, there is no default value.
    max-redirect 50 Integer The maximum number of redirects to follow. If this setting is not specified, the default is to follow 50 redirects. Set to 0 or a negative number to prevent following any redirects.
    trailing-linebreaks false String Removes leading and trailing whitespace and line breaks when set to true. If this setting is not specified or set to false, the data is left unchanged.

    Alternatively, additional settings can be provided in the request transformation. Additional settings that do not share a key are sent cumulatively, regardless of where they are specified. For all settings except for content-type, if the same settings key is specified both in this field and in the request, that specified in the request takes precedence.

    For content-type, a value specified here takes precedence over all other places in the UI where the content-type can be specified. If content-type is specified in multiple places, this order of precedence is followed:

    1. A Content-Type header provided in the Additional Settings table of an HTTP v2 (Beta) GET activity (this table) overrides all fields below.
    2. The bodyContentType field specified in a request transformation overrides the remaining fields below.
    3. A Content-Type header provided in the request transformation headers node overrides the remaining fields below.
    4. A Content-Type header provided in the Request Headers field of an HTTP v2 (Beta) GET activity overrides the remaining fields below.
    5. A Content-Type header provided in the Request Headers field of an HTTP v2 (Beta) connection overrides the remaining field below.
    6. A Content-Type header provided in the Content-Type field of an HTTP v2 (Beta) connection has the least precedence.

    To save the row, click the submit icon submit icon in the rightmost column.

    To edit or delete a single row, hover over the rightmost column and use the edit icon edit icon or delete icon delete icon.

    To delete all rows, click Clear All.

  • 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. If you do not provide a custom request schema, the connector's default request schema will be used.

HTTP v2 (Beta) GET Activity Configuration Step 2

  • Provide Request Schema: The request schema defines the structure of request data that is used by the HTTP v2 (Beta) GET activity. 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. If you do not provide a custom response schema, the connector's default response schema will be used.

HTTP v2 (Beta) GET Activity Configuration Step 3

  • Response: The response schema defines the structure of response data that is used by the HTTP v2 (Beta) GET activity. 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 are displayed.

HTTP v2 (Beta) GET Activity Configuration Step 4

  • Data Schemas: These data schemas are inherited by adjacent transformations and are displayed again during transformation mapping.

    If any custom schemas were provided in the previous steps, they will be displayed. If custom schemas were not provided, the default schemas included with the connector will be displayed.

    The default request and response schemas consist of these nodes and fields:

    • Request:

      Request Schema Node/Field Notes
      json Format of the request schema
      request Request node
      root Root node
      headers Node of headers
      item Node of a specific header
      key Key of the header
      value Value of the header
      requestParameters Node of request parameters
      item Node of a specific request parameter
      key Key of the request parameter
      value Value of the request parameter
      additionalSettings Node of additional settings
      item Node of a specific additional setting
      key Key of the additional setting
      value Value of the additional setting
      body Request body
      bodyContentType Content-Type of the request body

      Note

      This field takes precedence over a Content-Type header provided in the headers node.

    • Response:

      Response Schema Node/Field Notes
      json Format of the response schema
      response Response node
      responseItem Node of the response item
      status A boolean indicating whether a response was returned
      properties Properties of the response
      headers Node of headers
      item Node of a specific header
      key Key of the header
      value Value of the header
      responseContent Content of the response
      error Error node
      statusCode HTTP status code of the response
      details Response details
  • Refresh: Click the refresh icon Refresh icon or the word Refresh to regenerate schemas from the HTTP v2 (Beta) endpoint. This action also regenerates a schema in other locations throughout the project where the same schema is referenced, such as in an adjacent transformation.

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

Next Steps

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

Menu actions for an activity are accessible from the project pane and the design canvas. For details, see Activity Actions Menu in Connector Basics.

HTTP v2 (Beta) GET activities that are used as a source can be used with these operation patterns:

HTTP v2 (Beta) GET activities that are used as a target can be used with these operation patterns:

A typical use case is to use an HTTP v2 (Beta) GET activity as a source in the Two-transformation Pattern. In this example, the first transformation (HTTP v2 (Beta) GET Request) creates a request structure that is passed to the HTTP v2 (Beta) GET activity. The second transformation (HTTP v2 (Beta) GET Response) receives the response structure, which is then written to a variable by a Variable Write activity (Write HTTP v2 (Beta) GET Response) and a message is then logged by the Write to Operation Log script:

HTTP v2 (Beta) GET operation

To use the activity with scripting functions, write the data to a temporary location and then use that temporary location in the scripting function.

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