Loading…
Loading…
The conversion engine is the heart of the product. Since v1.0 it converts in both directions on one runtime:
The conversion engine is the heart of the product. Since v1.0 it converts in both directions on one runtime:
The defining property is that mapping is deterministic and full-field: every element of the request and response tree is mapped automatically from the WSDL/XSD contract — not a generic passthrough, and not just the fields someone remembered to map. There is no mediation language to author and no per-service code to maintain.
This page explains the mapping model. For the operator-tunable behaviors that ride on top of it, see the Conversion options reference.
When you import a WSDL, the parser materializes a canonical contract per operation — the full XSD tree for the request and the response, captured as an immutable snapshot with a checksum and parser version (see Import a WSDL and SOAP & XSD support). From that contract the platform generates an explicit, compiled mapping. The mapping is not heuristic guesswork executed per request: it is a compiled plan, cached per active operation version, so converter overhead stays low.
"Deterministic" means the same contract always produces the same mapping, and the same input always produces the same output. "Full-field" means the generated rules walk the entire tree — wrappers, nested complex types, arrays, choices, attributes, and mixed content — not just the top level.
For an inbound REST/JSON request the engine builds a valid SOAP envelope:
minOccurs / maxOccurs; reject a missing required
field with a clear validation error before the backend call.nillable="true" element with a null value becomes xsi:nil="true"; a
non-nillable null is a validation error.xsd:sequence order; enforce exactly one branch for xsd:choice.In the Consume direction the request leg runs the other way — an inbound SOAP envelope is parsed and converted into the outbound REST call (see Consume direction).
For the SOAP response the engine produces a stable, typed JSON shape:
Envelope/Body/<OperationResponse> wrappers
down to the mapped payload root via the recorded unwrap chain.xsi:nil, empty nodes, missing nodes — xsi:nil="true" → null; an empty element
follows your configured null/empty policy for its type; a missing optional node is omitted by
default.Conversion options (field casing, array collapse, envelope wrap, JSON field ordering, and the rest) shape the final JSON — see the reference.
A <soap:Fault> — for either SOAP 1.1 (faultcode / faultstring / detail) or SOAP 1.2
(two-level Code/Value plus application Subcode) — is normalized into a deterministic REST
error shape. You choose that shape with the error-shape conversion option: the platform
default object, RFC 7807 Problem Details, a flat error body, or the upstream payload passed
through unchanged. The HTTP status a backend failure surfaces as is governed by the
upstream-failure-status option (propagate vs mask-as-200). WSDL-declared wsdl:fault detail
contracts are reflected in the generated OpenAPI v3 so consumers know an error's shape before
they hit one. See SOAP & XSD support → Faults.
The generated mapping is explicit and inspectable, not a black box:
rules[] list of compiled instructions (fromJsonPath → toSoapPath, with type, coercion,
required, namespace).unwrapChain[], and a rules[] list
(fromSoapPath → toJsonPath, with type, coercion, null policy, array policy).Every generated artifact stamps the mapping-engine version, contract version, contract parser version, and contract checksum, so you always know exactly which contract a live mapping was generated from.
Mappings are immutable and versioned. Activating a version makes a snapshot live; you can roll back to any prior version at any time. Editing a field override creates a new revision rather than mutating the active one. See Publish & version a service.