Çok kiracılı uygulamalar için hizmet aslı profillerini yapılandırma

Bu makalede, Power BI Embedded müşterileriniz için gömme çözümü için bunları seçtikten sonra hizmet sorumlusu profillerini yapılandırma ve kullanma işlemleri açıklanmaktadır. Profiller, müşteri kapsamındaki içerik yönetimini ve çok sayıda çalışma alanını destekler. Müşteri ayrımı doğru uygulama yönlendirmeye, çalışma alanı izinlerine ve uygun şekilde kapsamı belirlenmiş embed belirteçlerine bağlıdır; profiller bağımsız bir Microsoft Entra kimliği veya kriptografik müşteri sınırı oluşturmaz.

Not

Yeni çok kiracılı çözümler için, barındırma ve güven gereksinimlerinin uygun olduğu durumlarda yönetilen kimliği ve federasyon kimlik bilgilerini kullanarak adanmış müşteri hizmet sorumlularıyla başlayın. Profiller, gereksinimleri bunların avantaj ve sınırlamalarına uyan yeni ve mevcut uygulamalar için geçerli ve isteğe bağlı bir çözüm olarak kalır. Gereksinimlerinizi karşılıyorsa profilleri kullanmaya devam edebilirsiniz.

Profiller Microsoft Entra kimlikleri değildir ve Fabric REST API'leri ile kullanılamaz. Çözümünüz aşağı akış hizmetleri için müşteri kimlikleri, bağımsız Microsoft Entra oturum açma günlükleri, iş yükü kimliği Koşullu Erişim veya profil modeliyle sınırlandırılan özellikler gerektiriyorsa, hizmet sorumlusu profillerini hizmet sorumlularıyla değiştirmeyi göz önünde bulundurun.

Not

Power BI'deki kiracı sözcüğü bazen bir Microsoft Entra kiracısına karşılık gelebilir. 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, bu makalede ele aldığımız şekilde her bir 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, tarayıcıda rapor işlemek için kullanılan bir ekleme belirteci oluşturmak için ilgili profili kullanır.

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.

Hizmet sorumlusu Profilleri ve çok kiracılılık diyagramı.

Not

Bu alternatife genel bakış için bkz. Hizmet sorumlusu profilleri: İsteğe bağlı çok kiracılı çözüm. Profil modelini seçtikten sonra aşağıdaki yapılandırma adımları uygulanır.

Power BI içeriğinizi ayarlamak için aşağıdaki adımlar gerekir:

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:

Yönetici portalı anahtarının ekran görüntüsü.

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 bunu yalnızca hizmet sorumlusu kullanabilir.
  • 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ı, hizmet sorumlusu Microsoft Entra belirtecini Authorization üst bilgi kısmında ve profil kimliğini X-PowerBI-Profile-Id üst bilgi kısmında 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 atayın

    POST https://api.powerbi.com/v1.0/myorg/groups/aaaabbbb-0000-cccc-1111-dddd2222eeee/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/aaaabbbb-0000-cccc-1111-dddd2222eeee/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 kullanıcılı anlam modellerine (müşteri başına bir anlam modeli) ulaşmanız beklenir.

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

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 eklenmiş 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ştirmeleri etkinleştirme
  • Anlamsal model yenileme sıklığını ayarlama

Ö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 nedenleriyle, farklı bölgelerde birden çok Power BI kiracısı oluşturmak isteyebilirsiniz. Multi-geo hakkında daha fazla bilgi için okuyun.

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 bir anlam modeli tutmaları gerekir
  • 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

Profil modelini seçmeden veya genişletmeden önce kimlik, API ve ölçek sınırlarını değerlendirin.

Kimlik ve API sınırlamaları

Profilleri benimsemeden veya mevcut profil tabanlı çözümü genişletmeden önce şu sınırlamaları gözden geçirin:

Sınırlama Çözümünüz için ne anlama gelir
Microsoft Entra kimliği değil Bir profil yalnızca Power BI içinde bulunur. Microsoft Entra araçları aracılığıyla bunu bağımsız olarak yönetemez veya gözden geçiremez ya da aşağı akış hizmetlerinde bir kimlik olarak izin veremezsiniz. Örneğin profil, semantik modelden lakehouse veya ambara Direct Lake bağlantısının kimliği olamaz.
Fabric REST API desteği yok Profiller Power BI REST API, Power BI .NET SDK ve desteklenen XMLA/TOM arabirimleri aracılığıyla çalışır. Fabric REST API'leri bunları desteklemez ve desteklenmesi planlanmamaktadır.
Bağımsız oturum açma kimliği yok Profil kapsamındaki işlemler, müşteri başına bağımsız Microsoft Entra oturum açma kayıtları oluşturmaz. Power BI etkinlik günlükleri profilleri tanımlamaya devam edebilir.
Profil başına Koşullu Erişim yok Profil, iş yükü kimliği Koşullu Erişiminin hedefleyebileceği bir kimlik sorumlusu değildir. Uygun ayrılmış hizmet asılları için politikaların ayrı lisanslama ve yapılandırma gereksinimleri vardır.
Oluşturan ilkeye bağlı Profilleri üst servis sorumluları arasında aktaramazsınız. Üst öğeyi değiştirmek için profillerin yeniden oluşturulması, çalışma alanı erişiminin geri yüklenmesi ve müşteri eşlemelerinin güncelleştirilmesi gerekir.
Yalnızca API yönetimi Profillerin, bunları incelemek ve yönetmek için ayrılmış bir yönetim kullanıcı arabirimi yoktur. Bunlar Microsoft Entra yönetim merkezi'da temsil edilmez.

Bu sınırlamalar çözümünüzü kısıtlarsa bkz. Hizmet sorumlusu profillerini hizmet sorumlularıyla değiştirin. Geçişi seçen müşteriler için bu kılavuz, barındırma ve güven gereksinimleri uygun olduğunda yönetilen kimlik ve federasyon kimlik bilgilerini önerir. Doğrudan service principal kimlik doğrulaması alternatif olarak kalır.

Desteklenen arabirimler ve ölçek sınırları

  • 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ıyla 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 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 gerekir.

Veri ayrımı

hizmet sorumlusu profillerini kullandığınızda uygulamanızın kimliği doğrulanmış her müşteriyi doğru profile ve izin verilen kaynaklara eşlemesi gerekir. Çalışma alanı izinleri ve uygun kapsamlı gömme belirteçleri erişimi denetler. Profil bağımsız bir Microsoft Entra kimliği değildir ve üst hizmet asıl sorumlusu, oluşturduğu herhangi bir profil aracılığıyla işlem yapabilir.

Çözümünüz Microsoft Entra yönetişimi, bağımsız oturum açma izleme, uygun iş yükü kimliği için Koşullu Erişim ilkeleri, alt hizmet kimlikleri veya Fabric REST API erişimi gerektirdiğinde ayrılmış hizmet asıllarını göz önünde bulundurun. Ayrıca, profilden ebeveyne bağlama veya yalnızca API yönetiminin operasyonel zorluklar oluşturduğu durumlarda da bir alternatiftir. Profiller gereksinimlerinizi karşılıyorsa bunları kullanmaya devam edebilirsiniz.

Ayrılmış servis asılları, müşteri izinlerini ve kimlik doğrulamasını bağımsız olarak yönetmenize olanak sağlar. Depolanan sertifikalar kullanıyorsanız, bunları her müşteri için ayrı olarak yenileyebilirsiniz. Ancak, kimlik bilgisi sızıntısının veya çalışma zamanı güvenliğinin aşılmasının etkisi, çalışma zamanının hangi müşteri kimlik bilgilerini veya federe güven ilişkilerini kullanabileceğine bağlıdır. Her iki mimari de müşteri arası yalıtımı otomatik olarak garanti etmez.

Adanmış kimliklerin yönetilmesi dizin nesnesi sınırlarını ve yaşam döngüsü çalışmasını beraberinde getirir. Bu dengeleri değerlendirin ve geçiş yapmayı seçerseniz Hizmet sorumlusu profillerini hizmet sorumlularıyla değiştir öğesini izleyin. embed token’ını oluştururken arka uçta son kullanıcıya gösterilecek verilerin yapılandırmasını koruyun. Bir kimlik, çalışma alanı veya içerik seçmeden önce müşteri üyeliğini doğrulayın.

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. Bu işlemi otomatikleştirebilmenize rağmen, raporun yalnızca bir kopyasına sahipseniz 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 bilgiler ve sertifika ihtiyacı azaltır.

Not

Profilleri oluşturan ve kullanan yönetilen kimlik, bu profilleri Microsoft Entra kimliklerine dönüştürmez veya Fabric REST API'leriyle kullanımını etkinleştirmez. Bu koşul, ayrılmış müşteri hizmeti sorumluları olarak kimlik doğrulaması yapmak için yönetilen kimlik ve federasyon kimlik bilgilerinin kullanılmasından farklıdır. Bkz. Hizmet sorumlusu profillerini hizmet sorumlularıyla değiştirin.

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şimi 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 de silinir.
  • Birden çok kaynağın (farklı bölgelerdeki farklı web uygulamaları) kullanılması, ayrı olarak yönetilmesi gereken birden çok kimlikle sonuçlanabilir (her kimliğin kendi profilleri vardır).

Yukarıdaki önemli noktalar nedeniyle, kullanıcı tarafından atanan bir yönetilen kimlik kullanmanızı öneririz.

Örnek

Power BI ve App-Owns-Data gömme ile çok kiracılı bir ortamı yönetmek için hizmet sorumlusu profillerini nasıl kullanabileceğinizi gösteren bir örnek için, App owns data multitenant deposunu Power BI Dev Camp'den (üçüncü taraf bir site) indirin.

İlgili içerik

  • Son güncelleştirme: