Power BI Embedded: Uygulamanıza Analitik Ekleme

Her SaaS uygulamasının eninde sonunda analitiklere ihtiyacı vardır. Kullanıcılar, kullanım modellerini, performans ölçümlerini ve iş sonuçlarını gösteren kontrol panelleri ister. Sıfırdan özel bir analiz katmanı oluşturmak (grafik kitaplıkları, veri hatları, önbelleğe alma, dışa aktarma işlevleri, detaya inme etkileşimleri) 6-12 aylık mühendislik çalışması ve sürekli bakım gerektirir. Power BI Embedded bir alternatif sunar: Microsoft'un altyapısı tarafından desteklenen, doğrudan uygulamanıza yerleştirilmiş kurumsal düzeyde analiz özellikleri.

Power BI Embedded yalnızca "bir sayfaya iframe yerleştirmek" değildir. Kendi uygulamanızın kullanıcı arayüzünde etkileşimli, güvenli, çok kiracılı analiz deneyimleri sunmaya yönelik eksiksiz bir platformdur. Siz Power BI'ın gelişmiş görselleştirme motorundan, DAX hesaplama katmanından ve veri bağlantısı altyapısından yararlanırken, müşterileriniz ürününüze özgü görünen ve hissettiren analizlerle etkileşime girer.

Bu kılavuz, Power BI'ı uygulamanıza yerleştirmeye yönelik mimariyi, kimlik doğrulama modellerini, çok kiracılı güvenliği, kapasite planlamayı, SDK entegrasyonunu ve fiyatlandırma hususlarını kapsar. Yerleşik bir analiz uygulaması planlıyorsanız mimari rehberliği ve geliştirme desteği için Power BI yerleşik analiz hizmetlerimizi keşfedin.

Önemli Çıkarımlar

• Power BI Embedded iki senaryoyu destekler: "müşterileriniz için yerleştirme" (uygulama, verilere sahiptir) ve "kuruluşunuz için yerleştirme" (kullanıcı, verilere sahiptir)
• Çok kiracılı SaaS uygulamaları için hizmet sorumlusu kimlik doğrulaması önerilir; ana kullanıcı hesapları daha basittir ancak tek hata noktaları oluşturur
• Satır düzeyinde güvenlik (RLS), paylaşılan veri kümelerinde kiracı verilerinin izolasyonunu sağlamaya yönelik birincil mekanizmadır
• Fabric F SKU'ları, geliştirme için F2'den başlayarak yerleşik senaryolar için en uygun maliyetli kapasiteyi sağlar
• JavaScript SDK, derinlemesine programatik kontrol sağlar: filtre uygulama, olayları yakalama, gezinmeyi kontrol etme ve temaları özelleştirme
• Kapasite boyutu yalnızca toplam kullanıcı sayısına değil, eşzamanlı kullanıcılara, sorgu karmaşıklığına ve veri hacmine bağlıdır
• Özel temalar ve gizli krom, yerleşik raporların uygulamanıza özgü olmasını sağlar

---

Senaryoları Yerleştirme: Müşteriler ve Organizasyon

Müşterileriniz için Yerleştirin (Uygulamanın Verileri Vardır)

"Verilerin sahibi uygulama" senaryosu, SaaS uygulamalarının birincil kullanım durumudur. Uygulamanız bir hizmet sorumlusu veya ana kullanıcı hesabı kullanarak Power BI ile kimlik doğrular, bir ekleme belirteci oluşturur ve katıştırılmış raporu son kullanıcılarınıza sunar. Müşterileriniz Power BI ile hiçbir zaman doğrudan etkileşime girmez ve Power BI lisanslarına ihtiyaç duymazlar.

Mimari akışı:

1. Müşteriniz, kimlik doğrulama sisteminizi kullanarak uygulamanızda oturum açar.
2. Uygulama arka ucunuz, söz konusu müşteriye yönelik belirli rapora, veri kümesine ve RLS rolüne göre belirlenen bir ekleme belirteci oluşturmak için Power BI REST API'yi çağırır.
3. Arka uç, yerleştirme belirtecini ve yerleştirme URL'sini ön uca döndürür.
4. Ön uç, Power BI JavaScript SDK'sını yerleştirme belirteciyle başlatır ve raporu belirlenmiş bir kapsayıcı öğesinde işler.
5. Yerleştirme belirtecinin süresi, yapılandırılabilir bir sürenin (varsayılan 1 saat) ardından sona erer ve uygulamanız onu şeffaf bir şekilde yeniler.

Temel özellikler:

• Müşterilerin Power BI Pro veya Kullanıcı Başına Premium lisanslarına ihtiyacı yoktur
• Tüm kapasite maliyetleri Yapı/Yerleşik SKU'lar aracılığıyla tarafınızca (uygulama sağlayıcı) karşılanır
• Kullanıcıların RLS ve programatik filtreleme aracılığıyla gördükleri üzerinde tam kontrole sahip olursunuz
• Kimlik doğrulama tamamen uygulamanızın kimlik doğrulama sistemi dahilindedir
• Gömülü belirteçler, belirli yapılara kapsamlı, zaman sınırlı erişim sağlar

Bu, analiz tüketicisinin Power BI'ın temel teknoloji olduğunu bilmemesi veya umursamaması gereken ISV'ler, SaaS platformları ve dahili portallar tarafından kullanılan modeldir.

Kuruluşunuza Yerleştirin (Veriler Kullanıcıya Aittir)

"Verilerin sahibi kullanıcı" senaryosu, Power BI içeriğini kullanıcıların zaten Power BI lisanslarına (Pro veya PPU) sahip olduğu dahili uygulamalara eklemek içindir. Katıştırılmış deneyim kullanıcının kendi Power BI kimliğini ve izinlerini kullanır.

Mimari akışı:

1. Kullanıcı, uygulamanız aracılığıyla Azure AD ile kimlik doğrulaması yapar.
2. Uygulamanız, OAuth 2.0 akışını kullanarak kullanıcı adına bir erişim belirteci alır.
3. Uygulama, yerleştirme yapılandırmasını almak için kullanıcının belirteciyle Power BI REST API'yi çağırır.
4. Rapor, kullanıcının tam Power BI izinleriyle oluşturulur.

Temel özellikler:

• Her kullanıcının Power BI Pro veya Kullanıcı Başına Premium lisansına sahip olması gerekir
• Kullanıcılar içeriği kendi Power BI izinlerine ve RLS atamalarına göre görür
• Ek Yapı/Gömülü kapasite gerekmez (kullanıcının Pro/PPU lisans tahsisini kullanır)
• Uygulama geliştiricisi için daha az kontrol, kullanıcı için daha fazla özerklik
• Daha basit mimari ancak kullanıcı başına daha yüksek lisans maliyeti

Bu model genellikle intranet portalları, SharePoint entegrasyonları ve kullanıcıların zaten Power BI lisanslarına sahip olduğu ve mevcut erişim izinlerini koruması gereken dahili uygulamalar için kullanılır.

Senaryolar Arasında Seçim Yapmak

Harici müşterileri hedefleyen çoğu SaaS uygulaması için "uygulama verilere sahiptir" doğru seçimdir. Bu kılavuzun geri kalanı öncelikle bu senaryoya odaklanmaktadır.

---

Kimlik Doğrulama: Hizmet Sorumlusu ve Ana Kullanıcı Karşılaştırması

Hizmet Sorumlusu Kimlik Doğrulaması

Hizmet sorumlusu, Power BI'ın kaynaklara program aracılığıyla erişmek için güvendiği bir Azure AD uygulama kimliğidir. Üretime gömülü uygulamalar için önerilen kimlik doğrulama yöntemidir.

Kurulum gereksinimleri:

1. Bir uygulamayı Azure AD'ye kaydedin.
2. Uygulama için bir istemci sırrı veya sertifikası oluşturun.
3. Bir Azure AD güvenlik grubu oluşturun ve hizmet sorumlusunu buna ekleyin.
4. Power BI yönetici portalında Kiracı Ayarları > Geliştirici Ayarları altında güvenlik grubu için hizmet sorumlusu erişimini etkinleştirin.
5. Hizmet sorumlusuna, katıştırılmış içeriğinizi içeren belirli Power BI çalışma alanlarına erişim izni verin.

Avantajları:

• Belirli bir kullanıcı hesabına bağımlılık yok (tek hata noktasını ortadan kaldırır)
• İstemci sırları ve sertifikaları hizmet kesintisi olmadan döndürülebilir
• Hizmet sorumlularının kapsamı belirli çalışma alanlarına göre belirlenebilir (en az ayrıcalık)
• Azure tarafından barındırılan uygulamalarda Azure AD tarafından yönetilen kimliklerle çalışır
• Daha yüksek güvenlik için sertifika tabanlı kimlik doğrulamayı destekler

Sınırlamalar:

• "Çalışma Alanım"a erişilemiyor (kişisel çalışma alanları)
• Belirli yönetici API'leri çağrılamıyor
• Bazı gelişmiş özellikler için Azure AD Premium gerekir
• İlk kurulum, ana kullanıcıdan daha karmaşıktır

Ana Kullanıcı Kimlik Doğrulaması

Ana kullanıcı, uygulamanızın Power BI ile kimlik doğrulaması yapmak için kullandığı, Power BI Pro veya PPU lisansına sahip normal bir Azure AD kullanıcı hesabıdır. Uygulama, yerleştirme belirteçleri oluşturmak için bu kullanıcı olarak oturum açar.

Avantajları:

• Daha basit başlangıç kurulumu (kullanıcı oluşturma, lisans atama, çalışma alanına erişim izni verme)
• Yönetici API'leri dahil tüm Power BI özelliklerine erişebilir
• Azure AD uygulaması kaydı gerekmez

Dezavantajları:

• Tek hata noktası: Kullanıcı hesabı kilitlenirse, parolanın süresi dolarsa veya MFA tetiklenirse uygulamanız analitik erişimini kaybeder
• Etkileşimli oturum açmayı gerektiren koşullu erişim ilkeleri kullanılamaz
• Şifre rotasyonu uygulama güncellemelerini gerektirir
• Makine süreçleri için insan hesaplarının kullanılmamasına ilişkin en iyi güvenlik uygulamalarını ihlal ediyor
• Kullanıcı hesabının lisans maliyeti

Öneri: Tüm üretim dağıtımları için hizmet sorumlusu kimlik doğrulamasını kullanın. Ana kullanıcı hesapları, basitliğin güvenilirlikten daha önemli olduğu kavram kanıtlama ve geliştirme ortamları için kabul edilebilir.

Token Üretimi ve Yönetimi

Kimlik doğrulama yönteminden bağımsız olarak uygulamanız Power BI REST API aracılığıyla ekleme belirteçleri oluşturur. Belirteç, gömülü oturumun izinlerini kapsar.

Belirteç eklemeyle ilgili hususlar:

• Jeton ömrü: Varsayılan 1 saattir, 24 saate kadar yapılandırılabilir. Daha kısa ömürler daha güvenlidir ancak daha sık yenileme gerektirir.
• Belirteç kapsamı: Her belirtecin kapsamı belirli raporlara, veri kümelerine ve çalışma alanlarına göre belirlenir. Mümkün olan en dar kapsamı oluşturun.
• RLS kimliği: Satır düzeyinde güvenlik kullanıldığında, RLS kimliği (kullanıcı adı ve roller) belirtecin içine gömülür. Kiracı izolasyonunu bu şekilde sağlayabilirsiniz.
• Jeton yenileme: Kullanıcı arabiriminiz jetonun son kullanma tarihini izlemeli ve süresi dolmadan yeni bir jeton talep etmelidir. JavaScript SDK'sı bunun için etkinlikler sağlar.

Jeton oluşturma örnek akışı:

POST https://api.powerbi.com/v1.0/myorg/GenerateToken
{
    "datasets": [{"id": "dataset-guid"}],
    "reports": [{"id": "report-guid"}],
    "identities": [{
        "username": "[email protected]",
        "roles": ["TenantRole"],
        "datasets": ["dataset-guid"]
    }]
}

Yanıt, bir yerleştirme belirtecini ve süre sonu zaman damgasını içerir. Arka ucunuz bu belirteci önbelleğe alır (son kullanma tarihine göre) ve kimliği doğrulanmış ön uç isteklerine sunar.

---

Çok Kiracılı Satır Düzeyinde Güvenlik

RLS Gömülü Yazılımlar için Neden Kritiktir

Çok kiracılı bir SaaS uygulamasında birden çok müşterinin verileri genellikle aynı Power BI veri kümesinde bulunur. Satır düzeyinde güvenlik olmadan, yerleştirme belirteci veri kümesindeki tüm verilere erişim izni verir. RLS, temel veri kümesi paylaşılsa bile her müşterinin yalnızca kendi verilerini görmesini sağlar.

Çok kiracılı yerleşik senaryolar için RLS isteğe bağlı değildir. Kiracı izolasyonundaki başarısızlık bir veri ihlalidir. RLS'yi sonradan akla gelen bir düşünce olarak değil, temel bir güvenlik kontrolü olarak tasarlayın.

Statik RLS

Statik RLS, Power BI Desktop'ta DAX ifadelerini kullanarak sabit filtre kurallarını tanımlar. Her rolde hangi satırların görünebileceğini kısıtlayan bir dizi tablo filtresi bulunur.

Örnek:

Müşteriler tablosunda bu filtreye sahip bir "KiracıRolü":

[TenantId] = USERNAME()

Bir ekleme belirteci oluştururken uygulamanız USERNAME() değerini geçerli kiracının tanımlayıcısına ayarlar. DAX filtresi, tüm sorguları TenantId'nin eşleştiği satırlarla sınırlar.

Statik RLS, kiracının doğrudan izolasyonu için basit ve etkilidir. Aşağıdaki durumlarda iyi çalışır:

• Kiracı yalıtımı, ilişkiler aracılığıyla yayılan tek bir sütuna (TenantId) dayanır
• Tüm kiracılar yalnızca kendi verilerine göre filtrelenmiş aynı rapor yapısını görür
• RLS rollerinin sayısı küçük ve sabittir

Dinamik RLS

Dinamik RLS, kullanıcının kimliğine göre sorgu zamanında değerlendirme yapan DAX ifadelerini kullanır. Bu, her kiracı için ayrı roller oluşturmaya gerek kalmadan daha karmaşık güvenlik senaryolarına olanak tanır.

Ortak dinamik RLS modelleri:

USERPRINCIPALNAME() modeli:

[Email] = USERPRINCIPALNAME()

Ekleme belirteci, etkili kimliğin kullanıcı adını kullanıcının e-postasına ayarlar. Filtre, bir güvenlik eşleme tablosundaki E-posta sütunuyla eşleşir.

Güvenlik tablosu modeli: Kullanıcıları erişebilecekleri verilerle eşleştiren özel bir güvenlik tablosu oluşturun:

Bu güvenlik tablosunu birleştiren RLS filtrelerini ilişkiler aracılığıyla olgu tablolarınıza uygulayın. Bu kalıp, yalnızca kiracı düzeyinde yalıtımı değil, kiracı içindeki kullanıcı düzeyindeki izinleri de destekler.

RLS Testi ve Doğrulaması

Dağıtım öncesi testler:

1. Power BI Desktop'ta her RLS rolünü örnek kullanıcı adlarıyla test etmek için "Farklı Görüntüle"yi kullanın.
2. Tablolar arasındaki çapraz filtrelemenin RLS sınırlarına uygun olduğunu doğrulayın.
3. Uç durumları test edin: eşleşen satırı olmayan kullanıcılar (hataları değil boş raporları görmelidir), birden fazla role sahip kullanıcılar ve filtre sütunlarında boş değerler.
4. ALL() veya REMOVEFILTERS() kullanan DAX ölçümlerinin RLS'yi atlamadığını doğrulayın (bunu yapmamalı, ancak doğrulayın).

Üretim doğrulaması:

• Dağıtım hattınızın bir parçası olarak RLS testini otomatikleştirin
• Kiracı kimliklerini test etmek için yerleştirme belirteçleri oluşturun ve sorgu sonuçlarının beklenen verilerle eşleştiğini doğrulayın
• Kapasite ölçümlerinde RLS atlama girişimlerini izleyin (olağandışı sorgu modelleri, beklenmeyen veri hacimleri)
• RLS yapılandırmalarının üç aylık güvenlik incelemelerini gerçekleştirin

---

Kapasite Boyutlandırma ve Yapı SKU'ları

Kapasiteyi Anlamak

Power BI Embedded, özel kapasite gerektirir; yani yerleşik iş yükleriniz için ayrılmış bilgi işlem kaynakları. Kapasite, raporların oluşturulması, sorguların yürütülmesi ve veri kümelerinin yenilenmesi için mevcut işlem gücünü belirleyen Kapasite Birimleri (CU'lar) cinsinden ölçülür.

Kapasite kullanıcı başına değildir. Tüm gömülü oturumlarınızın yararlandığı paylaşılan bir bilgi işlem havuzudur. Bu, fiyatlandırmanın toplam kullanıcı sayısına göre değil eşzamanlılık ve sorgu karmaşıklığına göre ölçeklendiği anlamına gelir.

Kumaş F SKU Seçenekleri

Microsoft Fabric F SKU'ları, Power BI Embedded kapasitesi için geçerli fiyatlandırma modelidir. Eski A SKU'larını daha esnek, duraklatma özelliğine sahip bir modelle değiştirdiler.

Önemli notlar:

• Eşzamanlı kullanıcılar toplam kullanıcı sayısı anlamına gelmez. Kullanıcıların aynı anda aktif olarak sorgulama yapması anlamına gelir. Tipik bir oran, toplam kullanıcıların %5-10'unun herhangi bir zamanda eşzamanlı olmasıdır.
• Bunlar yaklaşık kılavuz numaralarıdır. Gerçek kapasite büyük ölçüde sorgu karmaşıklığına, model boyutuna ve rapor başına görselleştirme sayısına bağlıdır.
• F SKU'ları kullanılmadığında duraklatılabilir (eski P SKU'larının aksine), bu da geliştirme ve sezonluk iş yükleri açısından değerlidir.
• F64 ve üzeri, hiçbir ek lisans maliyeti olmaksızın Power BI Premium özelliklerini (sayfalara ayrılmış raporlar, yapay zeka, dağıtım ardışık düzenleri) içerir.

Kapasite Boyutlandırma Metodolojisi

1. Adım: Eşzamanlı kullanıcıları tahmin edin.

Eşzamanlı kullanıcılar = Toplam kullanıcılar x En yüksek eşzamanlılık oranı

Mesai saatlerinde erişilen SaaS analiz kontrol panelleri için: %5-10 eşzamanlılık oranı. Gün boyunca sık sık kontrol edilen operasyonel gösterge tabloları için: %15-25 eşzamanlılık oranı. Olay odaklı kontrol panelleri için (gerçek zamanlı izleme, uyarılar): %30-50 eşzamanlılık oranı.

2. Adım: Sorgu karmaşıklığını değerlendirin.

Basit raporlar (5-10 görsel, temel toplamalar, tek olgu tablosu): 1x temel. Orta düzey raporlar (10-20 görsel, zamanlı bilgi, çoklu olgu tabloları): 2-3x temel. Karmaşık raporlar (20'den fazla görsel, karmaşık DAX, büyük veri kümeleri, çapraz kaynak sorguları): 4-6x temel.

3. Adım: Gerekli kapasiteyi hesaplayın.

Yukarıdaki tablodaki eşzamanlı kullanıcı tahmininizle eşleşen SKU ile başlayın. Karmaşıklık faktörünüzle çarpın. Sonuç, SKU'nun eşzamanlı sorgu kapasitesini aşarsa sonraki katmana geçin.

4. Adım: Yük testiyle doğrulayın.

Teorik boyutlandırma bir başlangıç ​​noktasıdır. Üretim lansmanından önce gerçekçi veri hacimleri, sorgu modelleri ve eşzamanlılık düzeyleriyle yük testi yapın. Microsoft, bu amaç için bir Power BI Embedded kapasite yük testi aracı sağlar.

5. Adım: Büyümeyi planlayın.

Önümüzdeki 6-12 aydaki büyümeyi karşılamak için mevcut zirvenizin üzerine %30-50 oranında boşluk ekleyin. F SKU'lar kesinti olmadan yükseltilebilir, böylece artımlı olarak doğru boyutlandırabilirsiniz.

Maliyet Optimizasyon Stratejileri

• Çalışma saatleri dışında geliştirme kapasitelerini duraklatın. F SKU'lar etkin durumdayken saniye başına faturalandırılır, duraklatıldığında ücretsizdir. Azure Otomasyonu veya Logic Apps ile duraklatma/devam ettirme işlemlerini otomatikleştirmek, geliştirme maliyetlerini %60-70 oranında azaltabilir.

• Kapasiteyi ölçeklendirmeden önce modelleri optimize edin. F8'de iyi optimize edilmiş bir model genellikle F32'de kötü optimize edilmiş bir modelden daha iyi performans gösterir. Performans sorunlarını hesaplamaya atmadan önce model optimizasyonuna yatırım yapın.

• Büyük veri kümeleri için toplama tablolarını kullanın. Verilerin ortak ayrıntı düzeylerinde (günlük, haftalık, aylık) önceden toplanması, özet düzeyindeki görseller için sorgu işlemeyi %80-90 azaltırken ayrıntıya yönelik ayrıntılı inceleme yeteneğini korur.

• Power BI REST API aracılığıyla rapor düzeyinde önbelleğe alma uygulayın. Sık veri güncellemelerine sahip kontrol panelleri için önbelleğe alınan sonuçlar, kullanıcı oturumu başına kapasite tüketimini azaltır.

• Farklı iş yükleri için ayrı kapasiteleri göz önünde bulundurun. Yenileme işlemlerini etkileşimli sorgulardan yalıtmak, yenileme ani artışlarının kullanıcı deneyimini olumsuz etkilemesini önler. Bu, özellikle iş saatleri içinde yenilenen büyük veri kümeleriniz varsa önemlidir.

---

JavaScript SDK Entegrasyonu

Temel Yerleştirme

Power BI JavaScript SDK'sı (powerbi-client), Power BI içeriğini web uygulamanıza eklemek ve denetlemek için programlı arabirim sağlar.

Kurulum:

npm install powerbi-client

Temel yerleştirme akışı:

import * as pbi from 'powerbi-client';

const powerbi = new pbi.service.Service(
    pbi.factories.hpmFactory,
    pbi.factories.wpmpFactory,
    pbi.factories.routerFactory
);

const embedConfig = {
    type: 'report',
    id: reportId,
    embedUrl: embedUrl,
    accessToken: embedToken,
    tokenType: pbi.models.TokenType.Embed,
    settings: {
        panes: {
            filters: { visible: false },
            pageNavigation: { visible: true }
        },
        background: pbi.models.BackgroundType.Transparent,
        layoutType: pbi.models.LayoutType.Custom,
        customLayout: {
            displayOption: pbi.models.DisplayOption.FitToWidth
        }
    }
};

const reportContainer = document.getElementById('report-container');
const report = powerbi.embed(reportContainer, embedConfig);

Programatik Kontrol

SDK, gömülü rapor üzerinde kapsamlı programatik kontrol sağlar:

Filtre uygulama:

const filter = {
    $schema: "http://powerbi.com/product/schema#basic",
    target: {
        table: "Sales",
        column: "Region"
    },
    operator: "In",
    values: ["North", "South"],
    filterType: pbi.models.FilterType.BasicFilter
};

await report.setFilters([filter]);

Olayları yakalama:

report.on('loaded', function() {
    console.log('Report loaded successfully');
});

report.on('dataSelected', function(event) {
    const data = event.detail;
    // Handle user selection — navigate to detail page, update other UI, etc.
});

report.on('pageChanged', function(event) {
    const pageName = event.detail.newPage.displayName;
    // Track page navigation in your analytics
});

Jeton yenileme:

report.on('tokenExpired', async function() {
    const newToken = await fetchNewEmbedToken();
    await report.setAccessToken(newToken);
});

Navigasyon kontrolü:

// Navigate to a specific page
const pages = await report.getPages();
const targetPage = pages.find(p => p.displayName === 'Revenue Analysis');
await targetPage.setActive();

// Set a specific slicer value
const visuals = await targetPage.getVisuals();
const slicer = visuals.find(v => v.type === 'slicer');
await slicer.setSlicerState({
    filters: [{
        $schema: "http://powerbi.com/product/schema#basic",
        target: { table: "Date", column: "Year" },
        operator: "In",
        values: [2026],
        filterType: pbi.models.FilterType.BasicFilter
    }]
});

Performans için Aşamalı Oluşturma

Çok sayıda görsel içeren karmaşık raporlarda, aşamalı oluşturma, ekranın üst kısmındaki içeriği ilk önce oluşturarak algılanan performansı artırır:

const embedConfig = {
    // ... standard config
    settings: {
        // ... other settings
        commands: [{
            visualRendered: {
                phase: 1,
                visualNames: ['revenue-kpi', 'trend-chart', 'summary-table']
            }
        }]
    }
};

report.on('visualRendered', function(event) {
    if (event.detail.phase === 1) {
        // Hide loading spinner, show report
        document.getElementById('loading').style.display = 'none';
    }
});

---

Özel Temalar ve Markalama

Özel Temalar Neden Önemlidir

Varsayılan Power BI görselleri Microsoft'un renk paletini ve stilini kullanır. Gömülü bir bağlamda bu, uygulamanızla görsel tutarsızlık yaratır. Özel temalar, yerleşik analitiği ürününüzün tasarım sistemiyle uyumlu hale getirerek deneyimin sabitlenmiş olmaktan ziyade yerel olmasını sağlar.

Tema JSON Yapısı

Power BI temaları; renkler, yazı tipleri, görsel varsayılanlar ve öğe stili üzerinde denetime sahip JSON dosyaları olarak tanımlanır:

{
    "name": "MyApp Theme",
    "dataColors": [
        "#2563EB", "#7C3AED", "#059669", "#D97706",
        "#DC2626", "#0891B2", "#4F46E5", "#65A30D"
    ],
    "background": "#FFFFFF",
    "foreground": "#1E293B",
    "tableAccent": "#2563EB",
    "textClasses": {
        "callout": {
            "fontSize": 28,
            "fontFace": "Inter, sans-serif",
            "color": "#0F172A"
        },
        "title": {
            "fontSize": 14,
            "fontFace": "Inter, sans-serif",
            "color": "#1E293B"
        },
        "header": {
            "fontSize": 12,
            "fontFace": "Inter, sans-serif",
            "color": "#475569"
        },
        "label": {
            "fontSize": 11,
            "fontFace": "Inter, sans-serif",
            "color": "#64748B"
        }
    },
    "visualStyles": {
        "*": {
            "*": {
                "border": [{
                    "color": {"solid": {"color": "#E2E8F0"}},
                    "radius": 8
                }],
                "background": [{
                    "color": {"solid": {"color": "#FFFFFF"}},
                    "transparency": 0
                }]
            }
        }
    }
}

Temaları Program Aracılığıyla Uygulama

Temalar yerleştirme sırasında uygulanabilir veya dinamik olarak değiştirilebilir (karanlık mod desteği için kullanışlıdır):

// Apply theme at embed time
const embedConfig = {
    // ... standard config
    theme: { themeJson: customThemeJson }
};

// Switch theme dynamically (e.g., light/dark mode toggle)
await report.applyTheme({ themeJson: darkThemeJson });

Power BI Chrome'u Gizleme

Tamamen yerel bir görünüm için Power BI'ın yerleşik kullanıcı arayüzü öğelerini gizleyin ve bunları kendi uygulama kontrollerinizle değiştirin:

const settings = {
    panes: {
        filters: { visible: false },      // Hide filter pane
        pageNavigation: { visible: false } // Hide page tabs
    },
    bars: {
        actionBar: { visible: false },     // Hide action bar
        statusBar: { visible: false }      // Hide status bar
    },
    background: pbi.models.BackgroundType.Transparent,
    visualRenderedEvents: true
};

Daha sonra uygulamanızın kullanıcı arayüzü çerçevesinde özel gezinme, filtreleme ve dışa aktarma kontrolleri oluşturun. Kullanıcılar özel kontrollerinizle etkileşimde bulunduğunda filtreleri programlı bir şekilde uygulamak, sayfaları değiştirmek ve dışa aktarmaları tetiklemek için JavaScript SDK'yı kullanın.

Bu yaklaşım daha fazla geliştirme çabası gerektirir ancak kullanıcıların uygulamanızın yerel özellikleri ile yerleşik Power BI içeriğini ayırt edemediği kusursuz bir deneyim üretir.

---

Gömülü için Performans Optimizasyonu

Ön Uç Performansı

• SDK'yı geç yükleme. Power BI JavaScript SDK'sı yaklaşık 300 KB'tır. Eşzamansız olarak ve yalnızca kullanıcı bir analiz sayfasına gittiğinde yükleyin.
• Yerleştirme belirteçlerini önceden yükleyin. Kullanıcı raporu talep etmeden önce yerleştirme belirteçleri oluşturun. Uygulamanız kullanıcının analitiği (gezinme modellerine göre) görüntüleyeceğini biliyorsa, sayfa geçişleri sırasında belirteci önceden yükleyin.
• Önyükleme yerleştirmeyi kullanın. SDK, yerleştirme belirteci kullanılabilir olmadan önce iframe'i başlatan bir önyükleme modelini destekler ve algılanan yükleme süresini 200-500 ms kadar azaltır.

// Bootstrap first (fast — creates iframe immediately)
const report = powerbi.bootstrap(container, { type: 'report' });

// Load later when token is available
const embedConfig = { /* full config */ };
report.load(embedConfig);

• Raporu önbelleğe almayı uygulayın. Bir rapor yüklendikten sonra iframe onu bellekte tutar. Kullanıcı uzaklaşıp geri dönerse yeniden yerleştirmek yerine mevcut iframe'i yeniden kullanın. Bu, aynı oturumdaki tekrar ziyaretlerin yükleme süresini tamamen ortadan kaldırır.

Arka Uç Performansı

• Yerleştirme belirteçlerini önbelleğe alın. Yerleştirme belirteçleri tüm kullanım süreleri boyunca geçerlidir (varsayılan 1 saat). Bunları Redis'te veya bellekte önbelleğe alın ve aynı rapor/kimlik kombinasyonuna yönelik isteklerde yeniden kullanın.
• Toplu belirteç oluşturma. Bir kullanıcının kontrol paneli birden fazla yerleşik rapor içeriyorsa, GenerateToken uç noktasının çoklu kaynak özelliğini kullanarak tüm yerleştirme belirteçlerini tek bir API çağrısında oluşturun.
• API hız sınırlarını izleyin. Power BI REST API'nin hizmet sorumlusu başına hız sınırları vardır. 429 yanıtı izleyin ve üstel geri çekilmeyi uygulayın. Yüksek ölçekli uygulamalar için yükü birden fazla hizmet sorumlusuna dağıtın.

Gömülü için Rapor Tasarımı

Gömülü tüketim için tasarlanan raporlar, görsel karmaşıklıktan ziyade performansa öncelik vermelidir:

• Görselleri sayfa başına 8-12 ile sınırlandırın (her görsel ayrı bir sorgu oluşturur)
• Mümkün olduğunda DirectQuery yerine İçe Aktarma modunu kullanın (10-100 kat daha hızlı)
• Verileri uygun ayrıntı düzeyinde önceden toplayın
• Açılış sayfalarında karmaşık DAX önlemlerinden kaçının (ayrıntıya geçiş ayrıntıları için bunları kaydedin)
• Dinamik hesaplamalar yerine önceden hesaplanmış görünümler için yer imlerini kullanın
• Rapor yükleme sürelerini yalnızca tek kullanıcı düzeyinde değil, beklenen eşzamanlılık düzeyinde test edin

ECOSIRE, yerleşik analitiği uygulayan kuruluşlar için ilk günden itibaren en iyi performansı sağlamak amacıyla mimari danışmanlık ve geliştirme hizmetleri sağlar.

---

Gömülü Sistemler için Güvenlik Konuları

Token Güvenliği

Ekleme belirteçleri Power BI içeriğine erişim sağlar. Bunlara hassas kimlik bilgileri olarak davranın:

• Hiçbir zaman istemci tarafı kaynak kodunda veya URL parametrelerinde yerleştirme belirteçlerini açığa çıkarmayın
• Sunucu tarafında belirteçler oluşturun ve bunları kimliği doğrulanmış API uç noktaları aracılığıyla teslim edin
• En kısa pratik belirteç ömrünü kullanın (çoğu uygulama için varsayılan 1 saat makuldür)
• Uzun ömürlü tokenler oluşturmak yerine token yenileme mantığını uygulayın
• Anormallikler (olağandışı hacim, beklenmeyen rapor kimlikleri) için belirteç oluşturma modellerini izleyin

Kiracı Yalıtım Doğrulaması

Çok kiracılı uygulamalar için kiracı yalıtımını sürekli olarak doğrulayın:

• Kiracı A için yerleştirme belirteçleri oluşturan ve Kiracı B'nin verilerinin erişilebilir olmadığını doğrulayan otomatik testler
• Kiracılar arası veri erişim girişimlerini tespit etmek için sorgu günlüğü
• Düzenli RLS yapılandırma denetimleri (RLS rolleri Power BI Desktop'ta değiştirilebilir ve yanlışlıkla zayıflatılabilir)
• RLS filtre hataları hakkında uyarı (yanlış yapılandırmaya işaret edebilir)

Ağ Güvenliği

• Azure AD Koşullu Erişimi kullanarak Power BI REST API erişimini bilinen IP aralıklarıyla kısıtlayın
• Şirket içi veri kaynaklarına ağ geçidi bağlantıları için özel uç noktaları kullanın
• Tüm API çağrılarını izlemek ve belirteç oluşturmayı eklemek için Power BI yönetici portalında denetim günlüğünü etkinleştirin
• Uygulamanızın etki alanına iframe yerleştirmeyi kısıtlamak için İçerik Güvenliği Politikası başlıklarını uygulayın

---

SSS

10.000 kullanıcıya sahip bir SaaS uygulamasının Power BI Embedded'in maliyeti ne kadardır?

Maliyet, toplam kullanıcıya değil, eşzamanlı kullanıcılara bağlıdır. 10.000 kullanıcınızın %5'i en üst düzeyde eşzamanlıysa (500 eşzamanlı kullanıcı), yaklaşık olarak ayda 8.200 ABD doları tutarında (kullandıkça öde) F32 kapasitesine ihtiyacınız olacaktır. Rezervasyonla (1 yıllık taahhüt) bu, ayda yaklaşık 5.500 ABD dolarına düşer. Raporun karmaşıklığına, veri kümesi boyutuna ve kullanım modellerine bağlı olarak gerçek maliyetiniz daha yüksek veya daha düşük olabilir. Pilot uygulama için F8 ile başlayın, gerçekçi eşzamanlılıkla test yapın ve gerçek ölçümlere göre ölçeklendirin.

Power BI Embedded'i Azure olmadan kullanabilir miyim?

Power BI Embedded, kimlik doğrulama için Azure AD'yi ve Azure aracılığıyla sağlanan Yapı/Gömülü kapasiteyi gerektirir. Uygulamanızın kendisi herhangi bir yerde (AWS, GCP, şirket içi) barındırılabilir ancak Power BI kaynaklarının Azure'da olması gerekir. Hizmet sorumlusu veya ana kullanıcı hesabının Azure AD'de olması ve kapasitenin bir Azure kaynağı olması gerekir. Mevcut Azure ayak izi olmayan kuruluşlar için kurulum, kapasitenin ötesinde yaklaşık 2-4 saatlik Azure yapılandırma çalışması ve minimum devam eden Azure yönetimi ekler.

Power BI Embedded A SKU'ları, EM SKU'ları ve Fabric F SKU'ları arasındaki fark nedir?

SKU'lar, Azure aracılığıyla sağlanan orijinal Power BI Embedded kapasitesiydi. EM SKU'ları, Office 365'e dahili yerleştirme için bir lisanslama seçeneğiydi. Her ikisinin de yerini, tüm Power BI ve Fabric iş yükleri için birleşik bir kapasite modeli sağlayan Fabric F SKU'ları aldı. F SKU'ları saniye başına faturalandırma, duraklatma/devam ettirme özelliği ve daha basit bir fiyatlandırma yapısı sunar. Yeni uygulamalar için yalnızca F SKU'larını kullanın. Mevcut A SKU müşterileri, daha iyi fiyatlandırma ve özellikler için F SKU'larına geçişi planlamalıdır.

Kullanıcılar yerleşik raporlardan verileri dışa aktarabilir mi?

Evet, ancak bunu yerleştirme ayarları aracılığıyla kontrol edebilirsiniz. JavaScript SDK'sı, rapor başına dışa aktarma özelliklerini (Excel'e, PDF'ye, PowerPoint'e Aktarma) etkinleştirmenize veya devre dışı bırakmanıza olanak tanır. Ayrıca, format, uygulanan filtreler ve denetim günlüğü üzerinde daha fazla kontrol sahibi olmanızı sağlayan Dışa Aktarma API'si aracılığıyla özel dışa aktarma işlevini de uygulayabilirsiniz. Hassas veriler için yerleşik dışa aktarmayı devre dışı bırakın ve ek yetkilendirme kontrolleri ve filigran uygulayan kendi dışa aktarma mekanizmanızı sağlayın.

Gömülü bir senaryoda rapor geliştirmeyi nasıl halledebilirim?

Rapor geliştirme, standart Power BI iş akışını takip eder: Power BI Desktop'ta raporlar oluşturun, bir geliştirme çalışma alanında yayınlayın, örnek ekleme belirteçleriyle test edin, dağıtım işlem hatları aracılığıyla üretime yükseltin. Temel fark, yerleşik raporların RLS davranışı, eşzamanlılık altında performans, ekran boyutlarında duyarlı düzen ve uygulamanızın kullanıcı arayüzüyle etkileşimi için ek testlere ihtiyaç duymasıdır. Her rapor dağıtımının bir parçası olarak otomatik RLS doğrulamasını ve performans regresyon testini içeren bir CI/CD hattı oluşturun.