Skip to end of metadata
Go to start of metadata

Introduction

SOAP activities interact with a SOAP connection to read or write data as a source or target in an operation. The specific activities that are available depend on the SOAP methods selected during configuration of the SOAP connection. You can configure as many SOAP activities as you like for each SOAP connection. 

Whether the activity can be used as a source or a target in an operation or a script depends on the specific web service and the request and response structures, if present. For more information about what determines if an activity can be used as a source or target, see Parts of an Operation in Operation Creation and Configuration.

Creating a SOAP Activity

From the design canvas, open the Connectivity tab of the design component palette:

Within the Endpoints filter, click the SOAP connection block to display activities that are available to be used with the SOAP connection. The specific activities that are available depend on the SOAP methods selected during configuration of the SOAP connection.

To create an activity that can be configured, the activity must first be added to an operation on the design canvas. To add an activity to an operation, 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.

Accessing Menu Actions

After a SOAP activity has been added to an operation, menu actions for that activity are accessible from the project pane in both the Workflows and Components tabs, and from the design canvas:

  • Project Pane: In the Workflows or Components tab of the project pane, hover over an activity name and click the actions menu icon  to open the actions menu.

  • Design Canvas: Within the operation, click an existing activity block to open the actions menu.

Each of these menu actions is available:

  • View/Edit: This opens the activity configuration screen for you to configure the activity. For details, see Configuring a SOAP Activity later on this page.
  • Delete: This is used to permanently delete the activity (see Component Dependencies, Deletion, and Removal).
  • Rename: This positions the cursor on the activity name in the project pane for you to make edits.
  • View Dependencies: This changes the view in the project pane to display any other parts of the project that the activity is dependent on (see Component Dependencies, Deletion, and Removal).
  • Remove: Available only from the actions menu on the design canvas, this removes the activity as a step in the operation without deleting it from the project. When you remove an activity that is adjacent to a transformation, if schemas are provided within that activity, they will no longer be referenced by the transformation. Removed components can be accessed or permanently deleted from the project pane (see Component Dependencies, Deletion, and Removal).
  • Deploy: This deploys the activity and any components it is dependent on (see Component Deployment).
  • Configurable Deploy: This opens the deployment screen, where you can select project components to deploy (see Component Deployment).
  • Add to group: This opens a prompt to create a new custom group or to add the component to an existing group. Custom groups are an organizational tool to help organize a project (see Component Groups).
  • Duplicate: This creates a copy of the activity as a new, unreferenced component. Upon creating the component copy, the cursor is positioned on the component name within the project pane for you to rename the component.

Configuring a SOAP Activity

Follow these steps to configure a SOAP activity:

Step 1 – Enter Basic Information

  • Name: Enter a name to use to identify the SOAP activity. This field will be prepopulated with the name of the method. You may create multiple activities using the same method, but the name must be unique for each SOAP method and must not contain forward slashes (/) or colons (:).
  • 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 Discard Changes to close the configuration without saving changes made to any step. A message will ask you to confirm that you want to discard changes.

Step 2 – Review Data Schema

  • Data Schema: The request and/or response data schemas are displayed. If the operation uses a transformation, the data schemas will be 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 Discard Changes to close the configuration without saving changes made to any step. A message will ask you to confirm that you want to discard changes.

Next Steps

After configuring a SOAP activity, you can use it within an operation as described below. You may also want to configure chunking to split the data into smaller chunks for processing. A special use case on how to handle SOAP services that do not require request parameters is also covered below.

Completing the Operation

After configuring a SOAP activity, complete the configuration of the operation by adding and configuring other activitiestransformations, or scripts as operation steps (see Operation Creation and Configuration). 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 (see Operation Settings).

SOAP activities that are used as a source can be used with these operation patterns:

Other patterns are not valid using SOAP activities that are used as a source.

SOAP activities that are used as a target can be used with these operation patterns:

Other patterns are not valid using SOAP activities that are used as a target.

Operations that contain a SOAP activity can have only one SOAP activity and cannot also contain any NetSuite, SalesforceSAP, or ServiceMax activities.

Typically, an operation that calls a SOAP web service contains two transformations: The first transforms data into a web service request, and the second transforms data from a web service response to a target system. This example depicts how such an operation might be set up:

Operations that use SOAP activities can also have operation actions configured to trigger upon a SOAP fault — an error resulting from an incorrect message format, header processing, or incompatibility. Operation actions can be configured to run an operation or send an email after a SOAP fault occurs. For instructions on triggering an action upon SOAP fault, refer to Operation Actions.

When ready, deploy and run the operation (see Operation Deployment and Execution) and validate behavior by checking the operation logs (see Operation Logs).

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

Using a SOAP Service without Request Parameters

SOAP web services are commonly used as the first target in the Two-Target Transformation Pattern: A source provides the request that the SOAP web service takes as input, and the service then outputs a response that is written to another target.

But some SOAP web services might not require anything to be provided in the request beyond just asking for the service. In this case, two transformations are still required by the pattern, but the request structure may not have any fields that require mapping; instead, the structure may consist of only nodes without fields.

To demonstrate, this operation uses this US Holiday Service WSDL with the method GetHolidaysAvailable:

Within Transformation 1, we can see that all nodes are expanded and there are no fields present:

The result is an empty transformation without any mappings, which is required in order for the operation to be valid.

On This Page

Last updated:  Mar 11, 2020

  • No labels