Business Intelligence

Diversiteit in klanten en sectoren

In de wereld van de data draait alles om efficiëntie. Het ophalen van data moet soepel verlopen en de integratie met tools moet zo eenvoudig mogelijk zijn. Je wil zo snel mogelijk je data ophalen. En hoe “verser” de data is, hoe beter.

 

Door: Ted Jansen

Nu hebben wij als data-gekkies experts de neiging om allemaal moeilijke termen de wereld in te slingeren en dan maar te hopen dat iedereen nog snapt waar we het over hebben. Daarom hebben we een aantal blogs voorbereid, waarin wij je meenemen in wat de termen betekenen, hoe je keuzes daarin maakt, en wat de voordelen zijn. Dit is blog één van de volgende vier:
  • OData, en andere interfaces;
  • Microsoft Power BI en Fabric licenties;
  • Parquet, Delta Lake;
  • Hoe dit te automatiseren binnen Fabric;

 

Dit eerste deel richt zich op OData en waarom het in veel gevallen de betere keuze is voor de integratie is in Microsoft Fabric omgevingen. Voor de mensen onder ons die denken, deze muur aan tekst geloof ik wel, klik hier om naar de samenvatting te gaan.

Wat is OData v4?

OData (Open Data Protocol) is een open standaardprotocol dat het ophalen van data via API’s vereenvoudigt. Microsoft heeft aan de “wieg” gestaan bij de ontwikkeling in 2007, en ervoor gezorgd dat de standaard inmiddels breed omarmd wordt door de industrie.

 

Met OData kun je data op een gestandaardiseerde manier opvragen, filteren, sorteren en zelfs gerelateerde gegevens in één keer ophalen. Dit maakt het een krachtige tool voor BI-toepassingen, vooral in combinatie met Microsoft Fabric.

 

In dit blog zullen we elke keer refereren naar de meest recente versie van de specificatie, versie 4. Versie 4 van OData is de nieuwste en meest geavanceerde versie, met verbeterde prestaties en ondersteuning voor complexere situaties.

Waarom zou je OData kiezen in plaats van een (traditionele) REST of SOAP-integratie?

SOAP- en REST-integraties zijn bekende routes, maar in een BI-context vaak traag en onnodig complex. Dit zijn een paar redenen waarom:

 

  • Handmatige query-logica:
    Wil je specifieke data filteren of sorteren? Dan moet je vaak complexe query-logica inbouwen, en soms moet zelfs de leverancier dit voorbereiden.
  • Geen standaard metadata-discovery:
    Traditionele API’s bieden geen automatische manier om de datastructuur te ontdekken. Dit betekent dat je handmatig moet documenteren welke velden beschikbaar zijn.
  • Geen ondersteuning voor incremental loads:
    Als je alleen gewijzigde data wilt ophalen, moet je dit bijna altijd zelf bouwen.
  • Veel losse API-aanroepen:
    Wil je data uit meerdere gerelateerde tabellen? Dan moet je vaak meerdere API-aanroepen doen, wat leidt tot meer complexiteit en netwerkbelasting.

Okay, leuk. Maar, noem dan eens concrete voorbeelden.

Laten we eens kijken naar de belangrijkste voordelen van OData v4, specifiek voor BI en datawarehousing.

Standaard Query Functionaliteit

Met OData kun je eenvoudig filteren, sorteren, en pagineren via de URL. Dit betekent dat je zonder extra backend-code complexe query’s kunt uitvoeren.

Voorbeelden:

  • /Products?$filter=Price gt 100 haalt alleen producten op met een prijs groter dan 100.
  • /Customers?$orderby=Name&$top=10 sorteert klanten op naam en haalt de eerste 10 op.

Dit maakt het veel makkelijker om dynamische data-extracties te doen.

 

Pagineren

Sommige datasets zijn zo groot dat een server ze niet in één keer kan terugsturen. In dat geval wordt het antwoord opgedeeld in kleinere stukken, oftewel “pages”. Met pagineren haal je steeds een deel van de data op, wat efficiënter werkt en voorkomt dat je server overbelast raakt.

 

Automatische Metadata Discovery

Een van de krachtigste functies van OData is het zogenaamde ‘$metadata-endpoint’. Hiermee kun je de volledige structuur van de API automatisch ontdekken:

 

  • Welke tabellen (entiteiten) zijn beschikbaar?
  • Welke kolommen heeft elke tabel?
  • Wat zijn de datatypes?
  • Wat zijn de relaties tussen tabellen?

 

Tools binnen Microsoft Fabric, zoals Data Factory, kunnen dit endpoint gebruiken om automatisch mappings te genereren. Dit scheelt ontzettend veel handmatig werk.

 

Wat is Metadata, Simpel uitgelegd?

Stel je voor dat je een doos met speelgoed hebt. Als iemand wil weten wat er in die doos zit, geef je een lijst met alles wat erin zit: poppen, auto’s, blokken, en de kleuren van elk stuk speelgoed. Deze lijst is eigenlijk de metadata. Het vertelt wat er in de doos zit, zonder dat je elk stuk speelgoed eruit hoeft te halen.

 

Bij data werkt dat net zo. Metadata geeft een beschrijving van de structuur van de data: welke tabellen zijn er, welke velden heeft elke tabel, en wat is het datatype (is het een getal, is het tekst, etc) van elk veld. Dit helpt tools om automatisch te begrijpen hoe ze met de data moeten werken.

 

Wist je dat

Wist je dat wij met onze eigen tool, BI Connect, dit al jaren doen? Als je dus met AFAS wil verbinden hoef je helemaal niet na te denken over REST, OData of andere complexe termen. Het is gewoon plug-and-play.

 

Incremental Loads met Delta Queries

Bij het laden van data in een data warehouse wil je vaak alleen gewijzigde of nieuwe gegevens ophalen. Want, die urenregel die je 3 jaar geleden hebt geboekt zal na 3 jaar echt niet meer wijzigen. Die kan je met een zogenaamde Delta Query overslaan. Het voordeel? De data is sneller binnen. Hoe relaxed is dat.

 

OData ondersteunt dit met Delta Queries. Je voegt simpelweg de parameter ‘$delta’ toe aan het einde van je aanroep, en je krijgt vervolgens alleen de gegevens die sinds de laatste aanroep zijn gewijzigd of toegevoegd.

 

Soms zie je spoken

Lang niet alle bronsystemen gaan helaas goed om met gewijzigde gegevens, en ondersteunen deze functionaliteit niet. Speciaal aandachtspunt is ook nog het geval als je gegevens verwijdert. Sommige systemen hebben moeite om dit soort zaken in een OData aanroep te verwerken.

 

Voorbeeld: Je gooit die urenregel van 3 jaar geleden weg. Je bronsysteem verwijdert de regel ook echt ‘hard’ uit de database, en kan je dus nooit meer terugvinden. In je delta-query komt die regel ook niet naar voren, omdat het systeem niet meer doorheeft dat die regel ooit heeft bestaan.

 

Consequentie: in je datawarehouse heb je de urenregel nog steeds zitten terwijl die niet meer bestaat. Daardoor sluit je rapportage niet meer aan, en kan je je voorstellen dat het heel snel, heel vervelend kan worden. Zeker bij rapportages die meer operationeel zijn gefocust.

 

De meeste systemen bevatten wel een audit-log, maar dit is vaak niet gekoppeld aan het OData-proces. Onze ervaring is dat moderne systemen, zoals Salesforce, hier heel goed mee omgaan. Zij markeren de betreffende urenregel met een ‘Verwijderd’-vlag. De regel wordt naar een soort ‘prullenbak’ verplaatst en pas na een bepaalde periode echt verwijderd.

 

Gerelateerde gegevens ophalen met één aanroep

OData ondersteunt $expand, waarmee je data uit meerdere tabellen in één API-aanroep kunt ophalen. Dit bespaart tijd en vermindert netwerkbelasting.

 

Voorbeeld: Stel, je wilt bij je orders meteen de klantdata ophalen. Met de $expand-functionaliteit haalt OData automatisch de gegevens uit de klantentabel erbij.

 

Ook hier geldt: niet alle bronsystemen ondersteunen volledig de $expand functionaliteit. Het is daarom goed om dit vooraf te controleren bij de bron die je wilt gebruiken.

Helaas, niet alle applicaties ondersteunen OData

Hoewel OData veel voordelen biedt, is het belangrijk om te realiseren dat lang niet alle applicaties OData ondersteunen. In sommige gevallen ben je aangewezen op traditionele REST- of zelfs SOAP-interfaces. Bij oudere systemen kan het zelfs nodig zijn terug te vallen op methoden zoals CSV-exports, maatwerkexports of soms zelfs handmatige exports om data op te halen.

 

Dit betekent dat je soms pragmatisch moet zijn. Als OData beschikbaar is, geniet het de voorkeur vanwege de standaardisatie en efficiëntie. Maar als het niet beschikbaar is, moet je flexibel genoeg zijn om alternatieven te gebruiken. Een goede tip: als je toegang hebt tot de SQL-database via een ODBC-connectie, heeft dat altijd de voorkeur boven andere opties, inclusief OData.

 

Hier al een kleine sneak peek voor een volgende blog. Soms word je als gebruiker echt verwend door de leverancier en bieden ze zelfs Parquet-bestanden aan. Dat is echt ultiem. Parquet-bestanden zijn stukken efficiënter dan OData of een directe ODBC-connectie, dus stay tuned voor meer hierover in onze volgende blog.

 

Let wel: niet alle bronsystemen die OData ondersteunen, bieden ook daadwerkelijk ondersteuning voor functies zoals $delta of $expand. Dit kan verschillen per systeem. Het is dus belangrijk om te controleren welke onderdelen van de OData-specificatie jouw bronsysteem ondersteunt

Jansen, je praat te veel

Hier, heb je een samenvatting. Scheelt weer lezen.

 

In de wereld van data draait alles om snel, efficiënt en flexibel data ophalen. En laten we eerlijk zijn, daar komen vaak de nodige technische termen bij kijken. Geen zorgen, we nemen je stap voor stap mee in deze eerste blog van onze serie over data-integraties.

 

📚 Wat is OData?

OData staat voor Open Data Protocol en maakt het simpel om via API’s data op te vragen, te filteren en zelfs relaties tussen verschillende datasets te achterhalen. Microsoft heeft dit protocol mee op de kaart gezet, en versie 4 (v4) is nu de nieuwste en krachtigste variant.

 

Kenmerk OData v4 Traditionele API’s
Query-functionaliteit Gestandaardiseerd (filter, sort, expand) Custom implementatie nodig
Metadata Discovery Automatisch via $metadata Handmatig instellen en documenteren
Incremental Loads Ondersteund via Delta Queries Maatwerk nodig
Paginering Standaard ondersteund Maatwerk nodig
Data-integratietools Native ondersteuning in Microsoft Fabric Minder directe ondersteuning
Complexe relaties ophalen Ondersteund met $expand Meerdere API-aanroepen ndoig
Prestatieoptimalisaties Automatische paginering en streaming Vereist handmatige optimalisatie, soms ook niet mogelijk

 

Wanneer kies je voor OData?

  1. Als er geen directe ODBC-connectie of Parquet-export mogelijk is.
  2. Als je grote datasets naar een datawarehouse wilt verplaatsen.
  3. Als je complexe query-opties nodig hebt.
  4. Wanneer incremental loads belangrijk zijn.

 

Maar er zijn ook nadelen…

Niet alle systemen ondersteunen OData volledig. Denk aan beperkte ondersteuning voor $delta of $expand. Ook zijn er nog altijd verouderde systemen die je dwingen om REST, SOAP of zelfs CSV-bestanden te gebruiken. OData is dus niet altijd de magische oplossing.

 

Wanneer een traditionele API beter is

Hoewel OData veel voordelen biedt, zijn er situaties waarin een traditionele API geschikter kan zijn:

  • ✅ Je hebt een lichte en eenvoudige API nodig.
  • ✅ Je wilt volledige controle over maatwerklogica in de backend.
  • ✅ De applicatie die je wilt integreren ondersteunt geen OData.

 

Conclusie

OData is ideaal om massaal data op te halen vanuit je externe SaaS-applicatie. Het integreet naadloos in het Microsoft Fabric-landschap. Maar zoals altijd: check eerst of jouw bronsysteem alle benodigde OData-functionaliteiten ondersteunt.

Sparren over hoe jij optimaal je data kan inladen?

Denk je nu: “Hé, misschien kan ik OData wel inzetten binnen ons bedrijf of data-platform?” Of denk je: “Ja, hier snap ik dus echt niks van”? Kan allebei natuurlijk. Of misschien denk je wel iets totaal anders? Wat je ook denkt. We nodigen je graag uit om langs te komen. Dan hebben we het er even over. De koffie staat klaar. Of wij komen langs, nemen we zelfs een Brabantse lekkernij mee ;-).

Gerelateerde insights

Op de hoogte blijven
van het laatste nieuws

Vul hieronder jouw e-mailadres in