Skip to end of metadata
Go to start of metadata

Introduction

An API SOAP Request activity receives data from an API endpoint and is intended to be used a source to provide data to an operation. An API SOAP Response activity returns data to an API endpoint and is intended to be used as a target to consume data in an operation. Jitterbit Custom APIs are configured through API Manager.

The API SOAP Request or Response activities can be configured using a WSDL schema only. If instead you want to interact with an API connection using a JSON, XML, CSV, or XSD schema, use a non-SOAP API Request or Response activity. If you want to interact with a SOAP connection without using an API, use a SOAP endpoint.

Using the preconfigured API connection, you can configure any number of API SOAP activities associated with an API endpoint.

Creating an API SOAP 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 preconfigured API connection block to display activities that are available to be used with an API 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 API SOAP Activity

Follow these steps to configure an API SOAP Request or Response activity:

Step 1: Enter a Name and Provide a WSDL

  • Name: Enter a name to use to identify the API SOAP activity. The name must be unique for each API SOAP Request or Response activity and must not contain forward slashes (/) or colons (:).
  • Upload URL, Upload File, or Select Existing: Use the radio button to select the source of the WSDL (Web Services Description Language) file to upload or reuse. Files up to 5 MB in size can be uploaded.
    • Upload URL: Enter the URL of the WSDL file into the text box, then click the Upload button. The URL must be accessible without authentication or you will receive an error. If uploading a WSDL with the same name as an existing WSDL, see Replacing an Uploaded WSDL later on this page.
    • Upload File: Use the Browse button to the right to browse to a WSDL or ZIP file. If providing a ZIP file, it must contain a single WSDL file, though it can also contain any XSD files that the WSDL is dependent on. Then click the Upload button. If uploading a WSDL with the same name as an existing WSDL, see Replacing an Uploaded WSDL later on this page.

      NOTE: Any schemaLocation must be resolved to a local file using a relative reference. This usually means that instead of supplying a tuple such as this:

      xsi:schemaLocation='http://schemas.xmlsoap.org/wsdl/mime/ http://ws-i.org/profiles/basic/1.1/wsdlmime-2004-08-24.xsd'

      Instead, you would supply this:

      xsi:schemaLocation='http://schemas.xmlsoap.org/wsdl/mime/ wsdlmime-2004-08-24.xsd'

      In the above example, the XSD file wsdlmime-2004-08-24.xsd is located either in the same directory or on a path relative to the WSDL being loaded.

    • Select Existing: Use the dropdown to select from an existing WSDL file that has previously been used in the current project.
  • Port: Use the dropdown to select the appropriate port.

  • Service and Binding: By default, these fields autopopulate based on the provided WSDL and port and cannot be edited.
  • Operation: Use the dropdown to select the method from the provided WSDL that you want to execute with this activity.
  • 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: Review the Data Schemas

  • Data Schema: 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.

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

Replacing an Uploaded WSDL

If replacing a WSDL by reuploading one with the same name using Upload URL or Upload File, its WSDL operations must be named the same as any that are currently in use by existing activities. If they are not named the same or if in-use WSDL operations are missing from the replacement WSDL, an error message instructs you to delete those activities first:

If the WSDL replacement criteria described above are met, a confirmation message lists activities that may be impacted by the replacement of the WSDL to review adjacent transformations for potential mapping errors. On acknowledgment of the message, the WSDL will be replaced in all locations where it is used throughout the project:

Next Steps

After configuring an API SOAP Request or Response activity, you can use it within an operation as described below. Once the operation is set up, select it in the configuration of the Jitterbit Custom API to expose the operation or operation chain as a consumable REST endpoint. 

Completing the Operation

After configuring an API SOAP Request or Response 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.

After an API SOAP Request or Response 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.

API SOAP Request activities can be used as a source with these operation patterns:

When used in an operation chain, no more than one API or API SOAP Request activity can be present. In addition, the API or API SOAP Request activity must be the source of the first operation. That is, no other operation may be calling this operation from a script or an operation action.

CAUTION: Operations that begin with an API Request activity cannot be executed manually using the operation Deploy and Run option because they retrieve the source data externally.

API SOAP Response activities can be used as a target with these operation patterns:

Other patterns are not valid using API SOAP activities. See the validation patterns on the Operation Validity page.

When used in an operation chain, no more than one API or API SOAP Request activity can be present. In addition, the API or API SOAP Request activity must be the source of the first operation. That is, no other operation may be calling this operation from a script or an operation action.

CAUTION: Operations that begin with an API Request activity cannot be executed manually using the operation Deploy and Run option because they retrieve the source data externally.

This example depicts how API SOAP Request and Response activities might be used within an operation chain:

This example shown below uses an API SOAP Response activity twice within an operation chain, which can be used for handling different error responses. For example, this setup provides the ability to override HTTP error code responses for Custom APIs using the Jitterbit variable jitterbit.api.response.status_code, set in a Jitterbit Script:

Other examples using API or API SOAP activities as sources or targets in an operation include Capturing Data Changes with a Harmony API or HTTP Endpoint and Configuring Outbound Messages with Harmony API (These patterns use Design Studio as an example, but the same concepts can be applied in Cloud Studio).

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

Configuring the Jitterbit Custom API

After the operation setup is complete, complete the configuration of the Jitterbit Custom API using API Manager. To configure a Jitterbit Custom API, refer to API Creation and Configuration.

Note that after you have configured a Jitterbit Custom API to call a Cloud Studio operation, you cannot delete the operation without first changing the API's configuration so it no longer calls the operation.

On This Page

Last updated:  Apr 08, 2021

  • No labels