Az n8n és a Power BI integrációja a hatékonyabb adatkezelésért

A Power BI 2026. áprilisi frissítésének modellezési szekciójában van egy szokatlanul őszinte mondat. A previewban most megjelenő Direct Lake számított oszlopokat és táblákat a bejegyzés arra az esetre ajánlja, amikor „az oszlopok és táblák upstream létrehozása nem megoldható, például mert az adat-előkészítést a OneLake-ben egy másik csapat birtokolja”. Vagyis a Microsoft egy feature-bejelentésben ismeri el: a riportkészítők rendszeresen olyan upstream adatokra várnak, amelyek fölött nincs kontrolljuk.

Az adat elkészülte és a riport határideje közötti résen dől el, hogy egy BI-működés ténylegesen mennyire hatékony. Az áprilisi kiadás sokat ad a modellezési és fogyasztási rétegnek, a lényegét érdemes is végignézni. Egyúttal jó alkalom elmondani, miért futtatok a Power BI mellett egy workflow-orchestrátort (nálam ez az n8n), ahelyett hogy mindent a Power BI-ra bíznék.

Mit szállít valójában az áprilisi frissítés

A leglátványosabb tétel a Copilot a Power BI mobilappokban: az in-report Copilot mostantól nyitott, oda-vissza beszélgetést támogat az éppen nézett riport kontextusában, a válaszokhoz hivatkozásokat ad a felhasznált vizuálokra, iPhone-on és iPaden pedig hangalapú diktálás is van. A Narrative vizuál okosabb defaultot kapott: Copilot-licenc esetén eleve Copilot módban nyílik, a prompt karakterlimitje pedig 10 000-re nőtt.

A riportoldalon a modern visual defaults preview base theme switchert ad a Customize current theme dialógusba, képarányonként előre beállított vászonméreteket kínál, és javítja a beépített tábla- és mátrixstílusokat. A card, a button slicer és a list slicer vizuálok Fixed size opciót kaptak pixelpontos méretezéssel, az Autogrid pedig Fit to space névre váltott. A preview vizuálok mostantól „(preview)” jelölést viselnek a Visualizations panelen, és az elválasztó vonal alá kerültek, elkülönítve a generally available vizuáloktól.

Adatos szemmel a modellezési rész az igazán érdekes. A Direct Lake számított oszlopok (nem materializált formában) és a Direct Lake on OneLake oszlopokra hivatkozó számított táblák previewban, fokozatosan válnak elérhetővé, a számított oszlopok pedig user-context-aware módon reagálhatnak olyan DAX-függvényekre, mint a UserCulture(), a UserPrincipalName() és a CustomData(); a Microsoft példaként az adatfordítást említi.

A fenti lista minden eleme ugyanakkor a modell- vagy vászonrétegben él. Azt a kérdést, hogy az adat hogyan és mikor érkezik meg, ez a kiadás is (mint a legtöbb) érintetlenül hagyja.

A pénzügyi csapatok valódi szűk keresztmetszete

Képzeljünk el egy tipikus középvállalati pénzügyi csapatot zárás idején. A főkönyv akkor zár, amikor zár; az utolsó költséghely-allokációs fájl akkor érkezik, amikor a regionális könyvelő elküldi; a bankkivonat-export egy olyan portálon múlik, amelyet előző negyedévben terveztek újra. A Power BI ütemezett frissítése eközben reggel 7-kor fut, mert valaki egyszer beírt egy 7-est. Amikor az ütemezés megnyeri a versenyt az adattal szemben, a csapat egy magabiztos külsejű, de félig betöltött táblára épült riportot kap, a kontroller pedig a délelőttöt olyan számok magyarázásával tölti, amelyek soha nem voltak igaziak. Nem az elpazarolt frissítés a drága, hanem a szenior kollégák órái, amelyek az output újraellenőrzésére mennek el.

Amikor a Morgan Stanley-nél globális költségdashboardot építettem (Power BI, 50+ felhasználó, automatizált variancia-elemzés), ritkán a modellezésen akadtunk el. Ami feltartott minket, az a havi 600+ számla volt, amely PDF-ben és Excelben érkezett, és előbb fel kellett dolgozni ahhoz, hogy bármelyik DAX-mérőszámnak legyen mit hitelesen aggregálnia.

Hol van az n8n helye a Power BI mellett

Az n8n dolga ebben a felállásban mindaz, amiről a Power BI csendben feltételezi, hogy már megtörtént:

• Begyűjtés. Beszállítói portálok, e-mail-mellékletek, SFTP-re érkező fájlok, többlépéses autentikációjú REST API-k. A Power Query egy részüket eléri, de adatformázásra készült, nem arra, hogy tucatnyi forrás hitelesített letöltését pásztorolja.
• Validációs kapuk. Kontrollösszegek, és annak ellenőrzése, hogy az időszakra várt összes fájl tényleg megérkezett-e. Ha egy kapu elbukik, semmi nem fut tovább.
• Készenlét-vezérelt frissítés. Fix ütemezés helyett a workflow a Power BI REST API-n keresztül akkor frissíti a szemantikus modellt, amikor a kapuk átmentek. A frissítés időpontja az adat teljességének következménye lesz, nem egy hónapokkal korábbi tipp.
• Hibajelzés. Ha valami eltörik, a chatbe érkező üzenet megmondja, melyik lépés és melyik fájl bukott el. Ez jobb, mint vezetői meetingen szembesülni a problémával.

A Syngentánál a mostani munkám egy része pontosan erre a mintára épül: n8n-pipeline-ok Amazon Redshift-integrációval, mögöttük Fabric lakehouse, rajta RLS, adatminőségi standardok és CI/CD a BI-eszközökre. Az orchestrátor és a lakehouse nem versenyez egymással: az egyik azt dönti el, mikor és egyáltalán fusson-e valami, a másik azt, hogy mit jelent az adat, és ki láthatja.

Munkamegosztás, ami kitart

Ha egy csapat azt mérlegeli, mi hová tartozik, ezt a felosztást védeném meg:

Érdemes megállni a Direct Lake sornál. A Direct Lake számított oszlop a megosztott adat-előkészítési tulajdonlás utolsó méteres tapasza; az orchestráció ugyanannak a problémának az upstream megoldása. A kettő kiegészíti egymást, és a legtöbb ilyen felállásban élő csapatnak előbb-utóbb mindkettő kelleni fog.

A kivezetési közlemények üzemeltetői szemmel

Az áprilisi jegyzetek két kivezetése több figyelmet érdemel, mint amennyit kapni fog. A Power BI Desktop régi fájlválasztója az SU04-gyel nyugdíjba megy, teendő nincs vele. A beépített IBM Netezza ODBC-drivert viszont szintén kivezetik, és az már igényel munkát: a meglévő connector újrahasználható, de az új ODBC-drivert telepíteni kell.

A connector- és driver-csere a BI-környezetek csendes, visszatérő költsége. Ha a kinyerési logika harminc pbix-fájlban és néhány gateway-gépen szóródik szét, minden ilyen közlemény harminc apró migrációt jelent. Ha a begyűjtés néhány orchestrációs workflow-n fut keresztül, akkor egyet. Ezt a fajta adathatékonyságot egyetlen feature-dia sem említi, a karbantartási naptárban viszont negyedévente megjelenik.

A teljes kiadás, a kihagyott vizuál- és témarészletekkel együtt, a Fabric community blogon olvasható: Power BI April 2026 Feature Summary. Először a modellezési és a kivezetési szekciókat érdemes elolvasni; a vászoncsinosítás ráér addig, amíg az alatta lévő adat ki nem érdemli.