API SOAP Request activity

Introduction

An API SOAP Request activity, using its preconfigured API connection, retrieves data when called by an API Manager custom API and is intended to be used as a target to consume data in an operation.

The API SOAP Request activity can be configured using a WSDL schema only. To interact with an API connection using a JSON, XML, CSV, or XSD schema, use a non-SOAP API Request activity instead. To interact with a SOAP connection without using a custom API, use the SOAP connector.

For information on the relationship between API connector activities and API Manager APIs, see these resources:

• API Manager API types

• Custom API configuration

• Building a simple custom API

Create an API SOAP Request activity

An instance of an API SOAP Request activity is created from the preconfigured API connection using its SOAP Request 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 API SOAP Request 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 API SOAP Request activity

Follow these steps to configure an API SOAP Request activity:

• Step 1: Enter a name and specify settings
  Provide a name for the activity and select the method to be used for uploading the WSDL schema.

• Step 2: Review the data schemas
  Any request or response schemas generated from the endpoint are displayed.

Step 1: Enter a name and specify settings

In this step, provide a name for the activity and select the method to be used for uploading the WSDL schema. Each user interface element of this step is described below.

• Name: Enter a name to identify the activity. The name must be unique for each API SOAP Request 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 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 Upload. The URL must be accessible without authentication or you will receive an error at runtime. If uploading a WSDL with the same name as an existing WSDL, see Replacing an uploaded WSDL later on this page.

  • Upload File: Click Browse (located on the right) to locally browse to a WSDL or ZIP file. If providing a ZIP file, it must contain a single WSDL file (though it can contain any XSD files that the WSDL is dependent on). Then click Upload.

    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:

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

    you would supply:

    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 WSDL and port provided 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

Any request or response schemas generated from the endpoint are displayed:

• Data Schemas: The request and response schemas for this activity are displayed. These data schemas are inherited by adjacent transformations are displayed again during transformation mapping.

• 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 re-uploading 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 and suggests to review adjacent transformations for potential mapping errors. Clicking Continue replaces the WSDL in all locations where it is used throughout the project:

Next steps

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

Complete the operation

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.

Menu actions for an activity are accessible from the project pane and the design canvas. For details, see Activity actions menu in Connector basics.

API SOAP Request activities can be used as a target 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 source only)
• Two-transformation pattern (as the first source only)

Operations that begin with an API SOAP Request activity cannot be executed manually using the operation Deploy and Run or Run options. Instead, these operations require data that is provided when an API call is made using a custom API created through API Manager. An API may be called from an application or — if the API supports GET — you can paste the URL into a web browser to consume the API manually.

A typical use case is to use an API SOAP Request activity in an operation chain, where the first operation is triggered by an API and the second operation runs on success of the first operation. Both operations in this example use the Transformation Pattern.

In this example, a custom API triggers the operation Inbound SOAP Request to run. The API SOAP Request activity (API SOAP Request) generates a response structure that is received by the transformation (API SOAP to Database), which is then upserted in a database using a Database Upsert activity (Upsert Response).

On success of the operation Inbound SOAP Request, the operation Outbound SOAP Response runs. A Database Query activity (Query Request) generates a response structure that is received by the transformation (Database to API SOAP), which is then returned to the API by an API SOAP Response activity (API SOAP Response):

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

Additional examples

Other examples using API activities as targets in an operation include Capturing data changes with an API Manager API or HTTP endpoint and Configure outbound messages with an API Manager API. (These patterns use Design Studio as an example, but the same concepts can be applied in Integration Studio.)

Configuring an API Manager custom API

After the operation setup is complete, configure a custom API using API Manager.