Onboarding a service — overview

Onboarding is the no-code process that takes a SOAP (or REST) contract and turns it into a live, converted endpoint with a generated machine-readable contract,…

Onboarding is the no-code process that takes a SOAP (or REST) contract and turns it into a live, converted endpoint with a generated machine-readable contract, deterministic full-field mapping, and observability — without writing a mediation script.

Since v1.0 onboarding runs in two directions on the same runtime:

Publish — a REST facade over a SOAP backend. Consumers call generated REST/JSON; the runtime converts to SOAP and calls your existing backend. Published contract: OpenAPI v3.
Consume — a SOAP facade over a migrated REST backend. Legacy SOAP clients keep speaking SOAP; the runtime converts to REST and calls your migrated backend. Published contract: WSDL (served back at the consume endpoint).

See Introduction → Publish / Consume for the conceptual model.

The Publish flow at a glance

Discover → Import WSDL → Configure backend → Review OpenAPI → Publish & version

Discover (optional). If your gateway forwards traffic to the platform, services are discovered from real edge traffic and you onboard a row directly. See Traffic-driven discovery. You can skip this and start from a WSDL.
Import the WSDL. Upload a file, paste a URL, or paste raw XML. The parser materializes a per-operation request/response contract and infers a draft service, backend endpoint, SOAP version, and auth hint. See Import a WSDL.
Configure the backend. Set the endpoint URL, SOAP version, auth, timeout/retry, and (optionally) multi-backend routing with failover and health checks. See Configure the backend.
Review the OpenAPI. Generation runs at publish; the emitted OpenAPI v3 reflects your conversion options and per-operation fault schemas. Review it before going live. See Generate & review the OpenAPI.
Publish & version. A publish-readiness gate combines mapping diagnostics, backend configuration, a successful SOAP test, and WSDL-drift signals. Activating a version makes an immutable mapping snapshot live; you can roll back at any time. See Publish & version a service.

Every generated operation gets a deterministic, full-field mapping (how mapping works). Manual work is for exceptions only.

Zero-touch shortcut

You can collapse Discover → Import → Generate into a single step with zero-touch autopilot: the platform imports the WSDL, generates the service, operations, and mappings, and reports a readiness score per operation, leaving you to review and publish.

The Consume flow at a glance

The Consume (SOAP-facade) direction modernizes the backend while keeping legacy SOAP clients working. It requires four grounding inputs, supplied in order:

Service identity → Old WSDL → REST OpenAPI → REST backend config (incl. auth)
                 → Example payloads → Mapping review → Publish (WSDL serve-back)

The runtime accepts SOAP 1.1 or 1.2 inbound, converts to a REST call against the migrated backend (with outbound REST auth), and wraps the REST response back into a SOAP envelope. The consumer-facing contract is the WSDL served back at the consume endpoint, not OpenAPI.

See Consume direction (SOAP facade) for the full flow.

Runtime URL shape (both directions)

Every runtime invocation uses the same direction-prefixed path:

/{publish|consume}/{environment}/{serviceKey}/{operationPath...}

The direction segment is required; a path without it is rejected with HTTP 400. The published OpenAPI servers[].url (Publish) and the emitted WSDL <soap:address> (Consume) both carry the direction segment so generated clients hit the canonical route.

What every onboarded service gets

A deterministic, full-field mapping generated from the contract — see How mapping works.
Conversion options that resolve through a system → service → operation → field hierarchy — see the Conversion options reference.
Field-level overrides in the UI for the exceptions — see Field-level overrides.
Request and response validation modes (off / shadow|monitor / enforce) — see Validation modes.
Immutable, versioned mappings with activate/rollback.
Observability from the first call — dashboards, logs, audit. See Observability.

Next reads

All Specaria SOAP to REST docs

Loading…