Profil perwakilan layanan untuk aplikasi multitenansi di Power BI Embedded

Artikel ini menjelaskan bagaimana ISV atau pemilik aplikasi Power BI Embedded lainnya dengan banyak pelanggan dapat menggunakan profil perwakilan layanan untuk memetakan dan mengelola data setiap pelanggan sebagai bagian dari penyematan Power BI mereka untuk solusi pelanggan Anda. Profil perwakilan layanan memungkinkan ISV untuk membangun aplikasi yang dapat diskalakan yang memungkinkan isolasi data pelanggan yang lebih baik dan menetapkan batas keamanan yang lebih ketat antara pelanggan. Artikel ini membahas keuntungan dan batasan solusi ini.

Profil perwakilan layanan adalah profil yang dibuat oleh perwakilan layanan. Aplikasi ISV memanggil API Power BI menggunakan profil perwakilan layanan, seperti yang dijelaskan dalam artikel ini.

Perwakilan layanan aplikasi ISV membuat profil Power BI yang berbeda untuk setiap pelanggan, atau penyewa. Saat pelanggan mengunjungi aplikasi ISV, aplikasi menggunakan profil yang sesuai untuk menghasilkan token semat yang akan digunakan untuk merender laporan di browser.

Menggunakan profil prinsipal layanan memungkinkan aplikasi ISV untuk menghosting beberapa pelanggan pada satu tenant Power BI. Setiap profil mewakili satu pelanggan dalam Power BI. Dengan kata lain, setiap profil membuat dan mengelola konten Power BI untuk satu data pelanggan tertentu.

Menyiapkan konten Power BI Anda melibatkan langkah-langkah berikut:

• Membuat profil
• Mengatur izin profil
• Membuat ruang kerja untuk setiap pelanggan
• Mengimpor laporan dan model semantik ke ruang kerja
• Atur rincian koneksi model semantik untuk menyambungkan ke data pelanggan
• Menghapus izin dari perwakilan layanan (opsional, tetapi membantu skalabilitas)
• Menyematkan laporan ke dalam aplikasi

Semua langkah di atas dapat sepenuhnya otomatis menggunakan REST API Power BI.

Prasyarat

Sebelum dapat membuat profil perwakilan layanan, Anda perlu:

• Menyiapkan prinsipal layanan dengan mengikuti tiga langkah pertama dari Sematkan konten Power BI dengan prinsipal layanan.
• Dari akun admin tenant Power BI, aktifkan pembuatan profil di tenant menggunakan grup keamanan yang sama yang Anda gunakan saat membuat prinsipal layanan.

Membuat profil

Profil dapat dibuat, diperbarui, dan dihapus menggunakan REST API Profil.

Misalnya, untuk membuat profil:

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"}

Perwakilan layanan juga dapat memanggil REST API Dapatkan Profil untuk mendapatkan daftar profilnya. Contohnya:

GET https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXA…UUPA

Hak Akses Profil

API apa pun yang memberikan izin kepada pengguna untuk item Power BI juga dapat memberikan izin profil untuk item Power BI. Misalnya, Tambahkan API Pengguna Grup dapat digunakan untuk memberikan izin profil ke ruang kerja.

Poin-poin berikut penting untuk dipahami saat menggunakan profil:

• Profil milik perwakilan layanan yang membuatnya, dan hanya dapat digunakan oleh perwakilan layanan tersebut.
• Pemilik profil tidak dapat diubah setelah pembuatan.
• Profil bukanlah identitas mandiri. Ini membutuhkan token Microsoft Entra perwakilan layanan untuk memanggil REST API Power BI.

Aplikasi ISV memanggil REST API Power BI dengan menyediakan token Microsoft Entra perwakilan layanan di header Otorisasi , dan ID profil di header X-PowerBI-Profile-Id . Contohnya:

  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

Membuat ruang kerja

Ruang kerja Power BI digunakan untuk menghosting item Power BI seperti laporan dan model semantik.

Setiap profil perlu:

• Membuat setidaknya satu ruang kerja Power BI

  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"
  }
  

• Berikan izin akses ke ruang kerja. Profil perwakilan layanan harus memiliki akses Admin ke ruang kerja.

• Menetapkan ruang kerja untuk kapasitas

  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"
  }
  

Baca selengkapnya tentang ruang kerja Power BI.

Mengimpor laporan dan model semantik

Gunakan Power BI Desktop untuk menyiapkan laporan yang tersambung ke data pelanggan atau data sampel. Kemudian, Anda dapat menggunakan API Impor untuk mengimpor konten ke ruang kerja yang dibuat.

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=

Gunakan parameter himpunan data untuk membuat model semantik yang dapat terhubung ke sumber data pelanggan yang berbeda. Kemudian, gunakan API Perbarui parameter untuk menentukan data pelanggan mana yang terhubung dengan model semantik.

Mengatur koneksi model semantik

ISV biasanya menyimpan data pelanggan mereka dengan salah satu dari dua cara:

• Database terpisah untuk setiap pelanggan
• Database multipenyewa tunggal

Dalam kedua kasus tersebut, Anda harus berakhir dengan model semantik penyewa tunggal (satu model semantik per pelanggan) di Power BI.

Database terpisah untuk setiap pelanggan

Jika aplikasi ISV memiliki database terpisah untuk setiap pelanggan, buat model semantik tenant tunggal di Power BI. Berikan setiap model semantik dengan detail koneksi yang menunjuk ke database yang cocok. Gunakan salah satu metode berikut untuk menghindari pembuatan beberapa laporan identik dengan detail koneksi yang berbeda:

• Parameter model semantik: Buat model semantik dengan parameter dalam detail koneksi (seperti nama server SQL, nama database SQL). Kemudian, impor laporan ke ruang kerja pelanggan dan ubah parameter agar sesuai dengan detail database pelanggan.

• Perbarui Datasource API: Buat .pbix yang menunjuk ke sumber data dengan konten sampel. Kemudian, impor .pbix ke ruang kerja pelanggan dan ubah detail koneksi menggunakan API Update Datasource.

Database multipenyewa tunggal

Jika aplikasi ISV menggunakan satu database untuk semua pelanggannya, pisahkan pelanggan ke dalam model semantik yang berbeda di Power BI sebagai berikut:

Buat laporan menggunakan parameter yang hanya mengambil data pelanggan yang relevan. Kemudian, impor laporan ke ruang kerja pelanggan dan ubah parameter untuk hanya mengambil data pelanggan yang relevan.

Menyematkan laporan

Setelah penyiapan selesai, Anda dapat menyematkan laporan pelanggan dan item lain ke dalam aplikasi Anda menggunakan token semat.

Saat pelanggan mengunjungi aplikasi Anda, gunakan profil yang sesuai untuk memanggil API GenerateToken. Gunakan token semat yang dihasilkan untuk menyematkan laporan atau item lain di browser pelanggan.

Untuk membuat token penyematan:

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"
    }
  ]
}

Aspek desain

Sebelum menyiapkan solusi multipenyewa berbasis profil, Anda harus mengetahui masalah berikut:

• Skalabilitas
• Otomatisasi & kompleksitas operasional
• Kebutuhan Multi-Geo
• Efisiensi biaya
• Keamanan tingkat baris

Skalabilitas

Dengan memisahkan data menjadi model semantik terpisah untuk setiap pelanggan, Anda meminimalkan kebutuhan akan model semantik besar. Ketika kapasitas kelebihan beban, sistem dapat menghapus model semantik yang tidak digunakan untuk membebaskan memori bagi model semantik aktif. Pengoptimalan ini tidak mungkin untuk satu model semantik besar. Dengan menggunakan beberapa model semantik, Anda juga dapat memisahkan penyewa menjadi beberapa kapasitas Power BI jika perlu.

Tanpa profil, entitas layanan dibatasi hingga 1.000 ruang kerja. Untuk mengatasi batas ini, perwakilan layanan dapat membuat beberapa profil, di mana setiap profil dapat mengakses/membuat hingga 1.000 ruang kerja. Dengan beberapa profil, aplikasi ISV dapat mengisolasi konten setiap pelanggan menggunakan kontainer logis yang berbeda.

Setelah profil perwakilan layanan memiliki akses ke ruang kerja, akses perwakilan layanan induknya ke ruang kerja dapat dihapus untuk menghindari masalah skalabilitas.

Bahkan dengan keuntungan ini, Anda harus mempertimbangkan skala potensial aplikasi Anda. Misalnya, jumlah item ruang kerja yang dapat diakses profil dibatasi. Saat ini, profil memiliki batas yang sama dengan pengguna biasa. Jika aplikasi ISV memungkinkan pengguna akhir untuk menyimpan salinan yang dipersonalisasi dari laporan tersemat, profil pelanggan akan memiliki akses ke semua laporan yang dibuat dari semua penggunanya. Model ini pada akhirnya dapat melebihi batas.

Otomatisasi dan kompleksitas operasional

Dengan pemisahan berbasis profil Power BI, Anda mungkin perlu mengelola ratusan atau ribuan item. Oleh karena itu, penting untuk menentukan proses yang sering terjadi dalam manajemen siklus hidup aplikasi Anda, dan memastikan Anda memiliki set alat yang tepat untuk melakukan operasi ini dalam skala besar. Beberapa operasi ini meliputi:

• Menambahkan penyewa baru
• Memperbarui laporan untuk beberapa atau semua penyewa
• Memperbarui skema model semantik untuk beberapa atau semua penyewa
• Kustomisasi yang tidak diencana untuk penyewa tertentu
• Frekuensi penyegaran model semantik

Misalnya, membuat profil dan ruang kerja untuk penyewa baru adalah tugas umum, yang dapat sepenuhnya otomatis dengan Power BI REST API.

Kebutuhan untuk Multi-Geo

Dukungan Multi-Geo untuk Power BI Embedded berarti bahwa ISV dan organisasi yang membangun aplikasi menggunakan Power BI Embedded untuk menyematkan analitik ke dalam aplikasi mereka sekarang dapat menyebarkan data mereka di berbagai wilayah di seluruh dunia. Untuk mendukung pelanggan yang berbeda di berbagai wilayah, tetapkan ruang kerja pelanggan ke kapasitas di wilayah yang diinginkan. Tugas ini adalah operasi sederhana yang tidak melibatkan biaya tambahan. Namun, jika Anda memiliki pelanggan yang membutuhkan data dari beberapa wilayah, profil penyewa harus menduplikasi semua item ke dalam beberapa ruang kerja yang ditetapkan pada kapasitas regional yang berbeda. Duplikasi ini dapat meningkatkan kompleksitas biaya dan manajemen.

Untuk alasan kepatuhan, Anda mungkin masih ingin membuat beberapa penyewa Power BI di berbagai wilayah. Baca selengkapnya tentang multi-geo.

Efisiensi biaya

Pengembang aplikasi yang menggunakan Power BI Embedded perlu membeli kapasitas Power BI Embedded. Model pemisahan berbasis profil bekerja dengan baik dengan kapasitas karena:

• Objek terkecil yang dapat Anda tetapkan secara independen ke kapasitas adalah ruang kerja (misalnya, Anda tidak dapat menetapkan laporan). Dengan memisahkan pelanggan berdasarkan profil, Anda mendapatkan ruang kerja yang berbeda - satu per pelanggan. Dengan cara ini, Anda mendapatkan fleksibilitas penuh untuk mengelola setiap pelanggan sesuai dengan kebutuhan performa mereka, dan mengoptimalkan pemanfaatan kapasitas dengan meningkatkan atau menurunkan skala. Misalnya, Anda dapat mengelola pelanggan besar dan penting dengan volume dan volatilitas tinggi dalam kapasitas terpisah untuk memastikan tingkat layanan yang konsisten, sambil mengelompokkan pelanggan yang lebih kecil dalam kapasitas lain untuk mengoptimalkan biaya.

• Memisahkan ruang kerja juga berarti memisahkan model semantik antara penyewa sehingga model data berada dalam gugus yang lebih kecil, bukan model semantik besar tunggal. Model yang lebih kecil ini memungkinkan kapasitas untuk mengelola penggunaan memori dengan lebih efisien. Model semantik kecil yang tidak digunakan dapat dikeluarkan setelah periode tidak aktif, untuk mempertahankan performa yang baik.

Saat membeli kapasitas, pertimbangkan batas jumlah refresh paralel, karena proses refresh mungkin memerlukan kapasitas tambahan saat Anda memiliki beberapa model semantik.

Keamanan Tingkat Baris

Artikel ini menjelaskan cara menggunakan profil untuk membuat model semantik terpisah untuk setiap pelanggan. Atau, aplikasi ISV dapat menyimpan semua data pelanggan mereka dalam satu model semantik besar dan menggunakan keamanan tingkat baris (RLS) untuk melindungi data setiap pelanggan. Pendekatan ini dapat nyaman untuk ISV yang memiliki pelanggan yang relatif sedikit dan model semantik kecil hingga menengah karena:

• Hanya ada satu laporan dan satu model semantik untuk dipertahankan
• Proses onboarding untuk pelanggan baru dapat disederhanakan

Namun, sebelum menggunakan RLS, pastikan Anda memahami batasannya. Semua data untuk semua pelanggan berada dalam satu model semantik Power BI besar. Model semantik ini berjalan dalam satu kapasitas dengan penskalaannya sendiri dan batasan lainnya.

Bahkan jika Anda menggunakan profil perwakilan layanan untuk memisahkan data pelanggan, Anda masih dapat menggunakan RLS dalam satu model semantik pelanggan untuk memberikan akses grup yang berbeda ke berbagai bagian data. Misalnya, Anda dapat menggunakan RLS untuk mencegah anggota satu departemen mengakses data departemen lain di organisasi yang sama.

Pertimbangan dan batasan

• Profil Perwakilan Layanan hanya didukung melalui Power BI REST API, Power BI .NET SDK, dan melalui titik akhir XMLA dan Model Objek Tabular (TOM) saat menggunakan pustaka klien Analysis Services versi 16.0.139.27 atau yang lebih tinggi. Profil Prinsipal Layanan tidak didukung di Power BI melalui titik akhir XMLA atau Model Objek Tabular (TOM) dengan pustaka klien yang lebih lama.
• Profil perwakilan layanan tidak didukung dengan Azure Analysis Services (AAS) dalam mode koneksi langsung.
• Profil maksimum yang dapat dimiliki satu perwakilan layanan, adalah 100.000.

Batasan kapasitas Power BI

• Setiap kapasitas hanya dapat menggunakan memori dan V-core yang dialokasikan, sesuai dengan SKU yang dibeli. Untuk ukuran model semantik yang direkomendasikan untuk setiap SKU, lihat model semantik besar Premium.
• Untuk menggunakan model semantik yang lebih besar dari 10 GB, gunakan kapasitas Premium dan aktifkan pengaturan Model semantik besar.
• Untuk jumlah refresh yang dapat berjalan bersamaan pada kapasitas, lihat manajemen sumber daya dan pengoptimalan.

Mengelola perwakilan layanan

Mengubah prinsipal layanan

Dalam Power BI, profil merupakan milik perwakilan layanan yang membuatnya. Artinya, profil tidak dapat dibagikan dengan prinsipal lain. Dengan batasan ini, jika Anda ingin mengubah perwakilan layanan karena alasan apa pun, Anda harus membuat ulang semua profil dan menyediakan akses profil baru ke ruang kerja yang relevan. Sering kali, aplikasi ISV harus menyimpan pemetaan antara ID profil dan ID pelanggan untuk memilih profil yang tepat saat diperlukan. Jika Anda mengubah perwakilan layanan dan membuat ulang profil, ID juga akan berubah, dan Anda mungkin perlu memperbarui pemetaan dalam database aplikasi ISV.

Menghapus prinsipal layanan

Jika Anda menghapus perwakilan layanan di direktori aktif, semua profilnya di Power BI akan dihapus. Namun, Power BI tidak akan segera menghapus konten, sehingga admin penyewa masih dapat mengakses ruang kerja. Berhati-hatilah saat menghapus perwakilan layanan yang digunakan dalam sistem produksi, terutama ketika Anda membuat profil menggunakan perwakilan layanan ini di Power BI. Jika Anda menghapus perwakilan layanan yang telah membuat profil, ketahuilah bahwa Anda harus membuat ulang semua profil, menyediakan akses profil baru ke ruang kerja yang relevan, dan memperbarui ID profil di database aplikasi ISV.

Pemisahan data

Ketika data dipisahkan oleh profil perwakilan layanan, pemetaan sederhana antara profil dan pelanggan mencegah satu pelanggan melihat konten pelanggan lain. Menggunakan perwakilan layanan tunggal mengharuskan perwakilan layanan memiliki akses ke semua ruang kerja yang berbeda di semua profil.

Untuk menambahkan pemisahan ekstra, tetapkan prinsipal layanan terpisah ke setiap penyewa, alih-alih menggunakan satu prinsipal layanan untuk mengakses beberapa ruang kerja dengan profil yang berbeda. Menetapkan perwakilan layanan terpisah memiliki beberapa keuntungan, termasuk:

• Kesalahan manusia atau kebocoran kredensial tidak akan menyebabkan data beberapa penyewa terekspos.
• Rotasi sertifikat dapat dilakukan secara terpisah untuk setiap penyewa.

Namun, menggunakan beberapa prinsipal layanan menyebabkan biaya manajemen yang tinggi. Pilih jalur ini hanya jika Anda memerlukan pemisahan tambahan. Perlu diingat bahwa konfigurasi data yang akan ditampilkan kepada pengguna akhir ditentukan saat Anda membuat token semat, proses khusus backend yang tidak dapat dilihat atau diubah oleh pengguna akhir. Meminta token penyematan menggunakan profil khusus untuk penyewa akan menghasilkan token penyematan untuk profil tersebut, yang memungkinkan pemisahan pelanggan berdasarkan penggunaan.

Satu laporan, beberapa model semantik

Umumnya, Anda memiliki satu laporan dan satu model semantik per penyewa. Jika Anda memiliki ratusan laporan, Anda akan memiliki ratusan model semantik. Terkadang, Anda mungkin memiliki satu format laporan, dengan model semantik yang berbeda (misalnya, parameter atau detail koneksi yang berbeda). Setiap kali Anda memiliki versi laporan baru, Anda harus memperbarui semua laporan untuk semua penyewa. Meskipun Anda dapat mengotomatiskan ini, pengelolaan akan lebih mudah jika Anda hanya memiliki satu salinan laporan. Buat ruang kerja yang berisi laporan untuk disematkan. Selama waktu proses sesi, hubungkan laporan ke model semantik khusus penyewa. Baca pengikatan dinamis untuk detail selengkapnya.

Menyesuaikan dan menulis konten

Saat Anda membuat konten, pertimbangkan dengan cermat siapa yang memiliki izin untuk mengeditnya. Jika Anda mengizinkan beberapa pengguna di setiap penyewa untuk mengedit, mudah untuk melebihi batasan model semantik. Jika Anda memutuskan untuk memberi pengguna kemampuan pengeditan, pantau pembuatan konten mereka dengan cermat, dan tingkatkan sesuai kebutuhan. Untuk alasan yang sama, sebaiknya jangan gunakan kemampuan ini untuk personalisasi konten, di mana setiap pengguna dapat membuat perubahan kecil pada laporan dan menyimpannya sendiri. Jika aplikasi ISV mengizinkan personalisasi konten, pertimbangkan untuk memperkenalkan kebijakan retensi ruang kerja untuk konten khusus pengguna. Kebijakan retensi memudahkan penghapusan konten saat pengguna pindah ke posisi baru, meninggalkan perusahaan, atau berhenti menggunakan platform.

Identitas yang Dikelola Sistem

Alih-alih perwakilan layanan, Anda dapat menggunakan identitas terkelola yang ditetapkan pengguna atau ditetapkan sistem untuk membuat profil. Identitas terkelola mengurangi kebutuhan akan rahasia dan sertifikat.

Berhati-hatilah saat menggunakan identitas yang dikelola sistem karena:

• Jika identitas terkelola yang ditetapkan sistem dinonaktifkan secara tidak sengaja, Anda akan kehilangan akses ke profil. Situasi ini mirip dengan kasus saat perwakilan layanan dihapus.
• Identitas terkelola yang ditetapkan sistem tersambung ke sumber daya di Azure (aplikasi web). Jika Anda menghapus sumber daya, identitas akan dihapus.
• Menggunakan beberapa sumber daya (aplikasi web yang berbeda di berbagai wilayah) akan menghasilkan beberapa identitas yang perlu dikelola secara terpisah (setiap identitas akan memiliki profilnya sendiri).

Karena pertimbangan di atas, sebaiknya gunakan identitas terkelola yang ditetapkan pengguna.

Contoh

Untuk contoh cara menggunakan profil principal layanan untuk mengelola lingkungan multipenyewa dengan embedding Power BI dan App-Owns-Data, unduh repositori App owns data multitenant dari Power BI Dev Camp (situs pihak ketiga).

Konten terkait

• Menggunakan SDK Power BI dengan perwakilan layanan
• Memigrasikan aplikasi multitenansi ke model profil perwakilan layanan
• Mengembangkan aplikasi multitenansi yang dapat diskalakan dengan penyematan Power BI