How It Works

Two parts, one clean line of separation

The Portal is where you configure things. The Gateway is what actually touches your data. They never share credentials.

Oracle Fusion Cloud
Your tenant
↔
Gateway
Runs on your server
↔
Your SQL Server
DEV / TEST / PROD

The Gateway polls the Portal for pipeline definitions and schedules, then connects directly to Fusion and your SQL Server using credentials that never leave your network.

From draft to scheduled run

1

Write and test the query

Build the SQL in the Portal's query editor. Run it against a small, hardcoded row limit to confirm it returns what you expect — nothing touches your production tenant yet.

2

Map fields to your table

Pull your SQL Server table's schema through the Gateway, then map each query column to a target field, with type conversion and any value transformations applied.

3

Choose a load strategy

Pick from Insert Only, Full Replace, Soft Deactivate & Merge, Delete-Match & Insert, or write Custom SQL for the merge step — the wizard generates the rest.

4

Publish

Publishing creates a real, named BI Publisher report in your Fusion environment's dedicated custom folder — a standard SQL report, not a workaround.

5

Schedule it

Set a recurrence, and the Gateway picks up the schedule on its next sync. Runs happen locally, in your time zone, with retry and row-level error handling built in.

6

Monitor and adjust

Every run is logged — success, partial success with skipped rows, or failure with a clear reason. Unschedule or detach a pipeline any time; you can always re-publish it later.

SQL Server is the common target, but not the only one. The Gateway can also be configured to load into other databases, or to export each run straight to plain spreadsheet files — the pipeline, mapping, and schedule you build stay exactly the same.

Curious how this fits your current warehouse setup?

Let's talk