HTTP POST activity¶
Introduction¶
An HTTP POST activity, using its HTTP 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).
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 Post activity¶
An instance of an HTTP POST activity is created from an HTTP connection using its POST 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 POST 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 Post activity¶
Follow these steps to configure an HTTP POST activity:
-
Step 1: Enter a name and specify settings
Provide a name for the activity and specify the URL, request parameters, and request headers. -
Step 2: Provide the request schema
Provide a custom request schema. -
Step 3: Provide the response schema
Provide a custom response schema. -
Step 4: Review the data schemas
The configured request and response schemas (if provided) 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, and request headers. Each user interface element of this step is described below.
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 POST activity and must not contain forward slashes
/
or colons:
. -
HTTP Verb: The HTTP verb cannot be changed.
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 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.
-
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).
-
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).
-
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.
-
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 POST 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 POST 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 POST 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 POST 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 POST activities to be used as a target, it is possible to use an HTTP POST activity as a source. 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.
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:
- Archive pattern
- Transformation pattern
- Two-target archive pattern (as the first source only)
- Two-target HTTP archive pattern (as the first or second source)
- Two-transformation pattern (as the first source only)
- Salesforce bulk target pattern
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:
- Archive pattern
- Script pattern
- Transformation pattern
- Two-target archive pattern (as the second target only)
- Two-target HTTP archive pattern (as the first or second target)
- Two-transformation pattern (as the second target only)
- Salesforce bulk source pattern
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¶
ArchiveFile
Base64EncodeFile
DBLoad
DBWrite
DeleteFile
DeleteFiles
DirList
FileList
FlushAllFiles
FlushFile
ReadFile
SfLookupAllToFile
WriteFile
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.