Four tools over one backend: a JDBC driver, an MCP server for AI agents, a native Oracle endpoint your database can link to, and a desktop client for accountants. No new platform, no data pipeline, no per-question BI Publisher report.
| If your stack is… | Use | Maturity | What it gives you |
|---|---|---|---|
| DBeaver, SQL Developer, DataGrip, JVM code, Airflow | OFJDBC | Established | A JDBC driver. Drop the JAR in, get autocomplete and live SQL. |
| Claude, Gemini, any MCP host | ofrag | Active | Semantic search over the schema, SQL validated before it runs. |
| SQLcl, python-oracledb, another Oracle database — or Toad / PL/SQL Developer | Oracle Fusion TNS Proxy | New | A real Oracle listener on 1521 — including dblink from EBS. Toad and PL/SQL Developer take the same Oracle-client path, not yet tested. |
| Accountants and support who don't write SQL | FusionLens | Active | Desktop GL investigation — pivot, drill, jump into Fusion. |
A read-only JDBC driver that turns your SQL into BI Publisher calls. Drop the JAR into DBeaver and you get autocomplete, syntax highlighting and a result grid against Fusion; drop it into Airflow or any JVM service and you have a data pipeline without a new integration.
An MCP server. A model can write SQL, but it cannot know that AP_INVOICES_ALL exists or that a status flag uses 'N'. ofrag gives it semantic search across 25,000+ tables and 500+ REST resources, and checks the SQL against a locally cached schema before anything runs — catching invented tables and columns early.
oratofusionproxyAn implementation of Oracle's own wire protocol — TNS, TTC, O5LOGON. Point SQLcl, DBeaver, SQL Developer, ojdbc or python-oracledb at 127.0.0.1:1521 and Fusion answers like any Oracle database. The reason it exists: a real Oracle instance — EBS R12, a warehouse — can read Fusion over a plain CREATE DATABASE LINK, with no Database Gateway and nothing installed on the database host.
A read-only desktop client for GL investigation. Pivot or flatten balances, then drill from any cell into the journal, the SLA line and the source document, with deep links back into the live Fusion page. Credentials live in the OS keychain.
Every tool reads the same tenant through the same backend, so the choice is only about the client you already have open. The table above decides it in one line — and switching later costs nothing but a different download.
Back to the chooser → All repositories →There is no undocumented API and no direct database connection to your tenant. Each tool sends SQL to a single universal BI Publisher report and parses what comes back. That is why the tools behave consistently — and why the setup below is done once, not per tool.
your tool
DBeaver · Claude · SQLcl · EBS dblink · FusionLens
│
▼
OFJDBC ofrag Oracle Fusion TNS Proxy FusionLens
│
│ SOAP
▼
one universal BI Publisher report (DM_ARB.xdm + RP_ARB.xdo)
│
▼
Oracle Fusion Cloud tenant
A BI Publisher developer uploads two catalog files — DM_ARB.xdm.catalog and RP_ARB.xdo.catalog, both in the ofjdbc repository — into a folder you control, typically /Custom/Financials/. Every tool reuses that same report; nothing else is installed in Fusion. If you already run OFJDBC, this step is done.
Each tool authenticates as you (SSO or basic) and runs the report as that account. It sees exactly what your Fusion privileges allow — no service account with wider access, no shared gateway.
Every query is a report execution: expect hundreds of milliseconds to seconds before the first row, depending on tenant load, result width and row count. Schema browsing is answered from a local cache, so only real queries pay that cost.
| Capability | Can it modify Fusion? | Notes |
|---|---|---|
| SQL through any of the tools | No | BI Publisher cannot write. DML and DDL are refused before they reach the tenant. |
| ofrag REST tools | Yes | Fusion REST APIs support create and update. Bounded by your own permissions — review before enabling in production. |
| ofrag ESS job submission | Yes | Submitting a job starts real business processing. Same caveat. |
| Metadata cache | No | Held locally. Schema browsing and validation run against it without touching Fusion. |
No data passes through infrastructure operated by me — the tools connect from your machine straight to your tenant. What you then send to an AI or embedding provider you configure is, naturally, seen by that provider. If your organisation has an AI data policy, that is the part to check.
OFJDBC is open source under MIT — read every line if you want to. The others ship as binary downloads with public documentation, not as source. All of them are ordinary local processes: run one behind your own firewall and watch where it connects, which is your tenant and nothing else. Nothing bundles or copies Oracle software; everything goes through the documented BI Publisher web service.
Yes — that is what the TNS proxy was built for. Your EBS database opens a plain CREATE DATABASE LINK at the proxy and sees Fusion as a remote Oracle server, joins between local and Fusion tables included. No Database Gateway, no dg4odbc, nothing installed on the database host. Verified live from 19c and from the 23ai/26ai generation; older releases are untested.
No — that is the point. One universal report is installed once per tenant, and every query from every tool reuses it. But that one-time installation is required: without it, nothing here can reach your data.
Each query is a BI Publisher report execution — typically a few seconds end to end for a small result on a warm cache. Real timings depend on tenant load, how wide the result is, how many rows come back, and network latency. Schema browsing and autocomplete are answered locally and are instant.
SQL access is read-only by construction. The parts that can modify anything are ofrag's REST and ESS tools, and those are bounded by the Fusion permissions of the account you configure — see the table above. Everything runs on your machine with your credentials.
Split it by how your client connects. Anything JDBC-based — DBeaver, SQL Developer, DataGrip, your own JVM code — takes OFJDBC, and that is the shortest path. Anything that goes through the Oracle client instead, or another Oracle database over a link, needs the TNS proxy: SQLcl and python-oracledb are verified there, while Toad and PL/SQL Developer speak the same protocol but have not been tested, so try before you rely on it. For an AI agent exploring the schema: ofrag. For someone who doesn't write SQL: FusionLens.
Mostly. OFJDBC is open source under MIT — free, permanently, source included. The TNS proxy and FusionLens are free binary downloads with no key and no account. ofrag is the exception: it starts on a two-week trial key, so you can try it on your own tenant before deciding whether it belongs in your stack.
It is a self-hosted option for ad-hoc SQL and AI access, with no data routed through a vendor's servers, and nothing to buy before you can tell whether it works on your tenant. Commercial products cover more ground — scheduling, transformation, governance, support — and change over time; compare against your own requirements rather than against a claim on this page.
Fusion is where these particular tools landed, but the work behind them is ordinary systems engineering: reading protocols out of packet captures, making drivers behave, modelling a schema nobody documented, and getting data out of systems that would rather not hand it over. If something here is broken, missing, or you are stuck on the tenant side, say so — bug reports and awkward questions are equally welcome, and I read every one.
Oracle Net (TNS/TTC) implemented from scratch, across two protocol generations and thin, OCI and dblink dialects — the kind of claim you check by connecting a client, not by reading about it.
25,000+ Fusion tables indexed and searchable, and the domain knowledge of which ones actually matter for a given accounting question.
Consultants and in-house teams run these against live tenants on real projects — not demos, and not only mine.