An ERP holds thousands of tables, and each vendor sets rules for how other software may read them. Backbone reads SAP ECC and S/4HANA through tables, BAPIs, CDS views and application-level change capture. It reads Oracle E-Business Suite and Oracle ERP through direct database access with parallel reads and change capture, and Oracle Cloud through its released APIs and extracts. Both run with a dedicated technical user and the authorisations your Basis or database team grants.
The interfaces differ by vendor. The way of working is the same, so a team that has loaded one ERP can load the other with the same tools and the same checks.
SAP allows other software to read ECC and S/4HANA through a defined set of interfaces and restricts others in numbered SAP Notes. Backbone uses five of the allowed methods. Which one a table gets is a setting per table, chosen for freshness, volume and how deleted rows must be handled. All five feed the same catalog, lineage and quality rules.
| Method | Best for | Freshness | Deleted rows | Reference figure | Extra SAP licence |
|---|---|---|---|---|---|
| Table extractionthrough a named function module | Master data, open items, custom Z-tables, full history for an archive or a decommissioning | Batch; minutes for changed-row reads | Detected by a full-load comparison or by change-pointer delete flags | 220M rows / 615 tables / ~30 GB in ~30 min on 64 vCPU (estimate) | None |
| BAPIs and function modulesread, and transact on the way back | Business-object reads with SAP’s own logic applied; the return path for planned orders and allocations | Seconds per call, batched | Handled by the object | confirmed transactions per run, batched by object | None |
| CDS viewsreleased and custom | S/4HANA semantics, calculated fields, views that provide their own delta | Batch or delta | Where the view provides delta and deletion | depends on the view; filters are pushed into the view | None |
| Extractor delta queueswhere they already exist | Existing BW extractors with delta queues | The extractor’s own cadence | The extractor’s own semantics | depends on the extractor | None |
| Change captureat the application level | Order, stock and delivery tables that the business needs within minutes | 1m 48s lag on the showcase estate | Insert, update and delete, with before and after values | 8.2M events/day (showcase estate) | None (SLT can be used where it already exists; it is optional) |
Every claim in the SAP section is a line in a dated statement your Basis team can check against the SAP Notes it cites. The statement lists the interfaces Backbone uses, the interfaces it leaves out, the authorisations the technical user needs, and the date of the last review. Procurement and audit teams can file it as it is.
| Table extraction | through a named, authorised function module: full reads, changed-row reads and partitioned reads |
| BAPIs and function modules | business-object reads, and transactions on the way back |
| CDS views | released and custom views, with delta where the view provides it |
| Change capture at the application level | change pointers, table-level change capture, delta-enabled CDS views and extractor delta queues |
| The ODP data replication API over RFC | SAP Note 3255746 restricts it for third-party tools |
| RFC_READ_TABLE in production | SAP Note 382318 restricts it; a named, authorised module is used for table reads |
| HANA database log capture | SAP Note 2971304 lists it as unsupported for third-party tools |
| ABAP add-ons or transports | no objects are installed in your ECC or S/4HANA system |
Signed by the Head of Engineering · dated · reviewed every quarter. SAP Notes cited: 3255746 · 382318 · 2971304
| SAP Note | What it says | What Backbone does |
|---|---|---|
| 3255746ODP data replication API over RFC | Use of the ODP-RFC API by third-party tools moved from unsupported to unpermitted. A patch shipped on 9 June 2026 blocks the calls, with an opt-out that expires in December 2026. | Extraction runs through tables, BAPIs, CDS views and application-level change capture, so the patch has no effect on it. |
| 382318RFC_READ_TABLE | The generic table-read function is restricted for production use by customers and partners. | Table reads go through a named, authorised function module that supports changed-row and partitioned reads. |
| 2971304HANA database log capture | Reading the HANA database log with third-party change-capture tools is unsupported. | Change capture stays at the application level: change pointers, table-level capture, CDS deltas and extractor queues. |
The 9 June 2026 patch turned a support question into a deadline for tools that read SAP through the ODP-RFC API. Backbone does not use that API, so its SAP extraction continues unchanged through December 2026 and after. Some replication and cloud-ingestion tools reach SAP through the ODP-RFC API. Those tools run on an opt-out until December 2026 and then stop. The sanctioned alternatives route through SAP’s own data-cloud products, which are licensed separately.
Table extraction, BAPIs, function modules, CDS views and application-level change capture stay fully usable. Backbone has used these methods since the SAP-to-Kinaxis integration went into production in 2021, which is why the assessment below takes a week and is free.
One week. Your extraction jobs are listed by method, every job that depends on ODP-RFC is flagged, the conversion is sized, and you receive a method-by-method replacement plan with the performance trade-offs stated. The same assessment covers your Oracle extraction jobs.
The same table, BAPI and change-capture methods work on ECC 6.0 today and on S/4HANA after the migration. A planning integration or a data-lake feed built on ECC now carries over to S/4HANA later: the catalog, lineage and quality rules stay, and only the connection changes.
S/4HANA Cloud, public edition, restricts RFC. There, released APIs and CDS-based OData are the supported paths, at lower throughput. The assessment states which paths apply to your edition before any plan is made.
Planning loads, control-tower KPIs and data-lake feeds on ECC data in weeks, on your own S/4HANA schedule.
When the migration lands, the same engine extracts every non-empty table, tiers the history and keeps it queryable.
Legacy decommissioning →Oracle E-Business Suite, Oracle ERP and PeopleSoft run on the Oracle database, and Oracle publishes the database interfaces for customer use. Backbone reads them with a dedicated read-only database user, so your DBA controls exactly what can be read. Oracle Cloud closes direct database access, so it is read through the released APIs and scheduled extracts instead. Which method a table gets is a setting per table, as on SAP.
| Method | Best for | Freshness | Deleted rows | Reference figure | What it needs |
|---|---|---|---|---|---|
| Database readsJDBC, in parallel partitions | Master data, open items, custom tables, full history for an archive or a decommissioning; PeopleSoft tables the same way | Batch | Detected by a full-load comparison | 2,891 tables / 18 GB per day (showcase estate) | A read-only database user with SELECT grants on the tables in scope |
| Changed rows onlyby last-update columns | Transaction tables that carry a last-update timestamp, which the standard E-Business Suite tables do | Minutes to hours, on the schedule you set | Detected by a full-load comparison, or by a deletion flag where the table keeps one | nightly loads stay small; volume depends on the table | The same read-only user |
| LogMiner change capturewhere the DBA allows it | Order, stock and invoice tables that the business needs within minutes | 210 ms p99 on the showcase estate | Insert, update and delete, with before and after values | 0.9M events/day (showcase estate) | Supplemental logging enabled by your DBA and read access to the redo log |
| Oracle Cloudreleased APIs and extracts | Oracle Fusion Cloud applications, where direct database access is closed | On the extract schedule; minutes for API reads | As the API or extract reports them | depends on the API limits of your tenancy | An integration user with the API roles in scope |
A read-only user with SELECT grants on the tables in scope. For LogMiner, supplemental logging on those tables and read access to the redo log. Backbone creates no objects in the ERP schema; staging happens in Lima’s own storage.
Parallel reads are capped per connection and per run window. Changed-row reads and LogMiner keep the daily volume small: 18 GB per day for 2,891 tables on the showcase estate.
Each E-Business Suite instance, PeopleSoft system or Oracle Cloud tenancy is one connection in the catalog. Their tables can be combined into one model on the pipeline canvas with SAP data.
Multi-ERP volumes →Extraction is the first half of the loop. Plans accepted in a planning application, purchase requisitions, allocations and corrected master data go back into the ERP through its released transactions. Each write carries a unique key, so a retry cannot create a duplicate. The ERP’s confirmation is captured, failures are re-queued with their reason, and every run is reconciled with record counts and control totals.
On SAP the writes are BAPI and IDoc transactions, for example BAPI_PLANNEDORDER_CREATE for a planned order. On Oracle they go through the open interface tables and public APIs of E-Business Suite, and the REST APIs of Oracle Cloud. On the showcase estate a country-code standardisation was written back to Oracle ERP this way.
Many companies run more than one ERP: several SAP systems from acquisitions, an Oracle E-Business Suite in one region, PeopleSoft for people data. Backbone treats each as one connection and combines their tables into one model on the pipeline canvas: plant and site codes mapped, units and calendars converted, customers and materials matched.
The performance estimate for this kind of estate is 615 tables and about 220 million rows from nine SAP, Oracle and PeopleSoft systems in roughly 30 minutes on a 64-vCPU node. The engine that does this is described on the scale page. How the engine scales →
catalogued from one S/4HANA system; 32 GB per day; 42 ms p99 on change documents
catalogued from one Oracle ERP system; 18 GB per day; LogMiner 0.9M events per day
~30 GB across nine SAP, Oracle and PeopleSoft systems in ~30 min on 64 vCPU
15 minutes end to end on 64 vCPU
A synthetic ECC planning set (MARA, MARC, MAST, STKO, STPO, EKKO, EKPO, VBAK, VBAP, AFKO) to Kinaxis; method published now, results next quarter
This table is updated as each programme lands.
| Programme | Status | What it gives you | Date |
|---|---|---|---|
| SAP PartnerEdge · ICC | Tier decision in progress | An SAP Store listing and the certification badge procurement teams filter on (Integration Certification), or the Interoperability Review | decision Q4 2026 |
| Oracle PartnerNetwork | Planned | A partner listing for the E-Business Suite and Oracle Cloud connectors | Q1 2027 |
| Kinaxis PartnerLink | Application submitted | “Kinaxis-certified application” on the technology page planning teams check | applied 2026 |
| o9 · OMP · Blue Yonder | Planned | Technology partnership badges as each target adapter is documented | Q1 2027 |
A dedicated RFC user with least-privilege authorisations for the specific tables, function modules, CDS views and BAPIs in scope. The authorisation-object list per method is in the security packet, and your Basis team reviews it before the first connection test.
A read-only database user with SELECT grants on the tables in scope. For LogMiner change capture, supplemental logging on those tables and read access to the redo log. For write-back, insert rights on the open interface tables for the objects in scope.
On SAP: no ABAP add-on and no transport; extraction and write-back use released interfaces. On Oracle: no objects are created in the ERP schema; staging happens in Lima’s own storage. Where you already have a certified SAP read module, Lima can use it.
No. SLT can be used where it is already licensed and in place, and change capture works without it. No Datasphere or data-cloud capacity is consumed.
Yes, through the released REST APIs and scheduled extracts, because Oracle Cloud closes direct database access. Throughput follows the API limits of your tenancy, and the assessment states what applies before any plan is made.
Parallel reads are capped per system and per run window. Changed-row reads and change capture keep the daily volume small, and full loads run in the windows your Basis or database team sets. The run dashboard shows the load on each connection.
One week. Your SAP and Oracle extraction jobs listed by method, exposure flagged, and a replacement plan with the trade-offs stated.
