Memahami pengikatan dependensi dalam penyebaran lintas ruang kerja

Saat Anda menyebarkan item Fabric di seluruh ruang kerja (misalnya, dari Pengembangan ke Pengujian hingga Produksi), dependensi antar item dapat rusak. Beberapa item menyimpan referensi ke dependensinya sebagai ID objek (GUID khusus ruang kerja), sementara yang lain menggunakan ID logis (pengidentifikasi portabel lintas ruang kerja yang disimpan dalam .platform file).

Item yang menggunakan ID logis dalam definisinya mengikat dengan benar ke item yang sesuai di ruang kerja target. Item yang menggunakan ID objek tetap mengarah ke ruang kerja sumber, yang menyebabkan deployment gagal.

Artikel ini memetakan jenis item Fabric mana yang mendukung pengikatan dependensi melalui ID logis saat Anda menggunakan integrasi Git, dan mana yang tidak. Untuk mempelajari selengkapnya tentang ID logis dan bagaimana item direpresentasikan dalam kontrol sumber, lihat ID Logis di Fabric.

Konsep Utama

  • ID logis: Pengenal lintas ruang kerja yang dibuat secara otomatis dalam .platform berkas. Item dengan ID logis yang sama diperlakukan sebagai item yang sama di seluruh ruang kerja.
  • ID Objek: GUID khusus ruang kerja yang mengidentifikasi instans tertentu. ID objek tidak bertahan dari penyebaran lintas ruang kerja tanpa intervensi manual atau parameterisasi.
  • Pengikatan dependensi (Git): Saat Anda menyinkronkan cabang Git ke ruang kerja baru, Fabric menyelesaikan referensi dependensi menggunakan ID logis, secara otomatis menunjuk ke item yang benar di ruang kerja target.
  • Berdasarkan nama atau URI: Beberapa item mereferensikan dependensi berdasarkan nama tampilan atau URI, bukan berdasarkan ID. Referensi ini mungkin atau mungkin tidak diselesaikan dengan benar, tergantung pada konvensi penamaan di seluruh ruang kerja.

Cara kerja pengikatan dependensi

Dalam ruang kerja, item mereferensikan dependensinya menggunakan ID objek. Saat Fabric mengekspor item ke Git, item tersebut mengganti beberapa ID objek ini dengan ID logis dari .platform file. Saat Anda menyinkronkan cabang Git ke ruang kerja yang berbeda, Fabric menyelesaikan ID logis tersebut kembali ke ID objek yang benar di ruang kerja target. Inilah yang membuat pengikatan dependensi berfungsi.

Namun, tidak semua referensi dependensi diganti dengan ID logis selama ekspor. Item yang menyimpan ID objek dalam representasi Git mereka masih mengarah ke ruang kerja asli setelah sinkronisasi, dan Anda perlu memperbaruinya secara manual atau melalui parameterisasi.

Important

Pengikatan dependensi hanya berlaku untuk referensi antara item Fabric dalam ruang kerja yang sama. Jika item mereferensikan item Fabric di ruang kerja yang berbeda, referensi tersebut menggunakan ID objek dan tidak mengikat secara otomatis. Referensi ke Koneksi (koneksi sumber data, gateway) juga tidak mengikat secara otomatis. Gunakan Pustaka Variabel dengan kumpulan nilai khusus lingkungan untuk mengelola referensi koneksi di seluruh lingkungan.

Kompatibilitas pengikatan dependensi

Tabel berikut menunjukkan apakah dependensi setiap jenis item Fabric terikat dengan benar saat Anda menyebarkan item antar-ruang kerja. Saat ini, artikel ini membahas perilaku integrasi Git . Karena pengikatan ditentukan oleh cara setiap item menyimpan referensi dependensinya dalam definisinya, perilaku yang sama berlaku untuk mekanisme penyebaran lain yang menggunakan kembali definisi tersebut, seperti alur penyebaran dan API impor (massal).

Tabel ini mengasumsikan dependensi adalah item lain di ruang kerja yang sama dengan item sumber. Referensi ke item di ruang kerja yang berbeda tidak pernah mengikat secara otomatis. Itu tetap disematkan ke ID objek sumber terlepas dari nilai yang ditampilkan dalam tabel.

Kolom Auto-bind in Git menunjukkan:

  • Ya: Definisi item di Git menyimpan referensi dependensi sebagai ID logis. Saat Anda menyinkronkan cabang ke ruang kerja baru, referensi mengikat secara otomatis ke item yang cocok di ruang kerja tersebut.
  • Tidak: Definisi item di Git menyimpan referensi dependensi sebagai ID objek (GUID khusus ruang kerja). Referensi terus mengarah ke ruang kerja sumber setelah sinkronisasi. Anda perlu memperbarui atau memparameterkannya secara manual untuk penyebaran lintas ruang kerja.
  • Parsial: Item menyelesaikan dependensi berdasarkan nama atau URI, yang mungkin berfungsi jika penamaan konsisten di seluruh ruang kerja.

Notebooks

Ketergantungan Pengikatan otomatis di Git Notes
Lakehouse Yes Memerlukan pengaktifan "Pengikatan Otomatis Lakehouse di Git" di pengaturan buku catatan. Saat diaktifkan, ID objek diganti dengan ID logis di notebook-settings.json. Pengaturan ini nonaktif secara default. Untuk informasi selengkapnya, lihat Pengikatan otomatis Lakehouse di Git.
Environment Yes
Database Cermin No

Note

Pengikatan Notebook ke Lakehouse tidak diaktifkan secara default. Anda perlu mengaktifkan pengaturan "Lakehouse Auto-Binding in Git" di setelan masing-masing notebook. Untuk informasi selengkapnya, lihat Kontrol dan penyebaran sumber buku catatan.

Reports

Ketergantungan Pengikatan otomatis di Git Notes
Model Semantik (dari laporan Power BI) Partial Laporan mereferensikan model melalui referensi relatif byPath di definition.pbir, bukan ID logis eksplisit. Hal ini teratasi dengan benar ketika model di-deploy ke lokasi relatif yang sama di ruang kerja target, tetapi tidak terikat melalui ID logis. Untuk informasi selengkapnya, lihat folder laporan proyek Power BI Desktop.
Model Semantik (dari laporan paginasi) No String koneksi laporan mereferensikan model semantik dengan ID khusus ruang kerja yang tidak ditulis ulang saat penerapan, sehingga tetap mengarah ke model sumber. Anda perlu memperbarui referensi ini untuk penyebaran lintas ruang kerja. (Laporan yang dibuat di Report Builder yang merujuk ke model berdasarkan nama mungkin malah dicocokkan berdasarkan nama tampilan, yaitu "Partial".)

Pipeline

Ketergantungan Pengikatan otomatis di Git Notes
Pipeline Yes
Notebook Yes
Dataflow Gen2 Yes
SQL Database Yes
Definisi Pekerjaan Spark No Aktivitas SparkJobDefinition mereferensikan Definisi Pekerjaan Spark berdasarkan ID objek, bukan ID logis, sehingga tetap mengarah ke item sumber setelah penyebaran. Anda perlu menjadikan nilai ini sebagai parameter untuk penerapan lintas ruang kerja.
Lakehouse Yes
Model Semantik No Aktivitas PBISemanticModelRefresh mereferensikan model semantik berdasarkan ID item, bukan ID logis. Anda perlu menjadikan nilai ini sebagai parameter untuk penerapan lintas ruang kerja.
Warehouse No Gudang artifactId diselesaikan melalui ID logis dan mengikat ulang, tetapi linkedService juga menyimpan SQL endpointruang kerja sumber , yang tidak ditulis ulang. Parameterkan endpoint untuk deployment lintas ruang kerja.

Model Semantik

Ketergantungan Pengikatan otomatis di Git Notes
Model semantik Partial Referensi model berantai atau komposit menggunakan string koneksi berdasarkan nama.
Titik Akhir SQL Analytics (lakehouse) No String koneksi Direct Lake di TMDL expressions.tmdl berisi URL endpoint khusus ruang kerja dan GUID database. Anda perlu mengganti parameter ini untuk penyebaran lintas ruang kerja.
KQL Database No String koneksi yang berisi URI kluster dalam ekspresi TMDL berisi nilai yang spesifik untuk ruang kerja.
database SQL No String koneksi di dalam ekspresi TMDL berisi nilai yang spesifik untuk ruang kerja.
Warehouse No Koneksi ke titik akhir analitik SQL gudang menggunakan URL khusus ruang kerja.

Rumah Danau

Ketergantungan Pengikatan otomatis di Git Notes
Lakehouse (pintasan) Yes Pintasan internal OneLake yang merujuk ke item Fabric lain, seperti lakehouse atau warehouse, disimpan sebagai ID logis dan ditautkan kembali ke item di ruang kerja target. Pintasan ke sumber eksternal, seperti Azure Data Lake Storage Gen2 atau Amazon S3, mengarah ke luar Fabric dan sebagai gantinya menyertakan referensi koneksi, sehingga tidak dikenai pengikatan ID logis. Untuk daftar lengkap target pintasan, lihat Pintasan OneLake. Untuk perilaku penyebaran, lihat Integrasi Git Lakehouse dan alur penyebaran.

Alur data (Gen2)

Secara default, Dataflow Gen2 membuat referensi absolut ke item Fabric: kueri menyimpan ID ruang kerja sumber dan ID objek item, yang tidak ditulis ulang saat penyebaran. Referensi sumber juga dapat menggunakan referensi relatif: ketika Anda memilih item di bawah node !(Current Workspace) di konektor Fabric, kueri menyimpan item tersebut berdasarkan nama (tanpa GUID), dan akan diarahkan ke item yang sesuai di ruang kerja target saat penerapan. Tujuan output selalu menggunakan referensi absolut dan tidak mengikat ulang. Untuk tujuan, dan untuk referensi sumber absolut apa pun, parameterkan nilai untuk penyebaran lintas ruang kerja. Untuk informasi selengkapnya, lihat Referensi relatif dengan konektor Fabric di Dataflow Gen2 dan Dataflow Gen2 dengan integrasi CI/CD dan Git.

Referensi sumber:

Ketergantungan Pengikatan otomatis di Git Notes
Lakehouse Partial Mengikat ulang hanya jika ditulis sebagai referensi relatif (!( Ruang Kerja Saat Ini)); Referensi absolut default tidak mengikat ulang.
Warehouse Partial Mengikat ulang hanya jika ditulis sebagai referensi relatif (!( Ruang Kerja Saat Ini)); Referensi absolut default tidak mengikat ulang.

Referensi tujuan:

Ketergantungan Pengikatan otomatis di Git Notes
Lakehouse No
Warehouse No
SQL Database No

Definisi Pekerjaan Spark

Ketergantungan Pengikatan otomatis di Git Notes
Environment Yes
Lakehouse No defaultLakehouseArtifactId menggunakan ID objek.

Salin Pekerjaan

Ketergantungan Pengikatan otomatis di Git Notes
Lakehouse Yes
Warehouse No Gudang artifactId diselesaikan melalui ID logis dan mengikat ulang, tetapi linkedService juga menyimpan SQL endPointruang kerja sumber , yang tidak ditulis ulang. Parameterkan endPoint untuk deployment lintas ruang kerja.
SQL Database Yes

API GraphQL

Ketergantungan Pengikatan otomatis di Git Notes
Titik Akhir SQL Yes
Warehouse Yes
SQL Database Yes

Untuk semua sumber data API GraphQL, Anda mungkin perlu mengonfigurasi ulang koneksi dan kredensial setelah penerapan.

Eventstreams

Ketergantungan Pengikatan otomatis di Git Notes
Lakehouse Yes
Eventhouse Yes Semua destinasi didukung penuh untuk CI/CD jika item berada di ruang kerja yang sama. Untuk Eventhouse dengan mode Penyerapan Langsung, Anda mungkin perlu mengonfigurasi ulang koneksi secara manual setelah penyebaran. Untuk informasi selengkapnya, lihat Eventstream CI/CD.
Aktivator (Refleks) Yes Semua destinasi didukung penuh untuk CI/CD jika item berada di ruang kerja yang sama. Untuk informasi selengkapnya, lihat Eventstream CI/CD.

Item KQL

Ketergantungan Pengikatan otomatis di Git Notes
database KQL ke eventhouse Yes parentEventhouseItemId di dalam DatabaseProperties.json adalah ID logis dan terikat ke eventhouse target. Database KQL disebarkan sebagai turunan dari eventhouse induknya.
Kueri KQL ke database KQL Partial Diselesaikan melalui clusterUri dan databaseName, bukan ID item. Definisi tersebut menyertakan databaseItemId, tetapi ini adalah ID objek yang tidak mengikat ulang, sehingga resolusi bergantung pada URI di seluruh lingkungan.
Dasbor Real-Time untuk database KQL Partial Menggunakan array dataSources yang berisi URI kluster. Pola yang sama dengan queryset KQL.

Gudang

Ketergantungan Pengikatan otomatis di Git Notes
Gudang (referensi silang) No Referensi ke gudang lain menggunakan ID objek.
Titik Akhir SQL No Referensi SQL Endpoint menggunakan pengidentifikasi khusus ruang kerja.

Perpustakaan Variabel

Ketergantungan Pengikatan otomatis di Git Notes
Fabric item (jenis ItemReference) No Jenis ItemReference variabel menyimpan workspaceId dan itemId sebagai GUID mentah. Anda harus memperbarui atau mengganti nilai-nilai ini secara manual melalui kumpulan nilai per lingkungan.

Item yang tidak memiliki dependensi

Item berikut tidak memiliki masalah pengikatan dependensi lintas ruang kerja:

  • Environment
  • SQL Database
  • Eventhouse (item kontainer; database KQL merujuk kepadanya)
  • Basis Data Tercermin (hanya untuk konfigurasi sumber eksternal)

RINGKASAN

Saat Anda menyebarkan item Fabric di seluruh ruang kerja, dependensi antar item dapat rusak jika referensi disimpan sebagai ID objek khusus ruang kerja, bukan ID logis portabel. Tidak semua jenis item mendukung pengikatan dependensi melalui ID logis. Sebelum Anda menyiapkan penyebaran lintas ruang kerja, tinjau tabel kompatibilitas dalam artikel ini untuk mengidentifikasi dependensi mana yang mengikat secara otomatis dan mana yang memerlukan parameterisasi manual.

Konten terkait

  • Last updated on