Fabric Apps backenddel: a pénzügyi folyamat utolsó lépése

A költséghelyfelelős megnyitja a hó végi eltéréselemzést, talál egy sort, amely jócskán túllépte a tervet, aztán megteszi azt az egyet, amiben a riport nem tud segíteni: beírja a magyarázatot egy e-mailbe vagy egy megosztott munkafüzet cellájába, ahonnan valaki kézzel másolja majd át a vezetői riportcsomagba. A szám egy szabályozott szemantikus modellből jött. A számról hozott döntés egy táblázatban él.

A Microsoft a barcelonai FabCon Europe-on pontosan ezt a rést vette célba. A júniusban indult alkalmazásréteg, a Fabric Apps backend functionöket, fájltárolást, PostgreSQL-t, beépített használati metrikákat és egy sor konnektort kapott a Fabricben már meglévő adatokhoz. Egy pénzügyi csapatnak ez kevésbé az alkalmazásfejlesztésről szól, sokkal inkább arról, hol lakhat a riportolási folyamat második fele.

Mit jelentettek be Barcelonában

A Fabric Appok a Rayfinre épülnek, ami egy code-first TypeScript keretrendszer. Te (vagy egy kódoló ágens) leírod az alkalmazást, a Rayfin SDK-ja és CLI-ja pedig típusos API-kat és klienseket generál, lokálisan futtatja az egészet, majd Fabric-elemként telepíti, ahol az adatbázist, a tárhelyet, a konnektorokat, a functionöket és a hitelesítést a platform üzemelteti. A termékcsapat szerint a júniusi indulás óta több mint 15 000 fejlesztő épített Fabric Appot, és sokan közülük nem fejlesztői munkakörben dolgoznak: designerek, termékmenedzserek, illetve pénzügyi csapatok, akik a saját, általuk legjobban ismert folyamataikhoz készítenek eszközt.

A szeptemberi bővítés azokat a részeket pótolja, amelyek egy prototípusnál komolyabb alkalmazáshoz eddig hiányoztak:

• Adatkonnektorok Fabric SQL adatbázisokhoz, warehouse-okhoz, lakehouse SQL analytics endpointokhoz és szemantikus modellekhez, automatikus sémafelismeréssel.
• PostgreSQL második lehetőségként az SQL Server mellett az alkalmazás saját adataihoz.
• Storage a fájloknak, kódban megadott mappákkal, engedélyezett fájltípusokkal, méretkorláttal és jogosultságokkal.
• Functions a szerveroldali TypeScript-logikához, mellette egy Secret Store, amely csak futásidőben adja át a hitelesítő adatokat a functionöknek.
• Beépített metrikák: bejelentkezések, alkalmazásbetöltések, lekérdezésszám, lekérdezési hibák, hibaarány és átlagos lekérdezési idő.

Kérdezd a modellt, ne építsd újra

BI-oldalról a szemantikusmodell-konnektor a legérdekesebb. Az alkalmazás DAX-lekérdezést küldhet a modellnek, és ugyanazt a választ kapja, mint bármelyik riportfogyasztó. A bevétel, az árrés és a tervtől való eltérés egyetlen helyen marad definiálva, olyan measure-ökben, amelyekről az üzlet már megvívta a vitáit, az alkalmazás pedig meghívja őket, ahelyett hogy JavaScriptben újraírná a logikát.

A bejelentés két rövid részletben mutatja meg a mintát. Itt egy eltéréskommentelő képernyőre átszabva látod:

# rayfin.yml: a szabályozott források, amelyeket az app elérhet
connectors:
  - name: ledger
    type: fabric-warehouse
    config: { workspaceId: ${WS_ID}, itemId: ${WAREHOUSE_ID} }
    auth: { type: delegated }      # a bejelentkezett felhasználó nevében fut
  - name: closeModel
    type: fabric-semanticmodel
    config: { workspaceId: ${WS_ID}, itemId: ${MODEL_ID} }
    auth: { type: delegated }

// Olvasás: a szemantikus modellt kérdezzük, így az app a jóváhagyott measure-öket mutatja.
const variances = await client.connectors.closeModel.executeQuery({
  query: 'EVALUATE TOPN(20, CostCentreVariance)',
});

// Írás: a magyarázat rekordként kerül az app saját adatbázisába.
await client.data.VarianceComment.create({
  costCentre, period, comment,     // az űrlapról érkező értékek
});

Ehhez semmit nem kell kimásolni a warehouse-ból vagy a modellből, és ez többet számít, mint elsőre látszik. A pénzügyi adat minden másolata eggyel több egyeztetnivaló, eggyel több lineage-kérdés az auditon, és eggyel több frissítés, amely a harmadik munkanapon elhasalhat.

Két identitás, és a választás maga a kontroll

Az auth: { type: delegated } beállítással a konnektor a bejelentkezett felhasználó nevében fut, a jogosultságokat pedig a forrás érvényesíti, a row-level securityt is beleértve. Az a regionális kontroller, aki a Power BI riportban csak a saját régióját látja, az alkalmazásban is csak azt fogja látni. A másik lehetőség az alkalmazásidentitás, arra az esetre, amikor az appnak tényleg saját jogosultság kell. A bejelentés nem kertel a következményről: az alkalmazásidentitás nem örökli a felhasználó jogosultsági határait, ezért „tudatosan válassz”.

Ezt a mondatot hozzáférés-szabályozási döntésként érdemes olvasni, és úgy is kell dokumentálni. A delegált identitás érvényben tartja a meglévő RLS-kialakítást. Az alkalmazásidentitás az érvényesítést az app kódjába helyezi át, ahol valakinek meg kell terveznie, tesztelnie és átnéznie. A functionök miatt a kérdés még élesebb, mert azok az app identitásával futnak, és a bejelentkezett felhasználó kontextusát továbbadhatják a lefelé menő hívásoknak.

A Microsoft két olyan kérdést is szétválaszt, amelyek az auditorokkal folytatott beszélgetésekben rendszeresen összemosódnak. A hitelesítés azt dönti el, ki nyithatja meg az alkalmazást, és a Microsoft Entrán keresztül még azelőtt megtörténik, hogy bármilyen alkalmazástartalom kimenne. A Fabric-jogosultságok azt döntik el, hogy az illető bent milyen adathoz fér hozzá. Az appok alapértelmezetten privátak, nyilvános elérés csak jóváhagyott anonim forgatókönyvekre van, tenant szinten pedig az adminisztrátorok korlátozhatják, hogyan lehet egyáltalán appot közzétenni.

Ahová írni lehet

A dashboard csak olvasható, egy pénzügyi folyamat utolsó lépése viszont szinte teljes egészében írás: a megjegyzés, a jóváhagyás, a módosított elhatárolás, az alátámasztó PDF. Az alkalmazás saját adatai egy menedzselt adatbázisba kerülnek, amelynek a sémája kódként utazik az alkalmazással, így nincs körbeküldött connection string, és nincs valakinek a laptopján felejtett migrációs szkript. A csatolmányok a storage-ba mennek, a rekord pedig hivatkozik a fájlra.

A Morgan Stanley-nél épített globális költség-dashboardom több mint ötven felhasználónak adott automatizált eltéréselemzést. Az eltérést a modell mindegyiküknek ki tudja számolni. A magyarázat viszont emberi munka, és csak akkor ér valamit, ha az időszakhoz, a költséghelyhez és a szerzőjéhez kötve van eltárolva. Ennek a darabnak lett most helye a Fabric Appsban, és mivel az app adatbázisa maga is elem a workspace-ben, a kommentárból adat lesz, amelyet a következő havi riport már le tud kérdezni.

Olvasás és írás forrásonként

A csak olvasható sorok előnyt jelentenek. Ha egy szemantikus modellbe az app nem tud írni, akkor a számai továbbra is egyetlen frissítési útvonalon érkeznek.

Amire a preview még nem ad választ

A Fabric Apps preview állapotban van, és a dokumentáció őszintén beszél a korlátairól. A workspace-hez Fabric-kapacitás kell, az app szolgáltatásai ebből fogyasztanak capacity unitot, és előbb egy tenant adminnak engedélyeznie kell a workloadot. Még nem minden régió támogatott. Telepítés után csak Fabric single sign-onnal lehet belépni. A Microsoft saját útmutatója szerint a platform nem feltétlenül jó választás olyan alkalmazásokhoz, amelyek összetett, többlépcsős tranzakciókat vagy tárolt eljárásokat igényelnek, és ez kizárja annak a jó részét, amit egy analitikus nyilvántartás (subledger) csinál.

A 2026 későbbi részére ígért roadmap megmutatja, mi hiányzik ma: admin- és security-portál, deployment pipeline-ok, beágyazás, custom claimek, Kusto-konnektor és eredetkövetéssel ellátott appmegosztás. Amíg nincs deployment pipeline, a környezetek közötti promóciót neked kell megtervezned. Egy apróbb részlet a doksiból a hozzáférési felülvizsgálatba is megér egy sort: alapértelmezés szerint a workspace minden tagja jogot kap az app futtatására.

A bejelentés ágens által írt kódra vonatkozó figyelmeztetése pedig teljes egészében érvényes. A generált kód kiindulópont, a típusos entitások fejlesztés közben kiszűrik az eltéréseket, de egyik sem helyettesíti a futásidejű validációt, a jogosultság-ellenőrzést és a code review-t.

Jó első app egy pénzügyi csapatnak

A termékcsapat saját tanácsa az, hogy válassz egyetlen folyamatot, amely dashboardban kezdődik és táblázatban ér véget, és építsd meg a végét. A legtöbb pénzügyi csapatnál könnyű összeírni a jelölteket: eltéréskommentár, elhatárolások megerősítése, egy értékhatár feletti kézi könyvelési tételek jóváhagyása, a költséghely-mapping karbantartása. Mindegyik kicsi, mindegyiket olyanok futtatják, akik jobban ismerik bármelyik fejlesztőcsapatnál, és jelenleg mindegyiknek a postafiókokban marad a bizonyítéka.

Kezdd a delegált identitású változattal, tartsd meg a szemantikus modellt a számok egyetlen forrásának, az app adatbázisát pedig kezeld új nyilvántartásként, amelynek gazda és megőrzési szabály kell. A teljes bemutató, a storage- és function-példákkal együtt, a Microsoft From prompt to production: What's new in Fabric Apps című posztjában olvasható, az aktuális előfeltételeket és korlátokat pedig a Microsoft Learn Fabric Apps áttekintője sorolja fel.