Skaalattavien monivuokraussovellusten kehittäminen Power BI:n upotuksen avulla

Tässä artikkelissa kuvataan, miten voit kehittää monivuokraajasovelluksen, joka upottaa Power BI -sisältöä ja saavuttaa parhaan skaalattavuuden, suorituskyvyn ja suojauksen tason. Suunnittelemalla ja ottamalla käyttöön sovelluksen palvelun päänimiprofiilien avulla voit luoda ja hallita usean kohteen ratkaisua, joka koostuu kymmenistä tuhansista asiakasvuokraajista, jotka voivat toimittaa raportteja yli 100 000 käyttäjälle.

Palvelun pääprofiilit ovat ominaisuus, jonka ansiosta sinun on helpompi hallita organisaation sisältöä Power BI:ssä ja käyttää kapasiteettejasi tehokkaammin. Palvelun pääprofiilien käyttäminen voi kuitenkin lisätä sovellusrakennetta monimutkaisuutta. Siksi niitä kannattaa käyttää vain silloin, kun mittakaavaa on tarpeen saavuttaa merkittävästi. Suosittelemme palvelun päänimen profiilien käyttämistä, kun sinulla on useita työtiloja ja yli 1 000 sovelluskäyttäjää.

Muistiinpano

Palvelun pääprofiilien käytön arvo kasvaa, kun tarve skaalata kasvaa sekä tarve saavuttaa korkein suojaustaso ja vuokraajan eristystaso.

Voit toteuttaa Power BI -upottamisen käyttämällä kahta eri upotusskenaariota: Upottaminen organisaatiolle ja Upottaminen asiakkaalle.

Upottaminen organisaatiollesi -skenaariota sovelletaan, kun sovelluksen kohderyhmä koostuu sisäisistä käyttäjistä. Sisäisillä käyttäjillä on organisaation tilit, ja heidän täytyy todentautua Microsoft Entra -tunnuksella (aiemmin azure Active Directory). Tässä skenaariossa Power BI on ohjelmisto palveluna (SaaS). Sitä kutsutaan joskus nimellä Käyttäjä omistaa tiedot.

Asiakkaan upotus -skenaariota sovelletaan, kun sovelluksen kohderyhmä koostuu ulkoisista käyttäjistä. Sovellus vastaa käyttäjien todentamisesta. Power BI -sisällön käyttämiseksi sovellus käyttää upotustietoja (Microsoft Entra -palvelun pääkäyttäjän tai pääkäyttäjätilin) Microsoft Entra -todennusta. Tässä skenaariossa Power BI on käyttöympäristö palveluna (PaaS) -palvelu. Sitä kutsutaan joskus nimellä Sovellus omistaa tiedot.

Muistiinpano

On tärkeää ymmärtää, että palvelun päänimiprofiilien ominaisuus on suunniteltu käytettäväksi asiakasskenaariossa upotuksen kanssa. Tämä johtuu siitä, että tämä skenaario tarjoaa isv-ohjelmistotoimittajille ja yritysorganisaatioille entistä paremman skaalauksen suurelle määrälle käyttäjiä ja suurelle määrälle asiakasvuokraajia.

Monivuokraajasovellusten kehittäminen

Jos olet jo tutustunut Microsoft Entraan, saatat ajatellakin Microsoft Entra -vuokraajaa sanalla vuokraaja . Vuokraajan käsite on kuitenkin erilainen, kun luodaan monivuokraajaratkaisu, joka upottaa Power BI -sisältöä. Tässä yhteydessä asiakasvuokraaja luodaan jokaisen asiakkaan puolesta, jolle sovellus upottaa Power BI -sisältöä käyttämällä asiakkaan skenaarion Upottaminen avulla. Yleensä kukin asiakasvuokraaja valmistellaan luomalla yksittäinen Power BI -työtila.

Jotta voit luoda skaalattavan monivuokraajaratkaisun, sinun on voitava automatisoida uusien asiakasvuokraajien luominen. Uuden asiakasvuokraajan valmistelu edellyttää yleensä koodin kirjoittamista, joka käyttää Power BI REST -ohjelmointirajapintaa uuden Power BI -työtilan luomiseen, semanttisten mallien (aiemmin tietojoukkoihin) luomiseen tuomalla Power BI Desktop (.pbix) -tiedostoja, päivittämällä tietolähdeparametreja, määrittämällä tietolähteen tunnistetietoja ja määrittämällä ajoitetun semanttisen mallin päivityksen. Seuraavassa kaaviossa näytetään, miten voit lisätä Power BI -kohteita, kuten raportteja ja semanttisia malleja, työtiloihin asiakasvuokraajien määrittämiseksi.

Kun kehität sovellusta, joka käyttää Asiakkaan upotus -skenaariota, voit tehdä Power BI REST -ohjelmointirajapinnan kutsuja käyttämällä upotustietoja, jotka ovat joko pääkäyttäjätili tai palvelun päänimi. Suosittelemme palvelun päänimen käyttämistä tuotantosovelluksissa. Se tarjoaa korkeimman suojauksen, ja tästä syystä se on Microsoft Entran suosittelema lähestymistapa. Lisäksi se tukee parempaa automaatiota ja skaalausta ja hallintakustannuksia on vähemmän. Sen määrittäminen ja hallinta edellyttää kuitenkin Power BI -järjestelmänvalvojan oikeuksia.

Palvelun päänimellä voit välttää yleisiä ongelmia, jotka liittyvät pääkäyttäjätileihin, kuten todennusvirheitä ympäristöissä, joissa käyttäjien on kirjauduttava sisään monimenetelmäisen todentamisen (MFA) avulla. Palvelun päänimen käyttäminen on yhdenmukaista myös sen ajatuksen kanssa, että Upottaminen asiakkaillesi perustuu Power BI -sisällön upottamiseen käyttämällä PaaS-ajattelutapaa SaaS-ajattelutapaan verrattuna.

1 000 työtilan rajoitus

Kun suunnittelet monivuokrausympäristöä, joka toteuttaa Upottaminen asiakkaillesi -skenaarion, muista ottaa huomioon, että upotusidentiteeteille ei voida myöntää käyttöoikeutta yli 1 000 työtilaan. Power BI -palvelu asettaa tämän rajoituksen hyvän suorituskyvyn varmistamiseksi REST-ohjelmointirajapinnan kutsuja tehtäessä. Tämä rajoitus johtuu siitä, miten Power BI ylläpitää tietoturvaan liittyviä metatietoja kunkin käyttäjätiedon kohdalla.

Power BI käyttää metatietoja seuraamaan työtiloja ja työtilan kohteita, joita käyttäjätiedot voivat käyttää. Itse asiassa Power BI:n on ylläpidettävä erillisenä käyttöoikeuksien hallintaluetteloa (ACL) kullekin käyttäjätietolle valtuutusosajärjestelmässään. Kun käyttäjätiedot tekevät REST-ohjelmointirajapinnan kutsun työtilan käyttämistä varten, Power BI:n on tehtävä tietoturvatarkistus käyttäjätietojen ACL:ään sen varmistamiseksi, että se on sallittu. Aika, joka kuluu sen määrittämiseen, onko kohdetyötila ACL:n sisällä, kasvaa eksponentiaalisesti työtilojen määrän kasvaessa.

Muistiinpano

Power BI ei pakota 1 000 työtilan rajoitusta koodilla. Jos yrität, lisäät upottavan käyttäjätiedon yli 1 000 työtilaan, ja REST-ohjelmointirajapinnan kutsut suoritetaan edelleen onnistuneesti. Sovelluksesi kuitenkin siirtyy tilaan, jossa sitä ei tueta , ja tällä voi olla vaikutuksia, jos yrität pyytää apua Microsoft-tuelta.

Ajattele tilannetta, jossa kaksi usean vuokraajan sovellusta on määritetty käyttämään yhtä palvelun päänimeä. Oletetaan, että ensimmäinen sovellus on luonut 990 työtilaa ja toinen sovellus 1 010 työtilaa. Tuen näkökulmasta ensimmäinen sovellus on tuettujen rajojen sisällä, kun taas toinen sovellus ei ole.

Vertaa nyt näitä kahta sovellusta pelkästään suorituskyvyn näkökulmasta. Eroa ei ole kovinkaan, koska molempien palvelun päänimien käyttöoikeusluetteloiden metatiedot ovat antaneet käyttöoikeusluetteloiden metatietojen kasvaa siten, että se heikentää suorituskykyä jossakin määrin.

Tässä on tärkein huomio: palvelun päänimen luomien työtilojen määrä vaikuttaa suoraan suorituskykyyn ja skaalattavuuteen. Palvelun päänimi, joka on 100 työtilan jäsen, suorittaa REST-ohjelmointirajapinnan kutsut nopeammin kuin palvelun päänimi, joka on 1 000 työtilan jäsen. Palvelun päänimi, joka on vain 10 työtilan jäsen, suorittaa REST-ohjelmointirajapinnan kutsut nopeammin kuin palvelun päänimi, joka on 100 työtilan jäsen.

Tärkeä

Suorituskyvyn ja skaalattavuuden näkökulmasta optimaalinen määrä työtiloja, joiden palvelun päänimi on tarkalleen yksi.

Semanttisten mallien ja tietolähteen tunnistetietojen eristyksen hallinta

Toinen tärkeä näkökohta monivuokraajasovellusta suunnitettaessa on asiakkaiden vuokraajien eristäminen. On tärkeää, että yhden asiakkaan vuokraajan käyttäjät eivät näe tietoja, jotka kuuluvat toiselle asiakkaan vuokraajalle. Siksi sinun on ymmärrettävä, miten voit hallita semanttisen mallin omistajuutta ja tietolähteen tunnistetietoja.

Semanttisen mallin omistajuus

Jokaisella Power BI:n semanttisella mallilla on yksi omistaja, joka voi olla joko käyttäjätili tai palvelun päänimi. Semanttisen mallin omistajuus vaaditaan ajoitetun päivityksen määrittämiseen ja semanttisen mallin parametrien määrittämiseen.

Vihje

Power BI -palvelu voit määrittää semanttisen mallin omistajan avaamalla semanttisen mallin asetukset.

Voit tarvittaessa siirtää semanttisen mallin omistajuuden toiselle käyttäjätilille tai palvelun päänimelle. Voit tehdä sen Power BI -palvelu tai käyttämällä REST-ohjelmointirajapinnan TakeOver toimintoa. Kun tuot Power BI Desktop -tiedoston ja luot uuden semanttisen mallin palvelun päänimellä, palvelun päänimeksi määritetään automaattisesti semanttinen mallin omistaja.

Tietolähteen tunnistetiedot

Semanttisen mallin yhdistäminen sen pohjana olevaan tietolähteeseen edellyttää, että semanttisen mallin omistajan on määritettävä tietolähteen tunnistetiedot. Power BI salaa ja tallentaa välimuistiin tietolähteen tunnistetiedot. Siitä alkaen Power BI käyttää näitä tunnistetietoja todentamiseen pohjana olevan tietolähteen kanssa päivitettäessä tietoja (tuontitallennustaulukoita varten) tai suoritettaessa läpivientikyselyitä (DirectQuery-tallennustaulukoille).

Suosittelemme, että otat käyttöön yleisen suunnittelumallin, kun valmistelet uutta asiakasvuokraajaa. Voit suorittaa joukon REST-ohjelmointirajapinnan kutsuja käyttämällä palvelun päänimen käyttäjätietoja:

1. Luo uusi työtila.
2. Liitä uusi työtila varattuun kapasiteettiin.
3. Luo semanttinen malli tuomalla Power BI Desktop -tiedosto.
4. Määritä tämän semanttisen mallin lähteen tunnistetiedot.

Kun nämä REST-ohjelmointirajapinnan kutsut on suoritettu, palvelun päänimestä tulee uuden työtilan järjestelmänvalvoja sekä semanttisen mallin ja tietolähteen tunnistetietojen omistaja.

Tärkeä

On yleinen väärinkäsitys siitä, että semanttisen mallin tietolähteen tunnistetiedot ovat työtilatason laajuisia. Tuo ei ole totta. Tietolähteen tunnistetiedot on rajoitettu palvelun päänimeen (tai käyttäjätiliin), ja tämä laajuus ulottuu kaikkiin Microsoft Entra -vuokraajan Power BI -työtiloihin.

Palvelun päänimen on mahdollista luoda tietolähteen tunnistetiedot, jotka semanttiset mallit jakavat eri työtiloissa eri asiakasvuokraajissa, seuraavan kaavion mukaisesti.

Kun tietolähteen tunnistetiedot jaetaan eri asiakasvuokraajaan kuuluvien semanttisten mallien kanssa, asiakkaan vuokraajia ei eristetä täysin.

Palvelun pääprofiilien suunnittelustrategiat

Suunnittelustrategioiden ymmärtäminen ennen palvelun päänimen profiiliominaisuuden julkaisua voi auttaa arvostamaan ominaisuuden tarvetta. Sitä ennen kehittäjät rakensivat monivuokraussovelluksia käyttämällä yhtä seuraavista kolmesta suunnittelustrategiasta:

• Yksittäisen palvelun päänimi
• Palvelun päänimen yhdistäminen
• Yksi palvelun päänimi per työtila

Kuhunkin näistä suunnittelustrategioista liittyy vahvuuksia ja heikkouksia.

Yhden palvelun päänimen suunnittelustrategia edellyttää Microsoft Entra -sovelluksen rekisteröinnin kertaluontia. Tästä syystä siihen liittyy vähemmän järjestelmänvalvojan kuormitusta kuin kahdessa muussa suunnittelustrategiassa, koska Microsoft Entra -sovellusten rekisteröinteja ei vaadita enemmän. Tämä strategia on myös yksinkertaisin määrittää, koska se ei vaadi lisäkoodin kirjoittamista, joka vaihtaa kutsuvan kontekstin palvelun päänimien välillä, kun teet REST-ohjelmointirajapinnan kutsuja. Tämän suunnittelustrategian ongelmana on kuitenkin se, että sitä ei skaalata. Se tukee vain monivuokrausympäristöä, joka voi kasvaa jopa 1 000 työtilaan. Lisäksi suorituskyky heikkenee varmasti, koska palvelun päänimelle myönnetään käyttöoikeus suurempaan määrään työtiloja. Ongelmia voi ilmetä myös asiakkaan vuokraajan eristyksessä, sillä yksittäisestä palvelun päänimestä tulee jokaisen semanttisen mallin omistaja ja kaikkien asiakkaiden vuokraajien kaikki tietojen tunnistetiedot.

Palvelun päänimen ryhmittelyn suunnittelustrategiaa käytetään yleisesti 1 000 työtilan rajoituksen välttämiseksi. Sen avulla sovellus voi skaalata minkä tahansa työtilojen määrään lisäämällä oikean määrän palvelun päänimiä varantoon. Esimerkiksi viiden palvelun päänimen varannon avulla voidaan skaalata jopa 5 000 työtilaa. 80 palvelun päänimen varannon avulla voidaan skaalata enintään 80 000 työtilaa ja niin edelleen. Vaikka tämä strategia voidaan skaalata suureen määrään työtiloja, siitä on kuitenkin useita haittoja. Ensin se edellyttää ylimääräisen koodin kirjoittamista ja metatietojen tallentamista, jotta konteksti voidaan vaihtaa palvelun päänimien välillä REST-ohjelmointirajapinnan kutsuja tehtäessä. Toiseksi tämä lisää järjestelmänvalvojan toimia, koska sinun on luotava Microsoft Entra -sovellusten rekisteröinnit aina, kun sinun on lisättävä varannon palvelujen päänimien määrää.

Lisäksi palvelun päänimen ryhmittelystrategiaa ei ole optimoitu suorituskyvyn parantamiseksi, koska sen avulla palvelun päänimistä voi tulla satojen työtilojen jäseniä. Se ei myöskään ole ihanteellinen asiakkaan vuokraajan eristyksen kannalta, koska palvelun päänimistä voi tulla asiakkaiden vuokraajien kesken jaettujen semanttisen mallin ja tietojen tunnistetietojen omistajia.

Yksi palvelun päänimi työtilan suunnittelustrategiaa kohden sisältää palvelun päänimen luomisen kullekin asiakasvuokraajalle. Teoreettisesta näkökulmasta tämä strategia tarjoaa parhaan ratkaisun, koska se optimoi REST-ohjelmointirajapintakutsujen suorituskyvyn ja tarjoaa samalla todellisen eristyksen semanttisille malleille ja tietolähteen tunnistetiedoilla työtilatasolla. Teoriassa paras toiminta ei kuitenkaan aina toimi parhaiten käytännössä. Tämä johtuu siitä, että vaatimuksena on luoda palvelun päänimi kullekin asiakkaan vuokraajalle, mikä on haittaa monille organisaatioille. Tämä johtuu siitä, että joillakin organisaatioilla on viralliset hyväksyntäprosessit tai niihin liittyy liiallista byrokratiaa Microsoft Entra -sovellusten rekisteröintien luomiseksi. Näiden syiden vuoksi mukautettua sovellusta ei voi antaa sille viranomaiselle, jonka se tarvitsee Microsoft Entra -sovellusten rekisteröinnit pyydettäessä ja automatisoidulla tavalla, jota ratkaisusi edellyttää.

Harvinaisemmassa tilanteessa, jossa mukautetulle sovellukselle on myönnetty asianmukaiset käyttöoikeudet, se voi Microsoft Graph -ohjelmointirajapinnan avulla luoda Microsoft Entra -sovellusrekisteröinnit pyydettäessä. Mukautetun sovelluksen kehittäminen ja käyttöönotto on kuitenkin usein monimutkaista, koska sen täytyy jotenkin seurata todennuksen tunnistetietoja jokaista Microsoft Entra -sovelluksen rekisteröintiä varten. Sen on myös voitava käyttää kyseisiä tunnistetietoja aina, kun sen on todennettava ja hankittava käyttöoikeustietueita yksittäisille palvelun päänimille.

Palvelun pääprofiilit

Palvelun pääprofiilien ominaisuus on suunniteltu siten, että sinun on helpompi hallita organisaation sisältöä Power BI:ssä ja käyttää kapasiteettejasi tehokkaammin. Niiden avulla voidaan vastata kolmeen erityiseen haasteeseen, joihin liittyy vähäisin määrä kehittäjätoimia ja kuormituskustannuksia. Näitä haasteita ovat muun muassa seuraavat:

• Skaalaus suureen määrään työtiloja.
• REST-ohjelmointirajapinnan kutsujen suorituskyvyn optimointi.
• Semanttisten mallien ja tietolähteen tunnistetietojen eristäminen asiakkaan vuokraajatasolla.

Kun suunnittelet usean kohteen sovellusta palvelun päänimien profiileilla, voit hyötyä kolmen suunnittelustrategian vahvuuksista (kuvattu edellisessä osiossa) ja välttämällä niihin liittyvät heikkoudet.

Palvelun pääprofiilit ovat paikallisia tilejä, jotka luodaan Power BI:n kontekstissa. Palvelun päänimi voi käyttää Profiles REST-ohjelmointirajapintatoimintoa uusien palvelun päänimiprofiilien luomiseen. Palvelun päänimi voi luoda ja hallita omia palvelun päänimiprofiilejaan mukautettua sovellusta varten seuraavassa kaaviossa esitetyllä tavalla.

Palvelun päänimen ja sen luomien palvelun pääprofiilien välillä on aina pää-alikohdesuhde. Et voi luoda palvelun päänimiprofiilia erillisenä entiteettinä. Sen sijaan voit luoda palvelun pääprofiilin käyttämällä tiettyä palvelun päänimeä, ja palvelun päänimi toimii profiilin pääkohteena. Lisäksi palvelun pääprofiili ei koskaan näy käyttäjätileille tai muille palvelun päänimille. Palvelun pääprofiilin voi nähdä ja käyttää vain sen luonut palvelun päänimi.

Microsoft Entra ei tunne palvelun pääprofiilia

Vaikka palvelun päänimi ja sen pohjana oleva Microsoft Entra -sovellusrekisteröinti ovat Microsoft Entran tuntemia, Microsoft Entra ID ei tiedä mitään palvelun päänimiprofiileista. Tämä johtuu siitä, että Power BI luo palvelun pääprofiilit ja ne ovat olemassa vain Power BI -palvelu-alijärjestelmässä, joka hallitsee Power BI:n suojausta ja käyttöoikeuksien myöntämistä.

Sillä, että palvelun pääprofiilit eivät ole Microsoft Entra ID:n tuntemia, on sekä etuja että haittoja. Ensisijaisena etuna on, että Upottaminen asiakasskenaariota varten -sovellus ei tarvitse erityisiä Microsoft Entra -käyttöoikeuksia palvelun pääprofiilien luomiseen. Tämä tarkoittaa myös sitä, että sovellus voi luoda ja hallita Microsoft Entrasta erillisiä paikallisia käyttäjätietoja.

Tästä voi kuitenkin olla myös haittaa. Koska Microsoft Entra ei tunne palvelun pääprofiilia, et voi lisätä palvelun pääprofiilia Microsoft Entra -ryhmään, jotta se saa implisiittisesti käyttöoikeuden työtilaan. Lisäksi ulkoiset tietolähteet, kuten Azure-SQL-tietokanta tai Azure Synapse Analytics, eivät pysty tunnistamaan palvelun pääprofiilia käyttäjätietoina muodostaessaan yhteyttä tietokantaan. Yksi palvelun päänimi työtilan suunnittelustrategiaa kohti (palvelun päänimen luominen kullekin asiakasvuokraajalle) voi siis olla parempi vaihtoehto, kun näihin tietolähteisiin on tarpeen muodostaa yhteys käyttämällä erillistä palvelun päänimeä, jolla on yksilöivät todentamisen tunnistetiedot jokaista asiakasvuokraajaa varten.

Palvelun pääprofiilit ovat ensiluokkaisia suojauksen päänimiä.

Vaikka Microsoft Entra ei tunne palvelun pääprofiilia, Power BI tunnistaa ne ensiluokkaisiksi suojausobjektiksi. Käyttäjätilin tai palvelun päänimen tavoin voit lisätä palvelun pääprofiilit työtilan rooliin (Hallinta tai jäsenenä). Voit myös tehdä siitä semanttisen mallin omistajan ja tietolähteen tunnistetietojen omistajan. Näistä syistä kannattaa luoda uusi palvelun päänimiprofiili kullekin uudelle asiakasvuokraajalle.

Vihje

Kun kehität Upottaminen asiakasskenaariota varten -sovellusta palvelun pääprofiilien avulla, sinun tarvitsee luoda vain yksi Microsoft Entra -sovelluksen rekisteröinti, jotta voit antaa sovelluksellesi yhden palvelun päänimen. Tämä lähestymistapa vähentää huomattavasti järjestelmänvalvojan kuormituskustannuksia verrattuna muihin monivuokraajasuunnittelustrategioihin, joissa on tarpeen luoda lisää Microsoft Entra -sovellusrekisteröinteja jatkuvasti sen jälkeen, kun sovellus on otettu käyttöön tuotannossa.

Suorita REST-ohjelmointirajapinnan kutsut palvelun pääprofiilina

Sovellus voi suorittaa REST-ohjelmointirajapinnan kutsuja käyttämällä palvelun pääprofiilin käyttäjätietoja. Tämä tarkoittaa sitä, että se voi suorittaa sarjan REST-ohjelmointirajapinnan kutsuja uuden asiakasvuokraajan valmistelemista ja määrittämistä varten.

1. Kun palvelun pääprofiili luo uuden työtilan, Power BI lisää profiilin automaattisesti työtilan järjestelmänvalvojaksi.
2. Kun palvelun pääprofiili tuo Power BI Desktop -tiedoston semanttisen mallin luomista vastaan, Power BI määrittää kyseisen profiilin semanttisen mallin omistajaksi.
3. Kun palvelun pääprofiili määrittää tietolähteen tunnistetiedot, Power BI määrittää kyseisen profiilin tietolähteen tunnistetietojen omistajaksi.

On tärkeää ymmärtää, että palvelun päänimellä on Power BI:ssä käyttäjätiedot, jotka ovat erillisiä ja erillisiä kuin niiden profiilien käyttäjätiedot. Sen avulla voit valita kehittäjänä. Voit suorittaa REST-ohjelmointirajapinnan kutsuja käyttämällä palvelun pääprofiilin käyttäjätietoja. Vaihtoehtoisesti voit suorittaa REST-ohjelmointirajapinnan kutsuja ilman profiilia, joka käyttää pääpalvelun päänimen käyttäjätietoja.

Suosittelemme, että suoritat REST-ohjelmointirajapinnan kutsut pääpalvelun päänimeksi, kun luot, tarkastelet tai poistat palvelun pääprofiilia. Käytä palvelun pääprofiilia kaikkien muiden REST-ohjelmointirajapintakutsujen suorittamiseen. Muilla kutsuilla voidaan luoda työtiloja, tuoda Power BI Desktop -tiedostoja, päivittää semanttisen mallin parametreja ja määrittää tietolähteen tunnistetiedot. He voivat myös noutaa työtilakohteen metatiedot ja luoda upotustunnuksia.

Harkitse esimerkkiä, jossa sinun on määritettävä asiakasvuokraaja Contoso-nimiiselle asiakkaalle. Ensimmäisessä vaiheessa tehdään REST-ohjelmointirajapinnan kutsu, jolla luodaan palvelun pääprofiili, jonka näyttönimeksi on määritetty Contoso. Tämä kutsu tehdään palvelun päänimen käyttäjätiedoilla. Kaikki jäljellä olevat määritysvaiheet käyttävät palvelun pääprofiilia seuraavien tehtävien suorittamiseen:

1. Luo työtila.
2. Liitä työtila kapasiteettiin.
3. Tuo Power BI Desktop -tiedosto.
4. Määritä semanttisen mallin parametrit.
5. Määritä tietolähteen tunnistetiedot.
6. Määritä ajoitettu tietojen päivitys.

On tärkeää ymmärtää, että työtilan ja sen sisällön käyttö on tehtävä käyttämällä asiakkaan vuokraajan luomiseen käytetyn palvelun päänimiprofiilin käyttäjätietoja. On myös tärkeää ymmärtää, että pääpalvelun päänimi ei tarvitse käyttöoikeutta työtilaan tai sen sisältöön.

Vihje

Muista, että kun teet REST-ohjelmointirajapinnan kutsuja, luo ja hallitse palvelun pääprofiilia palvelun päänimen avulla ja luo, määritä ja käytä Power BI -sisältöä palvelun pääprofiilin avulla.

Profiilien REST-ohjelmointirajapinnan toimintojen käyttäminen

Profiilit REST-ohjelmointirajapinnan toimintoryhmä koostuu toiminnoista, joilla luodaan ja hallitaan palvelun päänimiprofiileja:

• Create Profile
• Delete Profile
• Get Profile
• Get Profiles
• Update Profile

Palvelun pääprofiilin luominen

Luo palvelun pääprofiili Luo profiili REST -ohjelmointirajapintatoiminnon avulla. Sinun on määritettävä displayName -ominaisuus pyynnön leipätekstissä, jotta uudelle vuokraajalle voidaan antaa näyttönimi. Arvon on oltava yksilöllinen kaikissa palvelun päänimen omistamille profiileille. Kutsu epäonnistuu, jos toinen profiili, jolla on tämä näyttönimi, on jo olemassa palvelun päänimelle.

Onnistunut kutsu palauttaa ominaisuuden id , joka on profiilia edustava GUID-tunnus. Kun kehität sovelluksia, jotka käyttävät palvelun päänimen profiileja, suosittelemme tallentamaan profiilien näyttönimet ja niiden tunnusarvot mukautettuun tietokantaan. Näin sovelluksesi voi helposti noutaa tunnukset.

Jos olet ohjelmoimassa Power BI .NET SDK:lla, voit käyttää -Profiles.CreateProfilemenetelmää, joka palauttaa uutta profiilia edustavan ServicePrincipalProfile objektin. Sen avulla on helppo määrittää ominaisuuden id arvo.

Tässä on esimerkki palvelun pääprofiilin luomisesta ja käyttöoikeuden myöntämisestä työtilalle.

// 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);

työtilan käyttöoikeusruudun Power BI -palvelu voit määrittää, mitkä käyttäjätiedot, mukaan lukien suojausobjektit, voivat käyttää sitä.

Palvelun pääprofiilin poistaminen

Poista palvelun pääprofiili käyttämällä Poista profiili REST -ohjelmointirajapintatoimintoa. Tätä toimintoa voi kutsua vain pääpalvelun päänimi.

Jos olet ohjelmoimassa Power BI .NET SDK:n avulla, voit käyttää - Profiles.DeleteProfile menetelmää.

Nouda kaikki palvelun päänimiprofiilit

Nouda palvelun pääprofiilien luettelo, joka kuuluu kutsuvan palvelun päänimen kohteeseen, käyttämällä Hae profiilit REST -ohjelmointirajapinta -toimintoa. Tämä toiminto palauttaa JSON-hyötykuorman, joka sisältää id kunkin palvelun pääprofiilin -ja displayName -ominaisuudet.

Jos olet ohjelmoimassa Power BI .NET SDK:lla, voit käyttää Profiles.GetProfiles-menetelmää .

REST-ohjelmointirajapinnan kutsujen suorittaminen palvelun pääprofiilin avulla

REST-ohjelmointirajapinnan kutsujen tekemiseen palvelun pääprofiilin avulla on kaksi vaatimusta:

• Sinun on välitettävä pääpalvelun päänimen käyttöoikeustietue Valtuutus-otsikossa.
• Sinun on sisällytettävä X-PowerBI-profile-id-niminen otsikko, joka sisältää palvelun päänimiprofiilin tunnuksen arvon.

Jos käytät Power BI .NET SDK:ta, voit määrittää X-PowerBI-profile-id-otsikon arvon eksplisiittisesti välittämällä palvelun päänimen profiilin tunnuksen.

// 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();

Kuten yllä olevasta esimerkistä näkyy, kun lisäät X-PowerBI-profile-id-otsikon PowerBIClient objektiin, on helppoa käynnistää menetelmiä, kuten Groups.GetGroups, jotta ne suoritetaan palvelun pääprofiilin avulla.

On olemassa kätevämpi tapa määrittää X-PowerBI-profile-id-otsikko objektille PowerBIClient . Voit valmistella objektin välittämällä profiilin tunnuksen konstruktorille.

// 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);

Kun ohjelmoit monivuokraussovellusta, sinun on todennäköisesti vaihdettava pääpalvelun päänimeksi kutsujen suorittamisen ja kutsujen suorittamisen välillä palvelun pääprofiilina. Hyödyllinen tapa hallita kontekstin vaihtamista on esitellä luokkatason muuttuja, joka tallentaa objektin PowerBIClient . Voit sitten luoda apumenetelmän, joka määrittää muuttujan oikean objektin avulla.

// 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));
    }
}

Kun haluat luoda tai hallita palvelun pääprofiilia, voit kutsua SetCallingContext -menetelmää ilman mitään parametreja. Näin voit luoda ja hallita profiileja käyttämällä palvelun päänimen käyttäjätietoja.

// 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);

Kun sinun on luotava ja määritettävä työtila uudelle asiakasvuokraajalle, haluat suorittaa koodin palvelun päänimiprofiilina. Siksi sinun tulee kutsua - SetCallingContext menetelmää välittämällä profiilin tunnus. Näin voit luoda työtilan käyttämällä palvelun päänimiprofiilin käyttäjätietoja.

// 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);

Kun olet käyttänyt tiettyä palvelun pääprofiilia työtilan luomiseen ja määrittämiseen, käytä samaa profiilia työtilan sisällön luomiseen ja määrittämiseen. Määritystä ei tarvitse käynnistää -menetelmää SetCallingContext käyttäen.

Kehittäjämalli

Suosittelemme lataamaan mallisovelluksen nimeltä AppOwnsDataMultiTenant.

Tämä mallisovellus on kehitetty käyttämällä .NET 6:a ja ASP.NET, ja se esittelee tässä artikkelissa kuvattujen ohjeiden ja suositusten soveltamista. Koodista saat tietoja siitä, miten voit kehittää monivuokraajasovelluksen, joka toteuttaa upotuksen asiakasskenaariota varten palvelun pääprofiilien avulla.

Liittyvä sisältö

Lisätietoja tästä artikkelista saat seuraavista resursseista:

• Palvelun pääprofiilit usean kohteen sovelluksille Power BI Embeddedissä
• Usean asiakkaan sovellusten siirtäminen palvelun päänimiprofiilien malliin
• Profiilit Power BI:n REST-ohjelmointirajapinnan toimintoryhmä
• • AppOwnsDataMultiTenant-mallisovellus
• Kysyttävää? Voit esittää kysymyksiä Power BI -yhteisö
• Ehdotuksia? Kerro ideasi Power BI:n parantamiseksi