Fabric Mirroring: hoe we Synapse uit onze BC365-pipeline schrapten
We beheren het dataplatform van een productiebedrijf op Azure. Data uit Dynamics 365 Business Central voedt rapportages in meerdere BI-tools. Tot voor kort draaide die datastroom via een keten van BC2ADLS, Synapse pipelines en Spark-clusters. Het werkte, maar het was traag, duur en fragiel.
Vorige week hebben we die hele keten vervangen door Fabric Open Mirroring. Dit is het verhaal.
De oude situatie
De architectuur was in de zomer van 2025 opgezet. De datastroom was als volgt:
Business Central -> BC2ADLS -> Data Lake (Parquet) -> Synapse pipelines -> Fabric Lakehouse
Dit werkte voor dagelijkse batch-verwerking. Maar de business had twee eisen die deze architectuur niet aankon:
- Operationele rapporten met data die elke paar minuten ververst moest worden
- Analytische rapporten die minimaal elk halfuur actuele data moesten tonen
Het probleem zat in Synapse. Elke pipeline-run kostte compute-units, en bij hogere frequenties liepen de kosten uit de hand. We schaalden van Fabric F4 naar F8, maar dat was dweilen met de kraan open.
Waarom we niet direct konden vereenvoudigen
De voor de hand liggende oplossing was Fabric Lakehouse shortcuts: een directe link van de Data Lake Parquet-bestanden naar Fabric, zonder Synapse ertussenin. Maar dat werkte niet.
De reden: kolomnamen in Business Central bevatten speciale tekens. $Company, systemId-2000000000, standaard in BC365, maar fataal voor Fabric Lakehouse shortcuts. Parquet-bestanden met deze kolomnamen worden simpelweg niet herkend.
We hebben verschillende workarounds geprobeerd: kolomnamen hernoemen, staging-tabellen tussenzetten, Synapse als vertaallaag behouden. Het werkte, maar het was complex en kostbaar.
De doorbraak: Open Mirroring
Na analyse van de mogelijkheden heb ik contact gezocht met een van de experts achter BC2ADLS. De conclusie was helder: de nieuwste versie van BC2ADLS ondersteunt Open Mirroring, dat inmiddels GA (Generally Available) is in Fabric. Met een upgrade van zowel Business Central als BC2ADLS konden we de hele Synapse-laag elimineren.
Ik heb een analyse gemaakt van de verbeteropties en deze gepresenteerd aan de klant en de betrokken partijen. De oplossingsrichting was duidelijk:
Business Central -> BC2ADLS (v27+) -> Fabric Lakehouse (direct)
Geen Synapse. Geen Spark-clusters. Geen staging-tabellen. Data uit BC365 wordt near-realtime gespiegeld naar Fabric, met een latency van 10 tot 15 minuten, zonder de complexe pipeline die we oorspronkelijk hadden gebouwd.
De uitvoering
Het traject van analyse tot uitvoering:
- Probleemanalyse: de speciale tekens in kolomnamen geïdentificeerd als rootcause voor de performance-beperkingen
- Oplossingsrichting bepaald: Open Mirroring als alternatief voor de Synapse-pipeline, verbeteropties uitgewerkt en gepresenteerd
- Haalbaarheidscheck bij alle betrokken leveranciers: kan iedereen leveren binnen de planning?
- BC-upgrade van versie 26.5 naar 27.0, inclusief nieuwste BC2ADLS met Open Mirroring
- Fabric-herconfiguratie: Synapse-tussenstap verwijderen, directe mirroring inrichten
- Validatie: kloppen de rapporten nog met de nieuwe datastroom?
Het hele traject van besluit tot start kostte twee weken. De technische uitvoering aan onze kant kost naar verwachting enkele dagen.
Wat dit oplevert
| Aspect | Oude situatie | Met Open Mirroring |
|---|---|---|
| Architectuur | BC -> ADLS -> Synapse -> Fabric | BC -> Fabric (direct) |
| Verversingsfrequentie | Max 4x per dag | Elke 10-15 minuten |
| Bewegende delen | 5 componenten | 2 componenten |
| Synapse-kosten | Significant | Vervallen |
| Beheerslast | Hoog | Laag |
De les
1. Houd de roadmap in de gaten. Open Mirroring bestond nog niet toen we begonnen. Had het er wel geweest, dan hadden we de architectuur vanaf dag één anders opgezet. Cloud-platformen evolueren snel: wat vandaag een workaround vereist, is morgen een native feature.
2. Investeer in uw netwerk. De bevestiging dat Open Mirroring onze situatie kon oplossen kwam niet uit de standaard documentatie, maar uit een gericht gesprek met een specialist. Eén consultatie bespaarde ons maanden aan doorontwikkelen van een suboptimale architectuur.
3. Durf te vereenvoudigen. Het is verleidelijk om voort te bouwen op wat er staat. Wij hadden weken geïnvesteerd in Synapse-optimalisaties, staging-tabellen en kolomnaam-workarounds. Het kostte moed om dat allemaal los te laten en opnieuw te beginnen met een simpelere oplossing. Maar simpeler is bijna altijd beter.
De beste architectuur is niet de slimste. Het is de eenvoudigste die aan de eisen voldoet.