Szolgáltatásnévprofilok több-bérlős alkalmazásokhoz a Power BI Embeddedben

Ez a cikk azt ismerteti, hogy egy független szoftverszállító (ISV) vagy bármely más, sok ügyféllel rendelkező Power BI Embedded-alkalmazástulajdonos hogyan használhat szolgáltatásnévprofilokat az egyes ügyfelek adatainak leképezésére és kezelésére az ügyfelek power BI-beágyazási megoldásának részeként. A szolgáltatásnévprofilok lehetővé teszik, hogy az ISV méretezhető alkalmazásokat hozzon létre, amelyek jobb ügyféladat-elkülönítést tesznek lehetővé, és szigorúbb biztonsági határokat szabnak az ügyfelek között. Ez a cikk a megoldás előnyeit és korlátait ismerteti.

Feljegyzés

A Power BI-ben a bérlő szó néha egy Microsoft Entra-bérlőre hivatkozhat. Ebben a cikkben azonban a több-bérlős kifejezést használjuk egy olyan megoldás leírására, amelyben egy szoftveralkalmazás egyetlen példánya több ügyfelet vagy szervezetet (bérlőt) szolgál ki, amelyek az adatok fizikai és logikai elkülönítését igénylik. A Power BI alkalmazáskészítője például külön munkaterületet foglalhat le az egyes ügyfeleinek (vagy bérlőinek) a cikkben ismertetett módon. Ezek az ügyfelek nem feltétlenül Microsoft Entra-bérlők, ezért ne keverje össze az itt használt több-bérlős alkalmazás kifejezést a Microsoft Entra több-bérlős alkalmazással.

A szolgáltatás képviselő profilja egy szolgáltatás képviselője által létrehozott profil. Az ISV-alkalmazás szolgáltatásnév-profil használatával hívja meg a Power BI API-kat, amint azt a jelen cikk ismerteti.

Az ISV-alkalmazás szolgáltatásnév minden ügyfélhez vagy bérlőhöz másik Power BI-profilt hoz létre. Amikor egy ügyfél felkeresi az ISV-alkalmazást, az alkalmazás a megfelelő profillal hoz létre egy beágyazási jogkivonatot , amely a jelentés megjelenítésére szolgál a böngészőben.

A szolgáltatásnévprofilok használatával az ISV-alkalmazás több ügyfelet is üzemeltethet egyetlen Power BI-bérlőn. Minden profil egy ügyfelet jelöl a Power BI-ban. Más szóval minden profil létrehoz és kezel Egy adott ügyfél adataihoz tartozó Power BI-tartalmat.

A szolgáltatásnévprofilok és a több-bérlősség diagramja.

Feljegyzés

Ez a cikk azon szervezeteknek szól, amelyek szolgáltatásfőszereplői profilok használatával szeretnének több-bérlős alkalmazást beállítani. Ha szervezete már rendelkezik olyan alkalmazással, amely támogatja a több-bérlős használatot, és át szeretne migrálni a szolgáltatásnévprofil-modellbe, olvassa el az Áttelepítés a szolgáltatásnévprofil-modellbe című témakört.

A Power BI-tartalom beállítása a következő lépésekkel jár:

A fenti lépések teljes mértékben automatizálhatóka Power BI REST API-kkal.

Előfeltételek

A szolgáltatásnév-profilok létrehozása előtt a következőkre van szükség:

Képernyőkép a Felügyeleti portál kapcsolójáról.

Profil létrehozása

Profilok hozhatók létre, frissíthetők és törölhetők a Profiles REST API használatával.

Például profil létrehozásához:

POST https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…UUPA
Content-Type: application/json; charset=utf-8

{"displayName":"ContosoProfile"}

A szolgáltatási azonosító a profiljai listájának lekéréséhez meghívhatja a GET Profiles REST API-t is. Példa:

GET https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXA…UUPA

Profilengedélyek

Bármely API, amely felhasználói engedélyt ad a Power BI-elemekhez, profilengedélyt is adhat a Power BI-elemekhez. A Csoportfelhasználói API hozzáadása például profilengedély megadására használható egy munkaterületen.

A profilok használatakor az alábbi szempontokat fontos megérteni:

  • A profil az azt létrehozó szolgáltatásnévhez tartozik, és csak az adott szolgáltatásnév használhatja.
  • A profil tulajdonosa nem módosítható a létrehozás után.
  • A profilok nem önálló identitások. A Power BI REST API-k meghívásához szüksége van a Szolgáltatásnév Microsoft Entra-jogkivonatára .

Az ISV-alkalmazások úgy hívják meg a Power BI REST API-kat, hogy megadja a szolgáltatásnév Microsoft Entra-jogkivonatát az Engedélyezés fejlécben, és a profilazonosítót az X-PowerBI-Profile-Id fejlécben. Példa:

  GET https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
  Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUz.....SXBwasfg
  X-PowerBI-Profile-Id: 5f1aa5ed-5983-46b5-bd05-999581d361a5

Munkaterület létrehozása

A Power BI-munkaterületek Power BI-elemek, például jelentések és szemantikai modellek üzemeltetésére szolgálnak.

Minden profilnak a következőnek kell lennie:

  • Legalább egy Power BI-munkaterület létrehozása

    POST https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
Authorization: Bearer eyJ0eXA…ZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "name": "ContosoWorkspace"
}

  • Hozzáférési engedélyek megadása a munkaterülethez. A szolgáltatásnévprofilnak rendszergazdai hozzáféréssel kell rendelkeznie a munkaterülethez.

  • Munkaterület hozzárendelése kapacitáshoz

    POST https://api.powerbi.com/v1.0/myorg/groups/aaaabbbb-0000-cccc-1111-dddd2222eeee/AssignToCapacity HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…wNkZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "capacityId": "13f73071-d6d3-4d44-b9de-34590f3e3cf6"
}

További információ a Power BI-munkaterületekről.

Jelentések és szemantikai modellek importálása

A Power BI Desktop segítségével előkészítheti az ügyfél adataihoz vagy mintaadataihoz kapcsolódó jelentéseket. Ezután az Importálás API-val importálhatja a tartalmat a létrehozott munkaterületre.

POST https://api.powerbi.com/v1.0/myorg/groups/aaaabbbb-0000-cccc-1111-dddd2222eeee/imports?datasetDisplayName=ContosoSales HTTP/1.1
Authorization: Bearer eyJ...kZUiIsg
Content-Type: multipart/form-data; boundary="8b071895-b380-4769-9c62-7e586d717ed7"
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
Fiddler-Encoding: base64

LS04YjA3MTg5NS1iMzgwLTQ3...Tg2ZDcxN2VkNy0tDQo=

Adathalmazparaméterek használatával hozzon létre egy szemantikai modellt, amely képes csatlakozni a különböző ügyfelek adatforrásaihoz. Ezután az Update parameters API használatával határozza meg, hogy mely ügyfelek adataihoz csatlakozik a szemantikai modell.

A szemantikai modell kapcsolatának beállítása

Az ISV-k általában kétféleképpen tárolják ügyfeleik adatait:

Mindkét esetben arra kell törekednie, hogy egybérlős szemantikai modellekhez jusson el (minden ügyfélhez egy szemantikai modell) a Power BI-ban.

Külön adatbázis minden ügyfélhez

Ha az ISV-alkalmazás minden ügyfélhez külön adatbázissal rendelkezik, hozzon létre egybérlős szemantikai modelleket a Power BI-ban. Adja meg az egyes szemantikai modellek kapcsolati adatait, amelyek az egyező adatbázisra mutatnak. Az alábbi módszerek egyikével elkerülheti, hogy több azonos jelentést hozzon létre különböző kapcsolati adatokkal:

  • Szemantikai modellparaméterek: Hozzon létre egy szemantikai modellt a kapcsolat részleteiben szereplő paraméterekkel (például SQL Server név, SQL-adatbázis neve). Ezután importáljon egy jelentést egy ügyfél munkaterületére, és módosítsa a paramétereket az ügyfél adatbázis-adatainak megfelelően.

  • Datasource API frissítése: Hozzon létre egy .pbix-t, amely mintatartalommal rendelkező adatforrásra mutat. Ezután importálja a .pbix-t egy ügyfél munkaterületére, és módosítsa a kapcsolat részleteit az Update Datasource API használatával.

Egyetlen több-bérlői adatbázis

Ha az ISV-alkalmazás egy adatbázist használ az összes ügyfél számára, az ügyfeleket a következőképpen válassza el különböző szemantikai modellekre a Power BI-ban:

Hozzon létre egy jelentést olyan paraméterekkel, amelyek csak a megfelelő ügyfél adatait kérik le. Ezután importáljon egy jelentést egy ügyfél munkaterületére, és módosítsa a paramétereket , hogy csak a megfelelő ügyfél adatait kérje le.

Jelentés beágyazása

A telepítés befejezése után beágyazhat ügyféljelentéseket és egyéb elemeket az alkalmazásba egy beágyazási jogkivonat használatával.

Amikor egy ügyfél felkeresi az alkalmazást, a megfelelő profillal hívja meg a GenerateToken API-t. A létrehozott beágyazási jogkivonat használatával beágyazhat egy jelentést vagy más elemet az ügyfél böngészőjébe.

Beágyazási jogkivonat létrehozása:

POST https://api.powerbi.com/v1.0/myorg/GenerateToken HTTP/1.1
Authorization: Bearer eyJ0eXAiOi…kZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "datasets": [
    {
      "id": "3b1c8f74-fbbe-45e0-bf9d-19fce69262e3"
    }
  ],
  "reports": [
    {
      "id": "3d474b89-f2d5-43a2-a436-d24a6eb2dc8f"
    }
  ]
}

Tervezési szempontok

Profilalapú több-bérlős megoldás beállítása előtt vegye figyelembe a következő problémákat:

Méretezhetőség

Ha az adatokat külön szemantikai modellekre választja el az egyes ügyfelek számára, minimalizálja a nagy szemantikai modellek szükségességét. Ha a kapacitás túlterhelődik, kiürítheti a nem használt szemantikai modelleket, hogy memóriát szabadítjon fel az aktív szemantikai modellek számára. Ez az optimalizálás egyetlen nagy szemantikai modell esetében lehetetlen. Több szemantikai modell használatával szükség esetén több Power BI-kapacitásra is elkülönítheti a bérlőket.

Profilok nélkül a szolgáltatásazonosító 1000 munkaterületre korlátozódik. A korlát leküzdése érdekében a szolgáltatásnév több profilt is létrehozhat, ahol minden profil legfeljebb 1000 munkaterületet érhet el vagy hozhat létre. Több profillal az ISV-alkalmazás elkülönítheti az egyes ügyfelek tartalmát különböző logikai tárolók használatával.

Ha egy szolgáltatás-alkalmazásprofil hozzáféréssel rendelkezik egy munkaterülethez, a szülő-szolgáltatás-alkalmazás hozzáférése a munkaterülethez eltávolítható a méretezhetőségi problémák elkerülése érdekében.

Még ezekkel az előnyökkel is érdemes figyelembe vennie az alkalmazás lehetséges méretet. Például a profil által elérhető munkaterületelemek száma korlátozott. Egy profilnak ma ugyanazok a korlátai vannak, mint egy normál felhasználónak. Ha az ISV-alkalmazás lehetővé teszi a végfelhasználók számára a beágyazott jelentések személyre szabott másolatának mentését, az ügyfél profilja az összes felhasználó összes létrehozott jelentéséhez hozzáfér. Ez a modell végül meghaladhatja a korlátot.

Automatizálás és üzemeltetési összetettség

A Power BI profilalapú elkülönítésével több száz vagy több ezer elemet kell kezelnie. Ezért fontos meghatározni azokat a folyamatokat, amelyek gyakran fordulnak elő az alkalmazás életciklus-felügyeletében, és gondoskodni kell arról, hogy megfelelő eszközökkel rendelkezzen a műveletek nagy méretekben történő végrehajtásához. Néhány ilyen művelet a következők:

  • Új bérlő hozzáadása
  • Jelentés frissítése néhány vagy az összes bérlőhöz
  • A szemantikai modell sémájának frissítése néhány vagy az összes bérlő esetében
  • Nem tervezett testreszabások engedélyezése adott bérlőkhöz
  • Szemantikai modellfrissítések gyakoriságának beállítása

Egy új bérlő profiljának és munkaterületének létrehozása például gyakori feladat, amely teljes mértékben automatizálható a Power BI REST API-val.

Multi-Geo igények

A Power BI Embedded Multi-Geo támogatása azt jelenti, hogy azok az isv-k és szervezetek, amelyek a Power BI Embedded használatával építenek alkalmazásokat az elemzések alkalmazásba való beágyazásához, mostantól a világ különböző régióiban is üzembe helyezhetik az adataikat. A különböző régiókban lévő különböző ügyfelek támogatásához rendelje hozzá az ügyfél munkaterületét egy kapacitáshoz a kívánt régióban. Ez a feladat egy egyszerű művelet, amely nem jár többletköltséggel. Ha azonban több régióból származó adatokat igénylő ügyfelekkel rendelkezik, a bérlői profilnak az összes elemet több olyan munkaterületre kell duplikálnia, amelyek különböző regionális kapacitásokhoz vannak rendelve. Ez a duplikáció növelheti a költségek és a felügyelet összetettségét.

Megfelelőségi okokból előfordulhat, hogy továbbra is több Power BI-bérlőt szeretne létrehozni különböző régiókban. További információ a multi-geo-ról.

Költséghatékonyság

A Power BI Embeddedet használó alkalmazásfejlesztőknek Power BI Embedded-kapacitást kell vásárolniuk. A profilalapú elkülönítési modell jól működik a kapacitásokkal, mert:

  • A kapacitáshoz egymástól függetlenül hozzárendelhető legkisebb objektum egy munkaterület (például nem rendelhet hozzá jelentést). Az ügyfelek profilok szerinti elkülönítésével különböző munkaterületeket kap – ügyfélenként egyet. Így teljes rugalmasságot kap az egyes ügyfelek teljesítményigényeinek megfelelően történő kezeléséhez, valamint a kapacitáskihasználtság optimalizálásához fel- vagy leskálázással. A nagy és alapvető ügyfeleket például nagy mennyiséggel és volatilitással kezelheti egy külön kapacitásban, hogy egységes szolgáltatási szintet biztosítson, míg a kisebb ügyfeleket egy másik kapacitásba csoportosítva optimalizálja a költségeket.

  • A munkaterületek elkülönítése azt is jelenti, hogy a szemantikai modelleket el kell választani a bérlők között, hogy az adatmodellek kisebb adattömbökben legyenek, nem pedig egyetlen nagy szemantikai modellben. Ezek a kisebb modellek lehetővé teszik a memóriahasználat hatékonyabb kezelését. A kis, nem használt szemantikai modellek inaktivitás után kiüríthetők a jó teljesítmény fenntartása érdekében.

Kapacitás vásárlásakor vegye figyelembe a párhuzamos frissítések számának korlátját, mivel a frissítési folyamatok további kapacitást igényelhetnek, ha több szemantikai modellel rendelkezik.

Sorszintű biztonság

Ez a cikk bemutatja, hogyan hozhat létre külön szemantikai modellt a profilok használatával az egyes ügyfelek számára. Alternatív megoldásként az ISV-alkalmazások egyetlen nagy szemantikai modellben tárolhatják ügyfeleik adatait, és sorszintű biztonság (RLS) használatával védhetik az egyes ügyfelek adatait. Ez a megközelítés kényelmes lehet olyan ISV-k számára, amelyek viszonylag kevés ügyfelet és kis- és közepes méretű szemantikai modellt tartalmaznak, mivel:

  • Csak egy jelentést és egy szemantikai modellt kell fenntartaniuk
  • Az új ügyfelek előkészítési folyamata egyszerűsíthető

Az RLS használata előtt azonban győződjön meg arról, hogy tisztában van a korlátozásokkal. Az összes ügyfél összes adata egy nagy Power BI szemantikai modellben található. Ez a szemantikai modell egyetlen kapacitásban fut, saját skálázással és egyéb korlátozásokkal.

Még ha szolgáltatásnévprofilokat is használ az ügyfelek adatainak elkülönítéséhez, akkor is használhatja az RLS-t egyetlen ügyfél szemantikai modelljén belül, hogy különböző csoportok számára hozzáférést biztosítson az adatok különböző részeihez. Az RLS használatával például megakadályozhatja, hogy az egyik részleg tagjai hozzáférjenek egy másik részleg adataihoz ugyanabban a szervezetben.

Szempontok és korlátozások

  • A szolgáltatásnévprofilok csak a Power BI REST API-n, a Power BI .NET SDK-n, valamint az XMLA-végponton és a táblázatos objektummodellen (TOM) keresztül támogatottak az Analysis Services 16.0.139.27-es vagy újabb verziójának használatakor. A Szolgáltatásmegbízotti profilok nem támogatottak a Power BI-ban az XMLA-végpont vagy a Táblázatos Objektummodell (TOM) segítségével a régebbi ügyfélkönyvtárakkal.
  • Az Azure Analysis Services (AAS) élő kapcsolat módban nem támogatja a szolgáltatásnév-profilokat.
  • Az egyetlen szolgáltatásnév legfeljebb 100 000 profillal rendelkezhet.

A Power BI kapacitáskorlátozásai

Szolgáltatási főazonosítók kezelése

Szolgáltatási főelv módosítása

A Power BI-ban egy profil az azt létrehozó szolgáltatásnévhez tartozik. Ez azt jelenti, hogy egy profil nem osztható meg más tagokkal. Ezzel a korlátozással, ha bármilyen okból módosítani szeretné a szolgáltatásnevet, újra létre kell hoznia az összes profilt, és hozzáférést kell biztosítania az új profiloknak a megfelelő munkaterületekhez. Az ISV-alkalmazásnak gyakran mentenie kell egy megfeleltetést egy profilazonosító és egy ügyfélazonosító között, hogy szükség esetén a megfelelő profilt választhassa ki. Ha módosítja a szolgáltatásnevet, és újra létrehozza a profilokat, az azonosítók is megváltoznak, és előfordulhat, hogy frissítenie kell a leképezést az ISV-alkalmazás adatbázisában.

Szolgáltatásnév törlése

Figyelmeztetés

Legyen óvatos a szolgáltatási főfelhasználó törlésekor. Nem szeretné véletlenül elveszíteni az összes társított profil adatait.

Ha törli a szolgáltatási principal-t az Active Directoryban, a Power BI összes profilja törlésre kerül. A Power BI azonban nem törli azonnal a tartalmat, így a bérlői rendszergazda továbbra is hozzáférhet a munkaterületekhez. Legyen óvatos, amikor egy éles rendszerben használt szolgáltatási főelemet töröl, különösen akkor, ha ezzel a szolgáltatási főelemmel profilokat hozott létre a Power BI-ban. Ha töröl egy profilokat létrehozó szolgáltatásnevet, újra létre kell hoznia az összes profilt, hozzáférést kell biztosítania az új profiloknak a megfelelő munkaterületekhez, és frissítenie kell a profilazonosítókat az ISV-alkalmazás adatbázisában.

Adatok elkülönítése

Ha az adatokat szolgáltatásnév-profilok választják el egymástól, a profil és az ügyfél közötti egyszerű leképezés megakadályozza, hogy egy ügyfél egy másik ügyfél tartalmát lássa. Egyetlen szolgáltatási főfelhasználó használatához szükséges, hogy a szolgáltatási főfelhasználó hozzáférjen az összes profil különböző munkaterületeihez.

Az elkülönítés növelése érdekében rendeljen hozzá egy külön szolgáltatásközponti azonosítót minden bérlőhöz, ahelyett, hogy egyetlen szolgáltatásközponti azonosító több munkaterülethez fér hozzá különböző profilokkal. A különálló szolgáltatásnevek hozzárendelésének számos előnye van, például:

  • Az emberi hiba vagy a hitelesítő adatok szivárgása nem teszi lehetővé több bérlő adatainak nyilvánosságra hozását.
  • A tanúsítvány rotációja minden bérlő esetében külön végezhető el.

A több szolgáltatásnév használata azonban magas felügyeleti költséggel jár. Csak akkor válassza ezt az elérési utat, ha további elkülönítésre van szüksége. Ne feledje, hogy a végfelhasználók számára megjelenítendő adatok konfigurációja a beágyazási jogkivonat létrehozásakor van meghatározva, amely egy csak háttérbeli folyamat, amelyet a végfelhasználók nem láthatnak vagy módosíthatnak. Ha bérlőspecifikus profillal kér beágyazási jogkivonatot, létrehoz egy beágyazási jogkivonatot az adott profilhoz, amely lehetővé teszi az ügyfelek elkülönítését a használatban.

Egy jelentés, több szemantikai modell

Bérlőnként általában egy jelentés és egy szemantikai modell van. Ha több száz jelentéssel rendelkezik, több száz szemantikai modellje lesz. Előfordulhat, hogy egy jelentésformátum különböző szemantikai modellekkel (például különböző paraméterekkel vagy kapcsolati adatokkal) rendelkezik. Minden alkalommal, amikor a jelentés új verziójával rendelkezik, frissítenie kell az összes bérlő összes jelentését. Bár automatizálhatja ezt a folyamatot, egyszerűbben kezelhető, ha csak egy példánya van a jelentésnek. Hozzon létre egy munkaterületet, amely tartalmazza a beágyazandó jelentést. A munkamenet során kapcsolja össze a jelentést a bérlőspecifikus szemantikai modellel. További részletekért olvassa el a dinamikus kötéseket .

Tartalom testreszabása és létrehozása

Amikor tartalmat hoz létre, alaposan gondolja át, hogy kinek van engedélye a szerkesztésére. Ha lehetővé teszi, hogy egy bérlőben több felhasználó szerkesszen, könnyen túlléphetik a szemantikai modell korlátait. Ha úgy dönt, hogy szerkesztési képességet ad a felhasználóknak, monitorozza a tartalomlétrehozásukat, és szükség szerint vertikálisan felskálázza őket. Ugyanebből az okból nem javasoljuk, hogy ezt a képességet a tartalom személyre szabásához használja, ahol minden felhasználó elvégezhet kisebb módosításokat egy jelentésen, és mentheti saját maga számára. Ha az ISV-alkalmazás lehetővé teszi a tartalom személyre szabását, fontolja meg a munkaterület adatmegőrzési szabályzatainak bevezetését a felhasználóspecifikus tartalmakhoz. A megőrzési szabályzatok megkönnyítik a tartalom törlését, ha a felhasználók új helyre lépnek, elhagyják a vállalatot, vagy nem használják a platformot.

Rendszer által felügyelt identitás

Szolgáltatásnév helyett egy felhasználó által hozzárendelt vagy rendszer által hozzárendeltfelügyelt identitással hozhat létre profilokat. A felügyelt identitások csökkentik a titkos kódok és tanúsítványok szükségességét.

Legyen óvatos a rendszer által felügyelt identitás használatakor, mert:

  • Ha egy rendszer által hozzárendelt felügyelt identitás véletlenül ki van kapcsolva, elveszíti a hozzáférést a profilokhoz. Ez a helyzet hasonló ahhoz az esethez, amikor egy szolgáltatásnevet törölnek.
  • A rendszer által hozzárendelt felügyelt identitás egy Azure-beli erőforráshoz (webalkalmazáshoz) csatlakozik. Ha törli az erőforrást, az identitás is törlődik.
  • Ha több erőforrást használ (különböző régiókban különböző webalkalmazásokat) több identitást eredményez, amelyeket külön kell felügyelni (mindegyik identitás saját profilokkal rendelkezik).

A fenti szempontok miatt javasoljuk, hogy felhasználó által hozzárendelt felügyelt identitást használjon.

Példa

Ha például szolgáltatásnévprofilokat szeretne használni a több-bérlős környezetek Power BI- és App-Owns-Data-beágyazással való kezelésére, töltse le az alkalmazás tulajdonában lévő több-bérlős adattárat a Power BI Fejlesztői táborból (külső webhelyről).

Kapcsolódó tartalom

  • Last updated on