SOAP-WSDL Connector Guide

Design time behavior

The SOAP-WSDL connector parses a WSDL file and generates for each WSDL method an operation-type asset and each WSDL structure an entity-type asset. The connector can access the WSDL locally or fetch the file from a remote server.

Runtime behavior

The SOAP-WSDL connector receives from a client a JSON request (formatted according to the assets generated from the WSDL file on design time). The connector then converts the JSON request to a SOAP request and transfers it via HTTP to the data source endpoint. The data source sends back its response in SOAP format, and the connector parses the response and converts it to JSON before sending it back to the client.

Guide topics

The SOAP-WSDL connector guide includes the following topics:

Create a SOAP-WSDL asset: a detailed step-by-step tutorial on how to create a SOAP-WSDL module and assets.
Connector properties: a list of all the connector properties and their explanations.
Connector runtime behavior: a short description of the connector role on runtime.

Create SOAP-WSDL module and assets

To create a SOAP-WSDL asset, perform the following steps.

Step 1. Before you start

Before creating the SOAP-WSDL module, make sure that you have a WSDL data source file or an accessible WSDL file on a remote server that the connector can fetch.

Step 2. Create a SOAP-WSDL module

First, create the SOAP-WSDL module.

> ol create module --connector soap-wsdl module-soap-wsdl

$ ol create module --connector soap-wsdl module-soap-wsdl

Step 3. View the properties of the SOAP-WSDL connector

Review the connector properties. For more information on the SOAP-WSDL connection properties, see Properties below.

Navigate to the module folder:

> cd module-soap-wsdl

$ cd module-soap-wsdl

From under the module directory, display the help menu of the ol add command:
```
[module-name]> ol add --help
```
```
[module-name]$ ol add --help
```

The ol add help menu displays the connector property list.

Step 4. Test the connection to the remote server

Run the ol test connection command with the --host option to verify that the data source is accessible and that the connection properties are correct.

[module-name]> ol test connection --host http://www.dneonline.com/

[module-name]$ ol test connection --host http://www.dneonline.com/

Thanks to SoapUI for providing the open-source testing tool used in this connector guide.

Step 5. Add an asset to the SOAP-WSDL module

After you verified the connection parameters, you can create a SOAP-WSDL asset. The ol add command generates one or more asset folders, depending on the number of methods and structures defined in the WSDL file. Each asset folder contains the asset configuration file ([asset-name].json) and the asset testing resources. For every WSDL method, the command creates an operation-type asset and an entity-type asset for every WSDL structure.

[module-name]> ol add --source-path http://www.dneonline.com/calculator.asmx?wsdl

[module-name]$ ol add --source-path http://www.dneonline.com/calculator.asmx?wsdl

Step 6. Test the SOAP-WSDL asset

Test the asset you added to verify that you can request and receive actual business data from the data source.

From your module folder root go to assets/multiply/test_data/case1/:

[module-name]> ol cd assets/multiply/test_data/case1/

[module-name]$ cd assets/multiply/test_data/case1/

To view and edit the test input data open in.json:
```
case-1> notepad in.json
```
```
case-1$ notepad in.json
```

in.json contains the information sent to the remote business operation. It consists of the input keys and values that the business operation requires.

{
  "multiply" : {
    "intA" : 2,
    "intB" : 3
  }
}

In in.json, type the values of the input properties. In the example above, for the intA key type 2 and the intB key 3.

Now you are ready to run ol test asset:

> ol test asset multiply

$ ol test asset multiply

The response from the remote server is displayed:

{
  "multiplyResponse" : {
    "multiplyResult" : 6
  }
}

Properties

--source-path

A WSDL source file either from a local directory or from URL resource (required)

--source-path ./file-name.wsdl

--host

The host address

--host http://www.example.com/

--username

The host username

--username User001

--password

The host password

--password P@ssw0rd

--authentication-type

The connection authentication type (http-header/soap-header).[HTTP_HEADER, SOAP_HEADER, WSS] (default: SOAP_HEADER)

--authentication-type http-header

--trust-self-signed

Specify whether the HTTP client will trust self signed certificates. Not recommended - preferable to use signed certificates or import the certificate in your JVM truststore. (default: false)

--is-trust-self-signed  true

--skip-null-fields

Specify whether to serialize fields with a null value in the request (default: true)

--is-skip-null-fields true

--wss.user-name-token

The username token to be included in the <wsse:UsernameToken> element of the <wsse:Security> header. Including the username token enables the end-user identity to reach the destination web service even when multiple hops are on its path.

--wss.user-name-token UserNameToken

--wss.user-name

The username to be included in the <wsse:Username> element of the <wsse:Security> header. This required element specifies the claimed identity.

--wss.user-name UserName

--wss.password

The password to be included in the <wsse:Password> element of the <wsse:Security> header. There are two pre-defined types of password: PasswordText and PasswordDigest. PasswordDigest contains a password's digest (cryptographic checksum of password and optionally nonce and/or timestamp), and it is generated using SHA-1 algorithm. PasswordText is a default type and is used to hold a non-encrypted password

--wss.password myPassword

--wss.created

The request timestamp to be included in the optional <wsu:Created> element. The timestamp is appended to the nonce value to ensure that the nonce is used only once, therefore, providing a countermeasure for replay attacks.

--wss.created 2020-10-27T14:03:43.657Z

--wss.nonce

The nonce value to be included in the optional <wsse:Nonce> element of the <wsse:Security> header. A nonce is a random value the sender creates to include in each UsernameToken that it sends. Without nonce, when a UsernameToken is passed from one machine to another machine using a non-secure transport, such as HTTP, the token might be intercepted and used in a replay attack.

--wss.nonce ScdbTKR2ZZytJvjdvZu