OAC Connectivity: Remote Data Gateway & Cloud Data Sources

Explain how OAC connects securely to on-premise data sources via the Remote Data Connector/Gateway, alongside native cloud data source connectivity.

OAC runs in the cloud. A lot of the data it needs is behind a corporate firewall, and moving the transactional database to the cloud is not the answer.

It's like a hotel room's safe that only opens from the inside — the on-premise gateway reaches out to check in with the cloud service itself, rather than the cloud service trying to reach in through a door the customer's IT security team would never agree to unlock from the outside.

Key Concepts

The Remote Data Gateway is an agent inside your network.

    corporate network                 OAC (cloud)
    +--------------------+            +----------------+
    |  on-premise DB     |            |  OAC           |
    |  Data Gateway      | ==tunnel=> |  connection    |
    +--------------------+            +----------------+
        connection opens outward

The direction is the point, and it is the same design as SAP's Cloud Connector. The gateway opens an outbound connection to OAC and keeps it open. Queries travel down that channel.

No inbound firewall rule, nothing exposed to the internet, and the administrator declares which data sources are reachable — so a compromised OAC instance can reach those and nothing else.

What it means for performance. Every query crosses the internet and back. A visualisation over an on-premise source is as fast as that link, which is fine for aggregated queries and poor for pulling millions of rows to be summarised in the browser.

So the design rule is to aggregate on the source. Push the grouping into the query rather than retrieving detail and reducing it afterwards.

Cloud sources connect natively — Autonomous Data Warehouse, Object Storage, other cloud databases and SaaS applications — with no gateway involved.

Which gives a common hybrid shape.

    warehouse in the cloud    -> native connection, fast
    a few on-premise systems  -> via the gateway, aggregated queries
    files                     -> uploaded as datasets

The operational note. The gateway is a component you run: it needs a host, monitoring, and updating. When it is down, every on-premise source disappears from OAC at once, and the symptom is reports failing rather than a clear message about the gateway.

Running two for redundancy is the answer where those reports matter, and knowing that the gateway is a single point of failure by default is the thing worth saying.

What the interviewer is probing.1. "What is the Remote Data Gateway for?" Probing: the purpose. Stalls: "Connecting." *Moves up:* letting OAC query on-premise sources through an outbound agent, so no inbound firewall hole is opened.

2. "How does it connect?" Probing: the mechanism. Stalls: "A VPN." Moves up: the agent polls OAC outbound and relays queries, which is why it works through a corporate firewall unchanged.

3. "What is the performance consideration?" Probing: the practical angle. Stalls: "None." Moves up: every query crosses the network to on-premise, so large result sets are slow — aggregate before returning.

4. "What is the alternative design?" Probing: the architecture. Stalls: "There is none." Moves up: replicate the needed data into a cloud database so queries stay local, which is what most teams end up doing for heavy use.