An app reads its rows in place through the same connectors the rest of the platform uses, so building starts the day a system is connected.
Read through released interfaces, write through BAPIs and IDocs, stay inside SAP's published guidance.
Screens on SAP objects read the tables in place through the SAP connector's released read interfaces: the handler sends the filter and the columns, SAP returns the rows. Where the basis team allows it, change capture brings changed rows to a screen within minutes. Writes go through released BAPIs and IDocs, so a confirmed delivery date on a schedule line, a released requisition, a usage decision on an inspection lot or a new vendor arrive in SAP the way SAP expects them, with a document number back.
The connector stays inside SAP's published guidance for third-party access (Notes 3255746, 382318 and 2971304) and leaves the ODP RFC interface out of its design. On SAP ECC the same objects live in the classic tables: MATDOC becomes MKPF and MSEG, ACDOCA becomes BKPF and BSEG; the BAPIs are the same. ERP extraction: SAP and Oracle has the methods table and the extraction statement.
| Object | Read in place from | Written through | On SAP ECC |
|---|---|---|---|
| Purchase order line | EKKO · EKPO · EKET · EKBE | BAPI_PO_CHANGE · BAPI_PO_CREATE1 | same tables |
| Supplier master | LFA1 · LFB1 · LFM1 (business partner in S/4) | BAPI_BUPA_CREATE_FROM_DATA · BAPI_VENDOR_* | LFA1/LFB1/LFM1 vendor master, XK01 via BAPI |
| Material master | MARA · MARC · MAKT | BAPI_MATERIAL_SAVEDATA | same tables |
| Stock position | MARD · MCHB · MATDOC_EXTRACT | BAPI_GOODSMVT_CREATE (transfer, scrap, block) | MARD · MCHB · MBEW |
| Supplier invoice | RBKP · RSEG (supplier invoices) | BAPI_INCOMINGINVOICE_RELEASE · BAPI_INCOMINGINVOICE_CREATE | same tables |
| Quality notification | QMEL · QMFE · QMMA | BAPI_QUALNOT_CREATE · BAPI_QUALNOT_ADD_DATA · BAPI_QUALNOT_MODIFY_DATA | same tables |
| Journal line | ACDOCA (universal journal) | BAPI_ACC_DOCUMENT_POST · BAPI_ACC_DOCUMENT_REV_POST | BKPF and BSEG |
| Price condition | A004 · A005 · KONP (condition records) · PRCD_ELEMENTS | BAPI_PRICES_CONDITIONS | KONV for conditions |
36 app types in the catalogue read this system; each pair page lists the objects, the fields the criteria use and the write path.
REST resources and BI Cloud Connector for Fusion; JDBC reads and open interfaces for EBS.
On Oracle Fusion Cloud the handler reads objects through the released REST resources, filtered and with the columns the screen needs, and reads bulk history through BI Cloud Connector extracts landed by the Backbone. Writes use the same REST resources under the integration user's data-security profile, so a change order on a purchase order, a receipt, an invoice hold released or a new supplier site lands in Fusion through its own front door with the resource ID back.
On Oracle E-Business Suite the tables are read in place through JDBC with a read-only user, changed rows by their last-update columns, and writes go through the open interface tables and public APIs, run by a concurrent program, with the request ID stored. The EBS connector page lists the interface tables per object.
| Object | Read in place from | Written through | On Oracle E-Business Suite |
|---|---|---|---|
| Purchase order line | Procurement REST: purchaseOrders · lines · schedules | PATCH purchaseOrders (change order) · POST purchaseOrders | PO_HEADERS_ALL · PO_LINES_ALL · PO_LINE_LOCATIONS_ALL (write: PO_CHANGE_API1_S) |
| Supplier master | Procurement REST: suppliers · supplierSites | POST suppliers · PATCH supplierSites | AP_SUPPLIERS · AP_SUPPLIER_SITES_ALL (write: AP_SUPPLIERS_INT) |
| Material master | Product Hub REST: itemsV2 | POST/PATCH itemsV2 | MTL_SYSTEM_ITEMS_B (write: MTL_SYSTEM_ITEMS_INTERFACE) |
| Stock position | Inventory REST: inventoryOnhandBalances · inventoryItemLots | POST inventoryTransactions (transfer, scrap, status) | MTL_ONHAND_QUANTITIES_DETAIL (write: MTL_TRANSACTIONS_INTERFACE) |
| Supplier invoice | Payables REST: invoices | POST invoices · PATCH invoiceHolds | AP_INVOICES_ALL · AP_HOLDS_ALL (write: AP_INVOICES_INTERFACE) |
| Quality notification | Quality Management REST: qualityIssues · qualityActions | POST qualityIssues · POST qualityActions | QA_RESULTS (collection plans) |
| Journal line | General Ledger REST: journals · BICC GL journal lines extract | POST journals (ERP Integration Service, FBDI) | GL_JE_HEADERS · GL_JE_LINES (write: GL_INTERFACE) |
| Price condition | Pricing REST: priceLists · priceListItems | PATCH priceListItems | QP_LIST_HEADERS_B · QP_LIST_LINES |
35 app types in the catalogue read this system; each pair page lists the objects, the fields the criteria use and the write path.
History, aggregates and prepared results, read where they land; decisions recorded beside them.
Lakes hold the history an operational screen would struggle to serve: a year of stock positions, five years of journals, every forecast version. The Backbone lands ERP objects in a conformed model (RAW, CONFORMED and HISTORY schemas in Snowflake; bronze, silver and gold Delta tables in Unity Catalog on Databricks; Delta tables in OneLake on Fabric), and the app reads them in place through the native connector with the filter and the columns it needs.
Decisions taken in an app are recorded in a Lima-owned table in the lake through stage, COPY and MERGE, so analysts and dashboards see the decision beside the history. The operational write goes to the system of record: an app on Snowflake that reviews excess stock still writes the transfer to SAP or Oracle through their interfaces, and the pair pages say so for every app.
| Object | Read in place from | Written through | Note |
|---|---|---|---|
| Stock position | CONFORMED.STOCK_POSITION · HISTORY.STOCK_DAILY | MERGE into LIMA.APP_DECISIONS | |
| Purchase order line | CONFORMED.PURCHASE_ORDER_LINE · HISTORY.PO_LINE_VERSIONS | MERGE into LIMA.APP_DECISIONS · PO change to the ERP | |
| Journal line | CONFORMED.JOURNAL_LINE · HISTORY.JOURNAL_LINES | MERGE into LIMA.APP_DECISIONS | |
| Forecast | CONFORMED.FORECAST · HISTORY.FORECAST_VERSIONS | MERGE into LIMA.APP_DECISIONS | |
| Supplier invoice | CONFORMED.SUPPLIER_INVOICE | MERGE into LIMA.APP_DECISIONS | |
| Budget line | CONFORMED.BUDGET_LINE · CONFORMED.ACTUALS_MONTHLY | MERGE into LIMA.APP_DECISIONS |
36 app types in the catalogue read this system; each pair page lists the objects, the fields the criteria use and the write path.
23 app types in the catalogue read this system; each pair page lists the objects, the fields the criteria use and the write path.
Read through their APIs, change capture where offered, write under the integration user's own rules.
Accounts, opportunities, quotes, cases, orders and contracts read through the REST and Bulk APIs; changes arrive through Change Data Capture within seconds. Writes through the REST API under the integration user's profile and sharing rules.
9 app types in the catalogue read this system; each pair page lists the objects, the fields the criteria use and the write path.
Incidents, changes, requests, configuration items, assets and users read through the Table API with the integration user's access control lists. Approvals raised from an app appear in the ServiceNow approval list, so people can act in either place.
3 app types in the catalogue read this system; each pair page lists the objects, the fields the criteria use and the write path.
Workers, positions, time off, expense reports, cost centers and journals through web services and Reports-as-a-Service. Writes through released operations such as Submit_Expense_Report, so an approval taken in the app lands in Workday's business process step.
5 app types in the catalogue read this system; each pair page lists the objects, the fields the criteria use and the write path.
Apps read the plan and return decisions through the Backbone's planning connectors.
A shortage room, a production schedule change or an S&OP cycle reads the planning system's results, the constrained plan, the projected inventory, the forecast versions, through the Backbone connectors that already integrate the ERP with the planning system, and returns the agreed decisions the same way. Each planning system has its own page describing its data model and the loop.
Files, APIs and devices complete the picture: a supplier's spreadsheet becomes rows through a file handler, a carrier's tracking service through an API handler, a cold-room sensor through a device feed. The rows look the same to a screen, an expression and a decision node as rows from SAP.
Browse all 60 connectors with their methods, prerequisites and patterns →
The connectors and the catalog are shared by the whole platform. Once a system is connected and its objects registered, an app reads them through handlers the same day; a new object is a registration, and a new write path is a test write and a switch.
Through released BAPIs and IDocs under an SAP user with exactly the authorisations the app needs, with the RETURN table checked and the document number stored. Write-back is off per object until a test write has been confirmed, and an approval rule can sit in front of any write.
Yes. A handler per object per system, and a screen that shows both, for example when two divisions run different ERPs and one process spans them.
Operational rows the person acts on come from the ERP, live. History, aggregates and prepared results come from the lake. The pair pages in the catalogue show the split for every app.
Bring one process and the systems it touches. In the first session we register the data handlers, draw the levels or the lanes and run the first screen on your live rows.
