Power BI ekleme ile ölçeklenebilir çok kiracılı uygulamalar geliştirme

Bu makalede, en yüksek düzeyde ölçeklenebilirlik, performans ve güvenlik elde ederken Power BI içeriği ekleyen çok kiracılı bir uygulamanın nasıl geliştirildiği açıklanır. Hizmet sorumlusu profilleriyle bir uygulama tasarlayıp uygulayarak, 100.000'den fazla kullanıcının hedef kitlesine rapor sunabilen on binlerce müşteri kiracısını içeren çok kiracılı bir çözüm oluşturabilir ve yönetebilirsiniz.

Hizmet sorumlusu profilleri , Power BI'daki kurumsal içeriği yönetmenizi ve kapasitelerinizi daha verimli kullanmanızı kolaylaştıran bir özelliktir. Ancak, hizmet sorumlusu profillerini kullanmak uygulama tasarımınıza karmaşıklık katabilir. Bu nedenle, bunları yalnızca önemli bir ölçeğe ulaşmanız gerektiğinde kullanmanız gerekir. Çok sayıda çalışma alanınız ve 1.000'den fazla uygulama kullanıcınız olduğunda hizmet sorumlusu profillerini kullanmanızı öneririz.

Power BI ekleme işlemini gerçekleştirmek için iki farklı ekleme senaryosu kullanabilirsiniz: Kuruluşunuz için ekleme ve Müşteriniz için ekleme.

Kuruluşunuz için ekle senaryosu, uygulama hedef kitlesi iç kullanıcılardan oluşuyorsa geçerlidir. İç kullanıcıların kuruluş hesapları vardır ve Microsoft Entra Id ile kimlik doğrulaması yapmalıdır. Bu senaryoda Power BI hizmet olarak yazılımdır (SaaS). Bazen verilerin sahibi Kullanıcı olarak adlandırılır.

Müşteriniz için ekle senaryosu, uygulama hedef kitlesi dış kullanıcılardan oluşuyorsa geçerlidir. Uygulama, kullanıcıların kimliğini doğrulamakla sorumludur. Power BI içeriğine erişmek için uygulama, Microsoft Entra ile kimlik doğrulaması yapmak için bir ekleme kimliğine (Microsoft Entra hizmet sorumlusu veya ana kullanıcı hesabı) dayanır. Bu senaryoda Power BI hizmet olarak platformdur (PaaS). Bazen verilerin sahibi Uygulama olarak adlandırılır.

Çok kiracılı uygulama geliştirme

Microsoft Entra'yı biliyorsanız kiracı sözcüğü bir Microsoft Entra kiracısı düşünmenize yol açabilir. Ancak kiracı kavramı, Power BI içeriği ekleyen çok kiracılı bir çözüm oluşturma bağlamında farklıdır. Bu bağlamda, uygulamanın Müşteriniz için Ekle senaryosunu kullanarak Power BI içeriği eklediği her müşteri adına bir müşteri kiracısı oluşturulur. Her müşteri kiracısını genellikle tek bir Power BI çalışma alanı oluşturarak sağlarsınız.

Ölçeklenebilir bir çok kiracılı çözüm oluşturmak için yeni müşteri kiracıları oluşturmayı otomatikleştirebilmeniz gerekir. Yeni bir müşteri kiracısı sağlamak genellikle Power BI REST API'sini kullanarak yeni bir Power BI çalışma alanı oluşturmak, Power BI Desktop (.pbix) dosyalarını içeri aktararak anlamsal modeller oluşturmak, veri kaynağı parametrelerini güncelleştirmek, veri kaynağı kimlik bilgilerini ayarlamak ve zamanlanmış anlam modeli yenilemesi ayarlamak için kod yazmayı içerir. Aşağıdaki diyagramda, müşteri kiracılarını ayarlamak için çalışma alanlarına raporlar ve anlam modelleri gibi Power BI öğelerini nasıl ekleyebileceğiniz gösterilmektedir.

Müşteriniz için Ekle senaryosunu kullanan bir uygulama geliştirirken, ana kullanıcı hesabı veya hizmet sorumlusu olan bir ekleme kimliği kullanarak Power BI REST API çağrıları yapmak mümkündür. Üretim uygulamaları için hizmet sorumlusu kullanmanızı öneririz. En yüksek güvenliği sağlar ve bu nedenle Microsoft Entra tarafından önerilen yaklaşımdır. Ayrıca daha iyi otomasyon ve ölçeklendirmeyi destekler ve daha az yönetim yükü vardır. Ancak, ayarlamak ve yönetmek için Power BI yönetici hakları gerektirir.

Hizmet sorumlusu kullanarak, kullanıcıların çok faktörlü kimlik doğrulaması (MFA) kullanarak oturum açması gereken ortamlardaki kimlik doğrulama hataları gibi ana kullanıcı hesaplarıyla ilişkili yaygın sorunlardan kaçınabilirsiniz. Hizmet sorumlusu kullanmak, Müşteriniz için ekleme senaryosunun SaaS zihniyetinin aksine PaaS zihniyetini kullanarak Power BI içeriği eklemeye dayalı olduğu fikriyle de tutarlıdır.

1.000 çalışma alanı sınırlaması

Müşteriniz için Ekleme senaryonuzu uygulayan çok kiracılı bir ortam tasarlarken, ekleme kimliğine 1.000'den fazla çalışma alanına erişim verilebileceğini unutmayın. Power BI hizmeti, REST API çağrıları yaparken iyi performans sağlamak için bu sınırlamayı uygular. Bu sınırlamanın nedeni, Power BI'ın her kimlik için güvenlikle ilgili meta verileri nasıl koruduğuyla ilgilidir.

Power BI, bir kimliğin erişebileceği çalışma alanlarını ve çalışma alanı öğelerini izlemek için meta verileri kullanır. Power BI, yetkilendirme alt sistemindeki her kimlik için ayrı bir erişim denetimi listesi (ACL) tutmalıdır. Bir kimlik çalışma alanına erişmek için REST API çağrısı yaptığında, Power BI'ın yetkilendirildiğinden emin olmak için kimliğin ACL'sine karşı bir güvenlik denetimi yapması gerekir. Çalışma alanı sayısı arttıkça hedef çalışma alanının ACL içinde olup olmadığını belirlemek için gereken süre katlanarak artar.

İki çok kiracılı uygulamanın her birinin tek bir hizmet sorumlusu kullanacak şekilde ayarlandığı bir senaryo düşünün. Şimdi ilk uygulamanın 990 çalışma alanı oluşturduğunu, ikinci uygulamanın ise 1.010 çalışma alanı oluşturduğunu düşünün. Destek açısından bakıldığında, ilk uygulama desteklenen sınırlar içindeyken ikinci uygulama değildir.

Şimdi bu iki uygulamayı yalnızca performans açısından karşılaştırın. Bu kadar fark yoktur çünkü her iki hizmet sorumlusunun ACL'leri de ACL'lerinin meta verilerinin performansı bir dereceye kadar düşüreceği bir noktaya kadar büyümesine izin verir.

Temel gözlem şu şekildedir: Hizmet sorumlusu tarafından oluşturulan çalışma alanı sayısının performans ve ölçeklenebilirlik üzerinde doğrudan etkisi vardır. 100 çalışma alanının üyesi olan bir hizmet sorumlusu, REST API çağrılarını 1.000 çalışma alanının üyesi olan hizmet sorumlusundan daha hızlı yürütür. Benzer şekilde, yalnızca 10 çalışma alanının üyesi olan bir hizmet sorumlusu, REST API çağrılarını 100 çalışma alanının üyesi olan hizmet sorumlusundan daha hızlı yürütür.

Anlam modelleri ve veri kaynağı kimlik bilgileri için yalıtımı yönetme

Çok kiracılı bir uygulama tasarlarken bir diğer önemli özellik de müşteri kiracılarını yalıtmaktır. Bir müşteri kiracısından gelen kullanıcıların başka bir müşteri kiracısına ait verileri görmemesi kritik önem taşır. Bu nedenle, anlam modeli sahipliğini ve veri kaynağı kimlik bilgilerini yönetmeyi anlamanız gerekir.

Anlamsal model sahipliği

Her Power BI anlam modelinin bir kullanıcı hesabı veya hizmet sorumlusu olabilecek tek bir sahibi vardır. Zamanlanmış yenilemeyi ayarlamak ve anlam modeli parametrelerini ayarlamak için anlam modeli sahipliği gereklidir.

Gerekirse, anlam modelinin sahipliğini başka bir kullanıcı hesabına veya hizmet sorumlusuna aktarabilirsiniz. Bunu Power BI hizmeti veya REST API TakeOver işlemini kullanarak yapabilirsiniz. Hizmet sorumlusu kullanarak yeni bir anlam modeli oluşturmak için bir Power BI Desktop dosyasını içeri aktardığınızda, hizmet sorumlusu otomatik olarak anlam modeli sahibi olarak ayarlanır.

Veri kaynağı kimlik bilgileri

Anlamsal modeli temel alınan veri kaynağına bağlamak için anlam modeli sahibinin veri kaynağı kimlik bilgilerini ayarlaması gerekir. Veri kaynağı kimlik bilgileri Power BI tarafından şifrelenir ve önbelleğe alınır. Bu noktadan itibaren Power BI, verileri yenilerken (içeri aktarma depolama tabloları için) veya geçiş sorguları yürütürken (DirectQuery depolama tabloları için) temel alınan veri kaynağıyla kimlik doğrulaması yapmak için bu kimlik bilgilerini kullanır.

Yeni bir müşteri kiracısı sağlarken ortak bir tasarım deseni uygulamanızı öneririz. Hizmet sorumlusunun kimliğini kullanarak bir dizi REST API çağrısı yürütebilirsiniz:

1. Yeni çalışma alanı oluşturun.
2. Yeni çalışma alanını ayrılmış bir kapasiteyle ilişkilendirin.
3. Anlam modeli oluşturmak için Power BI Desktop dosyasını içeri aktarın.
4. Bu anlam modeli için anlam modeli kaynak kimlik bilgilerini ayarlayın.

Bu REST API çağrıları tamamlandığında, hizmet sorumlusu yeni çalışma alanının yöneticisi ve anlam modeli ile veri kaynağı kimlik bilgilerinin sahibi olacaktır.

Hizmet sorumlusunun, aşağıdaki diyagramda gösterildiği gibi müşteri kiracıları genelindeki farklı çalışma alanlarındaki anlam modelleri tarafından paylaşılan veri kaynağı kimlik bilgileri oluşturması mümkündür.

Veri kaynağı kimlik bilgileri farklı müşteri kiracılarına ait anlamsal modeller tarafından paylaşıldığında, müşteri kiracıları tam olarak yalıtılmış olmaz.

Hizmet sorumlusu profillerinden önceki tasarım stratejileri

Hizmet sorumlusu profili özelliği kullanıma sunulmadan önce tasarım stratejilerini anlamak, özellik gereksinimini takdir etmenize yardımcı olabilir. Bu süreden önce geliştiriciler aşağıdaki üç tasarım stratejisinden birini kullanarak çok kiracılı uygulamalar oluşturmİşler:

• Tek hizmet sorumlusu
• Hizmet sorumlusu havuzu
• Çalışma alanı başına bir hizmet sorumlusu

Bu tasarım stratejilerinin her biriyle ilişkili güçlü ve zayıf yönleri vardır.

Tek hizmet sorumlusu tasarım stratejisi, bir Microsoft Entra uygulama kaydının bir kerelik oluşturulmasını gerektirir. Bu nedenle, daha fazla Microsoft Entra uygulama kaydı oluşturma gereksinimi olmadığından diğer iki tasarım stratejisinden daha az yönetim yükü içerir. Rest API çağrıları yaparken çağrı bağlamını hizmet sorumluları arasında değiştiren ek kod yazmayı gerektirmediğinden, bu strateji de en kolay şekilde ayarlanır. Ancak, bu tasarım stratejisiyle ilgili bir sorun, ölçeklendirilmiyor olmasıdır. Yalnızca 1.000 çalışma alanına kadar büyüyebilen çok kiracılı bir ortamı destekler. Ayrıca, hizmet sorumlusuna daha fazla sayıda çalışma alanına erişim verildiğinden performansın da düşe olduğundan emin olun. Tek hizmet sorumlusu tüm müşteri kiracılarında her anlam modelinin ve tüm veri kimlik bilgilerinin sahibi olduğundan müşteri kiracı yalıtımıyla ilgili bir sorun da vardır.

Hizmet sorumlusu havuzu tasarım stratejisi genellikle 1.000 çalışma alanı sınırlamasını önlemek için kullanılır. Uygulamanın havuza doğru sayıda hizmet sorumlusu ekleyerek herhangi bir sayıda çalışma alanına ölçeklendirilmesine olanak tanır. Örneğin, beş hizmet sorumlusu içeren bir havuz, 5.000 çalışma alanına kadar ölçeklendirmeyi mümkün kılar; 80 hizmet sorumlusu içeren bir havuz, 80.000 çalışma alanına kadar ölçeği artırmayı vb. mümkün kılar. Ancak bu strateji çok sayıda çalışma alanına ölçeklense de çeşitli dezavantajları vardır. İlk olarak, REST API çağrıları yaparken hizmet sorumluları arasında bağlam geçişi yapmak için ek kod yazmanızı ve meta verileri depolamanızı gerektirir. İkincisi, havuzdaki hizmet sorumlularının sayısını artırmanız gerektiğinde Microsoft Entra uygulama kayıtları oluşturmanız gerektiğinden daha fazla yönetim çalışması gerektirir.

Dahası, hizmet sorumlularının yüzlerce çalışma alanına üye olmasına izin verdiğinden hizmet sorumlusu havuzu stratejisi performans için iyileştirilmemiştir. Hizmet sorumluları, müşteri kiracıları arasında paylaşılan anlamsal modelin ve veri kimlik bilgilerinin sahibi olabileceğinden, müşteri kiracı yalıtımı açısından da ideal değildir.

Çalışma alanı başına bir hizmet sorumlusu tasarım stratejisi, her müşteri kiracısı için bir hizmet sorumlusu oluşturmayı içerir. Teorik açıdan bakıldığında, bu strateji rest API çağrılarının performansını iyileştirirken çalışma alanı düzeyinde anlamsal modeller ve veri kaynağı kimlik bilgileri için gerçek yalıtım sağladığından en iyi çözümü sunar. Ancak, teoride en iyi sonuç her zaman pratikte en iyi şekilde çalışmaz. Bunun nedeni, her müşteri kiracısı için hizmet sorumlusu oluşturma gereksiniminin birçok kuruluş için pratik olmadığıdır. Bunun nedeni, bazı kuruluşların resmi onay süreçlerine sahip olması veya Microsoft Entra uygulama kayıtları oluşturmak için aşırı bürokrasi içermesidir. Bu nedenler, özel bir uygulamaya microsoft entra uygulama kayıtlarını isteğe bağlı olarak ve çözümünüzün gerektirdiği otomatik şekilde oluşturmak için gereken yetkiyi vermenizi imkansız hale getirebilir.

Özel bir uygulamaya uygun izinlerin verildiği daha az yaygın senaryolarda, microsoft Graph API'sini kullanarak isteğe bağlı olarak Microsoft Entra uygulama kayıtları oluşturabilir. Ancak, her Microsoft Entra uygulama kaydı için kimlik doğrulama kimlik bilgilerini izlemesi gerektiğinden, özel uygulamanın geliştirilmesi ve dağıtılması genellikle karmaşıktır. Ayrıca tek tek hizmet sorumluları için kimlik doğrulaması yapması ve erişim belirteçleri alması gerektiğinde de bu kimlik bilgilerine erişim kazanmalıdır.

Hizmet sorumlusu profilleri

Hizmet sorumlusu profilleri özelliği, Power BI'daki kurumsal içeriği yönetmenizi ve kapasitelerinizi daha verimli kullanmanızı kolaylaştıracak şekilde tasarlanmıştır. En düşük geliştirici çabası ve ek yükünü içeren üç özel zorluğun giderilmesine yardımcı olur. Bu zorluklar şunlardır:

• Çok sayıda çalışma alanına ölçeklendirme.
• REST API çağrılarının performansını iyileştirme.
• Anlamsal modelleri ve veri kaynağı kimlik bilgilerini müşteri kiracısı düzeyinde yalıtma.

Hizmet sorumlusu profillerini kullanarak çok kiracılı bir uygulama tasarlarken, ilişkili zayıflıklarından kaçınırken üç tasarım stratejisinin (önceki bölümde açıklanan) güçlü yönlerinden yararlanabilirsiniz.

Hizmet sorumlusu profilleri, Power BI bağlamında oluşturulan yerel hesaplardır. Hizmet sorumlusu, yeni hizmet sorumlusu profilleri oluşturmak için REST API işlemini kullanabilir Profiles . Bir hizmet sorumlusu, aşağıdaki diyagramda gösterildiği gibi özel bir uygulama için kendi hizmet sorumlusu profilleri kümesini oluşturabilir ve yönetebilir.

Hizmet sorumlusu ile oluşturduğu hizmet sorumlusu profilleri arasında her zaman bir üst-alt ilişki vardır. Tek başına varlık olarak hizmet sorumlusu profili oluşturamazsınız. Bunun yerine, belirli bir hizmet sorumlusunu kullanarak bir hizmet sorumlusu profili oluşturursunuz ve bu hizmet sorumlusu profilin üst öğesi olarak görev alır. Ayrıca, bir hizmet sorumlusu profili hiçbir zaman kullanıcı hesaplarına veya diğer hizmet sorumlularına görünmez. Hizmet sorumlusu profili yalnızca onu oluşturan hizmet sorumlusu tarafından görülebilir ve kullanılabilir.

Hizmet sorumlusu profilleri Microsoft Entra tarafından bilinmiyor

Hizmet sorumlusunun kendisi ve temel alınan Microsoft Entra uygulama kaydı Microsoft Entra tarafından bilinse de, Microsoft Entra Kimliği hizmet sorumlusu profilleri hakkında hiçbir şey bilmez. Bunun nedeni, hizmet sorumlusu profillerinin Power BI tarafından oluşturulması ve yalnızca Power BI güvenlik ve yetkilendirmesini denetleen Power BI hizmeti alt sisteminde bulunmasıdır.

Hizmet sorumlusu profillerinin Microsoft Entra ID tarafından bilinmemesinin hem avantajları hem de dezavantajları vardır. Birincil avantajı, müşteri senaryonuz için ekleme uygulamasının hizmet sorumlusu profilleri oluşturmak için özel Microsoft Entra izinlerine ihtiyaç duymamasıdır. Ayrıca uygulamanın Microsoft Entra'dan ayrı bir yerel kimlik kümesi oluşturabileceği ve yönetebileceği anlamına gelir.

Ancak dezavantajları da vardır. Hizmet sorumlusu profilleri Microsoft Entra tarafından bilinmediğinden, çalışma alanına örtülü olarak erişim vermek için Bir Microsoft Entra grubuna hizmet sorumlusu profili ekleyemezsiniz. Ayrıca Azure SQL Veritabanı veya Azure Synapse Analytics gibi dış veri kaynakları, veritabanına bağlanırken hizmet sorumlusu profillerini kimlik olarak tanıyamaz. Bu nedenle, her müşteri kiracısı için benzersiz kimlik doğrulaması kimlik bilgilerine sahip ayrı bir hizmet sorumlusu kullanarak bu veri kaynaklarına bağlanma gereksinimi olduğunda, çalışma alanı başına bir hizmet sorumlusu tasarım stratejisi (her müşteri kiracısı için hizmet sorumlusu oluşturma) daha iyi bir seçim olabilir.

Hizmet sorumlusu profilleri birinci sınıf güvenlik sorumlularıdır

Hizmet sorumlusu profilleri Microsoft Entra tarafından bilinmese de Power BI bunları birinci sınıf güvenlik sorumluları olarak tanır. Bir kullanıcı hesabı veya hizmet sorumlusu gibi, bir çalışma alanı rolüne (Yönetici veya Üye olarak) hizmet sorumlusu profilleri ekleyebilirsiniz. Ayrıca bunu anlamsal model sahibi ve veri kaynağı kimlik bilgilerinin sahibi yapabilirsiniz. Bu nedenlerden dolayı, her yeni müşteri kiracısı için yeni bir hizmet sorumlusu profili oluşturmak en iyi yöntemdir.

REST API çağrılarını hizmet sorumlusu profili olarak yürütme

Uygulamanız bir hizmet sorumlusu profilinin kimliğini kullanarak REST API çağrıları yürütebilir. Bu, yeni bir müşteri kiracısı sağlamak ve ayarlamak için bir dizi REST API çağrısı yürütebileceği anlamına gelir.

1. Hizmet sorumlusu profili yeni bir çalışma alanı oluşturduğunda Power BI bu profili otomatik olarak çalışma alanı yöneticisi olarak ekler.
2. Hizmet sorumlusu profili anlamsal model oluşturmak için bir Power BI Desktop dosyasını içeri aktardığında, Power BI bu profili anlam modeli sahibi olarak ayarlar.
3. Bir hizmet sorumlusu profili veri kaynağı kimlik bilgilerini ayarlarken, Power BI bu profili veri kaynağı kimlik bilgilerinin sahibi olarak ayarlar.

Bir hizmet sorumlusunun Power BI'da profillerinin kimliklerinden ayrı ve ayrı bir kimliğe sahip olduğunu anlamak önemlidir. Bu size geliştirici olarak seçim sağlar. Hizmet sorumlusu profilinin kimliğini kullanarak REST API çağrılarını yürütebilirsiniz. Alternatif olarak, üst hizmet sorumlusunun kimliğini kullanan bir profil olmadan REST API çağrılarını yürütebilirsiniz.

Hizmet sorumlusu profilleri oluştururken, görüntülerken veya silerken üst hizmet sorumlusu olarak REST API çağrılarını yürütmenizi öneririz. Diğer tüm REST API çağrılarını yürütmek için hizmet sorumlusu profilini kullanmanız gerekir. Bu diğer çağrılar çalışma alanları oluşturabilir, Power BI Desktop dosyalarını içeri aktarabilir, anlam modeli parametrelerini güncelleştirebilir ve veri kaynağı kimlik bilgilerini ayarlayabilir. Ayrıca çalışma alanı öğesi meta verilerini alabilir ve ekleme belirteçleri oluşturabilirler.

Contoso adlı bir müşteri için müşteri kiracısı ayarlamanız gereken bir örneği düşünün. İlk adım, görünen adı Contoso olarak ayarlanmış bir hizmet sorumlusu profili oluşturmak için bir REST API çağrısı yapar. Bu çağrı, hizmet sorumlusunun kimliği kullanılarak yapılır. Kalan tüm kurulum adımları, aşağıdaki görevleri tamamlamak için hizmet sorumlusu profilini kullanır:

1. Çalışma alanı oluşturun.
2. Çalışma alanını bir kapasiteyle ilişkilendirin.
3. Power BI Desktop dosyasını içeri aktarın.
4. Anlam modeli parametrelerini ayarlayın.
5. Veri kaynağı kimlik bilgilerini ayarlayın.
6. Zamanlanmış veri yenilemeyi ayarlayın.

Çalışma alanına ve içeriğine erişimin, müşteri kiracısını oluşturmak için kullanılan hizmet sorumlusu profilinin kimliği kullanılarak yapılması gerektiğini anlamak önemlidir. Üst hizmet sorumlusunun çalışma alanına veya içeriğine erişmesine gerek olmadığını anlamak da önemlidir.

Profiller REST API işlemlerini kullanma

Profiller REST API işlem grubu, hizmet sorumlusu profillerini oluşturan ve yöneten işlemlerden oluşur:

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

Hizmet sorumlusu profili oluşturma

Hizmet sorumlusu profili oluşturmak için Profil Oluştur REST API'sini kullanın. Yeni kiracı için displayName bir görünen ad sağlamak için istek gövdesinde özelliğini ayarlamanız gerekir. Değer, hizmet sorumlusunun sahip olduğu tüm profillerde benzersiz olmalıdır. Hizmet sorumlusu için bu görünen ada sahip başka bir profil zaten varsa çağrı başarısız olur.

Başarılı bir çağrı, profili temsil eden bir GUID olan özelliğini döndürür id . Hizmet sorumlusu profillerini kullanan uygulamalar geliştirirken, profil görünen adlarını ve kimlik değerlerini özel bir veritabanında depolamanızı öneririz. Bu şekilde, uygulamanızın kimlikleri alması kolaydır.

Power BI .NET SDK'sı ile programlama kullanıyorsanız, yeni profili temsil eden bir ServicePrincipalProfile nesne döndüren yöntemini kullanabilirsinizProfiles.CreateProfile. Özellik değerini belirlemeyi id kolaylaştırır.

Aşağıda bir hizmet sorumlusu profili oluşturma ve çalışma alanı erişimi verme örneği verilmiştir.

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

Power BI hizmeti çalışma alanı Erişim bölmesinde, güvenlik sorumluları dahil olmak üzere hangi kimliklerin erişime sahip olduğunu belirleyebilirsiniz.

Hizmet sorumlusu profilini silme

Hizmet sorumlusu profilini silmek için Profili Sil REST API'sini kullanın. Bu işlem yalnızca üst hizmet sorumlusu tarafından çağrılabilir.

Power BI .NET SDK'sı ile programlamak istiyorsanız yöntemini kullanabilirsiniz Profiles.DeleteProfile .

Tüm hizmet sorumlusu profillerini alma

Çağrı yapan hizmet sorumlusuna ait hizmet sorumlusu profillerinin listesini almak için Profilleri Al REST API işlemini kullanın. Bu işlem, her hizmet sorumlusu profilinin id ve displayName özelliklerini içeren bir JSON yükü döndürür.

Power BI .NET SDK'sı ile programlamak istiyorsanız Profiles.GetProfiles yöntemini kullanabilirsiniz.

Hizmet sorumlusu profili kullanarak REST API çağrılarını yürütme

Hizmet sorumlusu profili kullanarak REST API çağrıları yapmak için iki gereksinim vardır:

• Yetkilendirme üst bilgisinde üst hizmet sorumlusu için erişim belirtecini geçirmeniz gerekir.
• Hizmet sorumlusu profilinin kimliğinin değerini içeren X-PowerBI-profile-id adlı bir üst bilgi eklemeniz gerekir.

Power BI .NET SDK'sını kullanıyorsanız, hizmet sorumlusu profilinin kimliğini geçirerek X-PowerBI-profile-id üst bilgi değerini açıkça ayarlayabilirsiniz.

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

Yukarıdaki örnekte gösterildiği gibi, nesneye X-PowerBI-profile-id üst bilgisini PowerBIClient eklediğinizde, gibi Groups.GetGroupsyöntemleri çağırmak kolaydır, bu nedenle hizmet sorumlusu profili kullanılarak yürütülürler.

Bir nesne için X-PowerBI-profile-id üst bilgisini ayarlamanın daha kullanışlı bir PowerBIClient yolu vardır. Profilin kimliğini oluşturucuya geçirerek nesneyi başlatabilirsiniz.

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

Çok kiracılı bir uygulamayı programlarken, çağrıları üst hizmet sorumlusu olarak yürütme ve çağrıları hizmet sorumlusu profili olarak yürütme arasında geçiş yapmanız gerekebilir. Bağlam değiştirmeyi yönetmek için kullanışlı bir yaklaşım, nesnesini depolayan PowerBIClient sınıf düzeyinde bir değişken bildirmektir. Ardından değişkeni doğru nesneyle ayarlayan bir yardımcı yöntem oluşturabilirsiniz.

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

Bir hizmet sorumlusu profili oluşturmanız veya yönetmeniz gerektiğinde, herhangi bir parametre olmadan yöntemini çağırabilirsiniz SetCallingContext . Bu şekilde, hizmet sorumlusunun kimliğini kullanarak profil oluşturabilir ve yönetebilirsiniz.

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

Yeni bir müşteri kiracısı için çalışma alanı oluşturmanız ve ayarlamanız gerektiğinde, bu kodu hizmet sorumlusu profili olarak yürütmek istersiniz. Bu nedenle, profilin SetCallingContext kimliğini geçirerek yöntemini çağırmalısınız. Bu şekilde, hizmet sorumlusu profilinin kimliğini kullanarak çalışma alanını oluşturabilirsiniz.

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

Çalışma alanı oluşturmak ve yapılandırmak için belirli bir hizmet sorumlusu profilini kullandıktan sonra, çalışma alanı içeriğini oluşturmak ve ayarlamak için aynı profili kullanmaya devam etmelisiniz. Kurulumu tamamlamak için yöntemini çağırmanız SetCallingContext gerekmez.

Geliştirici örneği

AppOwnsDataMultiTenant adlı örnek bir uygulamayı indirmenizi öneririz.

Bu örnek uygulama .NET 6 ve ASP.NET kullanılarak geliştirilmiştir ve bu makalede açıklanan kılavuz ve önerilerin nasıl uygulanacağını gösterir. Hizmet sorumlusu profillerini kullanarak Müşteriniz için ekleme senaryosunu uygulayan çok kiracılı bir uygulama geliştirmeyi öğrenmek için kodu gözden geçirebilirsiniz.

İlgili içerik

Bu makale hakkında daha fazla bilgi için aşağıdaki kaynaklara göz atın:

• Power BI Embedded'de çok kiracılı uygulamalar için hizmet sorumlusu profilleri
• Çok müşterili uygulamaları hizmet sorumlusu profilleri modeline geçirme
• Profiller Power BI REST API işlem grubu
• • AppOwnsDataMultiTenant örnek uygulaması
• Sorularınız var mı? Power BI Topluluğu sormayı deneyin
• Öneri? Power BI'ı geliştirmek için fikirlere katkıda bulunma