SAP ECC Integration with Microsoft Fabric (A Developer’s Guide)

If you are looking for a practical guide on how to connect SAP ECC data to Microsoft Fabric pipelines, you’re in the right place.

Out of the box, Fabric doesn’t offer a native, one-click ECC → Fabric connector. But that doesn’t mean you’re stuck. Teams are delivering this integration every week by composing a set of reliable building blocks: 

• Azure Data Factory (ADF) connectors for SAP (including a dedicated SAP ECC connector via OData, and SAP Table/SAP CDC (ODP) connectors)
• Fabric’s On-Premises Data Gateway (OPDG); the secure bridge that lets Fabric Data Factory reach into your ECC system.
• Partner connectors (e.g., ASAPIO Fabric Connector, dab Nexus) that replicate ECC/S/4 data into OneLake via Open Mirroring when you want lower-code replication
• SAP Datasphere → OneLake shortcuts as another path if your organisation already runs Datasphere.
  

The trick is choosing a pattern that matches your data needs, your network/security constraints, and how much engineering you’re willing to invest.

In practice, most teams converge on three pragmatic routes:

First, expose business entities from ECC over OData through SAP Gateway and let ADF pull them into OneLake. 

Second, use the SAP Table connector in ADF for raw table snapshots with partitioning, great for MARA/MAKT, LFA1, and the STKO/STPO/MAST set behind BOMs. 

Third, step up to CDC using SAP’s ODP framework when you truly need ongoing deltas and near-real-time updates.

All three routes land your ECC data neatly in Microsoft Fabric, where you can model once and serve everywhere.

In this guide, you’ll learn how each route works, when to use it, what prerequisites to watch for, and the common gotchas that teams most often trip over.

Route 1: OData via SAP Gateway → ADF → OneLake

If your priority is clean, business-friendly data, OData is the most natural entry point. By publishing OData services from ECC through SAP Gateway (either embedded or hub deployment), you expose entities such as materials, vendors, and purchase orders in a REST-like format. ADF’s SAP ECC connector reads those services directly. 

To move that data into Fabric, ADF connects securely through a Self-Hosted Integration Runtime installed close to your ECC system in the network. The extracted data is then written into OneLake as Delta tables, which you can model directly in Fabric. 

This route feels intuitive for developers because it aligns with how they already work with REST APIs: pagination, filtering, and predictable payloads are supported natively.

For curated datasets, such as vendor master data or material catalogues, OData gives you exactly what you need with minimal effort. 

Use this route when you want entity-level extracts that map closely to business objects, and you can afford to curate OData services in ECC. It works best for scenarios where clarity and structure matter more than raw volume.

(Please note that SAP’s official recommendation for exposing OData APIs is indeed via SAP BTP Integration Suite; many teams running ECC on-premise still deploy a Self-Hosted Integration Runtime to bridge ADF with SAP Gateway directly. Because it’s the simplest way to connect Fabric to on-prem ECC.)

Gotchas

• Not every ECC object is readily available as OData. You may need to wrap BAPIs or BOR objects as custom OData services,
  
• Also, for very large hierarchical structures (think deep multi-level BOMs), OData can be chatty. You may still do your “heavy” extractions with table pulls and then stitch the hierarchy in Fabric.

Route 2: SAP Table Connector (Snapshots + Partitioning) → OneLake

When you need scale and direct access to SAP’s raw tables, the SAP Table connector in ADF is the go-to option. Instead of relying on which entities are published as OData, this connector lets you pull straight from ECC’s core tables, such as MARA/MAKT for materials, LFA1 for vendors, or STKO/STPO/MAST for BOMs. 

Technically, this connector does not connect to the database directly. It uses SAP’s Remote Function Call (RFC) protocol via the SAP .NET Connector (NCo) on the Self-Hosted Integration Runtime (SHIR). You still install SHIR near ECC for secure connectivity, but once configured, the pipeline is straightforward: select columns, apply filters, and partition the load so you’re not pulling entire tables in bulk every night.

The strength of this route is flexibility and throughput. You can move very large datasets, with partitioning and predicate pushdown that let you slice by timestamps or key ranges, far more efficiently than brute-force extraction.

That said, SAP generally recommends using APIs (OData, CDS views, BAPIs) over table-level extracts whenever possible. The Table connector makes sense when:

• The data you need isn’t published as OData,
• API performance is insufficient for your volume, or
• You’re building analytical models in Fabric where raw tables are acceptable.

Use this route for high-volume, table-level snapshots where OData isn’t an option, and you’re comfortable doing the business modelling in Fabric. Just keep in mind that it’s a pragmatic workaround, not SAP’s officially preferred approach. 

Gotchas

• The trade-off is that you inherit more responsibility for modelling downstream in Fabric. For example, reconstructing a multi-level BOM requires transforms in notebooks or Dataflows Gen2 to explode parent-child relationships, validate units of measure, and enrich attributes from reference tables.
• Initial full copies can be heavy. Plan chunked loads and incremental filters.

Further Reading: SAP Connector Development: Tools, Costs, and Best Practices

Route 3: SAP CDC (ODP) for Deltas → OneLake

Snapshots are useful, but they fall short when business data is highly dynamic. Orders may change intraday, BOMs may be revised frequently, or you might need to track inventory movements in near real-time. In those cases, you turn to SAP’s Operational Data Provisioning (ODP) framework. 

ODP provides delta extraction out of ECC (from EhP5 onward) and S/4HANA. It exposes SAP DataSources and CDS views via an operational delta queue (ODQ), which can be consumed by external tools like Azure Data Factory’s SAP CDC (ODP) connector. Once configured, you no longer pull full tables; instead, you just fetch what changed.

This route removes the need for custom watermark logic and ensures you have a reliable feed of inserts, updates, and deletes. It integrates cleanly with Fabric by landing changes into Delta tables, and it pairs well with Open Mirroring patterns, which make downstream consumption even easier.

Use this route when freshness matters and you need continuously updated data flows from SAP into Fabric. Start with snapshots for a quick win, then layer in ODP on the objects where near-real-time deltas actually move the needle.

(ODP is the preferred path for delta-enabled extractors and is strategically aligned with SAP’s roadmap. For long-term, enterprise-grade delta handling, this is the route to aim for.)

Gotchas

ODP isn’t universally available: enabling it requires specific Basis configuration, and in ECC, it may depend on your enhancement package/SP level. Some landscapes prefer to front ODP with SAP SLT or certified partner tools for governance and resilience. Always validate feasibility with your SAP team and Microsoft account team before committing.

Connector Options Beyond the Three Routes

You might be wondering: “Where does OPDG fit? When would I choose a partner connector? How does Datasphere come into play?” While OData, Table Snapshots, and ODP form the three main integration routes, you’ll also encounter several connector choices depending on your architecture and team preferences. Understanding these options will help you decide where to orchestrate your pipelines and how much effort to invest in custom development versus packaged solutions.

1. ADF vs. Fabric On-Premises Data Gateway (OPDG)

Both SHIR (Self-Hosted Integration Runtime in ADF) and OPDG (On-Premises Data Gateway in Fabric) act as the secure bridge into ECC.

• Use SHIR when orchestrating via Azure Data Factory pipelines.
  
• Use OPDG when you prefer to orchestrate directly in Fabric Data Factory or Dataflows Gen2.

In both cases, place the runtime close to ECC, harden the host, and restrict egress to only the required Azure endpoints.

2. Partner Connectors

Some teams prefer not to hand-build OData services, table extractions, or CDC flows. Partner solutions such as ASAPIO Fabric Connector and dab Nexus provide low-code replication with monitoring, delta capture, and lineage tailored for SAP→Fabric scenarios.

• Best for when ODP access is limited or when you need to operationalise replication quickly.
  
• These tools are Clean Core certified and provide hardened, supported paths into OneLake/Open Mirroring.

3. SAP Datasphere → OneLake

If your organisation is already invested in SAP Datasphere, you can shortcut by creating OneLake shortcuts directly to Datasphere datasets. This avoids building new pipelines entirely, though it requires you to already have Datasphere licensed and in use.

Suggested Reading: SAP Integration with a Cloud SaaS on an SME Budget

A “Good First Build” Most Teams Can Ship In A Sprint

A pragmatic starting point is to land master data (MARA/MAKT, LFA1) and BOM structures nightly, then add deltas later. Use the SAP Table connector with partitioning based on change timestamps to keep runs efficient. 

Land everything as Delta in OneLake, register a Lakehouse, and create a gold model for Power BI. For BOMs, write a small transformation (SQL or a Fabric notebook) that reconstructs the multi-level hierarchy from STKO/STPO, validates units of measure, and enriches valuation fields from reference tables. 

Once stakeholders are happy with the model and reports, layer in ODP for the tables where intraday freshness matters—often orders or frequently-changed masters.

Monitoring is not optional. Even a simple pipeline run log with alerting on failures and long runtimes will save you from silent data drift. In Fabric, keep an eye on Lakehouse refreshes and semantic model health; in ADF, wire alerts on activity and integration runtime failures. 

Your future self and your auditors will thank you.

Developer Notes: OData vs. Tables vs. CDC (How to Choose)

When deciding between OData, Tables, and CDC, start from the business need and work backwards. If your goal is to extract curated business entities with predictable payloads and simple pagination, OData via the SAP ECC (OData) connector in ADF is the cleanest route. 

When scale and raw control over columns matter more (say, you need full tables like MARA or STPO), then the SAP Table connector with partitioning gives you both performance and flexibility. 

And when timeliness is the key driver, for example, in order data that changes intraday, step up to SAP CDC (ODP) to capture deltas directly into OneLake. 

Just remember to validate ODP availability and licensing up front, as not every ECC landscape has it switched on by default. 

The rule of thumb: batch where you can, real-time where you must.

Security And Networking Checklist: The Non-Glamorous Work That Saves Projects

Keep the integration runtime (SHIR/OPDG) on a hardened VM in the same network segment as ECC. 

Use SAProuter or another reverse-proxy pattern so you never expose ECC directly, and prefer SNC/HTTPS for OData. 

Store secrets in Key Vault, rely on managed identities for sinks where possible, and practice data minimisation; only publish and extract the fields you actually need. 

If you must call BAPIs/RFCs, consider wrapping them behind a small internal HTTP service and then proxying that service rather than exposing RFC endpoints head-on; it gives you cleaner auth, throttling, and logging boundaries.

Handling Data-Model Mismatches (BOMs, BPs, Units)

Expect SAP’s worldview to differ from your source systems. ECC models “material” at multiple organisational layers; your CRM or PLM may treat the same concept as one flat record. BOMs from a CAD-adjacent tool are often flatter than SAP’s STKO/STPO hierarchy. 

Business Partners in SAP can represent both customers and vendors, but your CRM probably splits those into separate entities. 

The fix is a stable mapping layer: declare a system of record for each entity, add enrichment where SAP needs fields your source doesn’t have (base UoM, valuation class), and keep the transformations versioned and testable in Fabric. 

Once that layer is in place, mismatches stop being emergencies and become routine change requests.

Common Pitfalls And How To Avoid Them

The most expensive mistakes are organisational, not technical. Don’t assume Fabric has a native ECC connector; it doesn’t. You’ll use ADF (OData, Table, CDC), Fabric OPDG + OData, or partner solutions.

Don’t skip observability; a failed job that goes unnoticed for a week will wreck the credibility of every report downstream. Silent IDoc or OData failures will wreck downstream reporting. Add alerts from day one.

Don’t ignore ODP constraints/licensing: Validate feasibility up front, or consider ASAPIO/dab Nexus if ODP isn’t viable.

Be cautious about deep ECC customisations you’ll have to unwind during an S/4HANA move. Lightweight bridges you can retire gracefully are better than monuments you’ll have to dismantle.

Don’t build everything as a custom RFC first. Prefer OData/Table/CDC where possible; resort to RFC only for gaps and wrap them behind secure HTTP if you must.

Choosing The Right Route For Your Scenario

A reliable way to decide is to start from your business need and work backwards. If you need curated business entities and manageable volumes, OData through SAP Gateway is a clean on-ramp. 

If you need control and scale, table extraction plus Fabric transforms gives you speed and transparency. When you truly need freshness, enable ODP-based CDC on the handful of objects where it matters and leave the rest as scheduled loads. 

Teams that mix these approaches, batch where they can, real-time where they must, ship faster and spend less.

If you already operate SAP Datasphere, consider letting it do what it’s good at: replicate from ECC, then surface that data to Fabric via OneLake shortcuts. It’s a tidy hand-off between ecosystems and reduces the number of moving parts you own.

A note on ECC: SAP has announced the end of mainstream maintenance for ECC in 2027. That means every year spent building deep integrations on ECC is a year closer to technical debt. If you’re making long-term bets on Microsoft Fabric, it’s worth planning for S/4HANA migration now to take advantage of the richer, standardised API catalogue and certified connectors that make S/4-to-Fabric integrations far smoother.

And if you’re still unsure about which route to take, or how to balance ECC’s realities with an S/4HANA roadmap, you can always reach out to us for a consultation.