Solutions For Microsoft Fabric

Microsoft Fabric, fed SAP data on Lima's capacity.

Lima Backbone lands SAP and Oracle data in your Fabric workspace as Delta tables in a OneLake Lakehouse — raw as loaded, conformed across ERPs — with every table reconciled, and keeps it current with change-data capture. Power BI reads the tables directly through Direct Lake. Extraction and transformation run on Lima's own capacity, so your Fabric capacity units stay for Power BI and analytics, and no Datasphere subscription is needed on this route.

Run the Terabyte Proof-of-Scale Lakehouse migration overview

Two-week Terabyte Proof-of-Scale on your largest tables.

Fabric landing model: Delta tables in a OneLake Lakehouse, raw and conformed, with the SQL analytics endpoint and a Direct Lake semantic model reading them; Lima writes on its own capacity and the fabric reads live.

~30 min

220M rows · 615 tables · ~30 GB on 64 vCPU

80 GB/day

moved in production on the engine

1m 48s

change-data lag behind SAP after the initial load

Step 1 · What lands where in Microsoft Fabric

Delta in OneLake, read directly by Power BI

Everything lands in your workspace as Delta tables in a Lakehouse on OneLake. The raw layer keeps SAP and Oracle as they are; the conformed layer is where the decimals are shifted, the keys trimmed and the ERPs joined — written in the order Power BI reads fastest.

Layer	What lands there	How Lima writes it	Status
raw tables	Every extracted table as loaded, productive client only, raw values kept, typed correctly (decimal with scale, date, datetime2)	Delta written to OneLake in parallel by partition; change data merged by full key	Shipped
conformed tables	Item, site, customer, order and accounting tables across ERPs with decimals shifted, keys trimmed, texts and code descriptions joined; V-Ordered for Power BI	Built from raw by Lima operators; reconciled against raw totals	Shipped
SQL analytics endpoint	T-SQL access to the same tables for analysts and tools	Created with the Lakehouse; nothing extra to load	Shipped
Direct Lake semantic model	Power BI reports on the conformed tables without an import refresh	Your Power BI team builds the model on the landed tables	Shipped
History tables	Closed periods and retired systems under retention rules and legal hold	Offload and decommissioning runs	Shipped
Delta and Iceberg on your own storage	Open table formats written outside OneLake for engines beside Fabric	On the published standards schedule	Scheduled · standards plan

Statuses match the published standards conformance page; the open-table-format line is dated there.

Step 2 · What makes ERP data awkward to land

Six things every SAP and Oracle table brings with it, and what they do to a lakehouse

These are the reasons a straight copy of ERP tables produces wrong totals. Each has a cause in how the ERP stores data and an effect an analyst sees.

The client column and multi-org tables counts wrong or a unit missingEvery SAP table carries a client column (MANDT) and most hold rows for several clients — test, quality, productive. Oracle E-Business Suite keeps several operating units in the same tables (the _ALL tables, keyed by ORG_ID). Land them unfiltered and every count is wrong; filter them wrongly and a whole business unit is missing.

Keys with leading zeros, and keys made of several columns joins fail silentlyAn SAP material number is stored as an 18-character field padded with zeros, so 4711 is '000000000000004711'; a document line is identified by company code, document number, fiscal year and line number together. Trim the zeros in one table and keep them in another, and joins fail silently; miss one key column and rows overwrite each other.

Dates and times stored as text the wrong day, or no dateSAP dates are eight-character strings ('20260912'), with '00000000' meaning no date, and times are six-character strings in the system's time zone. Loaded as text they cannot be compared or bucketed; loaded naively as dates they fail on the zero date or land in the wrong day after time-zone conversion.

Amounts with hidden decimals, quantities with a unit next door totals confidently wrongSAP stores every amount with two decimals regardless of currency; for currencies with none, such as JPY, the stored value 12.34 means 1,234 yen, and the correction lives in a separate table (TCURX). Quantities carry their unit in a neighbouring column. Sum a column without the currency shift or the unit and the total is confidently wrong.

Wide tables, and cluster tables in ECC the history left behindAccounting line items (BSEG) have more than 300 columns and, in ECC, sit in a cluster table that cannot be read like an ordinary table; pricing conditions and change-document items are stored the same way. Tools that read only transparent tables leave the most valuable history behind.

Few change timestamps, and rows that disappear a copy that driftsMany ECC tables record only a change date, or nothing; rows in schedule lines, conditions and some master tables are deleted outright. Keeping a lakehouse current needs change documents, change pointers or triggers to find what changed, and a way to apply deletes. Oracle E-Business Suite keeps a last-update timestamp on most tables, and still deletes rows.

Fabric-specific: capacity units, Direct Lake and the write order

Three things are specific to landing in Fabric. Capacity units: everything that runs inside Fabric draws on one capacity, so a heavy SAP extraction inside it slows the Power BI reports it was meant to feed. Direct Lake: Power BI can read Delta tables in OneLake directly, without an import refresh, when the tables are written in the right layout (V-Order) and kept current. Lakehouse versus Warehouse: the two hold data differently; the tables have to land where the reports will read them.

Step 3 · How Lima Backbone handles each one

One row, transformed on the way, with the raw value kept beside it

The figure follows one accounting line from SAP into Microsoft Fabric. The table maps all six problems and the Microsoft Fabric-specific ones.

Problem	What Lima does	The capability behind it	What you see
1 · Client and org	Filters to the productive client (and the operating units you name) on every table, and records the client in the landed row	Connector settings per source; lineage records the filter	Row counts per client before and after the filter
2 · Keys	Keeps every key column, adds a trimmed business key beside the raw one, and enforces uniqueness on the full key before the write	Key-aware transformation operators; uniqueness rules	Key coverage per table; duplicates listed with owners
3 · Dates and times	Converts eight-character dates and six-character times to real date and timestamp columns, turns the zero date into null, and converts system time to UTC with the source's time zone	Type-aware SAP operators	Conversion counts per column; anomalies listed
4 · Amounts and units	Applies the currency decimals table to every amount, keeps the unit beside every quantity, and checks totals per company code and period against the ERP	Currency and unit rules; control totals	Totals per company code and period, raw and shifted, against the ERP
5 · Wide and cluster tables	Reads ECC cluster tables through a named function module that unpacks them, and lands wide tables with their full column set, partitioned by period	Named SAP read paths; partitioned parallel loads	Column coverage per table; partitions with counts
6 · Change capture and deletes	Finds changes through change documents, change pointers, timestamps or triggers depending on the table, applies deletes, and replays late rows from the watermark	Change-data capture with per-table methods; ordered replay	Method per table; lag and deletes applied per run
Fabric · capacity	Runs extraction and transformation on Lima's own cluster and writes finished Delta tables to OneLake, so Fabric capacity units are spent on reads and reports	Lima's capacity tiers; parallel Delta writes	Capacity consumed by the load, shown beside the rows written
Fabric · Direct Lake	Writes the conformed tables V-Ordered and keeps them current with merged change data, so a Direct Lake semantic model reads them without an import refresh	Target-model catalogue for Fabric; change-data merges	Tables ready for Direct Lake, with their last-reconciled time

Step 4 · The checks that run on every table

Nine checks a migration and every change-data run pass through

Every check is a rule with an owner. A failed partition reruns from its checkpoint; a failed row is held with the rule and the row; the report stays open until every table reads Reconciled.

Check	Kind	Example	When it fails
Row count per table and per partition equals the source, for the productive client only	Completeness	BSEG fiscal 2024: 132 monthly partitions, each counted	Partition reruns from its checkpoint; report stays open until they match
Amount control totals per company code and period match the ERP's own totals after the decimal shift	Consistency	Sum of BSEG amounts for company code 1000, period 2024-03, in JPY and EUR	Exception to finance with both figures
Quantity control totals per unit match the source	Consistency	MSEG quantities per unit of measure, plant 1000	Exception to the data owner
Every key is unique in the target and every key column is present	Quality	Company code, document, year and line together on accounting lines	Load refused for the partition; owner notified
Zero dates become null; no date lies outside the valid range	Quality	'00000000' in 1.4 million rows of one table	Converted and counted; anomalies listed
Every currency used has a decimals entry; every unit pair used has a conversion	Completeness	9 rows in a currency with no entry in TCURX	Rows held; exception to finance
Rows deleted in the source are removed in the target	Consistency	Weekly full-key compare on schedule lines and conditions	Deletes applied; count reported
In the conformed layer, every child has its parent	Consistency	Every sales-order item has its header; every line has its material	Exception to the data owner
Change events applied in order; lag below the agreed threshold	Consistency	Watermark per table; lag shown on the dashboard	Run pauses and resumes from the checkpoint
Tables land in the Lakehouse the semantic model reads, with the approved schema	Quality	A table written to a Warehouse the report cannot read	Write refused; owner notified

Kinds: completeness (is everything there), consistency (do related numbers agree), quality (is each value valid).

Step 5 · Watching the data flow, correcting it on the way

One screen from the ERP table to the lakehouse table

Integration suites such as Informatica sell data integration, data quality, the catalog and lineage as separate services on one consumption meter, and a team stitches the four together for each load. Lima runs the four as one surface. The screen above is the same for every load into Microsoft Fabric: each step from the SAP or Oracle table to the Microsoft Fabric table shows its row count; the rule that stopped a row shows the row and the person who owns the fix; the fix is applied where the row stopped and the replay starts from that step. Column-level lineage is recorded from the run itself, so the trace from a number in Microsoft Fabric back to the ERP table is current every morning without a scanning project.

Rules in plain language

Checks a planner can read

A rule such as "confirmed date is on or after order date" is written in words, previewed on live rows, versioned, and owned by a named person.

Exceptions with owners

Nothing disappears

A row that fails a rule becomes an exception with the row, the rule, an owner and a deadline. The load carries on with the valid rows and says what it held.

Lineage from the run

Always current

Every step records what it read and wrote at column level, so the trace from a planning number back to the ERP field is captured as a by-product of running.

Governed planning master data

Parameters with owners

Values the ERP never held — hierarchies, changeover matrices, demand-stream rules — live in Lima with an owner and an effective date.

Acknowledged write-back

The loop closes

Results return to the ERP as transactions the ERP confirms; the confirmation is stored and reconciled against what was sent.

Deadlines on the pipeline

The planning run waits for nothing

Each load carries its window and deadline; a tripped rule pauses the run and the clock, and the run resumes from its checkpoint after the fix.

Step 6 · Keep it current, then use it

Change data keeps it current; Power BI and the fabric read it directly

After the initial load, Lima keeps the raw and conformed tables minutes behind the source; Power BI reads them through Direct Lake, and the same data serves questions, agents and planning loads without another copy.

Change data, merged by key

Inserts, updates and deletes found per table by the method that table allows, merged into the raw tables, then re-conformed; late rows replayed from the watermark; 1 minute 48 seconds behind SAP on the showcase estate.

Replication and sync →

Power BI without an import refresh

A Direct Lake semantic model reads the conformed tables as they are; a report shows the change minutes after SAP posted it.

Capacity units reserved for analytics

Extraction and transformation ran on Lima's cluster; a heavy SAP load never slows a report.

Questions and planning loads

ChatLima joins OneLake history with live SAP stock in one query; planning loads draw demand history from the conformed tables on the calendar.

Planning integration →

The Terabyte Proof-of-Scale, step by step

Fourteen days on the showcase estate

How the proof-of-scale runs into Fabric on the showcase estate's largest tables. Figures are from the showcase estate.

Day 1
scope

The largest tables chosenAccounting lines (1.2 billion rows), material documents, sales-order items and the material master from SAP ECC, plus Oracle order lines; a Lakehouse and a service principal created in your workspace.

Day 2
profile

Counted before anything moves2,480 non-empty tables, 3.9 TB; BSEG partitioned into 132 monthly slices; 14 currencies in use, all with decimals entries except one precious-metal currency.

Days 3–6
initial load

In parallel, on 128 vCPU, outside your capacityPartitions written as Delta to OneLake side by side on Lima's cluster; two partitions rerun from their checkpoints after a source timeout; every table reconciled by count and by amount totals per company code and period.

Day 7
change data

Minutes behindChange capture switched on per table; merges apply inserts, updates and deletes; lag settles at under two minutes; the conformed tables are V-Ordered on every merge.

Day 9
cost

Cost per terabyte, statedThe report shows terabytes moved, rows per minute, reconciliation variance (zero after the nine held rows were fixed), capacity units consumed inside Fabric, and cost per terabyte beside the metered alternative running today.

Day 11
use

Reports without a refreshA Direct Lake semantic model on the conformed tables serves the finance report; the fabric reads the same tables beside live SAP stock for the control tower.

Day 14
hand-over

Report signedReconciliation report, method per table and the exception register handed over; the migration extends to the rest of the estate at the same tier.

Partner status

Stated as it is

Program	What it gives you	Status
Microsoft partner listing	Recognised technology partner status	Planned

Statuses are stated as they are and dated when they change.

Lifecycle

Migration and replication use four stages at volume; Return is there the day you need planning write-back.

STEP 1

ConnectSAP, Oracle, WMS, files, lakehouses

STEP 2

Extracttable reads, BAPIs, CDS views, CDC

STEP 3

Transformat MRP volume, 150+ operators, Python

STEP 4

Loadon the run window, counts proved

STEP 5

Orchestratedeadlines, pause and resume, replay

STEP 6

Returnwrite-back, acknowledged

One engine underneath every page in this family. It reads from any source and writes to any target, runs batch loads or change-data streams, handles a nightly delta or a multi-terabyte migration, and is licensed by capacity, so the bill stays the same however many rows move. Lima's fabric answers questions on data in place; Lima Backbone moves, transforms and returns data on a deadline. When to federate and when to pipeline · The Backbone hub.

Terms on this page

Plain definitions

OneLakeFabric's single storage layer; every Lakehouse table is a Delta table in it.

LakehouseThe Fabric item that holds Delta tables and files and exposes them through a SQL endpoint.

Direct LakePower BI's way of reading Delta tables in OneLake directly, without importing them into a dataset.

V-OrderA write layout for Delta files that Power BI reads fastest.

Capacity unitThe measure of compute a Fabric capacity provides; everything running inside Fabric draws on it.

Currency decimals (TCURX)SAP's table of currencies whose stored amounts must be shifted because they use other than two decimals.

Questions we hear

Asked before the first load.

Fabric has its own ways to bring in SAP data. Where does Lima fit?

Lima reads SAP through interfaces SAP keeps open, fixes the six problems above on the way, reconciles every table, and writes finished Delta tables to OneLake on its own capacity. Your capacity stays for Power BI and analytics, and no SAP replication subscription is needed on this route.

Can Power BI read the tables directly?

Yes. They are Delta tables in a OneLake Lakehouse, written V-Ordered; a Direct Lake semantic model reads them without an import refresh.

Does Lima consume Fabric capacity units to load?

The write into OneLake is the only part inside Fabric; extraction and transformation run on Lima's cluster. The report on day nine shows the capacity consumed.

Lakehouse or Warehouse?

The tables land in the Lakehouse the semantic model reads; the SQL analytics endpoint gives T-SQL access to the same tables. A Warehouse copy is made only if a report needs it.

What about the ODP RFC deadline?

Lima's methods sit outside the interface SAP restricted in Note 3255746, so the December 2026 change has no effect on this path.