Méretezhető több-bérlős alkalmazások fejlesztése Power BI-beágyazással
Ez a cikk bemutatja, hogyan fejleszthet olyan több-bérlős alkalmazást, amely beágyazza a Power BI-tartalmakat a skálázhatóság, a teljesítmény és a biztonság legmagasabb szintjeinek elérése mellett. Szolgáltatásnévprofilokkal rendelkező alkalmazás tervezésével és implementálásával több tízezer ügyfélbérleményt tartalmazó több-bérlős megoldást hozhat létre és kezelhet, amely több mint 100 000 felhasználó célközönségének tud jelentéseket szolgáltatni.
A szolgáltatásnévprofilok olyan funkciók, amelyek megkönnyítik a szervezeti tartalmak Kezelését a Power BI-ban, és hatékonyabban használhatják kapacitásait. A szolgáltatásnévprofilok használata azonban összetettebbé teheti az alkalmazástervet. Ezért csak akkor érdemes használni őket, ha jelentős skálázásra van szükség. Szolgáltatásnévprofilok használatát javasoljuk, ha több munkaterülete és több mint 1000 alkalmazásfelhasználója van.
Feljegyzés
A szolgáltatásnévprofilok használatának értéke nő, ahogy a skálázási igény nő, valamint a legmagasabb szintű biztonság és bérlői elkülönítés elérése szükséges.
A Power BI-beágyazást két különböző beágyazási forgatókönyv használatával érheti el: a beágyazást a szervezet számára és a beágyazást az ügyfél számára.
A szervezeti forgatókönyv beágyazása akkor érvényes, ha az alkalmazás célközönsége belső felhasználókból áll. A belső felhasználóknak szervezeti fiókokkal kell rendelkezniük, és a Microsoft Entra-azonosítóval (korábbi nevén Azure Active Directoryval) kell hitelesíteniük magukat. Ebben a forgatókönyvben a Power BI szolgáltatásként (SaaS) működik. Néha úgy is nevezik, hogy a felhasználó az adatok tulajdonosa.
Az ügyfélforgatókönyv beágyazása akkor érvényes, ha az alkalmazás célközönsége külső felhasználókból áll. Az alkalmazás feladata a felhasználók hitelesítése. A Power BI-tartalmak eléréséhez az alkalmazás egy beágyazási identitásra (Microsoft Entra szolgáltatásnévre vagy fő felhasználói fiókra) támaszkodik a Microsoft Entrával való hitelesítéshez. Ebben a forgatókönyvben a Power BI szolgáltatásként platformként (PaaS) működik. Néha úgy is nevezik, hogy az alkalmazás az adatok tulajdonosa.
Feljegyzés
Fontos tisztában lenni azzal, hogy a szolgáltatásnévprofilok funkció az ügyfélforgatókönyv Beágyazás funkciójával való használatra lett kialakítva. Ennek az az oka, hogy ez a forgatókönyv lehetővé teszi az isv-k és a vállalati szervezetek számára, hogy nagyobb léptékű beágyazást tudjanak biztosítani nagy számú felhasználónak és nagy számú ügyfélbérlelőnek.
Több-bérlős alkalmazásfejlesztés
Ha ismeri a Microsoft Entrát, a bérlő szó vezethet a Microsoft Entra-bérlőre. A bérlő fogalma azonban eltér a Power BI-tartalmakat beágyazó több-bérlős megoldás létrehozásához. Ebben az összefüggésben a rendszer minden ügyfél nevében létrehoz egy ügyfél-bérlőt, amelynek az alkalmazás a Beágyazás az ügyfélforgatókönyvben való használatával beágyazza a Power BI-tartalmakat. Általában minden ügyfélbérlőt egyetlen Power BI-munkaterület létrehozásával épít ki.
Skálázható több-bérlős megoldás létrehozásához képesnek kell lennie az új ügyfélbérlelők létrehozásának automatizálására. Az új ügyfélbérlelő kiépítéséhez általában olyan kódot kell írni, amely a Power BI REST API-val hoz létre egy új Power BI-munkaterületet, szemantikai modelleket (korábbi nevén adathalmazokat) hoz létre a Power BI Desktop -fájlok (.pbix) importálásával, az adatforrás paramétereinek frissítésével, az adatforrás hitelesítő adatainak beállításával és az ütemezett szemantikai modellfrissítés beállításával. Az alábbi ábra bemutatja, hogyan adhat hozzá Power BI-elemeket, például jelentéseket és szemantikai modelleket a munkaterületekhez az ügyfélbérlők beállításához.
Amikor olyan alkalmazást fejleszt, amely a beágyazást használja az ügyfélforgatókönyvhöz, a Power BI REST API-hívások egy fő felhasználói fiókból vagy szolgáltatásnévből származó beágyazási identitás használatával kezdeményezhetők. Javasoljuk, hogy használjon egyszerű szolgáltatást éles alkalmazásokhoz. Ez biztosítja a legmagasabb biztonságot, és ezért ez a Microsoft Entra által javasolt megközelítés. Emellett támogatja a jobb automatizálást és skálázást, és kevesebb felügyeleti többletterheléssel jár. Ehhez azonban Power BI-rendszergazdai jogosultságok szükségesek a beállításhoz és a kezeléshez.
Szolgáltatásnév használatával elkerülheti a fő felhasználói fiókokkal kapcsolatos gyakori problémákat, például olyan környezetekben fellépő hitelesítési hibákat, ahol a felhasználóknak többtényezős hitelesítéssel (MFA) kell bejelentkezniük. A szolgáltatásnév használata azzal az elképzeléssel is összhangban van, hogy az ügyfélforgatókönyv beágyazása a Power BI-tartalmak PaaS-gondolkodásmód használatával történő beágyazásán alapul, szemben az SaaS-gondolkodásmóddal.
1000 munkaterületre vonatkozó korlátozás
Ha olyan több-bérlős környezetet tervez, amely megvalósítja az ügyfélforgatókönyv beágyazását, vegye figyelembe, hogy a beágyazási identitás nem tud hozzáférést biztosítani több mint 1000 munkaterülethez. A Power BI szolgáltatás ezt a korlátozást a REST API-hívások során a megfelelő teljesítmény biztosítása érdekében kényszeríti ki. Ennek a korlátozásnak az oka az, hogy a Power BI hogyan tartja fenn az egyes identitások biztonsági metaadatait.
A Power BI metaadatokat használ az identitás által elérhető munkaterületek és munkaterületelemek nyomon követésére. A Power BI-nak valójában külön hozzáférés-vezérlési listát (ACL) kell fenntartania az engedélyezési alrendszer minden identitásához. Amikor egy identitás REST API-hívást indít egy munkaterület eléréséhez, a Power BI-nak biztonsági ellenőrzést kell végeznie az identitás ACL-ján annak engedélyezéséhez. A munkaterületek számának növekedésével exponenciálisan nő annak meghatározása, hogy a cél-munkaterület az ACL-ben található-e.
Feljegyzés
A Power BI nem kényszeríti ki az 1000 munkaterület korlátozását kóddal. Ha megpróbálja, több mint 1000 munkaterülethez ad beágyazási identitást, és a REST API-hívások továbbra is sikeresek lesznek. Az alkalmazás azonban nem támogatott állapotba kerül, aminek következményei lehetnek, ha segítséget szeretne kérni a Microsoft támogatásától.
Vegyünk egy olyan forgatókönyvet, amelyben két több-bérlős alkalmazás van beállítva egyetlen szolgáltatásnév használatára. Most vegye figyelembe, hogy az első alkalmazás 990 munkaterületet hozott létre, míg a második alkalmazás 1010 munkaterületet hozott létre. Támogatási szempontból az első alkalmazás a támogatott határokon belül van, míg a második alkalmazás nem.
Most hasonlítsa össze ezt a két alkalmazást pusztán teljesítmény szempontjából. Nincs annyi különbség, mert a két szolgáltatásnév ACL-jei lehetővé tesziki lehetővé teszikii metaadatainak egy olyan pontra való növelését, amely bizonyos mértékig csökkenti a teljesítményt.
Íme a legfontosabb megfigyelés: A szolgáltatásnév által létrehozott munkaterületek száma közvetlen hatással van a teljesítményre és a méretezhetőségre. A 100 munkaterülethez tartozó szolgáltatásnév gyorsabban hajtja végre a REST API-hívásokat, mint egy 1000 munkaterületet tartalmazó szolgáltatásnév. Hasonlóképpen, egy olyan szolgáltatásnév, amely csak 10 munkaterület tagja, gyorsabban hajtja végre a REST API-hívásokat, mint egy 100 munkaterülethez tartozó szolgáltatásnév.
Fontos
A teljesítmény és a méretezhetőség szempontjából az optimális számú munkaterület, amelynek a szolgáltatásnév tagja , pontosan egy.
Szemantikai modellek és adatforrás-hitelesítő adatok elkülönítésének kezelése
A több-bérlős alkalmazások tervezésekor egy másik fontos szempont az ügyfélbérlelők elkülönítése. Kritikus fontosságú, hogy az egyik ügyfélbérbe tartozó felhasználók ne láthassanak egy másik ügyfélbérbe tartozó adatot. Ezért tisztában kell lennie azzal, hogyan kezelheti a szemantikai modell tulajdonjogát és az adatforrás hitelesítő adatait.
Szemantikai modell tulajdonjoga
Minden Power BI szemantikai modell egyetlen tulajdonossal rendelkezik, amely lehet felhasználói fiók vagy szolgáltatásnév. Az ütemezett frissítés beállításához és a szemantikai modell paramétereinek beállításához szemantikai modelltulajdonság szükséges.
Tipp.
Az Power BI szolgáltatás a szemantikai modell beállításainak megnyitásával meghatározhatja, hogy ki a szemantikai modell tulajdonosa.
Szükség esetén a szemantikai modell tulajdonjogát átviheti egy másik felhasználói fiókba vagy szolgáltatásnévbe. Ezt a Power BI szolgáltatás vagy a REST API-művelettel TakeOver teheti meg. Amikor power BI Desktop-fájlt importál egy új szemantikai modell létrehozásához egy szolgáltatásnév használatával, a szolgáltatásnév automatikusan szemantikai modell tulajdonosaként lesz beállítva.
Adatforráshoz tartozó hitelesítő adatok
Ha szemantikai modellt szeretne csatlakoztatni a mögöttes adatforráshoz, a szemantikai modell tulajdonosának meg kell adnia az adatforrás hitelesítő adatait. Az adatforrás hitelesítő adatait a Power BI titkosítja és gyorsítótárazza. Ettől a ponttól kezdve a Power BI ezeket a hitelesítő adatokat használja a mögöttes adatforrással való hitelesítéshez az adatok frissítésekor (tárolótáblák importálása esetén) vagy átmenő lekérdezések végrehajtásakor (DirectQuery-tárolótáblák esetében).
Javasoljuk, hogy egy új ügyfélbérlelő kiépítésekor alkalmazzon egy közös tervezési mintát. REST API-hívások sorozatát a szolgáltatásnév identitásával hajthatja végre:
- Hozzon létre egy új munkaterületet.
- Az új munkaterület társítása dedikált kapacitással.
- Szemantikai modell létrehozásához importáljon Egy Power BI Desktop-fájlt.
- Adja meg a szemantikai modell forrásának hitelesítő adatait a szemantikai modellhez.
A REST API-hívások befejezésekor a szolgáltatásnév lesz az új munkaterület rendszergazdája, valamint a szemantikai modell és az adatforrás hitelesítő adatainak tulajdonosa.
Fontos
Gyakori tévhit, hogy a szemantikai modell adatforrás-hitelesítő adatai munkaterületszintű hatókörrel vannak elosztva. Ez nem igaz. Az adatforrás hitelesítő adatai a szolgáltatásnévre (vagy felhasználói fiókra) terjednek ki, és ez a hatókör a Microsoft Entra-bérlő összes Power BI-munkaterületére kiterjed.
A szolgáltatásnév létrehozhat olyan adatforrás-hitelesítő adatokat, amelyeket szemantikai modellek osztanak meg különböző munkaterületeken az ügyfélbérlelők között, ahogyan az az alábbi ábrán látható.
Ha az adatforrás hitelesítő adatait különböző ügyfélbérlõkhöz tartozó szemantikai modellek osztják meg, az ügyfélbérlõk nem lesznek teljesen elkülönítve.
Tervezési stratégiák a szolgáltatásnév-profilok előtt
A szolgáltatásnév-profil funkció elérhetővé történő elérhetővé vált tervezési stratégiáinak megismerése segíthet felmérni a funkció szükségességét. Ez előtt a fejlesztők a következő három tervezési stratégia egyikével készítettek több-bérlős alkalmazásokat:
- Egyszerű szolgáltatásnév
- Szolgáltatásnév készletezése
- Munkaterületenként egy szolgáltatásnév
Mindegyik tervezési stratégiához vannak erősségek és gyengeségek.
Az egyszerű szolgáltatástervezési stratégia a Microsoft Entra-alkalmazásregisztráció egyszeri létrehozását igényli. Ezért kevesebb adminisztrációs többletterhelést jelent, mint a másik két tervezési stratégia, mivel nincs szükség további Microsoft Entra-alkalmazásregisztrációk létrehozására. Ez a stratégia azért is a legegyszerűbb beállítás, mert nem igényel olyan extra kódot, amely a REST API-hívások során a szolgáltatásnevek között váltja át a hívási környezetet. Ezzel a tervezési stratégiával azonban az a probléma, hogy nem méretezhető. Csak olyan több-bérlős környezetet támogat, amely akár 1000 munkaterületet is képes felnőni. Emellett a teljesítmény is csökkenni fog, mivel a szolgáltatásnév nagyobb számú munkaterülethez kap hozzáférést. Az ügyfélbérlők elkülönítésével is probléma van, mert az egyetlen szolgáltatásnév lesz az összes szemantikai modell és az összes ügyfélbérlő összes adat hitelesítő adatainak tulajdonosa.
A szolgáltatásnév-készletezési tervezési stratégiát gyakran használják az 1000 munkaterületre vonatkozó korlátozás elkerülésére. Lehetővé teszi, hogy az alkalmazás tetszőleges számú munkaterületre méretezhető legyen a megfelelő számú szolgáltatásnév hozzáadásával a készlethez. Egy öt szolgáltatásnévből álló készlet például 5000 munkaterület skálázását teszi lehetővé; A 80 szolgáltatásnévből álló készlet 80 000 munkaterületet és így tovább skálázhatóvá tesz. Bár ez a stratégia nagy számú munkaterületre skálázható, számos hátránya van. Először is szükség van további kód írására és metaadatok tárolására, hogy lehetővé tegye a környezetváltást a szolgáltatásnevek között REST API-hívások indításakor. Másodszor, ez nagyobb adminisztrációs erőfeszítést igényel, mivel microsoft entra-alkalmazásregisztrációkat kell létrehoznia, amikor növelnie kell a készletben lévő szolgáltatásnevek számát.
Ráadásul a szolgáltatásnév-készletezési stratégia nem a teljesítményre van optimalizálva, mert lehetővé teszi, hogy a szolgáltatásnevek több száz munkaterület tagjaivá váljanak. Az ügyfélbérlelők elkülönítése szempontjából sem ideális, mert a szolgáltatásnevek a szemantikai modell és az ügyfélbérlelők között megosztott adat hitelesítő adatok tulajdonosaivá válhatnak.
A munkaterületenkénti egyetlen szolgáltatásnév tervezési stratégiája magában foglalja egy szolgáltatásnév létrehozását az egyes ügyfélbérlelők számára. Elméleti szempontból ez a stratégia a legjobb megoldást kínálja, mivel optimalizálja a REST API-hívások teljesítményét, miközben valódi elkülönítést biztosít a szemantikai modellekhez és az adatforrás hitelesítő adataihoz a munkaterület szintjén. Az elméletben legjobban működő megoldás azonban nem mindig a gyakorlatban működik a legjobban. Ennek az az oka, hogy az egyes ügyfélbérlelőkhöz szolgáltatásnév létrehozására vonatkozó követelmény sok szervezet számára nem praktikus. Ennek az az oka, hogy egyes szervezetek hivatalos jóváhagyási folyamatokkal rendelkeznek, vagy túlzott bürokráciát igényelnek a Microsoft Entra-alkalmazásregisztrációk létrehozásához. Ezek az okok lehetetlenné tehetik, hogy az egyéni alkalmazásokat olyan szolgáltatónak adja, amely igény szerint és a megoldás által igényelt automatizált módon hozza létre a Microsoft Entra-alkalmazásregisztrációkat.
Kevésbé gyakori esetekben, amikor egy egyéni alkalmazás megfelelő engedélyeket kapott, a Microsoft Graph API-val igény szerint hozhat létre Microsoft Entra-alkalmazásregisztrációkat. Az egyéni alkalmazás fejlesztése és üzembe helyezése azonban gyakran bonyolult, mert valahogy nyomon kell követnie az egyes Microsoft Entra-alkalmazásregisztrációk hitelesítési hitelesítő adatait. Emellett hozzáférést kell szereznie ezekhez a hitelesítő adatokhoz, amikor hitelesítenie kell, és hozzáférési jogkivonatokat kell beszereznie az egyes szolgáltatásnevekhez.
Egyszerű szolgáltatásprofilok
A szolgáltatásnévprofilok funkció úgy lett kialakítva, hogy megkönnyítse a szervezeti tartalmak kezelését a Power BI-ban, és hatékonyabban tudja használni a kapacitásait. Három konkrét kihívás megoldásához nyújtanak segítséget, amelyek a legkisebb mértékű fejlesztői munkát és többletterhelést foglalják magukban. Ezek a kihívások a következők:
- Skálázás nagy számú munkaterületre.
- A REST API-hívások teljesítményének optimalizálása.
- Szemantikai modellek és adatforrás-hitelesítő adatok elkülönítése az ügyfél bérlői szintjén.
Ha szolgáltatásnév-profilok használatával tervez több-bérlős alkalmazást, a három (az előző szakaszban ismertetett) tervezési stratégia erősségeiből is profitálhat, és elkerülheti a hozzájuk kapcsolódó hiányosságokat.
A szolgáltatásnévprofilok a Power BI környezetében létrehozott helyi fiókok. A szolgáltatásnév a Profiles REST API-művelettel új szolgáltatásnévprofilokat hozhat létre. A szolgáltatásnév saját szolgáltatásnévprofilokat hozhat létre és kezelhet egy egyéni alkalmazáshoz, ahogyan az az alábbi ábrán látható.
A szolgáltatásnév és az általa létrehozott szolgáltatásnév-profilok között mindig van szülő-gyermek kapcsolat. Szolgáltatásnév-profil nem hozható létre önálló entitásként. Ehelyett egy szolgáltatásnévprofilt hoz létre egy adott szolgáltatásnév használatával, és ez a szolgáltatásnév szolgál a profil szülőjeként. Emellett a szolgáltatásnév profilja soha nem látható a felhasználói fiókok vagy más szolgáltatásnevek számára. A szolgáltatásnévprofilt csak az azt létrehozó szolgáltatásnév tekintheti meg és használhatja.
A Szolgáltatásnév-profilok nem ismertek a Microsoft Entra számára
Bár maga a szolgáltatásnév és annak mögöttes Microsoft Entra-alkalmazásregisztrációja ismert a Microsoft Entra számára, a Microsoft Entra ID nem tud semmit a szolgáltatásnév-profilokról. Ennek az az oka, hogy a szolgáltatásnévprofilokat a Power BI hozza létre, és csak a Power BI biztonságát és engedélyezését vezérlő Power BI szolgáltatás alrendszerben léteznek.
Az a tény, hogy a Szolgáltatásnév profilok nem ismertek a Microsoft Entra ID-ról, előnyei és hátrányai is vannak. Az elsődleges előnye, hogy az ügyfélforgatókönyv-alkalmazások beágyazásához nincs szükség speciális Microsoft Entra-engedélyekre a szolgáltatásnévprofilok létrehozásához. Azt is jelenti, hogy az alkalmazás létrehozhat és kezelhet a Microsoft Entra-tól eltérő helyi identitásokat.
Vannak azonban hátrányai is. Mivel a Szolgáltatásnév profilok nem ismertek a Microsoft Entra számára, nem adhat hozzá szolgáltatásnévprofilt egy Microsoft Entra-csoporthoz, hogy implicit módon hozzáférést biztosítson egy munkaterülethez. Emellett a külső adatforrások, például az Azure SQL Database vagy az Azure Synapse Analytics nem tudják felismerni a szolgáltatásnév-profilokat identitásként az adatbázishoz való csatlakozáskor. Így a munkaterületenkénti egyetlen szolgáltatásnév (szolgáltatásnév létrehozása az egyes ügyfélbérlelők számára) jobb választás lehet, ha az egyes ügyfélbérlelőkhöz külön szolgáltatásnévvel kell csatlakozni ezekhez az adatforrásokhoz.
A szolgáltatásnévprofilok első osztályú biztonsági tagok
Bár a Szolgáltatásnév profilok nem ismertek a Microsoft Entra számára, a Power BI első osztályú biztonsági tagokként ismeri fel őket. A felhasználói fiókhoz vagy a szolgáltatásnévhez hasonlóan szolgáltatásnévprofilokat is hozzáadhat egy munkaterületi szerepkörhöz (Rendszergazda vagy tagként). Szemantikai modelltulajdonossá és adatforrás-hitelesítő adatok tulajdonosává is teheti. Ezen okokból ajánlott új szolgáltatásnévprofilt létrehozni minden új ügyfélbérlelőhöz.
Tipp.
Amikor szolgáltatásnév-profilok használatával fejleszt beágyazást az ügyfélforgatókönyv-alkalmazáshoz , csak egyetlen Microsoft Entra-alkalmazásregisztrációt kell létrehoznia, hogy egyetlen szolgáltatásnevet biztosíthasson az alkalmazásnak. Ez a megközelítés jelentősen csökkenti a felügyeleti többletterhelést más több-bérlős tervezési stratégiákhoz képest, ahol az alkalmazás éles környezetben való üzembe helyezése után folyamatosan további Microsoft Entra-alkalmazásregisztrációkat kell létrehozni.
REST API-hívások végrehajtása szolgáltatásnévprofilként
Az alkalmazás rest API-hívásokat hajthat végre egy egyszerű szolgáltatásprofil identitásával. Ez azt jelenti, hogy rest API-hívások sorozatát hajthatja végre egy új ügyfélbérlevő kiépítéséhez és beállításához.
- Amikor egy egyszerű szolgáltatásprofil létrehoz egy új munkaterületet, a Power BI automatikusan hozzáadja ezt a profilt munkaterület-rendszergazdaként.
- Amikor egy szolgáltatásnévprofil importál egy Power BI Desktop-fájlt szemantikai modell létrehozásához, a Power BI ezt a profilt állítja be szemantikai modell tulajdonosaként.
- Amikor egy egyszerű szolgáltatásprofil beállítja az adatforrás hitelesítő adatait, a Power BI ezt a profilt állítja be az adatforrás hitelesítő adatainak tulajdonosaként.
Fontos tisztában lenni azzal, hogy a szolgáltatásnévnek olyan identitása van a Power BI-ban, amely elkülönül a profilok identitásától. Ez lehetővé teszi a választást fejlesztőként. REST API-hívásokat egy egyszerű szolgáltatásprofil identitásával hajthat végre. Másik lehetőségként a REST API-hívásokat profil nélkül is végrehajthatja, amely a szülőszolgáltatásnév identitását használja.
A szolgáltatásnévprofilok létrehozásakor, megtekintésekor vagy törlésekor javasoljuk, hogy a rest API-hívásokat szülőszolgáltatásnévként hajtsa végre. Az összes többi REST API-hívás végrehajtásához a szolgáltatásnév-profilt kell használnia. Ezek a hívások létrehozhatnak munkaterületeket, importálhatnak Power BI Desktop-fájlokat, frissíthetik a szemantikai modell paramétereit, és beállíthatják az adatforrás hitelesítő adatait. Emellett lekérhetik a munkaterületelem metaadatait, és beágyazási jogkivonatokat hozhatnak létre.
Vegyünk egy példát, ahol be kell állítania egy ügyfélbérlmét egy Contoso nevű ügyfélhez. Az első lépés egy REST API-hívással hoz létre egy szolgáltatásnévprofilt, amelynek megjelenítendő neve Contoso. Ez a hívás a szolgáltatásnév identitásával történik. A többi beállítási lépés a szolgáltatásnév-profillal hajtja végre a következő feladatokat:
- Munkaterület létrehozása.
- Rendelje hozzá a munkaterületet egy kapacitáshoz.
- Power BI Desktop-fájl importálása.
- Szemantikai modellparaméterek beállítása.
- Adatforrás hitelesítő adatainak beállítása.
- Ütemezett adatfrissítés beállítása.
Fontos tisztában lenni azzal, hogy a munkaterülethez és annak tartalmához való hozzáférést az ügyfélbérlelő létrehozásához használt egyszerű szolgáltatásprofil identitásával kell elvégezni. Azt is fontos megérteni, hogy a szülőszolgáltatás-tagnak nem kell hozzáférnie a munkaterülethez vagy annak tartalmához.
Tipp.
Ne feledje: REST API-hívások esetén a szolgáltatásnév használatával hozzon létre és kezelhessen szolgáltatásnévprofilokat, és a szolgáltatásnévprofil használatával hozzon létre, állítson be és érje el a Power BI-tartalmakat.
A Profilok REST API-műveleteinek használata
A Profiles REST API műveleti csoport olyan műveletekből áll, amelyek szolgáltatásnévprofilokat hoznak létre és kezelnek:
Create ProfileDelete ProfileGet ProfileGet ProfilesUpdate Profile
Egyszerű szolgáltatásprofil létrehozása
A Profil létrehozása REST API-művelettel hozzon létre egy egyszerű szolgáltatásprofilt. A tulajdonságot a displayName kérelem törzsében kell beállítania, hogy megjelenítse az új bérlő nevét. Az értéknek egyedinek kell lennie a szolgáltatásnév tulajdonában lévő összes profilban. A hívás sikertelen lesz, ha már létezik egy másik profil ezzel a megjelenítendő névvel a szolgáltatásnévhez.
A sikeres hívás visszaadja a id tulajdonságot, amely egy GUID, amely a profilt jelöli. Szolgáltatásnévprofilokat használó alkalmazások fejlesztésekor javasoljuk, hogy a profilmegjelenítési neveket és azok azonosítóértékeit egy egyéni adatbázisban tárolja. Így az alkalmazás egyszerűen lekérheti az azonosítókat.
Ha a Power BI .NET SDK-val programozott, használhatja a Profiles.CreateProfile metódust, amely az új profilt ServicePrincipalProfile képviselő objektumot adja vissza. Ez megkönnyíti a tulajdonság értékének id meghatározását.
Íme egy példa egy szolgáltatásnévprofil létrehozására és munkaterület-hozzáférés megadására.
// Create a service principal profile
string profileName = "Contoso";
var createRequest = new CreateOrUpdateProfileRequest(profileName);
var profile = pbiClient.Profiles.CreateProfile(createRequest);
// Retrieve the ID of the new profile
Guid profileId = profile.Id;
// Grant workspace access
var groupUser = new GroupUser {
GroupUserAccessRight = "Admin",
PrincipalType = "App",
Identifier = ServicePrincipalId,
Profile = new ServicePrincipalProfile {
Id = profileId
}
};
pbiClient.Groups.AddGroupUser(workspaceId, groupUser);
A Power BI szolgáltatás munkaterület Hozzáférés paneljén meghatározhatja, hogy mely identitások , köztük a biztonsági tagok férhetnek hozzá.
Szolgáltatásnévprofil törlése
A Profil törlése REST API művelettel törölhet egy egyszerű szolgáltatásprofilt. Ezt a műveletet csak a szülőszolgáltatás-tag hívhatja meg.
Ha a Power BI .NET SDK-val programozott, használhatja a metódust Profiles.DeleteProfile .
Az összes szolgáltatásnévprofil lekérése
A Profilok lekérése REST API-művelettel lekérheti a hívó szolgáltatásnévhez tartozó szolgáltatásnévprofilok listáját. Ez a művelet egy JSON-hasznos adatot ad vissza, amely tartalmazza az id egyes szolgáltatásnévprofilok tulajdonságait és displayName tulajdonságait.
Ha a Power BI .NET SDK-val programozott, használhatja a Profiles.GetProfiles metódust .
REST API-hívások végrehajtása egyszerű szolgáltatásprofil használatával
A REST API-hívások szolgáltatásnév-profillal történő indításának két követelménye van:
- Az Engedélyezési fejlécben át kell adnia a szülőszolgáltatásnév hozzáférési jogkivonatát.
- Tartalmaznia kell egy X-PowerBI-profile-id nevű fejlécet a szolgáltatásnév-profil azonosítójának értékével.
Ha a Power BI .NET SDK-t használja, az X-PowerBI-profile-id fejléc értékét explicit módon állíthatja be a szolgáltatásnév-profil azonosítójának megadásával.
// Create the Power BI client
var tokenCredentials = new TokenCredentials(GetACcessToken(). "Bearer");
var uriPowerBiServiceApiRoot = new Uri(uriPowerBiServiceApiRoot);
var pbiClient = new PowerBIClient(uriPowerBiServiceApiRoot, tokenCredentials);
// Add X-PowerBI-profile-id header for service principal profile
string profileId = "11111111-1111-1111-1111-111111111111";
pbiClient.HttpClient.DefaultRequestHeaders.Add("X-PowerBI-profile-id", profileId);
// Retrieve workspaces by using the identity of service principal profile
var workspaces = pbiClient.Groups.GetGroups();
Amint a fenti példában látható, miután hozzáadta az X-PowerBI-profile-id fejlécet az PowerBIClient objektumhoz, egyszerűen meghívhat metódusokat, például Groups.GetGroupsa szolgáltatásnév profillal hajthatja végre őket.
Egy objektum X-PowerBI-profile-id fejlécét PowerBIClient kényelmesebben állíthatja be. Az objektum inicializálásához adja meg a profil azonosítóját a konstruktornak.
// Create the Power BI client
string profileId = "11111111-1111-1111-1111-111111111111";
var tokenCredentials = new TokenCredentials(GetACcessToken(). "Bearer");
var uriPowerBiServiceApiRoot = new Uri(uriPowerBiServiceApiRoot);
var pbiClient = new PowerBiClient(uriPowerBiServiceApiRoot, tokenCredentials, profileId);
A több-bérlős alkalmazások programozása során valószínűleg váltania kell a hívások szülőszolgáltatásnévként való végrehajtása és a hívások szolgáltatásnévprofilként való végrehajtása között. A környezetváltás kezelésének hasznos módszere az objektumot tároló PowerBIClient osztályszintű változó deklarálása. Ezután létrehozhat egy segédmetódust, amely a megfelelő objektummal állítja be a változót.
// Class-level variable that stores the PowerBIClient object
private PowerBIClient pbiClient;
// Helper method that sets the correct PowerBIClient object
private void SetCallingContext(string profileId = "") {
if (profileId.Equals("")) {
pbiClient = GetPowerBIClient();
}
else {
pbiClient = GetPowerBIClientForProfile(new Guid(profileId));
}
}
Ha szolgáltatásnévprofilt kell létrehoznia vagy kezelnie, paraméterek nélkül hívhatja meg a SetCallingContext metódust. Így profilokat hozhat létre és kezelhet a szolgáltatásnév identitásával.
// Always create and manage profiles as the service principal
SetCallingContext();
// Create a service principal profile
string profileName = "Contoso";
var createRequest = new CreateOrUpdateProfileRequest(profileName);
var profile = pbiClient.Profiles.CreateProfile(createRequest);
Ha új ügyfélbérlelő munkaterületét kell létrehoznia és beállítania, a kódot szolgáltatásnév-profilként kell végrehajtania. Ezért a metódust a SetCallingContext profil azonosítójának megadásával kell meghívnia. Így létrehozhatja a munkaterületet a szolgáltatásnév-profil identitásával.
// Always create and set up workspaces as a service principal profile
string profileId = "11111111-1111-1111-1111-111111111111";
SetCallingContext(profileId);
// Create a workspace
GroupCreationRequest request = new GroupCreationRequest(workspaceName);
Group workspace = pbiClient.Groups.CreateGroup(request);
Miután egy adott szolgáltatásnévprofilt használt egy munkaterület létrehozásához és konfigurálásához, a munkaterület tartalmának létrehozásához és beállításához továbbra is ugyanazt a profilt kell használnia. A beállítás elvégzéséhez nincs szükség a SetCallingContext metódus meghívására.
Fejlesztői minta
Javasoljuk, hogy töltsön le egy AppOwnsDataMultiTenant nevű mintaalkalmazást.
Ez a mintaalkalmazás a .NET 6 és ASP.NET használatával lett kifejlesztve, és bemutatja, hogyan alkalmazhatók a cikkben ismertetett útmutatások és javaslatok. A kódot áttekintve megtudhatja, hogyan fejleszthet több-bérlős alkalmazást, amely szolgáltatásnévprofilok használatával implementálja az ügyfélforgatókönyv beágyazását.
Kapcsolódó tartalom
A cikkről további információt a következő forrásokban talál:
Visszajelzés
Hamarosan elérhető: 2024-ben fokozatosan kivezetjük a GitHub-problémákat a tartalom visszajelzési mechanizmusaként, és lecseréljük egy új visszajelzési rendszerre. További információ: https://aka.ms/ContentUserFeedback.
Visszajelzés küldése és megtekintése a következőhöz: