Mocking a SOAP service

Right-click a folder ▸ Add ▸ SOAP server.

Configuring

Each mocked operation is a list entry:

Field	Role
SOAPAction	The header value that identifies the operation
Name	The operation’s name
Response body	The XML envelope returned
Fault	Replies with a `<soap:Fault>` and an HTTP 500 status

A SOAP server item: the listening address, then two mocked operations — CreateInvoice, which returns a response body, and CancelInvoice, whose "Fault" box is ticked

Matching

An operation is chosen:

first by its SOAPAction — that is the normal route;
failing that by its name, compared with <soap:Body>’s first child.

That fallback is what lets you mock services whose client sends no SOAPAction header.

Mocking a fault

Mark an operation as a fault and Restorm replies with a <soap:Fault> envelope and an HTTP 500 status — exactly what a real SOAP service produces when it errors.

That is hard to provoke on a staging service, and yet it is the path your client has to know how to handle.

In a scenario

The SOAP server and SOAP server close actions. See Hosted servers.