Loading…
Loading…
Publishing makes a service live: it activates an immutable mapping version, generates the consumer-facing contract (OpenAPI v3 for Publish, WSDL serve-back for…
Publishing makes a service live: it activates an immutable mapping version, generates the consumer-facing contract (OpenAPI v3 for Publish, WSDL serve-back for Consume), and starts serving the converted endpoint. This page covers the publish readiness gate and how mapping versions work.
Before a service can publish, the platform assesses readiness so you don't ship a broken mapping by accident. Readiness combines per-operation mapping diagnostics, the backend configuration, a successful backend test, and (after first publish) WSDL-drift signals.
Each operation gets a generated-mapping quality grade from the contract parse:
| State | Meaning |
|---|---|
| AUTO_READY | The generated full-field mapping is complete; no manual action is needed before publishing this operation. |
| AUTO_READY_WITH_WARNINGS | The operation can publish, but the platform flagged something to review (e.g. an edge-case XSD construct, an ambiguous mapping, a capability note such as MTOM/XOP or WS-Addressing). Review the warnings; you can publish through them. |
| MANUAL_REQUIRED | The operation needs operator attention before it can publish (e.g. a construct the auto-mapper cannot resolve unambiguously, or a missing required input). Resolve it via field overrides or by deselecting the operation. |
The operation-level diagnostics UI explains why a field is required/optional, previews the input and response contract trees, and previews the generated rules — so a warning or manual-required flag tells you exactly where to look.
A service rolls its operations' readiness up to a service-level gate. In practice publish readiness resolves to one of:
AUTO_READY; nothing blocks publish.AUTO_READY_WITH_WARNINGS; you can
publish after acknowledging the warnings.MANUAL_REQUIRED, or a non-mapping
prerequisite is unmet; publish is blocked until resolved.Non-mapping prerequisites that participate in the gate include a configured, reachable backend (a backend test that fails with the configured auth/timeout blocks publish) and — for Consume services — the four required grounding inputs (Consume direction).
Mappings are immutable and versioned. You never edit a live mapping in place — every change (a regenerate, a field override, an option change) produces a new revision.
Each version stamps the mapping-engine version, contract version, contract parser version, and contract checksum, so you always know which contract a live mapping was generated from. See How mapping works → versioned & immutable.
You can regenerate the mapping per operation or for the full service (for example after a WSDL update). A non-breaking check report is produced before activation so you can confirm a regenerate doesn't break existing consumers before you make it live.
After publish, the platform watches the source WSDL for change. Drift state per version is one
of UP_TO_DATE / DRIFT_DETECTED / BREAKING_DRIFT / UNTRACKED. This reuses the same
re-import change detection machinery that compares
operations and counts breaking changes.
When drift is detected on a live service you can generate a replacement draft from the newer WSDL that preserves your existing REST paths and runtime policy for operations that still exist — so you upgrade the contract without re-doing your onboarding work. Review the replacement draft, then activate it as a new version (with rollback always available).
MANUAL_REQUIRED cases.