SOAP

• SOAP
  • Stubbing out a WSDL in component tests
  • Setting SOAP expectations

Service virtualization of SOAP APIs works in a similar way REST APIs.

However the API format for SOAP services is WSDL (not YAML). So you will need the WSDL file for the SOAP API that you need to stub out.

Stubbing out a WSDL in component tests

Commit the WSDL for the SOAP API into your central contract repository.

Once done, create the Specmatic configuration file in the root of your project. It should contain the following json configuration:

• specmatic.json
• specmatic.yaml

• {
    "sources": [
      {
        "provider": "git",
        "repository": "https://your-central-contract-repo.com",
        "consumes": [
          "/path/to/soap-api.wsdl"
        ]
      }
    ]
  }
  

• sources:
    - provider: git
      repository: https://your-central-contract-repo.com
      consumes:
        - /path/to/soap-api.wsdl
  

NOTE: Remember to update the repository and stub section, to reflect the git repository in which you placed the specification, and the stub path.

Setting SOAP expectations

Once again, you can use the same stub format that is used for REST APIs. The only difference is, put the SOAP payloads where the REST payloads would go.

It will look something like this:

{
    "http-request": {
        "method": "POST",
        "headers": {
            "SOAPAction": "\"SOAPAction\""
        },
        "body": "<your><soap><request><payload><here>"
    },
    "http-response": {
        "status": 200,
        "body": "<your><soap><response><payload><here>"
    }
}

You can get the actual SOAP requests and response payloads using the logs from Specmatic Proxy. While the proxy does not generate expectations for SOAP/XML yet, it does log these requests and responses to the console.