Loading…
Loading…
Learned examples are real request/response pairs captured from production traffic at your gateway edge, curated per service and operation.
Learned examples are real request/response pairs captured from production traffic at your gateway edge, curated per service and operation. They turn the traffic the platform is already observing for discovery into concrete evidence you can use while onboarding — and into a ground-truth check on your conversion mappings.
Instead of inventing sample payloads, you onboard against the messages your services actually exchange.
When ingest is healthy, the raw traffic log receives the full transaction artefacts per row — for F5 (via the relay path) and any connector whose edge provides them, that is the request body, response body, request headers, and response headers, alongside the transaction metadata (front-end/back-end endpoints, virtual servers, client IP, method, SOAP action, HTTP status, result code, and latency).
A background curator worker derives the learned-example dataset from those raw rows. A learned example is keyed by service and SOAP operation and carries:
The learned example's payload and header fields mirror whatever the raw ingest row carried at the moment the example was chosen. If a connector's edge does not capture bodies (many load balancers are URI-level by default — see load balancers), the metadata is still learned but the body fields will be empty for that source.
During onboarding, learned examples give you real per-operation sample payloads to work from — the actual XML your consumers send and the actual responses your backend returns — rather than synthetic stubs. They are surfaced on the discovery and observability surfaces (the "good examples" tile) so you can see representative live traffic for a service before and while you onboard it.
Because a learned example pairs a real SOAP request with its real response, it doubles as ground truth for your conversion mapping. You can confirm that the generated full-field mapping handles the shapes that actually occur in production — including the edge cases that synthetic samples miss — and catch gaps before they reach consumers. UTF-8 and Hebrew payloads are preserved end to end, so right-to-left and gendered-text content is captured faithfully.
The curator does not keep every transaction as an example — it keeps a representative, de-duplicated set per service/operation, incrementing a seen count when the same shape recurs rather than storing endless near-identical copies. This keeps the example set small, relevant, and fast to browse.
If a "good example" shows an empty response body for a service that does return response data, that is almost always a curation/derivation detail — not a sign that your edge isn't logging responses. The first thing to check is the raw traffic log for the same correlation ID: if the raw row has the response body, the data was captured and the gap is downstream of ingest. Only if the raw row is also missing the response is it an edge-logging configuration question.
Some traffic classes legitimately have no response body to capture (for example, fire-and-forget or acknowledgement-only operations); for those, an empty response example is expected and correct.
Learned examples are one of the curator-derived datasets that the platform builds from raw logs offline — alongside the aggregation tables that power the master discovery view. The raw log is the source of truth for both; the operator surfaces read the curated/aggregated outputs, which is what keeps them fast.