Power BI Embedded'de çok kiracılı uygulamalar için hizmet sorumlusu profilleri
Bu makalede, birçok müşterisi olan bir ISV'nin veya başka bir Power BI Embedded uygulama sahibinin, müşterileriniz için Power BI ekleme çözümünün bir parçası olarak her müşterinin verilerini eşlemek ve yönetmek için hizmet sorumlusu profillerini nasıl kullanabileceği açıklanmaktadır. Hizmet sorumlusu profilleri, ISV'nin daha iyi müşteri veri yalıtımı sağlayan ölçeklenebilir uygulamalar oluşturmasına ve müşteriler arasında daha sıkı güvenlik sınırları oluşturmasına olanak tanır. Bu makalede, bu çözümün avantajları ve sınırlamaları ele alınmaktadır.
Not
Power BI'daki kiracı sözcüğü bazen bir Microsoft Entra kiracısına başvurabilir. Ancak bu makalede, bir yazılım uygulamasının tek bir örneğinin fiziksel ve mantıksal veri ayrımı gerektiren birden çok müşteriye veya kuruluşa (kiracı) hizmet ettiği bir çözümü açıklamak için çok kiracılılık terimini kullanacağız. Örneğin, Power BI uygulama oluşturucusu aşağıda gösterildiği gibi her müşterisi (veya kiracısı) için ayrı bir çalışma alanı ayırabilir. Bu müşterilerin Microsoft Entra kiracıları olması şart değildir, bu nedenle burada kullandığımız çok kiracılı uygulama terimini Microsoft Entra çok kiracılı uygulamasıyla karıştırmayın.
Hizmet sorumlusu profili, hizmet sorumlusu tarafından oluşturulan bir profildir. ISV uygulaması, bu makalede açıklandığı gibi bir hizmet sorumlusu profili kullanarak Power BI API'lerini çağırır.
ISV uygulama hizmet sorumlusu , her müşteri veya kiracı için farklı bir Power BI profili oluşturur. Müşteri ISV uygulamasını ziyaret ettiğinde, uygulama ilgili profili kullanarak tarayıcıda rapor işlemek için kullanılacak bir ekleme belirteci oluşturur.
Hizmet sorumlusu profillerini kullanmak, ISV uygulamasının tek bir Power BI kiracısı üzerinde birden çok müşteri barındırmasına olanak tanır. Her profil Power BI'daki bir müşteriyi temsil eder. Başka bir deyişle, her profil belirli bir müşterinin verileri için Power BI içeriği oluşturur ve yönetir.
Not
Bu makale, hizmet sorumlusu profillerini kullanarak çok kiracılı bir uygulama ayarlamak isteyen kuruluşlara yöneliktir. Kuruluşunuzun zaten çok kiracılılığı destekleyen bir uygulaması varsa ve hizmet sorumlusu profil modeline geçmek istiyorsanız bkz . Hizmet sorumlusu profil modeline geçiş.
Power BI içeriğinizi ayarlamak için aşağıdaki adımlar gerekir:
- Profil oluşturma
- Profil izinlerini ayarlama
- Her müşteri için çalışma alanı oluşturma
- Raporları ve anlam modellerini çalışma alanına aktarma
- Müşterinin verilerine bağlanmak için anlam modeli bağlantı ayrıntılarını ayarlama
- Hizmet sorumlusundan izinleri kaldırma (isteğe bağlı, ancak ölçeklenebilirliğe yardımcı olur)
- Uygulamaya rapor ekleme
Yukarıdaki adımların tümü Power BI REST API'leri kullanılarak tamamen otomatikleştirilebilir.
Önkoşullar
Hizmet sorumlusu profilleri oluşturabilmeniz için önce şunları yapmanız gerekir:
- Hizmet sorumlusuyla Power BI içeriği ekleme işleminin ilk üç adımını izleyerek hizmet sorumlusunu ayarlayın.
- Power BI kiracısı yönetici hesabından, hizmet sorumlusunu oluştururken kullandığınız güvenlik grubunu kullanarak kiracıda profil oluşturmayı etkinleştirin.
Profil oluşturun
Profiller, Profiller REST API'sini kullanarak oluşturulabilir, güncelleştirilebilir ve silinebilir.
Örneğin, profil oluşturmak için:
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"}
Hizmet sorumlusu, profillerinin listesini almak için GET Profilleri REST API'sini de çağırabilir. Örneğin:
GET https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXA…UUPA
Profil izinleri
Power BI öğelerine kullanıcı izni veren tüm API'ler, Power BI öğelerine profil izni de verebilir. Örneğin, Bir çalışma alanına profil izni vermek için Grup Kullanıcısı Ekleme API'sini kullanabilirsiniz.
Profilleri kullanırken aşağıdaki noktaların anlaşılması önemlidir:
- Profil, onu oluşturan hizmet sorumlusuna aittir ve yalnızca bu hizmet sorumlusu tarafından kullanılabilir.
- Profil sahibi oluşturulduktan sonra değiştirilemez.
- Profil tek başına bir kimlik değildir. Power BI REST API'lerini çağırmak için hizmet sorumlusu Microsoft Entra belirtecine ihtiyacı vardır.
ISV uygulamaları, Yetkilendirme üst bilgisinde hizmet sorumlusu Microsoft Entra belirtecini ve X-PowerBI-Profile-Id üst bilgisinde profil kimliğini sağlayarak Power BI REST API'lerini çağırır. Örneğin:
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
Çalışma alanı oluşturma
Power BI çalışma alanları raporlar ve anlam modelleri gibi Power BI öğelerini barındırmak için kullanılır.
Her profilin şu şekilde olması gerekir:
En az bir Power BI çalışma alanı oluşturma
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" }Çalışma alanına erişim izinleri verin. Hizmet sorumlusu profilinin çalışma alanına Yönetici erişimi olmalıdır.
Çalışma alanını bir kapasiteye atama
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" }
Power BI çalışma alanları hakkında daha fazla bilgi edinin.
Raporları ve anlam modellerini içeri aktarma
Müşterinin verilerine veya örnek verilerine bağlı raporları hazırlamak için Power BI Desktop'ı kullanın. Ardından, içeriği oluşturulan çalışma alanına aktarmak için İçeri Aktarma API'sini kullanabilirsiniz.
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=
Farklı müşterilerin veri kaynaklarına bağlanabilen bir anlam modeli oluşturmak için veri kümesi parametrelerini kullanın. Ardından, anlam modelinin bağlandığı müşterilerin verilerini tanımlamak için Güncelleştirme parametreleri API'sini kullanın.
Anlam modeli bağlantısını ayarlama
ISV'ler genellikle müşterilerinin verilerini iki yoldan biriyle depolar:
Her iki durumda da Power BI'da tek kiracılı anlam modelleri (müşteri başına bir anlam modeli) ile sonuçlanmanız gerekir.
Her müşteri için ayrı bir veritabanı
ISV uygulamasının her müşteri için ayrı bir veritabanı varsa Power BI'da tek kiracılı anlam modelleri oluşturun. Her anlam modeline eşleşen veritabanına işaret eden bağlantı ayrıntılarını sağlayın. Farklı bağlantı ayrıntılarıyla birden çok özdeş rapor oluşturmaktan kaçınmak için aşağıdaki yöntemlerden birini kullanın:
Anlam modeli parametreleri: Bağlantı ayrıntılarında (SQL sunucusu adı, SQL veritabanı adı gibi) parametrelerle bir anlam modeli oluşturun. Ardından, bir raporu müşterinin çalışma alanına aktarın ve parametreleri müşterinin veritabanı ayrıntılarıyla eşleşecek şekilde değiştirin.
Veri Kaynağı API'sini Güncelleştirme: Örnek içeriğe sahip bir veri kaynağına işaret eden bir .pbix oluşturun. Ardından ,pbix dosyasını bir müşterinin çalışma alanına aktarın ve Veri Kaynağını Güncelleştir API'sini kullanarak bağlantı ayrıntılarını değiştirin.
Tek bir çok kiracılı veritabanı
ISV uygulaması tüm müşterileri için tek bir veritabanı kullanıyorsa, müşterileri Power BI'da aşağıdaki gibi farklı anlamsal modellere ayırın:
Yalnızca ilgili müşterinin verilerini alan parametreleri kullanarak bir rapor oluşturun. Ardından, bir raporu müşterinin çalışma alanına aktarın ve parametreleri yalnızca ilgili müşterinin verilerini alacak şekilde değiştirin.
Rapor ekleme
Kurulum tamamlandıktan sonra, ekleme belirteci kullanarak müşteri raporlarını ve diğer öğeleri uygulamanıza ekleyebilirsiniz.
Müşteri uygulamanızı ziyaret ettiğinde GenerateToken API'sini çağırmak için ilgili profili kullanın. Bir raporu veya diğer öğeleri müşterinin tarayıcısına eklemek için oluşturulan ekleme belirtecini kullanın.
Ekleme belirteci oluşturmak için:
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"
}
]
}
Tasarım yönleri
Profil tabanlı çok kiracılı bir çözüm ayarlamadan önce aşağıdaki sorunları bilmeniz gerekir:
- Ölçeklenebilirlik
- Otomasyon ve operasyonel karmaşıklık
- Multi-Geo gereksinimleri
- Maliyet verimliliği
- Satır düzeyi güvenlik
Ölçeklenebilirlik
Verileri her müşteri için ayrı anlamsal modellere ayırarak büyük anlam modelleri gereksinimini en aza indirirsiniz. Kapasite aşırı yüklendiğinde, kullanılmayan anlamsal modelleri çıkararak etkin semantik modellerin belleğini boşaltabilir. Bu iyileştirme tek bir büyük anlam modeli için mümkün değildir. Birden çok anlam modeli kullanarak, gerekirse kiracıları birden çok Power BI kapasitesine ayırabilirsiniz.
Profiller olmadan hizmet sorumlusu 1.000 çalışma alanıyla sınırlıdır. Bu sınırı aşmak için bir hizmet sorumlusu, her profilin en fazla 1.000 çalışma alanına erişebildiği/oluşturabildiği birden çok profil oluşturabilir. ISV uygulaması, birden çok profille her müşterinin içeriğini ayrı mantıksal kapsayıcılar kullanarak yalıtabilir.
Bir hizmet sorumlusu profilinin çalışma alanına erişimi olduğunda, ölçeklenebilirlik sorunlarını önlemek için üst hizmet sorumlusunun çalışma alanına erişimi kaldırılabilir.
Bu avantajlarla bile uygulamanızın olası ölçeğini dikkate almanız gerekir. Örneğin, bir profilin erişebileceği çalışma alanı öğelerinin sayısı sınırlıdır. Bugün, bir profil normal bir kullanıcıyla aynı sınırlara sahiptir. ISV uygulaması son kullanıcıların ekli raporlarının kişiselleştirilmiş bir kopyasını kaydetmesine izin veriyorsa, müşterinin profili tüm kullanıcılarının oluşturulan tüm raporlarına erişebilir. Bu model sonunda sınırı aşabilir.
Otomasyon ve operasyonel karmaşıklık
Power BI profil tabanlı ayrım ile yüzlerce veya binlerce öğeyi yönetmeniz gerekebilir. Bu nedenle, uygulama yaşam döngüsü yönetiminizde sık gerçekleşen işlemleri tanımlamak ve bu işlemleri büyük ölçekte yapmak için doğru araçlara sahip olduğunuzdan emin olmak önemlidir. Bu işlemlerden bazıları şunlardır:
- Yeni kiracı ekleme
- Kiracıların bazıları veya tümü için bir raporu güncelleştirme
- Kiracıların bazıları veya tümü için anlam modeli şemasını güncelleştirme
- Belirli kiracılar için planlanmamış özelleştirmeler
- Anlamsal model yenileme sıklığı
Örneğin, yeni bir kiracı için profil ve çalışma alanı oluşturmak yaygın bir görevdir ve Power BI REST API ile tamamen otomatikleştirilebilir.
Multi-Geo gereksinimleri
Power BI Embedded için Multi-Geo desteği, uygulamalarına analiz eklemek için Power BI Embedded kullanarak uygulama oluşturan ISV'lerin ve kuruluşların artık verilerini dünyanın farklı bölgelerine dağıtabileceği anlamına gelir. Farklı bölgelerdeki farklı müşterileri desteklemek için müşterinin çalışma alanını istenen bölgedeki bir kapasiteye atayın. Bu görev, ek maliyet gerektirmeyen basit bir işlemdir. Ancak, birden çok bölgeden verilere ihtiyaç duyan müşterileriniz varsa, kiracı profili tüm öğeleri farklı bölgesel kapasitelere atanmış birden çok çalışma alanında çoğaltmalıdır. Bu yineleme hem maliyet hem de yönetim karmaşıklığını artırabilir.
Uyumluluk nedeniyle, farklı bölgelerde birden çok Power BI kiracısı oluşturmak isteyebilirsiniz. Multi-geo hakkında daha fazla bilgi edinin.
Maliyet verimliliği
Power BI Embedded kullanan uygulama geliştiricilerinin bir Power BI Embedded kapasitesi satın alması gerekir. Profil tabanlı ayırma modeli kapasitelerle iyi çalışır çünkü:
Kapasiteye bağımsız olarak atayabileceğiniz en küçük nesne bir çalışma alanıdır (örneğin, rapor atayamazsınız). Müşterileri profillere göre ayırarak farklı çalışma alanları elde edersiniz; müşteri başına bir çalışma alanı. Bu şekilde, her bir müşteriyi performans gereksinimlerine göre yönetme ve ölçeği artırarak veya azaltarak kapasite kullanımını iyileştirme konusunda tam esneklik elde edersiniz. Örneğin, yüksek hacimli ve volatiliteye sahip büyük ve temel müşterileri ayrı bir kapasitede yöneterek tutarlı bir hizmet düzeyi sağlayabilir ve maliyetleri iyileştirmek için daha küçük müşterileri başka bir kapasitede gruplandırabilirsiniz.
Çalışma alanlarını ayırmak, veri modellerinin tek bir büyük semantik model yerine daha küçük öbekler halinde olması için kiracılar arasında semantik modellerin ayrılması anlamına da gelir. Bu küçük modeller kapasitenin bellek kullanımını daha verimli bir şekilde yönetmesini sağlar. Küçük, kullanılmayan semantik modeller, iyi performansı korumak için bir süre etkinlik dışı kalma süresinden sonra çıkarılabilir.
Kapasite satın alırken, birden çok anlam modeliniz olduğunda yenileme işlemlerinin fazladan kapasiteye ihtiyacı olabileceğinden paralel yenileme sayısı sınırını göz önünde bulundurun.
Satır Düzeyinde Güvenlik
Bu makalede, her müşteri için ayrı bir anlam modeli oluşturmak için profillerin nasıl kullanılacağı açıklanmaktadır. Alternatif olarak, ISV uygulamaları tüm müşterilerinin verilerini tek bir büyük anlam modelinde depolayabilir ve her müşterinin verilerini korumak için Satır düzeyi güvenlik (RLS) kullanabilir. Bu yaklaşım, nispeten az müşterisi ve küçük ve orta ölçekli anlam modelleri olan ISV'ler için kullanışlı olabilir çünkü:
- Yalnızca bir rapor ve bakım için tek bir anlam modeli vardır
- Yeni müşteriler için ekleme işlemi basitleştirilmiş olabilir
Ancak RLS'yi kullanmadan önce sınırlamalarını anladığınızdan emin olun. Tüm müşteriler için tüm veriler büyük bir Power BI anlam modelindedir. Bu anlamsal model, kendi ölçeklendirmesi ve diğer sınırlamalarıyla tek bir kapasitede çalışır.
Müşterilerinizin verilerini ayırmak için hizmet sorumlusu profillerini kullansanız bile, farklı gruplara verilerin farklı bölümlerine erişim vermek için tek bir müşterinin anlam modeli içinde RLS'yi kullanmaya devam edebilirsiniz. Örneğin, RLS'yi kullanarak bir departmanın üyelerinin aynı kuruluştaki başka bir departmanın verilerine erişmesini engelleyebilirsiniz.
Dikkat edilecekler ve sınırlamalar
- Hizmet Sorumlusu Profilleri yalnızca Power BI REST API, Power BI .NET SDK'sı ve Analysis Services istemci kitaplıkları sürüm 16.0.139.27 veya üzeri kullanılırken XMLA uç noktası ve Tablolu Nesne Modeli (TOM) aracılığıyla desteklenir. Hizmet Sorumlusu Profilleri, Power BI'da XMLA uç noktası veya eski istemci kitaplıklarına sahip Tablosal Nesne Modeli (TOM) aracılığıyla desteklenmez.
- Hizmet sorumlusu profilleri, canlı bağlantı modunda Azure Analysis Services (AAS) ile desteklenmez.
- Tek bir hizmet sorumlusunun sahip olabileceği maksimum profil sayısı 100.000'dir.
Power BI kapasite sınırlamaları
- Her kapasite, satın alınan SKU'ya göre yalnızca ayrılmış belleği ve sanal çekirdekleri kullanabilir. Her SKU için önerilen anlamsal model boyutu için Premium büyük anlam modelleri'ne başvurun.
- 10 GB'tan büyük bir anlam modeli kullanmak için Premium kapasite kullanın ve Büyük anlam modelleri ayarını etkinleştirin.
- Kapasitede eşzamanlı olarak çalışabilen yenileme sayısı için kaynak yönetimine ve iyileştirmeye başvurun.
Hizmet sorumlularını yönetme
Hizmet sorumlusunu değiştirme
Power BI'da profil, onu oluşturan hizmet sorumlusuna aittir. Başka bir deyişle, profil diğer sorumlularla paylaşılamaz. Bu sınırlamayla, herhangi bir nedenle hizmet sorumlusunu değiştirmek istiyorsanız, tüm profilleri yeniden oluşturmanız ve yeni profillere ilgili çalışma alanlarına erişim sağlamanız gerekir. IsV uygulamasının gerektiğinde doğru profili seçebilmesi için genellikle profil kimliğiyle müşteri kimliği arasındaki eşlemeyi kaydetmesi gerekir. Hizmet sorumlusunu değiştirir ve profilleri yeniden oluşturursanız kimlikler de değişir ve ISV uygulama veritabanında eşlemeyi güncelleştirmeniz gerekebilir.
Hizmet sorumlusunu silme
Uyarı
Hizmet sorumlusunu silerken çok dikkatli olun. İlişkili tüm profillerdeki verileri yanlışlıkla kaybetmek istemezsiniz.
Active Directory'deki hizmet sorumlusunu silerseniz, Power BI'daki tüm profilleri silinir. Ancak Power BI içeriği hemen silmez, bu nedenle kiracı yöneticisi çalışma alanlarına erişmeye devam edebilir. Özellikle Power BI'da bu hizmet sorumlusunu kullanarak profiller oluştururken, üretim sisteminde kullanılan bir hizmet sorumlusunu silerken dikkatli olun. Profiller oluşturan bir hizmet sorumlusunu silerseniz, tüm profilleri yeniden oluşturmanız, yeni profillere ilgili çalışma alanlarına erişim sağlamanız ve ISV uygulama veritabanındaki profil kimliklerini güncelleştirmeniz gerektiğini unutmayın.
Veri ayrımı
Veriler hizmet sorumlusu profilleriyle ayrıldığında, profille müşteri arasında basit bir eşleme, bir müşterinin başka bir müşterinin içeriğini görmesini engeller. Tek bir hizmet sorumlusu kullanmak için hizmet sorumlusunun tüm profillerdeki farklı çalışma alanlarına erişimi olması gerekir.
Ek ayrım eklemek için, farklı profiller kullanarak tek bir hizmet sorumlusunun birden çok çalışma alanına erişmesini sağlamak yerine her kiracıya ayrı bir hizmet sorumlusu atayın. Ayrı hizmet sorumluları atamanın aşağıdakiler gibi çeşitli avantajları vardır:
- İnsan hatası veya kimlik bilgisi sızıntısı birden çok kiracının verilerinin açığa çıkarılmasına neden olmaz.
- Sertifika döndürme her kiracı için ayrı ayrı yapılabilir.
Ancak, birden çok hizmet sorumlusu kullanmanın yüksek yönetim maliyeti vardır. Bu yolu yalnızca ek ayrıma ihtiyacınız varsa seçin. Ekleme belirtecini oluşturduğunuzda, son kullanıcıların göremeyeceği veya değiştiremeyen yalnızca arka uç işlemi olan son kullanıcıya gösterilecek verilerin yapılandırmasının tanımlandığını unutmayın. Kiracıya özgü bir profil kullanarak ekleme belirteci istemek, bu profil için bir ekleme belirteci oluşturur ve bu da size tüketimde müşteri ayrımı sağlar.
Bir rapor, birden çok anlam modeli
Genellikle kiracı başına bir raporunuz ve bir semantik modeliniz vardır. Yüzlerce raporunuz varsa, yüzlerce anlam modeliniz olur. Bazen, farklı semantik modellerle (örneğin, farklı parametreler veya bağlantı ayrıntıları) tek bir rapor biçiminiz olabilir. Raporun her yeni sürümüne sahip olduğunuzda, tüm kiracılar için tüm raporları güncelleştirmeniz gerekir. Bunu otomatikleştirebilirsiniz ancak raporun yalnızca bir kopyasına sahipseniz bunu yönetmek daha kolaydır. Eklenmek üzere raporu içeren bir çalışma alanı oluşturun. Oturum çalışma zamanı sırasında raporu kiracıya özgü anlam modeline bağlayın. Daha fazla ayrıntı için dinamik bağlamaları okuyun.
İçeriği özelleştirme ve yazma
İçerik oluşturduğunuzda, kimin düzenleme iznine sahip olduğunu dikkatlice göz önünde bulundurun. Her kiracıda birden çok kullanıcının düzenlemesine izin verirseniz anlamsal model sınırlamalarını kolayca aşabilirsiniz. Kullanıcılara düzenleme özelliği vermeye karar verirseniz, içerik oluşturma işlemlerini yakından izleyin ve gerektiğinde ölçeği büyütün. Aynı nedenle, her kullanıcının bir raporda küçük değişiklikler yapıp kendileri için kaydedebileceği içerik kişiselleştirme için bu özelliği kullanmanızı önermeyiz. ISV uygulaması içerik kişiselleştirmeye izin veriyorsa, kullanıcıya özgü içerik için çalışma alanı bekletme ilkeleri eklemeyi göz önünde bulundurun. Bekletme ilkeleri, kullanıcılar yeni bir konuma geçtiğinde, şirketten ayrıldığında veya platformu kullanmayı bıraktığında içeriği silmeyi kolaylaştırır.
Sistem Tarafından Yönetilen kimlik
Hizmet sorumlusu yerine, profil oluşturmak için kullanıcı tarafından atanan veya sistem tarafından atananyönetilen kimliği kullanabilirsiniz. Yönetilen kimlikler gizli dizi ve sertifika ihtiyacını azaltır.
Sistem tarafından yönetilen kimlik kullanırken dikkatli olun çünkü:
- Sistem tarafından atanan yönetilen kimlik yanlışlıkla kapatılırsa profillere erişiminizi kaybedersiniz. Bu durum, hizmet sorumlusu silindiği bir duruma benzer.
- Sistem tarafından atanan yönetilen kimlik, Azure'daki (web uygulaması) bir kaynağa bağlanır. Kaynağı silerseniz kimlik silinir.
- Birden çok kaynağın (farklı bölgelerdeki farklı web uygulamaları) kullanılması, ayrı olarak yönetilmesi gereken birden çok kimlikle sonuçlanır (her kimliğin kendi profilleri olur).
Yukarıdaki önemli noktalar nedeniyle, kullanıcı tarafından atanan bir yönetilen kimlik kullanmanızı öneririz.
Örnek
Power BI ve App-Owns-Data ekleme ile çok kiracılı bir ortamı yönetmek için hizmet sorumlusu profillerinin nasıl kullanılacağına ilişkin bir örnek için, Power BI Geliştirme Kampı'ndan (üçüncü taraf site) Uygulamanın veri sahibi çok kiracılı deposunu indirin.