Loading…
Loading…
Learn how the platform automatically discovers SOAP services from live gateway traffic, attributes consumers, and uses pre-computed aggregations for fast
Traffic-driven discovery automatically builds a complete and current inventory of SOAP services by observing live traffic at your gateway edge. As most enterprise SOAP estates have grown over many years, a complete inventory is often unavailable. This component solves that problem by creating an inventory from the traffic that is already passing through your load balancers or API gateways. If a service is receiving live traffic, it will be discovered.
The discovery process is a foundational input for API modernization. It provides an evidence-based, ranked worklist of services, enabling API publishers to prioritize which services to onboard and modernize based on actual usage. Discovery identifies what to onboard and in what order (busiest first), while the onboarding process turns a discovered service into a published one.
The system is designed for performance at scale. Operator-facing views, such as the master discovery view and dashboards, query pre-computed aggregation tables rather than raw traffic logs. This ensures that the UI remains responsive, loading in sub-second time even for estates with hundreds of services.
The discovery mechanism ingests data from your gateway edge, persists it, and processes it in the background to build and maintain the service inventory. This process involves learning the inventory from multiple inputs, attributing traffic to the correct consumers, and using an aggregation-based read path for performance.
The platform learns the service inventory from two complementary inputs, which a connector can provide:
Discovery is not limited to a single source. Traffic from the platform's own runtime proxy is also discovered. The Source of the discovery data is an explicit dimension, allowing you to filter views to a single source or see a combined view across all sources. By default, metrics are summed across all sources.
To answer "who is calling what," the platform attributes each transaction to the original API consumer. It inspects a chain of standard headers in a specific order to find the consumer's IP address, resolving it from the client IP rather than an intermediate gateway's IP.
The platform searches for the client IP in the following headers, in order of precedence:
| Header | Description |
|---|---|
X-Client-IP | A dedicated header for the client's IP address, often injected by the edge gateway. |
X-Forwarded-For | The de-facto standard proxy chain header. The platform selects the left-most IP address that is not a gateway's own IP. |
Forwarded | The RFC 7239 standard header. The platform processes this header, including its for= parameter. |
The first IP address found that is not the gateway's own immediate-hop IP is used for attribution. If no forwarding headers are present, or if all candidate IPs match the gateway's IP, attribution falls back to the gateway's IP address itself. In this case, the transaction is still ingested and the service is discovered, but the fine-grained, per-consumer analytics are lost.
A core architectural principle of the platform is that time-bucketed operator surfaces read from pre-computed aggregation tables, never from raw logs at query time. This rule applies to all traffic sources and is key to the platform's performance.
A background worker continuously processes raw transaction logs and rolls them up into these aggregation tables.
Aggregation tables are used by:
Raw logs are reserved for specific, targeted use cases:
This design ensures that operator UIs remain fast and responsive regardless of the total volume of raw traffic data, with data freshness determined by the aggregation refresh interval.
The master discovery view is the primary UI for interacting with the discovered service inventory. It presents a list of every discovered service, ranked by traffic volume over several rolling time windows.
The view includes the following metrics for each service:
| Window | Meaning |
|---|---|
| 24 hours | Indicates how busy the service is currently. |
| 7 days | Shows the recent steady-state traffic volume. |
| 1 month | Helps distinguish long-lived services from transient or one-off services. |
By sorting this list by any of the time windows, an API publisher can create an evidence-based worklist, prioritizing services for modernization based on real-world usage. This immediately surfaces high-traffic services that may have been forgotten and highlights services that have become inactive.
Condition: All or most traffic appears to originate from a single consumer, which is the IP address of the gateway or load balancer itself.
Cause: This occurs when the edge gateway does not inject a header containing the original client's IP address into the requests it forwards to the platform. Without one of the supported headers (X-Client-IP, X-Forwarded-For, Forwarded), the platform can only see the IP of the immediate upstream hop, which is the gateway.
Resolution: Configure your edge gateway to inject one of the supported client IP headers. This is a configuration recommendation, not a strict requirement, as discovery will still function without it. However, for accurate consumer attribution and analytics, header injection is necessary. Each connector's documentation provides specific instructions for enabling this feature for that vendor's gateway.