Często zadawane pytania dotyczące narzędzi do zarządzania cyklem życia sieci szkieletowej

Zarządzanie cyklem życia ma dwie części, integrację i wdrażanie. Aby dowiedzieć się, jaka jest integracja w usłudze Fabric, zapoznaj się z omówieniem integracji z usługą Git. Aby dowiedzieć się, jakie potoki wdrażania znajdują się w usłudze Fabric, zapoznaj się z omówieniem potoków wdrażania.

Aby uzyskać krótkie wyjaśnienie integracji z usługą Git, zobacz Omówienie integracji z usługą Git. Wielowierszowa lub sformatowana odpowiedź na pytanie. Użyj dowolnego formatowania języka Markdown, pod warunkiem że zachowasz wcięcie w wierszach po | Znaków.

Aby uzyskać krótkie wyjaśnienie potoków wdrażania, zobacz omówienie potoków wdrażania.

Aby uzyskać informacje na temat licencji, zobacz Licencje sieci szkieletowej.

Wszystkie obszary robocze muszą być przypisane do licencji usługi Fabric. Można jednak używać różnych typów pojemności dla różnych obszarów roboczych.

Aby uzyskać informacje na temat typów pojemności, zobacz Pojemność i jednostki SKU.

Model uprawnień potoków wdrażania został opisany w sekcji uprawnień .

Aby skonfigurować reguły wdrażania w potokach wdrażania, musisz być właścicielem modelu semantycznego.

Jeśli pojemność obszaru roboczego znajduje się w jednej lokalizacji geograficznej, gdy repozytorium Usługi Azure DevOps znajduje się w innej lokalizacji, administrator sieci szkieletowej może zdecydować, czy włączyć eksporty między lokalizacjami geograficznymi. Aby uzyskać więcej informacji, zobacz Użytkownicy mogą eksportować elementy do repozytoriów Git w innych lokalizacjach geograficznych.

Rozpocznij pracę z integracją z usługą Git, korzystając z instrukcji rozpoczynania pracy.

Może istnieć kilka powodów, dla których element został usunięty z obszaru roboczego.

• Jeśli element nie został zatwierdzony i został wybrany w akcji cofania , element zostanie usunięty z obszaru roboczego.
• Jeśli element został zatwierdzony, może zostać usunięty, jeśli przełączysz gałęzie, a element nie istnieje w nowej gałęzi.

Oto kilka ważnych zagadnień, które należy wziąć pod uwagę:

• Ograniczenia reguły wdrażania
• Obsługiwane źródła danych dla przepływów danych i reguł modelu semantycznego
• Odświeżanie przyrostowe
• Potoki wdrażania automatyzacji* nie mogą służyć do wdrażania elementów w obszarze roboczym, który znajduje się w innym regionie.

Możesz przypisać jeden obszar roboczy do potoku i wdrożyć go w potoku lub przypisać inny obszar roboczy do każdego etapu potoku. Aby uzyskać więcej informacji, zobacz przypisywanie obszaru roboczego do potoku wdrażania.

Zestawy danych korzystające z trybu łączności directQuery lub złożonej i mają tabele odmian lub automatycznej daty/godziny nie są obsługiwane w potokach wdrażania. Jeśli wdrożenie zakończy się niepowodzeniem i uważasz, że masz zestaw danych z tabelą odmian, możesz wyszukać właściwość odmian w kolumnach tabeli. Możesz użyć jednej z metod wymienionych poniżej, aby edytować model semantyczny tak, aby działał w potokach wdrażania.

• W zestawie danych, zamiast używać trybu DirectQuery lub trybu złożonego, użyj trybu importu .

• Usuń tabele automatycznej daty/godziny z modelu semantycznego. W razie potrzeby usuń pozostałe odmiany ze wszystkich kolumn w tabelach. Usunięcie odmiany może spowodować unieważnienie miar utworzonych przez użytkownika, kolumn obliczeniowych i tabel obliczeniowych. Użyj tej metody tylko wtedy, gdy rozumiesz, jak działa model semantyczny, ponieważ może to spowodować uszkodzenie danych w wizualizacjach.

Jeśli przypinasz kafelek do pulpitu nawigacyjnego, jeśli kafelek opiera się na nieobsługiwanym elemencie (żaden element nie na tej liście jest nieobsługiwany) lub na elemencie, który nie ma uprawnień do wdrożenia, po wdrożeniu pulpitu nawigacyjnego kafelek nie będzie renderowany. Jeśli na przykład utworzysz kafelek na podstawie raportu, który opiera się na modelu semantycznym, na którym nie jesteś administratorem, podczas wdrażania raportu zostanie wyświetlone ostrzeżenie o błędzie. Jednak podczas wdrażania pulpitu nawigacyjnego z kafelkiem nie zostanie wyświetlony komunikat o błędzie, wdrożenie zakończy się pomyślnie, ale kafelek nie wyświetli żadnych informacji.

Właściciel wdrożonego raportu podzielonego na strony jest użytkownikiem, który wdrożył raport. Podczas wdrażania raportu podzielonego na strony po raz pierwszy stajesz się właścicielem raportu.

Jeśli wdrażasz raport podzielony na strony na etapie, który zawiera już kopię tego raportu podzielonego na strony, zastępujesz poprzedni raport i stajesz się jego właścicielem zamiast poprzedniego właściciela. W takich przypadkach potrzebne są poświadczenia do bazowego źródła danych, aby dane mogły być używane w raporcie podzielonym na strony.

Podraporty raportów podzielonych na strony są przechowywane w tym samym folderze, który zawiera raport podzielony na strony. Aby uniknąć problemów z renderowaniem, gdy używasz selektywnej kopii do kopiowania raportu podzielonego na strony z podraportami, wybierz zarówno raport nadrzędny, jak i podraporty.

Reguły raportów podzielonych na strony można utworzyć, jeśli chcesz wskazać raport podzielony na strony do modelu semantycznego na tym samym etapie. Podczas tworzenia reguły wdrażania dla raportu podzielonego na strony należy wybrać bazę danych i serwer.

Jeśli ustawiasz regułę wdrażania dla raportu podzielonego na strony, który nie ma modelu semantycznego sieci szkieletowej, ponieważ docelowe źródło danych jest zewnętrzne, musisz określić zarówno serwer, jak i bazę danych.

Jednak raporty podzielone na strony korzystające z semantycznego modelu sieci szkieletowej używają wewnętrznego modelu semantycznego. W takich przypadkach nie można polegać na nazwie źródła danych w celu zidentyfikowania modelu semantycznego sieci szkieletowej, z którym nawiązujesz połączenie. Nazwa źródła danych nie zmienia się podczas aktualizowania jej na etapie docelowym przez utworzenie reguły źródła danych lub wywołanie interfejsu API źródła danych aktualizacji. Po ustawieniu reguły wdrażania należy zachować format bazy danych i zastąpić identyfikator obiektu modelu semantycznego w polu bazy danych. Ponieważ model semantyczny jest wewnętrzny, serwer pozostaje taki sam.

• Baza danych — format bazy danych raportu podzielonego na strony z semantycznym modelem sieci szkieletowej to sobe_wowvirtualserver-<dataset ID>. Na przykład sobe_wowvirtualserver-d51fd26e-9124-467f-919c-0c48a99a1d63. Zastąp element <dataset ID> identyfikatorem zestawu danych. Identyfikator zestawu danych można uzyskać z adresu URL, wybierając identyfikator GUID, który następuje po datasets/ i przed następnym ukośnikiem.

  

• Serwer — serwer hostujący bazę danych. Zachowaj istniejący serwer w następujący sposób.

Po wdrożeniu, jeśli pobrasz język RDL raportu podzielonego na strony, może nie zostać zaktualizowany przy użyciu najnowszej wersji, którą można zobaczyć w usługa Power BI.

Jeśli masz przepływ danych zawierający modele semantyczne skonfigurowane przy użyciu odświeżania przyrostowego, zasady odświeżania nie są kopiowane ani zastępowane podczas wdrażania. Po wdrożeniu przepływu danych zawierającego model semantyczny z odświeżaniem przyrostowym na etapie, który nie obejmuje tego przepływu danych, jeśli masz zasady odświeżania, musisz ponownie skonfigurować go na etapie docelowym. Jeśli wdrażasz przepływ danych z odświeżaniem przyrostowym na etapie, w którym już się znajduje, zasady odświeżania przyrostowego nie zostaną skopiowane. W takich przypadkach, jeśli chcesz zaktualizować zasady odświeżania na etapie docelowym, należy to zrobić ręcznie.

Potoki wdrażania nie wyświetlają zestawów danych należących do magazynów danych na etapach potoku. Podczas wdrażania elementu datamart jego zestaw danych jest również wdrażany. Zestaw danych schematu danych można wyświetlić w obszarze roboczym etapu, w którym się znajduje.

Powiązana zawartość

• Wprowadzenie do integracji z usługą Git
• Wprowadzenie do potoków wdrażania