--- title: "SAP data ontsluiten (2): Delen of zelf opslaan?" description: "SAP data ontsluiten (deel 2): Delen of zelf opslaan?\nIn deze blog kijken we naar de belangrijkste opties die SAP aanbiedt om de eigen data te ontsluiten naar andere platforms. SAP biedt hiervoor verschillende officiële mogelijkheden, waaronder SAP Business Data Cloud (BDC) Connect en Premium Outbound Integration via SAP Datasphere. Maar welke optie past het beste wanneer Databricks of Snowflake het primaire platform voor analytics en AI is?" image: https://tjoyzz.nl/hubfs/foto%20blog%20Dick-1.jpeg --- [![Tjoyzz](https://tjoyzz.nl/hubfs/NIEUWLOGO.png)](https://www.tjoyzz.nl/) [Home](https://www.tjoyzz.nl/#top) Specialisaties [DatA Insight](https://www.tjoyzz.nl/data-insight) [App Design & Build](https://www.tjoyzz.nl/app-design-build) [Integration](https://www.tjoyzz.nl/integration) [Services](https://www.tjoyzz.nl/#onze-kracht) Blogs [Nieuws](https://www.tjoyzz.nl/#nieuws) Over ons [Over Tjoyzz](https://www.tjoyzz.nl/over-ons) [Werken bij Tjoyzz](https://www.tjoyzz.nl/werkenbijtjoyzz) Wil je contact met ons? Wil je contact met ons? × ## Met wie wil je contact? ![Pascal de Zwart](https://tjoyzz.nl/hubfs/Pas%20foto.jpeg) ### Pascal de Zwart Directeur [+31 6 42142729](tel:+31642142729) ![Reninca de Zwart](https://tjoyzz.nl/hubfs/renincadezwart.png) ### Reninca de Zwart Directeur [+31 6 46003087](tel:+31646003087) ![Emmie de Jong](https://tjoyzz.nl/hubfs/emmie.png) ### Emmie de Jong Manager Operations [+31 6 15390103](tel:+31615390103) ![Emmie de Jong](https://tjoyzz.nl/hubfs/rogier.png) ### Rogier Schipper Business Development Manager [+31 6 31 79 99 52](tel:+31631799952) ![](https://tjoyzz.nl/hubfs/foto%20blog%20Dick-1.jpeg) blogs # SAP data ontsluiten (2): Delen of zelf opslaan? ![Dick Groenhof](https://tjoyzz.nl/hs-fs/hubfs/blog-aut-dick.png?width=48&height=48&name=blog-aut-dick.png) Dick Groenhof 15 oktober 2026 In de eerste blog van deze serie beschreven we waarom het ontsluiten van SAP data naar platforms zoals Databricks en Snowflake steeds meer een enterprise architectuurvraagstuk wordt. SAP Note 3255746 beperkt het gebruik van ODP RFC door third party applicaties. Organisaties moeten daarom goed nadenken over de manier waarop zij SAP data beschikbaar maken op hun strategische dataplatform. In deze blog kijken we naar de belangrijkste opties die SAP aanbiedt om de eigen data te ontsluiten naar andere platforms. SAP biedt hiervoor verschillende officiële mogelijkheden, waaronder **SAP Business Data Cloud (BDC) Connect** en **Premium Outbound Integration** via SAP Datasphere. Maar welke optie past het beste wanneer Databricks of Snowflake het primaire platform voor analytics en AI is? Het antwoord hangt vooral af van een fundamentele architectuurkeuze: **Is toegang tot SAP data alleen voldoende of wil je die data ook zelf opslaan, optimaliseren en verder distribueren?** ## Scenario 1: Zero-copy toegang is voldoende Met SAP BDC Connect kunnen organisaties SAP Data Products beschikbaar maken in Databricks of Snowflake via zero-copy data sharing. De data blijft opgeslagen binnen de SAP BDC architectuur, terwijl gebruikers deze vanuit hun externe dataplatform kunnen benaderen en combineren met andere datasets. Dit biedt duidelijke voordelen. Traditionele extractie- en replicatiepipelines zijn niet nodig, data hoeft niet dubbel te worden opgeslagen en SAP business semantics en metadata kunnen behouden blijven. Maar er zijn ook belangrijke beperkingen. ### Optimalisatie beperkingen **Het externe dataplatform heeft geen directe controle over de fysieke opslag en indeling van de gedeelde brondata.** Optimalisaties zoals partitionering, clustering en file layout kunnen daardoor niet op dezelfde manier worden toegepast als op eigen tabellen in Databricks of Snowflake. Query optimalisatie blijft (beperkt) mogelijk, maar de mogelijkheden om de fysieke dataorganisatie af te stemmen op specifieke analytics- en AI workloads zijn beperkter. ### Contractuele beperkingen op materialisatie en distributie Naast deze technische beperkingen introduceert SAP BDC Connect ook contractuele voorwaarden die relevant zijn voor organisaties die een extern dataplatform gebruiken. Het **SAP Business Data Cloud Supplement** bepaalt dat (SAP) Data Products uitsluitend **tijdelijk** mogen worden opgeslagen of gematerialiseerd op systemen van Third Party Connectors en alleen voor performance optimalisatie. Daarmee is het opbouwen van een permanent, zelfstandig beheerd datafundament op basis van deze gedeelde Data Products niet (zonder meer) toegestaan. Bovendien mogen de Data Products volgens dezelfde voorwaarden niet verder worden gedistribueerd vanuit de Third Party Connector systemen naar andere systemen buiten SAP BDC. **De beperkingen van zero-copy sharing zijn daarmee niet uitsluitend technisch van aard. Ook de contractuele gebruiksrechten bepalen in hoeverre een organisatie SAP data zelfstandig kan beheren, optimaliseren en verder distribueren op haar eigen dataplatform.** BDC Connect is daarom vooral interessant wanneer toegang tot SAP data met behoud van business context belangrijker is dan volledige controle over opslag, performance optimalisatie en verdere distributie. ## Scenario 2: SAP data persisteren op het externe dataplatform Voor veel organisaties is Databricks of Snowflake niet alleen een omgeving waarin data wordt geconsumeerd, maar het centrale platform waarop data wordt opgeslagen, getransformeerd en geoptimaliseerd voor analytics en AI. In dat geval wil je SAP data daadwerkelijk persisteren op het eigen platform, bij voorkeur met behoud van de oorspronkelijke business context. Een officiële SAP route hiervoor is **Premium Outbound Integration** vanuit SAP Datasphere. Hiermee kan SAP data via replication flows naar ondersteunde non-SAP targets worden gerepliceerd, waaronder cloud object storage en Kafka. Het voordeel is dat het externe dataplatform uiteindelijk over een eigen kopie beschikt. Hierdoor kunnen organisaties zelf bepalen hoe data wordt opgeslagen, gepartitioneerd, geclusterd en verwerkt, binnen de toepasselijke gebruiksrechten. Daar staan echter drie belangrijke nadelen tegenover. ### Kosten gebaseerd op ongecomprimeerde data SAP rekent voor Premium Outbound op basis van het geëxporteerde datavolume, in blokken van 20 GB. Volgens **SAP Note 3470559** wordt dit volume berekend op basis van de **ongecomprimeerde** omvang van de data. Daarbij wordt het aantal bytes bepaald door de individuele cellen, afhankelijk van hun datatype en waarde. Dit is een belangrijk verschil met de fysieke opslagomvang in SAP HANA, waar geavanceerde compressietechnieken worden toegepast. Ook wanneer de geëxporteerde data uiteindelijk in gecomprimeerd Parquet formaat wordt opgeslagen, blijft het ongecomprimeerde datavolume bepalend voor de Premium Outbound berekening. **Organisaties betalen dus niet op basis van de hoeveelheid data die uiteindelijk wordt opgeslagen, maar op basis van een ongecomprimeerd datavolume dat aanzienlijk groter kan zijn.** Dit maakt het vooraf inschatten van de kosten lastig. Vooral bij grote SAP datasets kan het verschil tussen de fysieke opslagomvang in HANA, het factureerbare outbound volume en de uiteindelijke opslagomvang op Databricks of Snowflake substantieel zijn. ### Wijzigingen kunnen opnieuw hoge extractiekosten veroorzaken De kosten beperken zich bovendien niet noodzakelijk tot de initiële data extractie en reguliere delta-verwerking. Volgens de SAP documentatie kan het toevoegen van een kolom aan een bestaand replication object leiden tot een nieuwe initial load van dat object. Bij grote datasets, bijvoorbeeld financiële boekingsgegevens uit ACDOCA, kan een relatief kleine wijziging daardoor betekenen dat opnieuw een aanzienlijke hoeveelheid data moet worden geëxporteerd. Omdat Premium Outbound wordt afgerekend op basis van het ongecomprimeerde datavolume, kunnen dergelijke wijzigingen opnieuw substantiële kosten veroorzaken. Dit is vooral relevant voor organisaties die hun dataplatform voortdurend doorontwikkelen. Het toevoegen van velden en aanpassen van datastructuren is daar een normaal onderdeel van data engineering. **Een architectuur waarbij wijzigingen opnieuw tot volledige data extracties kunnen leiden, beperkt daarmee zowel de flexibiliteit als de voorspelbaarheid van de kosten.** ### Verlies van business context Een derde belangrijk aandachtspunt bij Premium Outbound is het mogelijke verlies van SAP business context tijdens de replicatie. SAP Datasphere kan data beschikbaar maken met bijbehorende business semantics, zoals relaties tussen business objects, definities van measures en dimensions en specifieke business rules. Wanneer data via Premium Outbound naar een extern dataplatform wordt gerepliceerd, worden deze semantische definities echter niet automatisch volledig overgenomen. De data wordt beschikbaar gemaakt in een technisch formaat, bijvoorbeeld Parquet, maar dat betekent niet dat alle bijbehorende SAP business semantics behouden blijven. Hierdoor ontstaat het risico dat organisaties op hun externe dataplatform opnieuw moeten definiëren wat de data precies betekent. Denk bijvoorbeeld aan de interpretatie van financiële bedragen, valuta- en unitconversies of de relaties tussen verschillende SAP objecten. **Organisaties krijgen daarmee wel meer controle over de fysieke opslag en verwerking van hun SAP data, maar niet automatisch de business context die nodig is om deze data correct te interpreteren.** Dit kan leiden tot extra ontwikkel- en onderhoudskosten en tot verschillen tussen de interpretatie van data binnen SAP en die op het externe dataplatform. Voor organisaties die Databricks of Snowflake als hun primaire analytics- en AI platform gebruiken, is dit een belangrijke afweging: **eigen persistentie biedt technische vrijheid, maar het behouden of reconstrueren van SAP business semantics vraagt aanvullende aandacht.** ## Twee scenario's, twee verschillende afwegingen De keuze tussen zero-copy sharing en datareplicatie gaat uiteindelijk over meer dan alleen technologie. **Wanneer data alleen geconsumeerd hoeft te worden**, biedt BDC Connect een aantrekkelijke mogelijkheid om SAP data met behoud van business context beschikbaar te maken zonder traditionele replicatie. Daar staat tegenover dat het externe dataplatform minder controle heeft over de fysieke dataorganisatie en dat contractuele beperkingen gelden voor zelfstandige materialisatie en verdere distributie van SAP Data Products. **Wanneer het externe dataplatform de centrale omgeving is voor analytics en AI**, wordt eigen persistentie belangrijker. Organisaties willen dan volledige controle over dataopslag, optimalisatie, performance en verwerking. Premium Outbound ondersteunt dat model, maar introduceert aanvullende complexiteit, mogelijk aanzienlijke en lastig voorspelbare extractiekosten en de noodzaak om SAP business semantics op het externe dataplatform opnieuw beschikbaar te maken. De belangrijkste vraag is daarom niet alleen hoe SAP data beschikbaar wordt gemaakt, maar ook **in hoeverre een organisatie de data op haar eigen platform zelfstandig kan opslaan, optimaliseren en gebruiken voor haar analytics- en AI-workloads, met behoud van de oorspronkelijke business context**. ## Hoe nu verder? In de volgende blog onderzoeken we andere mogelijkheden om SAP data naar externe dataplatforms te ontsluiten, waaronder OData en third party (CDC) extractietechnologieën. Daarbij blijven we kijken vanuit hetzelfde perspectief: **Hoe kunnen organisaties SAP data efficiënt en met behoud van business context beschikbaar maken op hun eigen strategische dataplatform, zonder onnodige beperkingen in flexibiliteit, performance en kosten?** Benieuwd wat Tjoyzz voor jouw organisatie kan betekenen? Of wil je eens sparren over strategie, data, AI of de keuzes die voor je liggen? Stuur me gerust een bericht! [Volgende → SAP data ontsluiten: waarom dit een architectuurvraagstuk is geworden](https://tjoyzz.nl/blog/sap-data-ontsluiten-waarom-dit-een-architectuurvraagstuk-is-geworden) [![Tjoyzz](https://tjoyzz.nl/hubfs/NIEUWLOGO.png)](https://www.tjoyzz.nl/) ### Adres Henri Dunantlaan 34 3451 EP Vleuten ### Onze expertise [Specialisaties](https://www.tjoyzz.nl/) [Services](https://www.tjoyzz.nl/) [Data Insight](https://www.tjoyzz.nl/data-insight) [App Design & Build](https://www.tjoyzz.nl/app-design-build) [Integration](https://www.tjoyzz.nl/integration) ### Over Tjoyzz [Blogs](https://www.tjoyzz.nl/#blogs) [Nieuws](https://www.tjoyzz.nl/#nieuws) [Over ons](https://www.tjoyzz.nl/over-ons) ### Volg ons [in LinkedIn](https://www.linkedin.com/company/tjoyzz/about/) [f Facebook](https://www.linkedin.com/company/tjoyzz/about/) Instagram Tjoyzz © 2026 [Privacyverklaring](https://www.tjoyzz.nl/privacyverklaring) ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Dick Groenhof", "url" : "https://tjoyzz.nl/blog/author/dick-groenhof" }, "dateModified" : "2026-10-15T11:38:39.930Z", "datePublished" : "2026-10-15T11:37:26.000Z", "headline" : "SAP data ontsluiten (2): Delen of zelf opslaan?", "image" : [ "https://tjoyzz.nl/hubfs/foto%20blog%20Dick-1.jpeg" ], "mainEntityOfPage" : { "@id" : "https://tjoyzz.nl/blog/sap-data-ontsluiten-deel-2-delen-of-zelf-opslaan", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://tjoyzz.nl/hubfs/logo2.png" } } } ```