Skip to main content

Mocking SOAP Services

Beeceptor’s template engine provides native support for SOAP-based services, allowing you mocking and debugging of SOAP/XML requests. With the introduction of SOAPAction filters, you can precisely target specific SOAP operations and configure custom mock responses or SOAP faults as required.

Matching SOAP Operations​

Beeceptor's SOAPAction Matches filter in mock rules, making it easier to handle and test SOAP/XML-based requests. Many SOAP clients send a SOAPAction header or embed the operation name in the Content-Type header or SOAP body. This filter allows you to create mock rules that specifically target these SOAP requests, giving a better support for SOAP-based integrations.

Beeceptor automatically detects the SOAP action from various request components, ensuring smooth matching without the need to worry about version compatibility in your mock rules.

soap-action filter in mock rules

How It Works

The 'SOAPAction Matches' filter evaluates the incoming request and attempts to extract the SOAPAction value from multiple sources in a prioritized order:

  1. Content-Type Header – Looks for the action parameter in the Content-Type header (commonly used in some SOAP clients).
  2. SOAPAction Header – Extracts the value from the SOAPAction HTTP header, removing extra quotes if present.
  3. WS-Addressing in SOAP Body – If WS-Addressing headers are present in the XML, the SOAP action is read from there.
  4. Operation in SOAP Body – Falls back to parsing the SOAP body to determine the invoked operation.
  5. URL Path – As a last resort, the final segment of the request path is considered as the operation name.

If a valid SOAP action is found, Beeceptor checks it against the value defined in your mock rule. If it matches, the request qualifies and corresponding mock response is sent to the client.

SOAP Envelope​

Beeceptor automatically parses incoming SOAP/XML request payloads and converts them into an easy-to-use JSON object for response templates. During this conversion, XML namespaces are removed to simplify access.

SOAP requests generally follow a specific structure, which includes an Envelope, Header, and Body. The Envelope is the root element that wraps the entire message, while the Body carries the actual request data. With this JSON representation of SOAP envelope, Beeceptor makes it straightforward to access elements such as the envelope, headers, and request parameters directly within your mock rules.

If you receive a SOAP request:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://www.example.com/webservice">
   <soapenv:Header/>
   <soapenv:Body>
      <web:GetCityWeatherByZIP>
         <web:ZIP>10001</web:ZIP>
      </web:GetCityWeatherByZIP>
   </soapenv:Body>
</soapenv:Envelope>

Beeceptor parses the SOAP envelope and converts it to a simplified JSON object, which you can then use in your templates.

Intermittent JSON object in Beeceptor​

Beeceptor removes the XML namespace complexity and structures the SOAP request into a JSON format. This makes it straightforward to access the envelope, headers, and body parameters within your template.

{
  "Envelope": {
    "Header": {},
    "Body": {
      "GetCityWeatherByZIP": {
        "ZIP": "10001"
      }
    }
  }
}

In the above JSON structure:

  • The Envelope is the root, encapsulating the Header and Body.
  • The Body contains the actual request data, such as GetCityWeatherByZIP and its parameter ZIP.

You can access these parameters in your templates by referencing the path using dot notation on JSON object. For example, you would use the body helper to fetch the ZIP code from the parsed SOAP request.

Accessing Request Parameters in the Mocking Template​

Here’s an example template that uses the ZIP code from the SOAP request to generate a mock response with dynamic data.

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:web="http://www.example.com/webservice">
   <soapenv:Body>
      <web:GetCityWeatherByZIPResponse>
         <web:CityWeather>
            <web:City>New York</web:City>
            <web:ZIP>{{body 'Envelope.Body.GetCityWeatherByZIP.ZIP'}}</web:ZIP>
            <web:Weather>Cloudy</web:Weather>
            <web:Temperature>18</web:Temperature>
            <web:Humidity>{{faker 'number.int' '100'}}</web:Humidity>
         </web:CityWeather>
      </web:GetCityWeatherByZIPResponse>
   </soapenv:Body>
</soapenv:Envelope>

Key Points on Handling SOAP Requests​

  • Namespaces: Beeceptor automatically handles the XML namespaces in SOAP requests, stripping them out so you don’t have to worry about them when writing mock templates.
  • Accessing Nested Elements: You can easily access deeply nested elements within the SOAP body using the body helper with dot notation. For example, to access ZIP in the SOAP body, you can use {{body 'Envelope.Body.GetCityWeatherByZIP.ZIP'}}.
  • Handling Missing Data: If a parameter is missing from the SOAP request, you can provide a default value in the template using the body helper's second parameter. For example: {{body 'Envelope.Body.GetCityWeatherByZIP.ZIP' 'Unknown'}}.
  • Dummy Values: You can combine the faker helper to generate random data in the mocked response, allowing for more dynamic and realistic test scenarios.