Documentation
¶
Overview ¶
dev-soap-mock is a development-only SOAP upstream that dev/start.sh launches alongside the platform, so the WSDL catalog path (#1736) can be exercised end-to-end against a service that actually speaks SOAP.
Nothing else in the stack does. The api-test fixture is a REST service, and before this the only SOAP in the repository was a string constant in a unit test — which is exactly the shape of gap that lets an envelope be assembled wrongly and pass every gate.
Two services run from one process, because the two SOAP versions differ in the three things most easily got wrong:
- /Orders.svc SOAP 1.1. Content-Type text/xml, the action in a quoted SOAPAction header, and an UNQUALIFIED schema, so child elements must carry no namespace.
- /Orders12.svc SOAP 1.2. Content-Type application/soap+xml with the action as a parameter, no SOAPAction header, and a QUALIFIED schema, so child elements must be in the target namespace.
Each service refuses a request that gets any of those wrong, with a soap:Fault naming what was expected. That is the point: a mock that accepted anything would let a caller's envelope be wrong in every one of those ways and still report success.
The XML here is parsed and written with encoding/xml rather than through the platform's own internal/soap. An upstream that shared the implementation it is meant to check would agree with it about a mistake.
Operations, on both services:
GetOrder(OrderId, Detail?) -> the order, echoing what it received ListOrders(Customer, Limit?) -> a repeated element, for list encoding FailOrder(Reason) -> always a soap:Fault, HTTP 500
Usage:
go run ./cmd/dev-soap-mock SOAP_MOCK_ADDR=:9999 go run ./cmd/dev-soap-mock
Health:
curl http://localhost:9285/.health curl 'http://localhost:9285/Orders.svc?wsdl'
Source Files