Poznaj wiązanie zależności we wdrożeniu między obszarami roboczymi

Gdy wdrażasz elementy Fabric w różnych przestrzeniach roboczych (na przykład od Development do Test i Production), zależności między elementami mogą się zerwać. Niektóre elementy przechowują odwołania do swoich zależności jako identyfikatory obiektów (GUIDy specyficzne dla przestrzeni roboczej), podczas gdy inne używają logicznych identyfikatorów (przenośnych identyfikatorów między przestrzeniami roboczymi przechowywanych w pliku .platform ).

Elementy, które w swoich definicjach używają logicznych identyfikatorów, poprawnie wiążą się z odpowiadającym elementem w docelowej przestrzeni roboczej. Elementy używające identyfikatorów obiektów nadal wskazują źródłowy obszar roboczy, co powoduje niepowodzenie wdrożenia.

Ten artykuł mapuje, które typy elementów Fabric obsługują wiązanie zależności za pomocą logicznych identyfikatorów podczas integracji z Gitem, a które nie. Aby dowiedzieć się więcej o logicznych identyfikatorach i sposobie reprezentacji elementów w kontroli wersji źródłowych, zobacz Logical ID in Fabric.

Kluczowe pojęcia

  • Logiczny identyfikator: Automatycznie generowany identyfikator obejmujący wiele obszarów roboczych w .platform pliku. Elementy o tym samym logicznym ID są traktowane jako ten sam element w różnych przestrzeniach roboczych.
  • ID obiektu: Specyficzny dla przestrzeni roboczej GUID identyfikujący konkretną instancję. ID obiektów nie przetrwają wdrożenia między przestrzeniami roboczymi bez ręcznej interwencji lub parametryzacji.
  • Powiązanie zależności (Git): Gdy synchronizujesz gałąź Git z nowym obszarem roboczym, Fabric rozwiązuje odwołania zależności przy użyciu identyfikatorów logicznych, automatycznie wskazując odpowiedni element w docelowym obszarze roboczym.
  • Według nazwy lub URI: Niektóre elementy odnoszą się do zależności według nazwy wyświetlania lub URI, a nie według ID. Te odniesienia mogą, ale nie muszą się poprawnie rozwiązywać, w zależności od konwencji nazewnictwa w przestrzeniach roboczych.

Jak działa wiązanie zależności

W obrębie przestrzeni roboczej elementy odwołują się do swoich zależności za pomocą identyfikatorów obiektów. Gdy Fabric eksportuje element do Gita, zastępuje część tych ID obiektów logicznymi identyfikatorami z pliku.platform. Gdy synchronizujesz gałąź Git z innym workspace, Fabric rozwiązuje te logiczne ID z powrotem do właściwych ID obiektów w docelowej przestrzeni roboczej. To właśnie sprawia, że wiążenie zależności działa.

Jednak nie wszystkie odniesienia do zależności są zastępowane logicznymi identyfikatorami podczas eksportu. Elementy, które zachowują identyfikatory obiektów w swojej reprezentacji w Gicie, nadal wskazują na oryginalną przestrzeń roboczą po synchronizacji i trzeba je aktualizować ręcznie lub parametryzacją.

Important

Powiązanie zależności dotyczy tylko odniesień pomiędzy elementami Fabric w tym samym workspace. Jeśli element odwołuje się do elementu Fabric w innym obszarze roboczym, takie odwołanie używa identyfikatora obiektu i nie jest automatycznie wiązane. Odwołania do połączeń (połączenia ze źródłami danych, bramy) również nie wiązają się automatycznie. Używaj bibliotek zmiennych z zestawami wartości specyficznymi dla środowiska do zarządzania odwołaniami do połączeń między środowiskami.

Zgodność powiązań zależności

Poniższe tabele pokazują, czy zależności każdego typu elementu rozwiązania Fabric są prawidłowo powiązane podczas wdrażania między obszarami roboczymi. Obecnie ten artykuł omawia zachowania integracyjne z Gitem . Ponieważ binding jest określane przez to, jak każdy element przechowuje swoje odniesienia zależności w definicji, to samo zachowanie dotyczy innych mechanizmów wdrożenia, które ponownie wykorzystują te definicje, takich jak pipeline'y wdrożeniowe czy API importu (bulk).

Te tabele zakładają, że zależność to inny element w tej samej przestrzeni roboczej co element źródłowy. Odniesienie do elementu w innym obszarze roboczym nigdy nie jest automatycznie wiązane. Pozostaje przypięty do identyfikatora obiektu źródłowego niezależnie od wartości pokazanej w tabeli.

Kolumna Automatyczne wiązanie w Git wskazuje:

  • Tak: Definicja przedmiotu w Git przechowuje referencję zależności jako logiczny identyfikator. Gdy synchronizujesz gałąź z nowym obszarem roboczym, odwołanie zostaje automatycznie powiązane z pasującym elementem w tym obszarze roboczym.
  • Nie: Definicja elementu w Gicie przechowuje referencję zależności jako ID obiektu (GUID specyficzny dla przestrzeni roboczej). Referencja nadal wskazuje na źródłowy workspace po synchronizacji. Musisz ją ręcznie zaktualizować lub parametryzować, aby wdrożyć ją w różnych przestrzeniach roboczych.
  • Częściowe: Element rozwiązuje zależność według nazwy lub URI, co może działać, jeśli nazewnictwo jest spójne w różnych przestrzeniach roboczych.

Notebooks

Zależność Automatyczne przypisanie w Git Notatki
Lakehouse Yes Wymaga włączenia opcji „Lakehouse Auto-Binding in Git” w ustawieniach notatnika. Po włączeniu identyfikator obiektu jest zastępowany logicznym ID w notebook-settings.json. To ustawienie jest domyślnie wyłączone. Więcej informacji można znaleźć w artykule Lakehouse auto-binding in Git.
Environment Yes
Dublowana baza danych Nie.

Uwaga / Notatka

Powiązanie notesu z usługą Lakehouse nie jest domyślnie włączone. Musisz włączyć ustawienie „Lakehouse Auto-Binding in Git” w ustawieniach każdego notesnika. Aby uzyskać więcej informacji, zobacz Notes source control and deployment (Kontrola źródła notesu i wdrażanie).

Reports

Zależność Automatyczne przypisanie w Git Notatki
Model semantyczny (z raportu Power BI) Partial Raport odwołuje się do modelu za pomocą odwołania względnego byPath w definition.pbir, a nie jawnego identyfikatora logicznego. Jest poprawnie rozpoznawane, gdy model jest wdrażany w tej samej względnej lokalizacji w docelowym obszarze roboczym, ale nie jest wiązane przy użyciu identyfikatora logicznego. Więcej informacji można znaleźć w artykule folder raportów projektów programu Power BI Desktop.
Model semantyczny (z raportu paginowanego) Nie. Parametry połączenia raportu odwołują się do modelu semantycznego przy użyciu identyfikatora właściwego dla obszaru roboczego, który nie jest ponownie zapisywany podczas wdrażania, więc nadal wskazują model źródłowy. Musisz zaktualizować to odwołanie na potrzeby wdrożenia w wielu obszarach roboczych. (Raporty utworzone w Report Builder, które odwołują się do modelu według nazwy, mogą zamiast tego być rozpoznawane według nazwy wyświetlanej, czyli Partial.)

rurociąg

Zależność Automatyczne przypisanie w Git Notatki
rurociąg Yes
Notebook Yes
Przepływ danych Gen2 Yes
Baza danych SQL Yes
Definicja zadania platformy Spark Nie. Działanie SparkJobDefinition odwołuje się do definicji zadania Spark za pomocą identyfikatora obiektu, a nie identyfikatora logicznego, więc po wdrożeniu nadal wskazuje element źródłowy. Musisz ustawić tę wartość jako parametr na potrzeby wdrożenia między obszarami roboczymi.
Lakehouse Yes
Semantyczny model Nie. Aktywność PBISemanticModelRefresh odnosi się do modelu semantycznego za pomocą ID elementu, a nie logicznego ID. Musisz ustawić tę wartość jako parametr na potrzeby wdrożenia między obszarami roboczymi.
Magazyn Nie. Magazyn artifactId jest rozpoznawany na podstawie identyfikatora logicznego i ponownie wiązany, ale linkedService przechowuje także kod SQL endpoint źródłowego obszaru roboczego, który nie zostaje przepisany. Sparametryzuj endpoint na potrzeby wdrożenia między obszarami roboczymi.

Modele semantyczne

Zależność Automatyczne przypisanie w Git Notatki
Model semantyczny Partial Referencje modeli łańcuchowych lub złożonych używają łańcuchów połączeń według nazwy.
Punkt końcowy analizy SQL (lakehouse) Nie. Parametry połączenia Direct Lake w TMDL expressions.tmdl zawierają adres URL punktu końcowego specyficzny dla obszaru roboczego oraz identyfikator GUID bazy danych. Musisz zastąpić te parametry na potrzeby wdrożenia między obszarami roboczymi.
Baza danych KQL Nie. Parametry połączenia z identyfikatorem URI klastra w wyrażeniach TMDL zawierają wartości specyficzne dla obszaru roboczego.
baza danych SQL Nie. parametry połączenia w wyrażeniach TMDL zawiera wartości specyficzne dla przestrzeni roboczej.
Magazyn Nie. Połączenie z endpointem SQL Analytics magazynu wykorzystuje adres URL specyficzny dla przestrzeni roboczej.

Domy nad jeziorem

Zależność Automatyczne przypisanie w Git Notatki
Lakehouse (skrót) Yes Wewnętrzne skróty OneLake wskazujące na inny element Fabric, taki jak domek nad jeziorem czy magazyn, są przechowywane jako logiczny identyfikator i ponownie przypisywane do obiektu docelowego workspace. Skróty do zewnętrznych źródeł, takich jak Azure Data Lake Storage Gen2 czy Amazon S3, wskazują na zasoby poza środowiskiem Fabric i zamiast tego zawierają odwołanie do połączenia, więc nie podlegają wiązaniu z identyfikatorem logicznym. Pełną listę celów skrótów można znaleźć w artykule OneLake shortcuts. Informacje o sposobie wdrażania można znaleźć w artykule Integracja usługi Git z usługą Lakehouse i potoki wdrażania.

Przepływy danych (Gen2)

Domyślnie Dataflow Gen2 tworzy absolutne odwołania do elementów Fabric: zapytanie przechowuje identyfikator źródłowego workspace oraz ID obiektu elementu, które nie są przepisywane podczas wdrożenia. Odwołanie do źródła może zamiast tego używać odniesienia względnego: gdy wybierzesz element w węźle !(Current Workspace) w łączniku Fabric, zapytanie zapisuje element według nazwy (bez identyfikatorów GUID) i podczas wdrażania jest ono rozpoznawane jako pasujący element w docelowym obszarze roboczym. Wyjścia docelowe zawsze używają odwołań bezwzględnych i nie są ponownie wiązane. W przypadku miejsc docelowych oraz wszelkich bezwzględnych odwołań do źródła sparametryzuj wartości na potrzeby wdrażania między obszarami roboczymi. Aby uzyskać więcej informacji, zobacz Odwołania względne z łącznikami Fabric w usłudze Dataflow Gen2 oraz Dataflow Gen2 z integracją CI/CD i Git.

Źródła:

Zależność Automatyczne przypisanie w Git Notatki
Lakehouse Partial Jest ponownie wiązane tylko wtedy, gdy zostało utworzone jako odwołanie względne (!(Bieżący obszar roboczy)); domyślne odwołanie bezwzględne nie jest ponownie wiązane.
Magazyn Partial Jest ponownie wiązane tylko wtedy, gdy zostało utworzone jako odwołanie względne (!(Bieżący obszar roboczy)); domyślne odwołanie bezwzględne nie jest ponownie wiązane.

Odniesienia do miejsc docelowych:

Zależność Automatyczne przypisanie w Git Notatki
Lakehouse Nie.
Magazyn Nie.
Baza danych SQL Nie.

Definicje zadań platformy Spark

Zależność Automatyczne przypisanie w Git Notatki
Environment Yes
Lakehouse Nie. defaultLakehouseArtifactId używa identyfikatora obiektu.

Zadania kopiowania

Zależność Automatyczne przypisanie w Git Notatki
Lakehouse Yes
Magazyn Nie. Hurtownia artifactId jest rozpoznawana na podstawie identyfikatora logicznego i jest ponownie wiązana, ale linkedService przechowuje również SQL endPoint źródłowej przestrzeni roboczej, który nie jest ponownie zapisywany. Sparametryzuj endPoint na potrzeby wdrożenia między obszarami roboczymi.
Baza danych SQL Yes

Interfejsy API języka GraphQL

Zależność Automatyczne przypisanie w Git Notatki
Punkt końcowy SQL Yes
Magazyn Yes
Baza danych SQL Yes

Dla wszystkich źródeł danych API GraphQL może być konieczne ponowne skonfigurowanie połączenia i danych uwierzytelniających po wdrożeniu.

Strumienie zdarzeń

Zależność Automatyczne przypisanie w Git Notatki
Lakehouse Yes
Eventhouse Yes Wszystkie lokalizacje docelowe są w pełni obsługiwane przez CI/CD, gdy elementy znajdują się w tym samym obszarze roboczym. W przypadku Eventhouse z trybem Direct Ingestion może być konieczne ręczne ponowne skonfigurowanie połączenia po wdrożeniu. Więcej informacji można znaleźć w sekcji Eventstream CI/CD.
Aktywator (Refleks) Yes Wszystkie lokalizacje docelowe są w pełni obsługiwane przez CI/CD, gdy elementy znajdują się w tym samym obszarze roboczym. Więcej informacji można znaleźć w sekcji Eventstream CI/CD.

Przedmioty KQL

Zależność Automatyczne przypisanie w Git Notatki
Baza danych KQL do eventhouse Yes Element parentEventhouseItemId w DatabaseProperties.json jest logicznym identyfikatorem i jest powiązany z docelowym eventhouse. Baza danych KQL jest wdrażana jako element podrzędny swojego nadrzędnego obiektu eventhouse.
zestaw zapytań KQL do bazy danych KQL Partial Rozwiązuje się przez clusterUri i , databaseNamea nie przez ID przedmiotu. Definicja zawiera databaseItemId, ale jest to ID obiektu, które nie przewiązuje się, więc rozdzielczość zależy od URI w różnych środowiskach.
Real-Time Dashboard do bazy danych KQL Partial Używa tablicy dataSources z identyfikatorami URI klastra. Taki sam wzorzec jak w zestawie zapytań KQL.

Magazyny

Zależność Automatyczne przypisanie w Git Notatki
Magazyn (odnośnik krzyżowy) Nie. W odwołaniach do innych magazynów używane są identyfikatory obiektów.
Punkt końcowy SQL Nie. Referencje do SQL Endpoint używają identyfikatorów specyficznych dla przestrzeni roboczej.

Biblioteki zmiennych

Zależność Automatyczne przypisanie w Git Notatki
Elementy Fabric (typu ItemReference) Nie. Typ ItemReference zmienny przechowuje workspaceId i itemId jako surowe GUIDy. Musisz ręcznie aktualizować lub nadpisywać te wartości za pomocą zestawów wartości dla każdego środowiska.

Elementy bez zależności

Poniższe elementy nie mają problemów związanych z zależnościami między przestrzeniami roboczymi:

  • Environment
  • Baza danych SQL
  • Eventhouse (przedmiot kontenerowy; Bazy danych KQL się do niego odnoszą)
  • Lustrzana baza danych (tylko konfiguracja zewnętrzna)

Podsumowanie

Gdy wdrażasz elementy usługi Fabric między obszarami roboczymi, zależności między elementami mogą zostać zerwane, jeśli odwołania są przechowywane jako identyfikatory obiektów specyficzne dla danego obszaru roboczego zamiast jako przenośne identyfikatory logiczne. Nie wszystkie typy elementów wspierają wiązanie zależności za pomocą logicznych identyfikatorów. Zanim skonfigurujesz wdrożenie między przestrzeniami roboczymi, przejrzyj tabele kompatybilności w tym artykule, aby określić, które zależności wiążą się automatycznie, a które wymagają ręcznej parametryzacji.

Treści powiązane

  • Last updated on