Loading…
Loading…
This is the operator vocabulary. The terms here map directly onto UI labels, API resources, and s2r_-prefixed database tables, so getting them straight first…
This is the operator vocabulary. The terms here map directly onto UI labels, API resources,
and s2r_-prefixed database tables, so getting them straight first makes everything else
read cleanly. For the buyer-facing plain-language glossary, see
docs/marketing/glossary.md.
Since v1.0 all concepts below are part of the General Availability product.
A service is a single onboarded SOAP/REST integration unit — usually one WSDL (Publish) or
one OpenAPI/REST backend exposed as SOAP (Consume). It has a stable serviceKey, a
human-readable name, one direction, one or more
operations, one or more environments, and a chain of
mapping versions. A service is the unit you publish, version, and observe.
An operation is one callable action within a service — a WSDL operation (e.g.
GetCustomer), surfaced on the REST side as a method + path (e.g. GET /customers/{id}) in
the Publish direction. Each operation carries its own request mapping, response mapping, and
fault handling, and can have its own conversion-option overrides. Most
mapping detail, validation, and override settings live at the operation tier.
A mapping is the deterministic, rule-based translation between the SOAP message tree and the REST/JSON shape for a given operation. It is generated from the WSDL/XSD (or OpenAPI, in the Consume direction) and covers the entire request and response tree — every element, attribute, optional field, and declared fault — not just the happy path. This is what "full- field mapping" means. Because it is derived by rules from the contract, the same contract always produces the same mapping (deterministic); there is no transformation language and no hand-authored mediation. You can apply field-level overrides where a business rule requires deviation from the default.
Mappings are captured as immutable, versioned snapshots (v1, v2, …). Once a version is
created it never changes. You activate a version to make it serve live traffic, and you can
roll back to any prior version with one click. Re-importing a changed contract produces a
new version and a change report (added/removed operations, breaking changes, per-operation
deltas) rather than mutating the active one. This is how you evolve a service safely without a
risky in-place edit.
A service runs in exactly one direction:
See Introduction → The Publish / Consume model for worked examples.
Discovery is the platform learning which SOAP services actually run in production by
observing live gateway-edge traffic — rather than you hunting down and uploading WSDLs by
hand. Discovered services appear in a master discovery view with per-service request counts
over 24-hour / 7-day / 1-month windows. These counts are served from pre-computed
aggregation tables (not raw logs at query time), which is what keeps the view sub-second even
across large estates. Consumer attribution is resolved from forwarded headers
(X-Client-IP / X-Forwarded-For / Forwarded). Discovery feeds onboarding; you don't have
to know your inventory in advance.
A connector is the integration that lets the platform discover services and ingest traffic from a specific edge product. Each connector matches what its vendor actually exposes (a management API for discovery and/or an HTTP log/traffic feed for ingest). Since v1.0 the shipped set includes load balancers (F5 BIG-IP, Citrix NetScaler/ADC, HAProxy, nginx, Kemp LoadMaster, A10 Thunder ADC, Radware Alteon) and API gateways (IBM DataPower, Layer7, webMethods, Akana, TIBCO Mashery, Oracle API Gateway), plus a generic-HTTP receiver — a universal "bring your own edge" ingest path with per-vendor parsers and a dead-letter queue, for any gateway or appliance that can emit accessible HTTP traffic logs. See Discovery & connectors.
A learned example is a real request/response payload (and its headers) captured from production traffic and curated against a service/operation. It lets consumers see what actually flows through an operation rather than synthetic placeholders, and it doubles as evidence when reviewing a mapping. Learned examples are derived by the worker from the raw ingest feed; the raw traffic feed carries request body, response body, request headers, and response headers for most traffic. See Discovery → Learned examples.
A conversion option is an operator-tunable behavior that controls how a SOAP shape becomes
a REST shape (or vice versa). Each option is settable platform-wide as a default and
overridable per service / per operation / per field, resolved down a tier chain (field
beats operation beats service beats platform default). Since v1.0 the catalog includes
date/time formatting, numeric and boolean handling, null handling, array collapsing,
whitespace, binary encoding, duration, field-name casing, SOAP header propagation, response
envelope shape, JSON field ordering, error/fault shape (including RFC 7807), xsi:type
discriminator handling, upstream-failure status mapping, required-field handling, and
request/response validation modes. Your chosen options are reflected in the generated
OpenAPI v3 as well as at runtime. See the conversion options
reference.
A correlation ID is a unique identifier attached to a request and carried through its entire lifecycle — runtime conversion, backend call, response, logs, and audit. It is the primary key for tracing and searching: log search, the live traffic log, and drill-down are all keyed by correlation ID. When diagnosing a single call, the correlation ID is what ties the raw log row, the structured runtime log, and any audit entry together. See Observability → Logs & tracing.
Contract drift is when a backend's response no longer matches the contract the platform
expects for an operation. The runtime detects drift on backend responses and surfaces it as an
explicit signal, so a silently-changed backend doesn't quietly corrupt the converted output.
Response-side schema validation can run in off / monitor / enforce modes; in enforce
mode a violating backend response is rejected as upstream contract drift (an S2R-VAL-0430,
returned as HTTP 502 — an upstream problem, not a client error). See
Conversion → Validation modes.
Access is governed by role-based access control with three roles:
| Role | Can do | |---|---| | admin | Everything: onboarding, publishing, configuration, RBAC, retention, and all operator actions. | | operator | Day-to-day operations: onboard, configure, publish/version, run tests, manage discovery — but not platform-level admin functions. | | reader | Read-only: view services, dashboards, logs, and audit; no changes. |
Roles are resolved from your identity provider's groups, from direct in-app principal bindings, or from an emergency bootstrap list. Every change is captured in the audit trail. Identity is established via Google IAP, Azure AD, or standard SAML / OIDC. See Security → RBAC & roles.
An environment is a named deployment target for a service's backend (for example dev,
test, prod). A service can carry distinct backend endpoints and credentials per
environment, and traffic/observability surfaces treat environment as an explicit dimension so
you can filter by it. Mapping versions are environment-agnostic — the same versioned mapping
can be promoted across environments — while backend connection details are environment-scoped.
Service (one direction: PUBLISH or CONSUME)
├── Operation(s) ← request/response/fault mapping per operation
│ └── Conversion-option overrides ← field/operation tier
├── Mapping version(s) v1, v2, … ← immutable, one active, rollback any
├── Environment(s) dev / test / prod ← backend endpoint + credentials per env
└── Learned example(s) ← real captured payloads, per operation
Discovery (traffic-driven, via Connectors) ──► populates the service inventory
Correlation ID ──► threads one call across runtime, logs, audit
Contract drift ──► flagged when a backend response stops matching the contract
RBAC roles (admin / operator / reader) ──► gate every action; audited