Muistiinpano
Tämän sivun käyttö edellyttää valtuutusta. Voit yrittää kirjautua sisään tai vaihtaa hakemistoa.
Tämän sivun käyttö edellyttää valtuutusta. Voit yrittää vaihtaa hakemistoa.
Palvelun pääprofiilit ovat valinnainen ratkaisu monivuokraajasovellusten Power BI Embedded. Ne tarjoavat kevyet asiakasprofiilit ja tukevat suurta määrää asiakkaan työtiloja ilman erillistä Microsoft Entra rekisteröintiä kullekin asiakkaalle.
Uusille usean kohteen ratkaisuille suosittelemme erillisiä asiakaspalvelun päänimiä, jotka on todennettu hallituilla käyttäjätiedoilla ja yhdistettyjen käyttäjätietojen tunnistetiedoilla, joissa isännöinti- ja luottamusvaatimukset täyttyvät.
Profiilit ovat kelvollinen vaihtoehto uusille ja olemassa oleville sovelluksille, joiden vaatimukset sopivat hänen ominaisuuksiinsa. Niitä ei poisteta käytöstä. Olemassa olevat sovellukset, jotka ovat tyytyväisiä profiileihin, voivat jatkaa niiden käyttöä. Tässä artikkelissa kerrotaan niiden eduista, rajoituksista ja korkean tason määrityksestä. Katso API-esimerkkejä yksityiskohtaisesta profiilioppaasta.
Palvelun pääprofiilien sopivuus
Harkitse profiileja, kun sovelluksesi käyttää tuettuja liittymiä ja hyötyy skaalautuvasta ja hallintamallista, ja voit hyväksyä niiden käyttäjätietojen ja toiminnalliset rajoitukset. Asiakas on sovelluksesi looginen asiakas, eikä välttämättä erillinen Microsoft Entra vuokraaja.
| Etu | Mitä se tarkoittaa ratkaisullesi |
|---|---|
| Kevyet asiakaskontekstit | Luo profiilit yhdessä pääkohteessa ilman erillistä sovelluksen rekisteröintiä ja palvelun päänimeä kullekin asiakkaalle. |
| Tuettu työtilan skaalaus | Pääkohde voi luoda enintään 100 000 profiilia, joista jokaisella on käyttöoikeus jopa 1 000 työtilaan. Arvioi myös sovellettavat resurssi- ja kapasiteettirajat. |
| Automaattinen elinkaari | Luo ja hallitse profiileja ja asiakassisällön valmistelemista tuettujen REST-ohjelmointirajapintojen avulla. |
| Asiakkaan vaikutusalueen sisällön hallinta | Asiakasprofiilin avulla voit hallita työtilan käyttöoikeuksia, semanttisen mallin omistajuutta ja tietolähteen tunnistetietoja. Oikea sovelluksen reititys ja käyttöoikeudet ovat edelleen olennaisia. |
Profiilit voivat vähentää asiakaskohtaista hakemistojen valmistelua, mutta ne edellyttävät silti sovelluksen elinkaaren automatisointia. Pieni sovellus ei välttämättä tarvitse skaalausmalliaan. Jos sovelluksesi käyttää jo erillisiä päänimiä ja täyttää sen vaatimukset, sinun ei tarvitse vaihtaa profiileihin.
Rajoitukset ja kompromissit
Arvioi näitä rajoituksia yhdessä niiden etujen kanssa:
- Profiilit eivät ole riippumattomia Microsoft Entra käyttäjätietoja, eivätkä ne tuota riippumattomia asiakaskohtaisia Entra-kirjautumistietueita.
- Profiilit eivät voi vastaanottaa kuormituksen käyttäjätietojen ehdollisia käyttöoikeuskäytäntöjä tai palvelun loppuvaiheen käyttöoikeuksia itsenäisinä Entra-käyttäjätietoina.
- Profiilit eivät tue Fabric REST-ohjelmointirajapintoja. Tarkista tuetut liittymät ja skaalausrajoitukset.
- Profiilit pysyvät sidoksissa niiden luomiseen pääkohteeseen, ja niillä on vain ohjelmointirajapintoja koskeva hallinta.
- Pääkohde voi toimia minkä tahansa profiilinsa kautta. Profiilit eivät luo salausta asiakkaan eristämisestä.
Katso kaikki rajoitukset kohdasta Käyttäjätietojen ja ohjelmointirajapinnan rajoitukset. Erilliset päänimet edellyttävät myös hakemistokapasiteetin suunnittelua ja elinkaaren hallintaa; kumpikaan käyttäjätietomalli ei korvaa resurssien käyttöoikeuksia eikä suojattua asiakkaan reititystä.
Erilliset asiakastyötilat ja semanttiset mallit voivat parantaa kapasiteetin hallintaa jommassakummassa käyttäjätietomallissa. Nämä edut eivät edellytä profiileja. Jos olemassa oleva profiilipohjainen sovellus tarvitsee profiilimallin ulkopuolisia ominaisuuksia, katso Palvelun päänimiprofiilien korvaaminen palvelun päänimillä.
Profiilimallin toiminta
Sovelluksen pääpalvelun päänimi luo profiilin kullekin asiakkaan valtuutusrajalle. Sovellus yhdistää todennetun asiakkaan oikeaan profiiliin ja sen sallittuihin työtiloihin ja sisältöön.
Käytä profiililaajennuissa REST-kutsuissa pääkohteen Microsoft Entra käyttöoikeustietuetta ja otsikkoaX-PowerBI-Profile-Id. Profiili valitsee asiakaskontekstin; se ei ole erillinen Entra-käyttöoikeustietue. Katso Profiilin käyttöoikeudet.
Edellytykset
Kun olet valinnut profiilimallin, tarkista yksityiskohtainen määritysopas.
Sinun on myös tehtävä seuraavat toimet:
- Määritä pääpalvelun päänimen todentaminen ja tarvittavat vuokraajan asetukset. Katso palvelun päänimen määritys tai hallitun käyttäjätiedon pääkohteen asetus. Suojaa ja kierrä valitsemasi todentamismenetelmän käyttämät tallennetut salaisuudet tai varmenteet.
- Ota käyttöön profiilien luominen vuokraajassa Power BI -vuokraajan järjestelmänvalvojan tililtä.
Profiilipohjaisen ratkaisun määrittäminen
Jos valitset profiilit, määritä asiakaskonteksti, resurssit ja sovelluspyynnöt:
- Asiakasprofiilien luominen.
- Järjestä asiakkaan työtilat ja sisältö.
- Määritä profiilin huomioon ottavat sovelluspyynnöt.
- Vahvista asiakkaan käyttöoikeudet ja toiminnot.
Asiakasprofiilien luominen
Profiilien REST-ohjelmointirajapinnan ja pääpalvelun päänimen avulla voit luoda profiilin kullekin asiakasvaltuutusrajalle.
Tallenna asiakkaan profiiliin -yhdistämismääritys luotetun palvelinpuolen määrityksiin. Vahvista asiakkaan jäsenyys ennen profiilin tai resurssin valitsemista; älä hyväksy asiakkaalta mielivaltaisia profiilitunnuksia.
Työtilojen järjesteleminen
Helpoin tapa hallita tietoja on ylläpitää yhtä työtilaa asiakasta kohden. Jos sovelluksesi käyttää jo tätä mallia, sinun ei tarvitse luoda uusia työtiloja. Sinun on kuitenkin silti annettava jokaiselle profiilille järjestelmänvalvojan käyttöoikeus vastaavaan työtilaan Lisää ryhmän käyttäjä -ohjelmointirajapinnan avulla.
Jos sinulla ei ole yhtä työtilaa asiakasta kohden, käytä vastaavaa profiilia luomaan ryhmän ohjelmointirajapintaa , jotta voit luoda uuden työtilan kullekin asiakkaalle.
Järjestä kohteet työtiloissa
Kun olet luonut tai määrittänut asiakastyötiloja, tuo tarvittaessa raportteja ja semanttisia malleja. Säilytä olemassa oleva sisältö siellä, missä valittu rakenne tukee sitä. Valitse tarpeidesi semanttinen malli ja tietolähderakenne:
Jos sovelluksesi käyttää asiakkaalle erillistä semanttista mallia, semanttinen mallirakenne voi toimia sellaisenaan.
Jos mallisi hyötyy eri malleista, määritä kullekin asiakkaalle semanttinen malli. Arvioi kapasiteetti-, päivitys- ja hallintakustannuksia sen sijaan, että pelkät profiilit parantaisivat jokaisen sovelluksen skaalattavuutta.
Jos rakennuksessasi käytetään rivitason suojausta (RLS), vahvista upotustunnuksen luonnin aikana annetut voimassa olevat käyttäjätiedot ja roolit, mukaan lukien dynaamisen rivitason suojauksen odotettu
UserName()tulos ja staattisen rivitason suojauksen roolivalinta. Voit käyttää rivitason suojausta asiakkaan semanttisessa mallissa erottaaksesi käyttöoikeuden sen käyttäjien välillä.
Kun kohteet ovat valmiita, tuo ne asianmukaisiin työtiloihin. Voit automatisoida prosessin käyttämällä tuonnin ohjelmointirajapintaa.
Jos kyseessä on olemassa oleva semanttinen malli, jota asiakasprofiilin on hallittava vain omistaja -toiminnoilla, varmista, että profiili omistaa mallin. Jos se on tuettu, voit siirtää omistajuuden käyttämällä Ota haltuun ryhmässä -ohjelmointirajapintaa kyseisenä profiilina. Määritä tarvittavat yhteyden käyttäjätiedot ja tietolähteen tunnistetiedot ennen kyseisten toimintojen vaihtamista profiiliin. Työtilan järjestelmänvalvojan käyttöoikeus ei yksinään siirrä omistajuutta tai määritä näitä asetuksia.
Profiilin huomioon ottavat sovelluspyynnöt
Käytä yhdistettyä asiakasprofiilia johdonmukaisesti tuetuissa asiakastoiminnoissa:
- Todentaminen ja profiilin valinta: Hanki pääkohteen käyttöoikeustietue sen määritetyn todennusmenetelmän avulla. Valitse asiakasprofiili profiiliotsikon tai SDK-profiilin määrityksen avulla. Profiili käyttää pääkohteen tunnusta; älä käsittele profiilitunnusta Entra-päätunnuksena.
- Asiakkaan valmistelu: Luo asiakasprofiili ja luo ja hallitse asiakkaan työtilaa ja sisältöä sen avulla. Voit automatisoida tuonnin, yhteyden määrityksen ja elinkaaren muutokset tarvittaessa.
- Upotustunnuksen luominen: Käytä tarkoitettua asiakasprofiilin kontekstia GenerateToken-ohjelmointirajapinnan kutsumiseen. Pyynnön laajuus asiakkaan sallittuun sisältöön ja anna tarvittaessa vaaditut voimassa olevat RLS-käyttäjätiedot ja roolit. Pääkohde voi toimia profiiliensa kautta; profiili ei ole riippumaton suojausraja.
Vahvista asiakkaan käyttöoikeus
Testaa valittu määritys ennen tuotantokäyttöä:
- Varmista, että jokainen todennettu asiakas valitsee vain sille määritetyn profiilin ja sallitut resurssit. Testaa hylättyjä asiakaskohtaisia pyyntöjä ja onnistuneita pyyntöjä.
- Varmista asiakastyötilan käyttö, upotustunnuksen laajuus, raportin hahmontaminen ja soveltuva RLS-toiminta.
- Varmista semanttisen mallin omistajuus, yhteyden käyttäjätiedot, tietolähteen tunnistetiedot, parametripäivitykset ja ajoitettu päivitys.
- Tarkista resurssien toiminnan lokit ja päätietokirjautumisen valvonta. Profiilit eivät luo riippumattomia asiakaskohtaisia Entra-kirjautumisia.
- Automatisoi asiakkaiden käyttöönotto ja tarkista, onko työt tai sisältö, jotka ovat edelleen riippuvaisia profiilista, ennen kuin poistat sen käyttöoikeuden tai poistat sen.
Muistiinpano
Jos määrität aiemmin luodun sovelluksen uudelleen, pidä edellinen koodipolku ja vaaditut käyttöoikeudet käytettävissä pilottikokeilun käyttöönoton ja palautusjakson aikana. Aiemmin luodut laajat käyttöoikeudet voivat peittää virheellisen asiakkaan reitityksen, vaikka raportit hahmontaisiin onnistuneesti. Tallenna ja testaa muutuneen omistajuuden, yhteyksien, tunnistetietojen ja käyttöoikeuksien palauttaminen ennen vanhan määrityksen palauttamista. Poista vanhentunut koodi, työtilat ja myöntää vasta riippuvuuksien tarkistuksen jälkeen.