HTTP v2 PUT activity

Introduction

An HTTP v2 PUT activity, using its HTTP v2 connection, replaces an existing 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).

Create an HTTP v2 PUT activity

An instance of an HTTP v2 PUT activity is created from an HTTP v2 connection using its PUT 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 PUT activity can be edited from these locations:

The design canvas (see Component actions menu in Design canvas).
The project pane's Components tab (see Component actions menu in Project pane Components tab).

Configure an HTTP v2 PUT activity

Follow these steps to configure an HTTP v2 PUT activity:

Step 1: Enter a name and specify settings
Provide a name for the activity and specify the URL, request parameters, request headers, and additional settings.
Step 2: Provide the request schema
Provide a custom request schema (optional). If you do not provide a custom response schema, the connector's default response schema will be used.
Step 3: Provide the response schema
Provide a custom response schema (optional). If you do not provide a custom response schema, the connector's default response schema will be used.
Step 4: Review the data schemas
The configured request and response schemas are displayed.

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 PUT 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 v2 PUT activity and must not contain forward slashes / or colons :.
Path: Enter a URL to use for the activity:
- If left blank, the Base URL configured in the HTTP v2 connection will be used at runtime.
- If a partial path is specified, it will be appended to the Base URL configured in the HTTP v2 connection.
- If a full URL is specified, it will override the Base URL configured in the HTTP v2 connection.
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 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 transformation, that specified in the transformation takes precedence.

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

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

To delete all rows, click Clear All.
Request Headers: Click the 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 PUT activity (this field) overrides the remaining field below.
3. A header provided in the Request Headers field of an HTTP v2 connection, if Send Request Headers in Activity Execution is enabled, has the least precedence.
Note

If a header is defined in multiple locations, every instance of the header will be added to an activity's request following the order of precedence above. This order is based on how services typically handle duplicate headers in a request.

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

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

To delete all rows, click Clear All.

Additional Settings: Click the 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 transformation, that specified in the transformation 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:

A Content-Type header provided in the Additional Settings table of an HTTP v2 PUT activity (this table) overrides all fields below.
The bodyContentType field specified in a request transformation overrides the remaining fields below.
A Content-Type header provided in the request transformation headers node overrides the remaining fields below.
A Content-Type header provided in the Request Headers field of an HTTP v2 PUT activity overrides the remaining field below.
A Content-Type header provided in the Request Headers field of an HTTP v2 connection, if Send Request Headers in Activity Execution is enabled, has the least precedence.

Note

If a header is defined in multiple locations, every instance of the header will be added to an activity's request following the order of precedence above. This order is based on how services typically handle duplicate headers in a request.

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

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

To delete all rows, click Clear All.

Multipart: Select to support multipart/form-data requests when using default schemas. This is required for requests that include RFC 1867 form uploads.

Note

When using custom schemas, multipart/form-data is not supported.
Optional settings: Click to expand additional optional settings:
- Ignore operation error in case of non-successful status code: Select to have operations report a successful status even if a non-successful status code is returned from the API the connector is calling. The default value is unselected.
- Select HTTP status code to be considered success at operation runtime: Select either Grouped by Class or Granular (Manual Input) to consider specified status codes as successful in operation logs.
  - Grouped by Class: When selected, a dropdown is shown with classes of non-successful status codes to be treated as successful. Dropdown options include 3xx Redirection, 4xx Client Error, and 5xx Server Error. The default value of the dropdown is unselected.
  - Granular (Manual Input): When selected, a field is shown to manually enter a comma-delimited list of non-successful status codes to be treated as successful. This list can include different classes of status codes at the same time. The default value of the field is blank.
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 PUT activity configuration step 2

Provide Request Schema: The request schema defines the structure of request data that is used by the HTTP v2 PUT 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 PUT activity configuration step 3

Provide Response Schema: The response schema defines the structure of response data that is used by the HTTP v2 PUT activity. For instructions on completing this section of activity configuration, refer to Schemas defined in an activity.

Include Additional Properties from HTTP Response in the Schema: When Yes, Use Saved Schema or Yes, Provide New Schema is selected and the schema used has an XML or JSON file type, the checkbox Include Additional Properties from HTTP Response in the Schema is displayed. When selected, the schema is wrapped within a Jitterbit-defined structure, allowing additional parameters to be accessible in the schema:

HTTP v2 additional properties in response schema

JSONXML

{
  "__jitterbit_aditional_properties__": {
    "__jitterbit_api_headers__": [
      {
        "key": "",
        "value": ""
      },
      {
        "key": "",
        "value": ""
      }
    ],
    "__jitterbit_api_statuscode__": 200,
    "__jitterbit_api_errorbody__": ""
  },
  "root": {
    // Original JSON
  }
}

<__jitterbitResponse__>
    <__jitterbit_aditional_properties__>
        <__jitterbit_api_headers__>
            <key>headerKey1</key>
            <value>headerValue1</value>
        </__jitterbit_api_headers__>
        <__jitterbit_api_headers__>
            <key>headerKey2</key>
            <value>headerValue2</value>
        </__jitterbit_api_headers__>
        <__jitterbit_api_statuscode__>200</__jitterbit_api_statuscode__>
        <__jitterbit_api_errorbody__>
        </__jitterbit_api_errorbody__>
    </__jitterbit_aditional_properties__>
    <root>
        <!-- Original XML -->
    </root>
</__jitterbitResponse__>

__jitterbit_api_headers__: Returns the headers provided by the request call.
__jitterbit_api_statuscode__: Returns the status code of the request call.
__jitterbit_api_errorbody__: Returns the response body of the request call in string format if the request call returns an unsuccessful status code.
root: Houses the original structure of the response schema.

Note

When selected, a new schema is generated with the wrapper. The structure of the original schema is preserved within root. Because a new schema is generated for this purpose, the original without the wrapper can be used later if necessary.

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

For HTTP v2 activities, data schemas regenerate automatically based on updates made to the schemas defined in previous steps.

Caution

HTTP v2 activities created prior to the 10.85 / 11.23 Harmony release may have a manual Refresh button present due to previously defined project metadata. If present, do not interact with this button. Create a new instance of an affected activity to remove it.

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

multipart	Node of a multipart (included only when Multipart is selected in the activity configuration UI and default schemas are used)

plainText	Node of a multipart's plain-text parts

item	Node of a specific plain-text part in the multipart
key	Key of the plain-text part that maps to its `name` attribute in the request payload
value	Value of the plain-text part that maps to its content in the request payload
contentType	`Content-Type` of the plain-text part Note This field takes precedence over a `Content-Type` header provided in the `headers` node.

fileData	Node of a multipart's file data parts

item	Node of a specific file data part in the multipart
key	Key of the file data part that maps to its `name` and `filename` attributes in the request payload. It should include the file's extension if known Note If a path is supplied for this key and the `fileName` field is left empty, the `filename` attribute will contain only the file's name and extension.
value	Value of the file data part that maps to its content in the request payload Important The string supplied for this value represents the file itself and must be encoded in Base64 format. See Base64encodefile in Cryptographic functions for how to encode a file using a script.
fileName	String representing the file data part's file name that maps to its `filename` attribute in the request payload. It should include the file's extension if known. This field takes precedence over what is defined in the `key` field for the `filename` attribute
mimeType	String representing the file data part's MIME (media) type, independent from file extensions provided in the `key` or `fileName` fields

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
statusMessage	Status message of the response
details	Response details

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 PUT 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 PUT activities that are used as a source can be used with these operation patterns:

Transformation pattern
Two-target archive pattern (as the first source only)
Two-target HTTP archive pattern (as the first source only)
Two-transformation pattern (as the first or second source)

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

Transformation pattern
Two-transformation pattern (as the first or second target)

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.