Skip to end of metadata
Go to start of metadata

Introduction

HTTP targets are typically used as the end-point of a transformation operation. 

When HTTP is used as a target, the Jitterbit Agent submits an HTTP action (one of GET, POST, PUT, DELETE, or CUSTOM) and passes data to the URL specified in the target configuration.

You might configure an HTTP target with header information for a POST action in the definition. When it is used in an operation, an ASCII text message is formed by using this header information, a blank line, and the transformed information from a source.

For example, consider a transformation of a source database query into an XML document. The data is retrieved from the source and then transformed into the XML document format as defined in the transformation. Next, the target header information (defined by the target definition) is added to the beginning of the XML document, along with a blank line, and then the XML content. The final document is then passed to the target URL using an HTTP POST command.

Similar to an HTTP source, a response is returned from the HTTP request and is then parsed. If the message indicates success, nothing more is done. When an error message is received, it is used as part of the error logging process for the operation.

NOTE: Though HTTP POST can include virtually any type of payload, it must be understood by the server that is receiving it.

Creating an HTTP Target

You can choose to create a new HTTP target on its own, or within an existing operation. For details on how targets work within operations, see Creating an Operation.

Creating a New HTTP Target as a Standalone Target

Within your project in Jitterbit Design Studio, you create a new HTTP target by any of:

  • Go to File > New > New Target; or

  • In the tree on the left, right-click on Targets and select New Target; or
  • In the top toolbar, click the blue target icon .

In the popup, select HTTP as the type:

Your new target appears in its own New Target tab in the right pane of the window.

NOTE: If you create a standalone target using any of these methods, note that it is not connected to an operation. See Using an Existing HTTP Target in an Existing Operation below to use the new target.

Creating a New HTTP Target in an Existing Operation

A target is usually created by default when you create a new operation. (The exception is an operation that consists only of a script.) With an existing operation, you can specify the type of its target by:

  • Double-clicking on the target icon; in the popup, select Create New Target; or

  • Right-clicking on the target icon and selecting Create New Target

In the configuration screen that appears, use the Type dropdown to select  HTTP, as shown above.

Using an Existing HTTP Target in an Existing Operation

To use an existing HTTP target in an existing operation with a target, you can set it by any of:

  • Within the operation, double-clicking on the target icon, and in the resulting popup, selecting the desired HTTP target from the list; or

  • Within the operation, right-clicking on the target icon, choosing Select Existing Target, and in the resulting popup, selecting the desired HTTP target from the list; or

  • Dragging the desired HTTP target from the tree on the left and dropping it onto the existing target icon of the operation.

Configuring an HTTP Target

After you have created an HTTP target, the configuration screen will open in the main view of Design Studio. You can return to the configuration screen at any time by double-clicking on the target icon in the operation, or by double-clicking on the target in the tree on the left.

Basic Configuration

The configuration screen will appear similar to this example:

  • Name: Enter an appropriate, unique name for the source.
  • Type: Use the dropdown to select HTTP, if it is not already specified.
  • Connection Parameters: Specify the details for your HTTP connection:
    • URL: Enter a valid URL for the target. An HTTP target is defined by the URL of the resource, such as http://www.example.com/ups.app/xml/ShipConfirm.
      • To use SSL encryption, use https:// instead of http:// in the URL, such as https://www.example.com/ups.app/xml/ShipConfirm.
      • If query parameters are specified, provide them as they would be in a web browser, such as https://www.example.com/queryrecord?id=10.
    • Login: If applicable, enter the username and password that allows access to the URL. Leave these fields blank if no username or password is required.
    • Password: Enter a password to use with the Login to access the URL referenced in the URL field, if required.
    • Enable Retry option: Available only in Design Studio versions 10.22 and higher when using an environment associated with a Private Agent Group, this setting is used to retry a request when an HTTP endpoint returns one of these status codes: 500, 501, 502, 503, or 504.

      In order for this setting to take effect, Private Agents must be version 10.22 or higher. With earlier agent versions, the configuration of this setting will be ignored without an error.

      Select the checkbox to enable additional configuration options:

      • Max Retry: Enter the number of times (maximum of 5) that a request will be resent to NetSuite. If the request still fails after the maximum number of retries, an exception with an error message will be returned in the operation log. In addition, the Private Agent log file jitterbit.log will log each retry.

        Each retry is treated as part of the same operation run, where only a single record appears in the operation log. Any On Success or On Failure events configured to run downstream operations are triggered based on the end status of the operation after retrying up to the maximum number of retries.

      • Retry Interval (Seconds): Enter the number of seconds (maximum of 5) to wait between resending a request to the HTTP endpoint.
    • HTTP Verb: Use the dropdown to select one of GET, POST, PUT, DELETE, or CUSTOM, depending on the requirements of the endpoint. For a POST, an empty request is posted to the URL and the response is used as the source.
  • Test Connection: Clicking the  button will test the HTTP target; Jitterbit will perform an HTTP HEAD request and return an error if it is not successful. Note that HEAD may not be permitted by the HTTP server referenced by the URL, even if GET or POST is.
  • Click the Save button in either the main toolbar or the target's toolbar to save the configuration.

Options

Additional connection parameters can be specified by clicking the Options at the bottom of the Connection Parameters section:

  • Content-Type: The default content-type is empty, which should be used if the method being used does not accept structured data, or if the API does not require the content-type to be specified. This can be changed by deselecting Use default Content-Type and specifying an appropriate content-type. Examples of content-types include text/plainapplication/jsonapplication/x-www-form-urlencoded, etc.
  • Security Options: To have the Agent use a certificate to authenticate with the host, specify an appropriate certificate from the dropdown menu. (The green button to the right of the dropdown menu will refresh the list of certificates available from Jitterbit Harmony.)

    If applicable, select Use Basic HTTP Authentication to authenticate with the host using basic HTTP authentication without SSL encryption. Note that if this option is used, the provided password will be sent in clear text. (Unless required, this is not recommended.)

    TIP: You can manage client-side SSL certificates from the Management Console under Customizations > Client Certificates.
  • Write response to (optional): To save the response from the HTTP server, specify that it be written to a separate target using the dropdown menu. If specified, the Edit button becomes enabled to allow editing of that target.
  • Proxy Settings: Use the dropdown to select one of these options for a custom proxy for the HTTP host:
    • Disable: Proxy settings are disabled for this specific source, bypassing the Agent proxy configuration if one exists.
    • Default: Proxy settings are enabled, using the Agent proxy configuration if one exists. If proxy settings are not specified in the Agent configuration, the Default setting has the same result as the Disable setting.
    • Custom: Proxy settings are enabled for this specific target using custom information provided here. This option bypasses the Agent proxy configuration if one exists. When Custom is selected, these fields become available: 

      See Enabling Proxy for Private Agents for details on these fields.

Advanced Properties

Additional advanced parameters can be specified by clicking the Advanced Properties at the bottom of the Options section. These concern the HTTP headers sent with the request and SSL-related parameters:

  • Enable content encoding: If checked, the "Accept-Encoding" header will be sent with the encoding supported by Jitterbit. Currently, Gzip is supported. This option is off by default.

  • Enable chunked transfer encoding: If checked, the "Transfer-Encoding: chunked" header will be sent. Use this option if you are transferring large data sets. This option is off by default.

  • Send Expect: 100-continue: If checked, the "Expect: 100-continue" header will be sent. With this option, no data will be sent until the HTTP server has validated the headers. Use this option if you are sending large amounts of data but don't want to use chunked transfer encoding. This option is off by default.

  • Allow weak ciphers: If checked, this will allow communication with HTTP endpoints that use weak ciphers (DES/3DES and RC4). This option is off by default.
  • Set Accept-Encoding to GZip: Checked by default, this option tells the HTTP server that Jitterbit can accept a Gzip-compressed response. In return, Jitterbit will follow the RFC 1952 standard and automatically decompress Gzip HTTP responses. If the server does not use Gzip, Jitterbit will see that the response is not compressed and handle it as usual. This feature was added as of Jitterbit version 8.20 and is now checked by default for all new and existing HTTP sources. 
  • Request Headers (one line per header): Any text entered in this box will be sent as an HTTP header. Specify one header per line unless the header is wrapped according to the HTTP standard. Global data elements in square brackets will be replaced with their values.

  • SSL Version: Only applicable when using HTTPS, it allows the specification of a specific SSL version if the HTTP server requires it. The default is “Negotiate”. Options available are:

Predefined Target Global Variables That Affect an HTTP Target

These predefined target global variables affect HTTP targets:

  • 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.request.header.HeaderName
    (shown in the script editor as jitterbit.target.http.response.header.*)
  • jitterbit.target.http.ssl_cert_id

  • jitterbit.target.http.status_code

  • jitterbit.target.http.transfer_timeout

See Target Jitterbit Variables for details.

On This Page


Last updated:  Sep 04, 2020