IBM DataPower connector

IBM DataPower is the lighthouse legacy-API-gateway connector. It establishes the management-API-discovery plus HTTP-log-ingest pattern that the other legacy API gateways (Layer7, webMethods, Akana, TIBCO Mashery, Oracle OAG) reuse.

A note on vendor names. This page names IBM DataPower because the product integrates with it. That is interoperability information, not a comparison.

---

What the connector does

| Side | Mechanism | |---|---| | Discovery | The platform polls DataPower's REST management interface (/mgmt/) to enumerate domains and the services within each (e.g. MultiProtocolGateway, WSGateway, WebAppFW), with their front-end and back-end endpoints. | | Ingest | DataPower streams traffic to the platform via an HTTP log target (and/or syslog log target), parsed into the canonical transaction shape. |

Discovery is read-only for inventory; the connector also automates the log-target configuration on the gateway as part of onboarding.

---

Discovery via the REST management interface

DataPower exposes a REST management interface under /mgmt/, returning structured JSON for:

• Domains — the configured application domains on the appliance.
• Services per domain — the gateway objects (multi-protocol gateways, web-service gateways, etc.) and their configured front-side handlers and back-end URLs.

Polling the management interface gives a structured inventory — names, addresses, the front-to-back topology — rather than one scraped from URLs in traffic alone, and it surfaces configured-but-idle services. The platform uses a service account with read access for the discovery poll.

Version note. The REST management interface requires DataPower 7.2.0.0 or newer (the release line that introduced it). DataPower appliances older than 7.2 are out of the standard product's scope and handled as a targeted engagement — see Scope — the mainstream 80%.

---

Traffic ingest via the HTTP log target

DataPower can stream its logs to a remote endpoint. The connector uses an HTTP log target (DataPower POSTs each log record to the platform's ingest endpoint); a syslog log target is also supported where an operator prefers the same relay path used for load balancers.

Baseline vs. payload capture. A standard DataPower log target captures transaction events — correlation/transaction ID, front-end URI, back-end URL, client IP, status, method, and elapsed time. To capture the request and response bodies (and headers), DataPower requires a log action inside the service's processing policy, configured to emit the message context. The connector's baseline ingest does not require the bodies; when an operator adds the policy log action, the captured payloads flow through into the optional payload and header fields and become available to learned examples.

Adding the log action to a processing policy is the main operator task on the DataPower side, because each service policy that should be observed at the payload level must be edited. The onboarding flow assists with this.

---

What lands in the platform

The connector normalizes DataPower log records into the canonical transaction shape used by every connector: front-end URI, back-end URI, front virtual server (the DataPower service object name), client IP, gateway IP, HTTP method and status, latency, and — when the policy log action is configured — request/response bodies and headers. Records land in the unified traffic-log table tagged gateway_type = datapower, are rolled into the same aggregation tables that drive discovery, and feed the same observability surfaces.

Non-transaction log events (object lifecycle, error events without a transaction) are recognized and skipped rather than ingested as traffic.

---

Related

• API gateways — the Layer7 / webMethods / Akana / TIBCO Mashery / Oracle OAG connectors that reuse this management-API-plus-HTTP-log pattern.
• Generic-HTTP receiver — the underlying ingest receiver and envelope.

---

All Specaria SOAP to REST docs