Zdieľať cez


Profily objektu služby pre aplikácie s viacerými nájomníkmi v službe Power BI Embedded

Tento článok vysvetľuje, ako môže nezávislý dodávateľ softvéru alebo ktorýkoľvek iný vlastník aplikácie služby Power BI Embedded s mnohými zákazníkmi používať profily objektu služby na mapovanie a spravovanie údajov jednotlivých zákazníkov v rámci riešenia vkladania obsahu služby Power BI pre vašich zákazníkov . Profily objektu služby umožňujú nezávislým dodávateľom softvéru vytvárať škálovateľné aplikácie, ktoré umožňujú lepšiu izoláciu údajov zákazníkov a vytvárajú prísnejšie hranice zabezpečenia medzi zákazníkmi. V tomto článku sa popisujú výhody a obmedzenia tohto riešenia.

Poznámka

Slovo nájomník v službe Power BI môže niekedy odkazovať na nájomníka Microsoft Entra. V tomto článku však používame výraz multinájma na popis riešenia, v ktorom jedna inštancia softvérovej aplikácie slúži viacerým zákazníkom alebo organizáciám (nájomníkom), ktoré vyžadujú fyzické a logické oddelenie údajov. Zostavovač aplikácií Power BI napríklad môže priradiť samostatný pracovný priestor pre každého zo svojich zákazníkov (alebo nájomníkov), ako vidíme nižšie. Títo zákazníci nemusia nevyhnutne používať nájomníkov služby Microsoft Entra, a preto si nezamieňajte výraz viacúčelová aplikácia, ktorú tu používame, s aplikáciou Microsoft Entra multitenant.

Profil objektu služby je profil, ktorý vytvoril objekt služby. Aplikácia nezávislého dodávateľa softvéru volá rozhranie API služby Power BI pomocou profilu objektu služby, ako je vysvetlené v tomto článku.

Objekt služby aplikácie nezávislého dodávateľa softvéru vytvorí iný profil v službe Power BI pre každého zákazníka alebo nájomníka. Keď zákazník prejde do aplikácie isv, aplikácia použije príslušný profil na generovanie vkladacieho tokenu , ktorý sa použije na vykreslenie zostavy v prehliadači.

Použitie profilov objektu služby umožňuje aplikácii ISV hosťovať viacerých zákazníkov v jednom nájomníkovi služby Power BI. Každý profil predstavuje jedného zákazníka v službe Power BI. Inými slovami, každý profil vytvorí a spravuje obsah v službe Power BI pre údaje konkrétneho zákazníka.

Diagram profilov služby SP a architektúry s viacerými nájomnosťami.

Poznámka

Tento článok je zameraný na organizácie, ktoré chcú nastaviť viacúčelovú aplikáciu používajúcu hlavné profily služby. Ak už vaša organizácia má aplikáciu, ktorá podporuje viac nájomnosti a chcete migrovať do modelu profilu objektu služby, pozrite si tému Migrácia do modelu profilov objektu služby.

Nastavenie obsahu služby Power BI zahŕňa nasledujúce kroky:

Všetky vyššie uvedené kroky môžu byť plne automatizované pomocou rozhraní REST API služby Power BI.

Požiadavky

Pred vytvorením profilov objektu služby je potrebné:

  • Nastavte objekt služby pomocou prvých troch krokov v téme Vloženie obsahu služby Power BI pomocou objektu služby.
  • Pomocou konta správcu nájomníka služby Power BI povoľte vytváranie profilov v nájomníkovi pomocou rovnakej skupiny zabezpečenia, ktorú ste použili pri vytváraní objektu služby.

Snímka obrazovky s prepínačom portálu na správu.

Vytvorenie profilu

Profily je možné vytvoriť, aktualizovať a odstrániť pomocou rozhrania REST API profilov.

Ak chcete napríklad vytvoriť profil:

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"}

Objekt služby môže tiež zavolať rozhranie GET Profiles REST API , aby ste získali zoznam jeho profilov. Napríklad:

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

Povolenia profilu

Každé rozhranie API, ktoré udelí používateľovi povolenie na prístup k položkám Power BI, môže tiež udeliť povolenie profilu k položkám služby Power BI. Rozhranie API pridať používateľa skupiny možno napríklad použiť na udelenie povolenia profilu pracovnému priestoru.

Nasledujúce body sú dôležité na pochopenie pri používaní profilov:

  • Profil patrí objektu služby, ktorý ho vytvoril, a môže ho používať iba daný objekt služby.
  • Vlastníka profilu po vytvorení nie je možné zmeniť.
  • Profil nie je samostatná identita. Na volanie rozhraní REST API služby Power BI potrebuje token objektu služby Microsoft Entra .

Aplikácie nezávislých dodávateľov softvéru volajú rozhranie Power BI REST API tým, že zadajte token objektu služby Microsoft Entra do hlavičky Authorization a ID profilu v hlavičke X-PowerBI-Profile-Id . Napríklad:

  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

Vytvorenie pracovného priestoru

Pracovné priestory služby Power BI sa používajú na hosťovanie položiek služby Power BI, ako sú napríklad zostavy a sémantické modely.

Každý profil musí:

  • Vytvorenie aspoň jedného pracovného priestoru služby Power BI

    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"
    }
    
  • Udelí prístupové povolenia k pracovnému priestoru. Profil objektu služby musí mať prístup správcu k pracovnému priestoru.

  • Priradenie pracovného priestoru ku kapacite

    POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/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"
    }
    

Prečítajte si viac o pracovných priestoroch Power BI.

Import zostáv a sémantických modelov

Používajte aplikáciu Power BI Desktop na prípravu zostáv, ktoré sú pripojené k údajom zákazníka alebo vzorovým údajom. Potom môžete použiť rozhranie API importu na importovanie obsahu do vytvoreného pracovného priestoru.

POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/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=

Použite parametre množiny údajov na vytvorenie sémantického modelu, ktorý sa môže pripojiť k zdrojom údajov rôznych zákazníkov. Potom pomocou rozhrania API parametrov aktualizácie zadefinujte údaje zákazníkov, ku ktorým sa sémantický model pripája.

Nastavenie pripojenia sémantického modelu

Nezávislých dodávateľov softvéru zvyčajne ukladajú údaje svojich zákazníkov jedným z dvoch spôsobov:

V oboch prípadoch by ste mali skončiť so sémantickými modelmi s jedným nájomníkom (jeden sémantický model na zákazníka) v službe Power BI.

Samostatná databáza pre každého zákazníka

Ak má aplikácia nezávislých dodávateľov softvéru samostatnú databázu pre každého zákazníka, vytvorte sémantické modely s jedným nájomníkom v službe Power BI. Zadajte pre každý sémantický model podrobnosti pripojenia, ktoré smerujú na jeho zodpovedajúcu databázu. Ak sa chcete vyhnúť vytváraniu viacerých identických zostáv s rozličnými podrobnosťami o pripojení, použite jednu z nasledujúcich metód:

  • Sémantické parametre modelu: Vytvorte sémantický model s parametrami v podrobnostiach o pripojení (napríklad názov SQL servera, názov databázy SQL). Potom importujte zostavu do pracovného priestoru zákazníka a zmeňte parametre tak, aby zodpovedali podrobnostim databázy zákazníka.

  • Aktualizácia rozhrania API zdroja údajov: Vytvorte súbor .pbix, ktorý odkazuje na zdroj údajov so vzorovým obsahom. Potom importujte súbor .pbix do pracovného priestoru zákazníka a zmeňte podrobnosti pripojenia pomocou rozhrania API na aktualizáciu zdroja údajov.

Jedna viacúčelová databáza

Ak aplikácia nezávislých dodávateľov softvéru používa jednu databázu pre všetkých svojich zákazníkov, oddeľte zákazníkov do rôznych sémantických modelov v službe Power BI takto:

Vytvorte zostavu pomocou parametrov , ktoré načítajú iba údaje o relevantnom zákazníkovi. Potom importujte zostavu do pracovného priestoru zákazníka a zmeňte parametre tak, aby sa načítali iba údaje príslušného zákazníka.

Vloženie zostavy

Po dokončení nastavenia môžete do svojej aplikácie vkladať zostavy zákazníkov a ďalšie položky pomocou tokenu na vloženie.

Keď zákazník prejde do vašej aplikácie, pomocou príslušného profilu zavolajte rozhranie GenerateToken API. Pomocou vygenerovaného tokenu na vloženie zostavy alebo iných položiek do prehliadača zákazníka.

Generovanie vkladacieho tokenu:

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"
    }
  ]
}

Aspekty návrhu

Pred nastavením multitenantného riešenia založeného na profile by ste mali poznať nasledujúce problémy:

Škálovateľnosť

Rozdelením údajov do samostatných sémantických modelov pre každého zákazníka minimalizujete potrebu veľkých sémantických modelov. Pri preťažení môže kapacita vyradiť nepoužívané sémantické modely, čím sa uvoľní pamäť pre aktívne sémantické modely. Pre jeden veľký sémantický model je táto optimalizácia nemožná. Pomocou viacerých sémantických modelov môžete v prípade potreby rozdeliť nájomníkov do viacerých kapacít služby Power BI.

Bez profilov je objekt služby obmedzený na 1 000 pracovných priestorov. Na prekonanie tohto limitu môže objekt služby vytvoriť viacero profilov, v ktorých môže každý profil získať prístup alebo vytvoriť až 1 000 pracovných priestorov. S viacerými profilmi môže aplikácia ISV izolovať obsah každého zákazníka pomocou jedinečných logických kontajnerov.

Keď má profil objektu služby prístup k pracovnému priestoru, prístup objektu jeho nadradenej služby k pracovnému priestoru možno odstrániť, aby sa predišlo problémom so škálovateľnosťou.

Aj s týmito výhodami by ste mali zvážiť potenciálnu škálu svojej aplikácie. Počet položiek pracovného priestoru, ku ktorému má profil prístup, je napríklad obmedzený. V súčasnosti má profil rovnaké obmedzenia ako bežný používateľ. Ak aplikácia nezávislého dodávateľa softvéru umožňuje koncovým používateľom uložiť prispôsobenú kópiu svojich vložených zostáv, profil zákazníka bude mať prístup ku všetkým vytvoreným zostavám všetkých jej používateľov. Tento model môže nakoniec limit prekročiť.

Automatizácia a zložitosť prevádzky

V prípade odchodov na základe profilu v službe Power BI možno budete musieť spravovať stovky či tisíce položiek. Preto je dôležité definovať procesy, ktoré sa často vyskytujú v rámci spravovania životného cyklu vašej aplikácie, a zabezpečiť, aby ste mali správnu množinu nástrojov na vykonanie týchto operácií vo väčšom meradle. Niektoré z týchto operácií zahŕňajú:

  • Pridanie nového nájomníka
  • Aktualizácia zostavy pre niektorých alebo všetkých nájomníkov
  • Aktualizácia sémantického modelu schémy pre niektorých alebo všetkých nájomníkov
  • Neplánované prispôsobenia pre konkrétnych nájomníkov
  • Frekvencia obnovení sémantických modelov

Napríklad vytvorenie profilu a pracovného priestoru pre nového nájomníka je bežnou úlohou, ktorú možno pomocou rozhrania REST API služby Power BI plne automatizovať.

Potreby funkcie Multi-Geo

Podpora funkcie Multi-Geo pre službu Power BI Embedded znamená, že dodávatelia softvéru a organizácie, ktoré vytvárajú aplikácie pomocou služby Power BI Embedded s cieľom vloženia analýz do svojich aplikácií, teraz môžu využívať svoje údaje v rozličných oblastiach sveta. Ak chcete podporovať rôznych zákazníkov v rôznych oblastiach, priraďte pracovný priestor zákazníka ku kapacite v požadovanej oblasti. Táto úloha predstavuje jednoduchú operáciu, ktorá nezahŕňa dodatočné náklady. Ak však máte zákazníkov, ktorí potrebujú údaje z viacerých oblastí, profil nájomníka by mal duplikovať všetky položky do viacerých pracovných priestorov, ktoré sú priradené k rôznym regionálnym kapacitám. Táto duplicita môže zvýšiť náklady aj zložitosť spravovania.

Z dôvodov dodržiavania súladu môžete stále chcieť vytvoriť viacero nájomníkov služby Power BI v rôznych oblastiach. Prečítajte si viac o funkcii Multi-Geo.

Nákladová efektivita

Vývojári aplikácií používajúci službu Power BI Embedded si musia zakúpiť kapacitu služby Power BI Embedded. Model odchodu založený na profile funguje dobre s kapacitami, pretože:

  • Najmenším objektom, ktorý môžete nezávisle priradiť ku kapacite, je pracovný priestor (nemôžete napríklad priradiť zostavu). Rozdelením zákazníkov podľa profilov získate rôzne pracovné priestory – jeden na zákazníka. Týmto spôsobom získate úplnú flexibilitu pri spravovaní každého zákazníka podľa jeho potrieb výkonu a optimalizácii využitia kapacity škálovaním nahor alebo nadol. Môžete napríklad spravovať veľkých a kľúčových zákazníkov s veľkým objemom a vysokou mierou premenlivosti v samostatnej kapacite, čím zabezpečíte konzistentnú úroveň služby a zároveň zoskupiť menších zákazníkov v inej kapacite, čím optimalizujete náklady.

  • Rozdelenie pracovných priestorov tiež znamená oddelenie sémantických modelov medzi nájomníkmi tak, aby dátové modely boli v menších blokoch, a nie v jednom veľkom sémantickom modeli. Tieto menšie modely umožňujú kapacite efektívnejšie spravovať využívanie pamäte. Malé nepoužívané sémantické modely sa môžu po období nečinnosti vyradiť, aby sa zachoval dobrý výkon.

Pri nákupe kapacity zvážte obmedzenie počtu paralelných obnovení, keďže procesy obnovenia môžu pri viacerých sémantických modeloch vyžadovať dodatočnú kapacitu.

Zabezpečenie na úrovni riadkov

Tento článok vysvetľuje, ako používať profily na vytvorenie samostatného sémantického modelu pre každého zákazníka. Alternatívne môžu aplikácie nezávislých dodávateľov softvéru ukladať údaje všetkých zákazníkov v jednom veľkom sémantickom modeli a pomocou zabezpečenia na úrovni riadkov chrániť údaje každého zákazníka. Tento prístup môže byť pohodlný pre nezávislých dodávateľov softvéru, ktorí majú relatívne málo zákazníkov a malé až stredne veľké sémantické modely, pretože:

  • Na údržbu je k dispozícii len jedna zostava a jeden sémantický model
  • Proces vkladania nových zákazníkov možno zjednodušiť

Pred použitím zabezpečenia na úrovni riadkov sa však uistite, že rozumiete jeho obmedzeniam. Všetky údaje o všetkých zákazníkoch sa nachádzajú v jednom veľkom sémantickom modeli služby Power BI. Tento sémantický model sa spustí v jednej kapacite s jeho vlastnou škálovaním a ďalšími obmedzeniami.

Aj keď používate profily objektu služby na oddelenie údajov zákazníkov, stále môžete použiť zabezpečenie na úrovni riadkov v rámci sémantického modelu jedného zákazníka a poskytnúť rôznym skupinám prístup k rôznym častiám údajov. Zabezpečenie na úrovni riadkov môžete použiť napríklad na to, aby ste zabránili členom jedného oddelenia v prístupe k údajom iného oddelenia v tej istej organizácii.

Dôležité informácie a obmedzenia

  • Profily objektu služby sa podporujú iba prostredníctvom rozhrania REST API služby Power BI, súpravy .NET SDK služby Power BI a koncového bodu XMLA a tabuľkového objektového modelu (TOM) pri používaní klientskych knižníc služby Analysis Services verzie 16.0.139.27 alebo novšej. Profily objektu služby nie sú podporované v službe Power BI prostredníctvom koncového bodu XMLA ani tabuľkového objektového modelu (TOM) so staršími klientskymi knižnicami.
  • Profily objektu služby nie sú podporované v režime dynamického pripojenia v službe Azure Analysis Services (AAS).
  • Maximálny počet profilov, ktoré môže mať jeden objekt služby, je 100 000.

Obmedzenia kapacity služby Power BI

  • Každá kapacita môže používať iba pre každú vyhradenú pamäť a virtuálne jadrá podľa zakúpenej jednotky SKU. Odporúčanú veľkosť sémantického modelu pre každú skladovou jednotku SKU získate v odkaze na veľké sémantické modely kapacity Premium.
  • Ak chcete použiť sémantický model väčší ako 10 GB, použite kapacitu Premium a povoľte nastavenie Veľké sémantické modely .
  • Ak chcete zistiť počet súbežných obnovení v rámci kapacity, odkazujte na správu a optimalizáciu prostriedkov.

Spravovanie objektov služby

Zmena objektu služby

Profil v Power BI patrí objektu služby, ktorý ho vytvoril. To znamená, že profil nie je možné zdieľať s inými objektmi. Pri tomto obmedzení, ak chcete zmeniť objekt služby z akéhokoľvek dôvodu, budete musieť znova vytvoriť všetky profily a poskytnúť nové profily prístup k relevantným pracovným priestorom. Aplikácia nezávislého dodávateľa softvéru často musí uložiť priradenie medzi ID profilu a ID zákazníka, aby si v prípade potreby vybrala ten správny profil. Ak zmeníte objekt služby a znova vytvoríte profily, zmenia sa aj ID a možno bude potrebné aktualizovať priradenie v databáze aplikácie ISV.

Odstránenie objektu služby

Upozornenie

Pri odstraňovaní objektu služby buďte veľmi opatrní. Nechcete náhodou prísť o údaje zo všetkých súvisiacich profilov.

Ak odstránite objekt služby v službe Active Directory, všetky jeho profily v službe Power BI sa odstránia. Služba Power BI však obsah neodstráni okamžite, takže správca nájomníka môže naďalej pristupovať k pracovným priestorom. Pri odstraňovaní objektu služby, ktorý sa používa v produkčnom systéme, dávajte pozor, najmä ak ste vytvorili profily pomocou tohto objektu služby v službe Power BI. Ak odstránite objekt služby, ktorý vytvoril profily, uvedomte si, že budete musieť znova vytvoriť všetky profily, poskytnúť prístup nových profilov k relevantným pracovným priestorom a aktualizovať ID profilu v databáze aplikácie ISV.

Rozdelenie údajov

Keď sú údaje oddelené profilmi objektov služby, jednoduché mapovanie medzi profilom a zákazníkom zabráni jednému zákazníkovi zobraziť obsah iného zákazníka. Používanie jedného objektu služby vyžaduje, aby mal objekt služby prístup ku všetkým pracovným priestorom vo všetkých profiloch.

Ak chcete pridať dodatočné oddelenie, priraďte každému nájomníkovi samostatný objekt služby namiesto toho, aby ste k viacerým pracovným priestorom mali prístup pomocou rôznych profilov. Priradenie samostatných objektov služby má niekoľko výhod, medzi ktoré patrí:

  • Ľudská chyba alebo únik prihlasovacích údajov nespôsobí zobrazenie údajov viacerých nájomníkov.
  • Rotácia certifikátov sa môže vykonať samostatne pre každého nájomníka.

Použitie viacerých objektov služby je však spojené s vysokými nákladmi na spravovanie. Túto cestu vyberte iba v prípade, že potrebujete dodatočné oddelenie. Majte na pamäti, že konfigurácia údajov, ktoré sa majú zobraziť koncovému používateľovi, je definovaná pri generovaní vkladacieho tokenu, čo je proces iba na koncovom servere, ktorý koncoví používatelia nemôžu zobraziť ani zmeniť. Žiadosťou o token na vloženie pomocou profilu špecifického pre nájomníka sa vygeneruje vkladací token pre tento konkrétny profil, ktorý vám poskytne oddelenie spotreby zákazníkmi.

Jedna zostava, viaceré sémantické modely

Vo všeobecnosti máte jednu zostavu a jeden sémantický model na nájomníka. Ak máte stovky zostáv, budete mať stovky sémantických modelov. Niekedy môžete mať jeden formát zostavy s rôznymi sémantickými modelmi (napríklad rôznymi parametrami alebo podrobnosťami o pripojení). Vždy, keď budete mať novú verziu zostavy, musíte aktualizovať všetky zostavy pre všetkých nájomníkov. Ak máte len jednu kópiu zostavy, správu môžete automatizovať, ale ak máte len jednu kópiu. Vytvorte pracovný priestor obsahujúci zostavu, ktorá sa má vložiť. Počas režimu runtime relácie naviažte zostavu na sémantický model špecifický pre nájomníka. Ďalšie podrobnosti nájdete v článku o dynamických väzbách .

Prispôsobenie a vytváranie obsahu

Pri vytváraní obsahu starostlivo zvážte, kto má povolenie na jeho úpravu. Ak v každom nájomníkovi povolíte úpravy viacerým používateľom, je jednoduché prekročiť obmedzenia sémantických modelov. Ak sa rozhodnete poskytnúť používateľom možnosti úprav, pozorne monitorujte generovanie obsahu a podľa potreby ich zväčšujte. Z rovnakého dôvodu túto možnosť neodporúčame používať na prispôsobenie obsahu, v rámci čoho môže používateľ v zostave vykonať malé zmeny a uložiť si ju pre seba. Ak aplikácia nezávislého dodávateľa softvéru umožňuje prispôsobenie obsahu, zvážte zavedenie politík uchovávania pracovného priestoru pre obsah konkrétneho používateľa. Politiky uchovávania údajov uľahčujú odstránenie obsahu, keď sa používatelia presunú na nové miesto, opustia spoločnosť alebo prestanú používať platformu.

Systémová spravovaná identita

Namiesto objektu služby môžete použiť na vytvorenie profilov identitu priradenú používateľovi alebo systému spravovanúidentitu . Spravované identity znižujú potrebu tajného kódu a certifikátov.

Pri používaní systémovo spravovanej identity buďte opatrní, pretože:

  • Ak je spravovaná identita priradená systémom omylom vypnutá, stratíte prístup k profilom. Táto situácia je podobná situácii, keď sa objekt služby odstráni.
  • Spravovaná identita priradená systémom je pripojená k prostriedku v Azure (webová aplikácia). Ak prostriedok odstránite, identita sa odstráni.
  • Použitie viacerých zdrojov (rôznych webových aplikácií v rôznych oblastiach) bude mať za následok viacero identít, ktoré je potrebné spravovať samostatne (každá identita bude mať svoje vlastné profily).

Z dôvodu vyššie uvedených dôležitých informácií odporúčame použiť spravovanú identitu priradenú používateľom.

Príklad

Príklad použitia profilov objektov služby na správu viacúčelového prostredia pomocou služby Power BI a vkladania údajov app-Owns-Data, stiahnutie odkladacieho priestoru Aplikácia vlastní viacúčelové údaje z lokality Power BI Dev Camp (lokalita tretej strany).