Bagikan melalui

Profil perwakilan layanan untuk aplikasi multitenansi di Power BI Embedded

  • Artikel

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.

Catatan

Penyewa kata di Power BI terkadang dapat merujuk ke penyewa Microsoft Entra. Namun, dalam artikel ini, kami menggunakan istilah multipenyewa untuk menjelaskan solusi di mana satu instans aplikasi perangkat lunak melayani beberapa pelanggan atau organisasi (penyewa) yang memerlukan pemisahan data fisik dan logis. Misalnya, penyusun aplikasi Power BI dapat mengalokasikan ruang kerja terpisah untuk setiap pelanggannya (atau penyewa) seperti yang kami perlihatkan di bawah ini. Pelanggan ini belum tentu merupakan penyewa Microsoft Entra, jadi jangan bingung istilah aplikasi multipenyewa yang kami gunakan di sini, dengan aplikasi multipenyewa Microsoft Entra.

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 perwakilan layanan memungkinkan aplikasi ISV untuk menghosting beberapa pelanggan pada satu penyewa 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.

Diagram Profil SP dan multitenansi.

Catatan

Artikel ini ditujukan untuk organisasi yang ingin menyiapkan aplikasi multipenyewa menggunakan profil perwakilan layanan. Jika organisasi Anda sudah memiliki aplikasi yang mendukung multipenyewa, dan Anda ingin bermigrasi ke model profil perwakilan layanan, lihat Bermigrasi ke model profil perwakilan layanan.

Menyiapkan konten Power BI Anda melibatkan langkah-langkah berikut:

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

Prasyarat

Sebelum dapat membuat profil perwakilan layanan, Anda perlu:

  • Menyiapkan perwakilan layanan dengan mengikuti tiga langkah pertamaSematkan konten Power BI dengan perwakilan layanan.
  • Dari akun admin penyewa Power BI, aktifkan pembuatan profil di penyewa menggunakan grup keamanan yang sama dengan yang Anda gunakan saat membuat perwakilan layanan.

Cuplikan layar pengalihan portal Admin.

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

Izin 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:

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 penyewa 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 menghasilkan token semat:

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

Dengan memisahkan data menjadi model semantik terpisah untuk setiap pelanggan, Anda meminimalkan kebutuhan akan model semantik besar. Ketika kapasitas kelebihan beban, kapasitas dapat mengeluarkan model semantik yang tidak digunakan untuk membebaskan memori untuk 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, perwakilan 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 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 ke 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 Perwakilan 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.

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, referensi 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, referensikan manajemen sumber daya dan pengoptimalan.

Mengelola perwakilan layanan

Mengubah perwakilan layanan

Dalam Power BI, profil merupakan milik perwakilan layanan yang membuatnya. Artinya, profil tidak dapat dibagikan dengan perwakilan 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 perwakilan layanan

Peringatan

Berhati-hatilah saat menghapus perwakilan layanan. Anda tidak ingin kehilangan data secara tidak sengaja dari semua profil terkait.

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 tambahan, tetapkan perwakilan layanan terpisah ke setiap penyewa, alih-alih memiliki akses perwakilan layanan tunggal beberapa ruang kerja menggunakan 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 perwakilan layanan dilengkapi dengan 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 semat menggunakan profil khusus penyewa akan menghasilkan token semat untuk profil tertentu tersebut, yang akan memberi Anda pemisahan pelanggan dalam konsumsi.

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 runtime sesi, ikat 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 perwakilan layanan untuk mengelola lingkungan multipenyewa dengan Penyematan Power BI dan App-Owns-Data, unduh repositori multitenant data milik Aplikasi dari Power BI Dev Camp (situs pihak ketiga).

Konten terkait