Rozwiązywanie problemów z zarządzaniem cyklem życia
Skorzystaj z tego artykułu, aby rozwiązać problemy w procesie zarządzania cyklem życia.
Aby zrozumieć zagadnienia i ograniczenia różnych problemów z zarządzaniem cyklem życia, zapoznaj się z linkami w poniższej tabeli:
Temat | Integracja z usługą Git | Potoki wdrażania |
---|---|---|
Ogólne ograniczenia | ogólne ograniczenia usługi Git | ograniczenia potoków wdrażania |
Wymagane uprawnienia | permissions | permissions |
Ograniczenia obszaru roboczego | obszary robocze | obszary robocze |
Obsługiwane elementy sieci szkieletowej | obsługiwane elementy | obsługiwane elementy |
Model semantyczny | Ograniczenia modelu semantycznego |
Opis problemu: Po przejściu do karty integracji z usługą Git otrzymuję komunikat o błędzie i nie mogę uzyskać dostępu do usługi Azure DevOps.
Przyczyna: Jeśli metoda uwierzytelniania w usłudze Power BI jest słabsza niż metoda uwierzytelniania w usłudze Azure DevOps, funkcje między nimi nie działają.
Obejście: Administrator musi dostosować metodę uwierzytelniania w usługach Power BI i Azure DevOps. Zasady uwierzytelniania dla identyfikatora Entra firmy Microsoft (wcześniej znanego jako Usługa Azure Active Directory) są definiowane w temacie Zarządzanie metodami uwierzytelniania.
Opis problemu: Gdy próbuję nawiązać połączenie z repozytorium Git, otrzymuję komunikat, że nie można nawiązać połączenia, ponieważ obszar roboczy znajduje się w innym regionie.
Przyczyna: Jeśli obszar roboczy i repozytorium znajdują się w różnych regionach, należy włączyć przełącznik między regionami.
Rozwiązanie: włącz funkcję Git Actions w obszarach roboczych znajdujących się w innych lokalizacjach geograficznych.
Opis problemu: po wybraniu pozycji Połącz na karcie Integracja z usługą Git zostanie wyświetlone okno dialogowe Wystąpił błąd . Ponadto po wybraniu przycisku kontroli źródła okienko wskazuje, że musisz przeprowadzić synchronizację z gałęzią Git.
Przyczyna: Jeśli folder, z którym próbujesz nawiązać połączenie, ma podkatalogi, ale nie ma elementów sieci szkieletowej, połączenie nie powiedzie się.
Rozwiązanie: Otwórz repozytorium Git w usłudze Azure DevOps i przejdź do folderu Git zdefiniowanego w połączeniu. Jeśli folder Git zawiera podkatalogi, sprawdź, czy co najmniej jeden z nich reprezentuje katalog elementów. Jeśli katalog zawiera pliki item.config.json i item.metadata.json, jest to katalog elementów. Jeśli katalog nie zawiera tych plików, jest to podkatalog. Jeśli folder Git nie zawiera żadnych katalogów elementów, nie możesz nawiązać z nim połączenia. Usuń podkatalogi lub połącz się z innym folderem, który nie zawiera podkatalogów.
Niepowodzenie nawiązywania połączenia: pytam, czy chcę utworzyć nowy folder podczas próby nawiązania połączenia z gałęzią Usługi Git
Opis problemu: po wybraniu pozycji Połącz na karcie integracji z usługą Git zostanie wyświetlone okno dialogowe wskazujące nieprawidłową ścieżkę folderu.
Przyczyna: folder, z którym próbujesz nawiązać połączenie, nie istnieje, został usunięty lub różni się w przypadku poufności z istniejących folderów w repozytorium. Ten komunikat może pojawić się, jeśli łączysz się z nową gałęzią lub jeśli folder został usunięty z gałęzi.
Rozwiązanie 2.
- Aby utworzyć nowy folder i połączyć go z obszarem roboczym, wybierz pozycję Utwórz i zsynchronizuj.
- Aby połączyć obszar roboczy z innym folderem, wybierz pozycję Anuluj i wybierz inny folder w ustawieniach obszaru roboczego karty integracji z usługą Git.
Opis problemu: liczba ikona kontroli źródła wskazuje liczbę zmian wprowadzonych w obszarze roboczym od czasu ostatniego zatwierdzenia. Jeśli ikona nie ma liczby, być może wystąpił problem podczas nawiązywania połączenia z gałęzią.
Rozwiązanie: Rozłącz i połącz ponownie.
Niepowodzenie połączenia: mówi, że potrzebuję licencji Premium, aby nawiązać połączenie z usługą Git
Opis problemu: Mój obszar roboczy był wcześniej połączony z repozytorium Git, ale teraz mówi, że potrzebuję licencji Premium, aby nawiązać połączenie.
Przyczyna: Możesz połączyć się tylko z repozytoriami Git, jeśli masz prawidłową licencję Premium. Jeśli licencja wygasła lub zmienisz licencję na licencję, która nie obejmuje integracji z usługą Git, nie będzie już można nawiązać połączenia z tym repozytorium. Dotyczy to również licencji wersji próbnej.
Rozwiązanie: Odłącz się od usługi Git i pracuj bez kontroli źródła lub kup licencję Premium.
Opis problemu: Nie widzę gałęzi, z którą chcę nawiązać połączenie, na karcie Rozgałęzianie na panelu sterowania Źródło.
Przyczyna: Lista rozgałęziania pokazuje tylko gałęzie, do których masz uprawnienia do wyświetlania.
Rozwiązanie: Sprawdź, czy gałąź, której chcesz użyć, i czy masz uprawnienia do jej wyświetlania. Jeśli nie, poproś właściciela gałęzi o udzielenie ci uprawnień, aby wyświetlić ograniczenia gałęzi, aby uzyskać więcej informacji.
Opis problemu: podczas rozgałęziania do nowego obszaru roboczego przechodzim do nowego obszaru roboczego, ale integracja z usługą Git nie jest tam włączona. Przyczyna: Przełącznik integracji usługi Git może być włączony dla źródłowego obszaru roboczego, ale nie dla całej dzierżawy, ponieważ administrator dzierżawy może delegować kontrolę nad przełączenia do administratorów obszaru roboczego. W takim przypadku nowy obszar roboczy nie będzie miał włączonej integracji z usługą Git i musisz ręcznie włączyć go z ustawień obszaru roboczego przed zsynchronizowaniem obszaru roboczego z usługą Git. Rozwiązanie: włącz integrację usługi Git z ustawień obszaru roboczego nowego obszaru roboczego.
Opis problemu: jeśli w gałęzi Git wprowadzono aktualizacje, zatwierdzenia są wyłączone do momentu zaktualizowania obszaru roboczego.
Rozwiązanie: Aby włączyć zatwierdzenia, zaktualizuj obszar roboczy.
Opis problemu: Podczas próby zatwierdzenia elementów w usłudze Git występuje błąd informujący, że przekroczono maksymalny rozmiar zatwierdzenia.
Przyczyna: Całkowity rozmiar plików do zatwierdzenia jest ograniczony do 50 MB.
Rozwiązanie: Jeśli próbujesz zatwierdzić kilka elementów jednocześnie, rozważ zatwierdzenie ich w mniejszych partiach. Jeśli zatwierdzenie zawiera jeden element z wieloma plikami, skontaktuj się z pomocą techniczną.
Opis problemu: Zmiana tego samego elementu w obszarze roboczym i gałęzi Git może prowadzić możliwy konflikt. Jeśli zmiany zostały wprowadzone w obszarze roboczym i w gałęzi Git w tym samym elemencie, aktualizacje są wyłączone do momentu rozwiązania konfliktu.
Rozwiązanie: rozwiąż konflikty , a następnie spróbuj ponownie.
Błąd aktualizacji: aktualizacja nie zostanie ukończona, ponieważ spowoduje przerwanie linków zależności
Opis problemu: po wybraniu opcji Aktualizuj wszystko lub Cofnij zostanie wyświetlone okno dialogowe wskazujące niepowodzenie, ponieważ akcja spowoduje przerwanie linków zależności.
Rozwiązanie: Otwórz widok Pochodzenie, aby znaleźć element lub elementy, które zostaną usunięte z obszaru roboczego w aktualizacji i są połączone z elementami, które nie zostaną usunięte z obszaru roboczego.
Aby rozwiązać ten problem, usuń problematyczne elementy:
- Jeśli element nie jest obsługiwany przez usługę Git (na przykład Pulpity nawigacyjne), usuń go ręcznie z obszaru roboczego.
- Jeśli element jest obsługiwany przez usługę Git (na przykład raporty), usuń go z usługi Git (jeśli istnieje) lub z obszaru roboczego.
Wybierz pozycję Aktualizuj wszystko.
Aby uzyskać więcej informacji, zobacz Ręczne aktualizowanie z usługi Git.
Opis problemu: po zaktualizowaniu z usługi Git podczas przeglądania widoku pochodzenia zależności niektórych elementów nie są zgodne z oczekiwaniami. Na przykład model serwera proxy nie wskazuje już prawidłowego modelu.
Przyczyna: Integracja z usługą Git nie obsługuje obecnie modeli zapytań bezpośrednich i serwerów proxy.
Rozwiązanie: Aby naprawić zależności, wykonaj jedną z następujących czynności:
- Zmodyfikuj plik bim zestawu ProxyDataset w repozytorium Git, aby wskazywać prawidłowy zestaw danych, a następnie w obszarze roboczym zaktualizuj usługę Git, aby otrzymać zmianę.
- Użyj interfejsu API aktualizacji źródła danych, aby zaktualizować szczegóły połączenia modelu serwera proxy w obszarze roboczym.
Cofnij błąd: po wybraniu opcji "Cofnij" zostanie wyświetlone okno dialogowe wskazujące niepowodzenie, ponieważ nie można odnaleźć zależności
Opis problemu: Po wykonaniu akcji cofania pojawia się następujący błąd, jeśli na karcie Zmiany nie wybrano zależności w akcji "Cofnij".
Rozwiązanie: wybierz wszystkie zależności wybranej bazy danych i spróbuj ponownie.
Błąd zależności: po wybraniu opcji "Cofnij", "Aktualizuj" lub "Przełącz gałąź" zostanie wyświetlone okno dialogowe wskazujące niepowodzenie, ponieważ akcja spowoduje przerwanie łącza zależności
Opis problemu: Po cofnięciu, aktualizacji lub akcji przełączenia gałęzi pojawia się następujący błąd:
Przyczyna: W obszarze roboczym istnieje nieobsługiwany element, który zależy od elementu, który nie znajduje się już w obszarze roboczym, powodując problem z zależnością.
Rozwiązanie: Otwórz widok Pochodzenie, aby znaleźć element lub elementy wybrane jako "cofnięte" i są połączone z elementami, które nie są zaznaczone.
Aby rozwiązać ten problem, usuń problematyczne elementy:
- Jeśli wybrany element jest obsługiwany przez usługę Git (na przykład raporty), wybierz go również do usunięcia.
- Jeśli wybrany element nie jest obsługiwany przez usługę Git (na przykład Pulpity nawigacyjne), usuń go ręcznie z obszaru roboczego.
Aby dowiedzieć się więcej na temat zależności, zobacz Omówienie zależności.
Jeśli następujące warunki nie są spełnione, nie można wyświetlić przycisku Potoki wdrażania.
Masz licencję sieci szkieletowej.
Potoki wdrażania wyświetlają tag etapu potoku w obszarach roboczych przypisanych do potoku. Aby wyświetlić te tagi, musisz być administratorem potoku. Tagi etapów programowania i testowania są zawsze widoczne. Jednak tag Produkcyjny jest widoczny tylko wtedy, gdy masz dostęp do potoku.
Opis problemu: W pełnym potoku po wyrejeczeniu obszaru roboczego z etapu, a następnie wdrożeniu potoki wdrażania ponownie publikują połączenia między elementami na etapie źródłowym wdrożonym z etapu docelowego i etapem docelowym. Jednak czasami potoki wdrażania nie mogą ponownie publikować połączeń między elementami w etapach źródłowych i docelowych. Może się to zdarzyć, na przykład w przypadku przypadkowego usunięcia elementu.
Rozwiązanie: Aby ponownie opublikować te połączenia, usuń przypisanie i ponowne przypisanie tego samego obszaru roboczego na etapie docelowym.
Przyczyna: Po przypisaniu obszaru roboczego do etapu potoków wdrażania potoki wdrażania potoki wdrażania sprawdzają elementy (takie jak raporty i pulpity nawigacyjne) w obszarze roboczym. Jeśli w sąsiednim etapie istnieją dwa elementy tego samego typu o tej samej nazwie, potoki wdrażania nie mogą określić, który z nich powinien być zgodny z jednym z nich w przypisanym obszarze roboczym, a nie może przypisać komunikatu o błędzie obszaru roboczego . Jeśli na przykład próbujesz przypisać obszar roboczy do etapu testowego, a jeden z raportów nosi nazwę "sprzedaż regionalna", jeśli istnieje więcej niż jeden raport o tej samej nazwie na etapach programowania lub produkcji, przypisanie zakończy się niepowodzeniem. Przypisanie obszaru roboczego zakończy się również niepowodzeniem, jeśli przypisany obszar roboczy ma dwa semantyczne modele o nazwie "regionalny model semantyczny sprzedaży" i istnieje semantyczny model o tej samej nazwie w etapach programowania lub produkcji.
Rozwiązanie: Aby rozwiązać ten błąd, zmień nazwę elementu, który nie jest zgodny z elementem na etapie, który próbujesz przypisać. Możesz wybrać linki w komunikacie o błędzie, aby otworzyć elementy w sieci szkieletowej.
Widzę symbol "inny" po przypisaniu obszaru roboczego z semantycznymi modelami, które są podobne do modeli semantycznych w sąsiednich etapach
Przyczyna: Większość modeli semantycznych używa rozszerzonej funkcji metadanych modelu semantycznego, znanej również jako model v3. Jednak starsze raporty mogą używać starego typu metadanych modelu semantycznego, czasami nazywanego modelem w wersji 1. Jeśli przypisujesz obszar roboczy korzystający ze starego modelu metadanych modelu semantycznego (wersja 1), potoki wdrażania nie mogą ocenić, czy model semantyczny jest podobny w sąsiednich etapach. W takich przypadkach jest wyświetlany inny symbol interfejsu użytkownika, nawet jeśli modele semantyczne są identyczne.
Rozwiązanie: Aby rozwiązać ten problem, wdróż semantyczne modele pokazujące inny symbol.
Przyczyna: Istnieje kilka powodów, dla których nie można wyświetlić obszaru roboczego na liście obszarów roboczych, które można przypisać do potoku.
Rozwiązanie: Aby przypisać obszar roboczy do potoku, muszą zostać spełnione następujące warunki:
Jesteś administratorem obszaru roboczego
Obszar roboczy nie jest przypisany do żadnego innego potoku
Obszary robocze, które nie spełniają tych warunków, nie są wyświetlane na liście obszarów roboczych, z których można wybrać.
Przyczyna: Pierwsze wdrożenie mogło zakończyć się niepowodzeniem z kilku powodów.
Rozwiązanie: Niektóre możliwe przyczyny niepowodzenia z ich rozwiązaniami są wymienione w poniższej tabeli.
Błąd | Akcja |
---|---|
Nie masz uprawnień do pojemności. | Jeśli pracujesz w organizacji, która ma pojemność sieci szkieletowej, poproś administratora pojemności o dodanie obszaru roboczego do pojemności lub poproś o uprawnienia do przypisania pojemności. Gdy obszar roboczy znajduje się w pojemności, wdróż ponownie. Jeśli nie pracujesz w organizacji z pojemnością sieci szkieletowej, rozważ zakup warstwy Premium na użytkownika (PPU). |
Nie masz uprawnień obszaru roboczego. | Aby wdrożyć, musisz być członkiem obszaru roboczego. Poproś administratora obszaru roboczego o przyznanie Ci odpowiednich uprawnień. |
Administrator sieci szkieletowej wyłączył tworzenie obszarów roboczych. | Skontaktuj się z administratorem sieci Szkieletowej, aby uzyskać pomoc techniczną. |
Używasz selektywnego wdrażania i nie wybierasz wszystkich połączonych elementów. | Wykonaj jedną z następujących czynności: Usuń zaznaczenie zawartości połączonej z semantycznym modelem lub przepływem danych. Niezaznaczonej zawartości (takiej jak modele semantyczne, raporty lub pulpity nawigacyjne) nie zostaną skopiowane do następnego etapu. Wybierz model semantyczny lub przepływ danych połączony z wybranymi elementami. Wybrane elementy zostaną skopiowane do następnego etapu. |
Przyczyna: Potoki wdrażania nie obsługują wszystkich elementów.
Rozwiązanie: Aby uzyskać kompleksową listę obsługiwanych elementów w potokach wdrażania, zobacz następujące sekcje:
Żaden element, który nie znajduje się na liście obsługiwanych elementów, nie jest kopiowany do następnego etapu.
Przyczyna: Nie można zmienić połączenia ze źródłem danych w usługa Power BI.
Rozwiązanie: Jeśli chcesz zmienić źródło danych na etapach testowania lub produkcji, możesz użyć reguł wdrażania lub interfejsów API. Reguły wdrażania będą obowiązywać dopiero po następnym wdrożeniu.
Usunięto usterkę w środowisku produkcyjnym, ale teraz przycisk "wdróż na poprzednim etapie" jest wyłączony
Przyczyna: Można wdrażać wstecz tylko na pustym etapie. Jeśli masz zawartość na etapie testowania, nie możesz wdrażać wstecz z poziomu środowiska produkcyjnego.
Rozwiązanie: po utworzeniu potoku użyj etapu programowania, aby opracować zawartość, oraz etapy testowania, aby je przejrzeć i przetestować. Możesz naprawić błędy na tych etapach, a następnie wdrożyć środowisko stałe na etapie produkcji.
Uwaga
Wdrożenie wsteczne obsługuje tylko pełne wdrożenie. Nie obsługuje selektywnego wdrażania
Przyczyna: Zmiany powodujące niezgodność schematu etapu źródłowego, takie jak zastępowanie typu kolumny z liczby całkowitej do ciągu, powodują utratę danych w docelowym modelu semantycznym po wdrożeniu.
Podczas wdrażania metadane w modelu semantycznym źródłowym są sprawdzane względem metadanych docelowych. Zmiany powodujące niezgodność schematu powodują zatrzymanie wdrożenia. W takim przypadku zostanie wyświetlony komunikat o kontynuowaniu wdrażania .
Rozwiązanie: Jeśli będziesz kontynuować wdrażanie, utracisz dane na etapie docelowym. Tej opcji można użyć, jeśli zmiany wprowadzone w modelu semantycznym były zamierzone. Po zakończeniu wdrażania należy odświeżyć docelowy model semantyczny.
Jeśli zmiany nie były zamierzone, zamknij okno komunikatu, przekaż stały plik pbix do źródłowego obszaru roboczego i ponownie wdróż go.
Po niepomyślnie wdrożeniu ze względu na zmiany schematu na etapie docelowym zostanie wyświetlony komunikat Wdrożenie nie powiodło się, a następnie link Pokaż szczegóły . Link otwiera ten sam komunikat o wdrożeniu , który został wyświetlony podczas nieudanego wdrożenia.
Przyczyna: W przypadku korzystania z odświeżania przyrostowego dozwolone są tylko pewne zmiany modelu semantycznego , które wdrażasz. Jeśli wprowadzono zmiany modelu semantycznego, które nie są dozwolone, wdrożenie zakończy się niepowodzeniem i zostanie wyświetlony następujący komunikat:
Rozwiązanie: Jeśli celowo wprowadzono zmiany w modelu semantycznym, użyj jednego z następujących obejść:
Korzystanie z pliku pbix — publikowanie zmian bezpośrednio w docelowym modelu semantycznym. Wszystkie partycje i dane zostaną utracone, więc należy odświeżyć model semantyczny.
Korzystanie z narzędzi XMLA — wprowadzanie zmian bezpośrednio w modelu semantycznym na etapie docelowym.
Przyczyna: Model semantyczny i przepływy danych to elementy sieci szkieletowej, które przechowują dane i zawierają zarówno dane, jak i metadane. Podczas wdrażania kopiowane są tylko metadane, gdy dane nie są. W związku z tym po wdrożeniu semantycznego modelu lub przepływu danych może nie mieć żadnych danych, a wizualizacja raportu, która opiera się na tych danych, zostanie uszkodzona.
Rozwiązanie: Aby rozwiązać ten problem, odśwież przepływ danych, a następnie odśwież model semantyczny na etapie docelowym.
Przyczyna: Podczas pracy z potokami wdrażania może skończyć się potok, który nie ma właściciela. Na przykład potok można pozostawić bez właściciela, gdy użytkownik, który go posiadał, opuści firmę bez przenoszenia własności. Gdy potok nie ma właściciela, inni użytkownicy nie mogą uzyskać do niego dostępu. Jako obszar roboczy można przypisać tylko do jednego potoku, jeśli jest on przypisany do potoku bez właściciela, nikt nie może go przydzielić i nie można użyć obszaru roboczego w innym potoku.
Rozwiązanie: gdy potok pozostanie bez właściciela, administrator sieci szkieletowej może dodać nowego właściciela do potoku lub usunąć go. Aby dodać właściciela do potoku, użyj interfejsu API Admin — Pipelines UpdateUserAsAdmin .
Możesz również przejrzeć nasz skrypt programu PowerShell, AddUserToWorkspacePipeline (dostępny w repozytorium GitHub PowerBI-Developer-Samples ), który umożliwia wykonanie następujących czynności:
Zarządzanie dostępem do potoku — dodaj dowolnego użytkownika do obszaru roboczego w potoku.
Odzyskaj własność obszaru roboczego — dodaj dowolnego użytkownika do obszaru roboczego w potoku, który nie ma właściciela, co umożliwia odblokowanie go.
Aby użyć tego skryptu, należy podać nazwę obszaru roboczego i nazwę główną użytkownika (UPN). Skrypt znajduje potok przypisany do obszaru roboczego i dodaj uprawnienia administratora do określonego użytkownika.
Opis problemu: Błąd nie można rozpocząć wdrażania , który wskazuje, że źródłowe i docelowe modele semantyczne mają różne formaty modelowania danych, występuje, gdy semantyczne modele na etapie docelowym mają wyższą wersję modelu niż modele semantyczne na etapie źródłowym. W takich przypadkach potoki wdrażania nie mogą być wdrażane z etapu źródłowego do etapu docelowego. Aby uniknąć tego błędu, użyj modelu semantycznego, który ma tę samą (lub wyższą) wersję modelu na etapie źródłowym.
Rozwiązanie: Uaktualnij model semantyczny na etapie źródłowym przy użyciu punktu końcowego odczytu i zapisu XMLA lub programu Power BI Desktop. Po uaktualnieniu modelu semantycznego ponownie opublikuj go na etapie źródłowym.
Opis problemu: jeśli podczas wdrażania potoki wdrażania wykryje, że tryb łączności źródła danych na etapie docelowym nie jest taki sam jak źródło danych na etapie źródłowym, próbuje przekonwertować tryb łączności źródła danych na etapie docelowym. Jeśli używasz źródła danych z połączeniem na żywo lub trybami łączności w czasie rzeczywistym, potoki wdrażania nie mogą konwertować trybu łączności źródła danych docelowego.
Rozwiązanie: użyj punktu końcowego odczytu i zapisu XMLA lub programu Power BI Desktop, aby zmienić tryb połączenia źródła danych na etapie źródłowym lub usunąć źródło danych na etapie docelowym, aby wdrożenie je zastąpiło.
Przyczyna: Wdrożenie modelu semantycznego może zakończyć się niepowodzeniem z kilku możliwych powodów. Poniżej przedstawiono możliwe przyczyny niepowodzenia:
- Duży model semantyczny nie jest skonfigurowany przy użyciu dużego formatu modelu semantycznego.
- Model semantyczny zawiera zależność cykliczną lub samodzielną (na przykład element A odwołuje się do elementu B i elementu B odwołuje się do elementu A). W takim przypadku zostanie wyświetlony następujący komunikat o błędzie: Wdrożenie co najmniej jednego elementu nie powiodło się, ponieważ spowoduje to dwukierunkową zależność między elementami.
Rozwiązanie 2.
- Jeśli model semantyczny jest większy niż 4 GB i nie korzysta z dużego formatu modelu semantycznego, wdrożenie może zakończyć się niepowodzeniem. Spróbuj ustawić model semantyczny tak, aby używał dużego formatu modelu semantycznego i ponownie wdróż go.
- Jeśli model semantyczny zawiera zależność cykliczną lub samodzielną, usuń zależność i ponownie wdróż.
Mam semantyczny model z trybem DirectQuery lub trybem łączności złożonej korzystającym z tabel odmiany lub automatycznej daty/godziny
Przyczyna: Modele semantyczne korzystające z trybu łączności DirectQuery lub złożonej i mają tabele odmiany lub automatycznej daty/godziny nie są obsługiwane w potokach wdrażania.
Rozwiązanie: Jeśli wdrożenie zakończy się niepowodzeniem i uważasz, że jest to spowodowane tym, że masz model semantyczny z tabelą odmian, możesz wyszukać właściwość odmian w kolumnach tabeli. Możesz użyć jednej z następujących metod, aby edytować model semantyczny, aby działał w potokach wdrażania.
Użyj trybu importu zamiast trybu DirectQuery lub trybu złożonego w modelu semantycznym.
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, co może spowodować uszkodzenie danych w wizualizacjach.
Rozwiązanie: Aby wdrożyć raport podzielony na strony, musisz być członkiem obszaru roboczego w wdrażanym obszarze roboczym (obszar roboczy etapu źródłowego). Jeśli nie jesteś członkiem obszaru roboczego na etapie źródłowym, nie możesz wdrożyć raportu podzielonego na strony.
Niezgodność źródła danych: Raport podzielony na strony etapu docelowego wyświetla dane z modelu semantycznego sieci szkieletowej na etapie źródłowym
Opis problemu: Obecnie modele semantyczne są traktowane jako zewnętrzne źródło danych usług Analysis Services, a połączenia z modelami semantycznymi nie są przełączane automatycznie po wdrożeniu.
Podczas wdrażania raportu podzielonego na strony połączonego z semantycznym modelem sieci szkieletowej nadal wskazuje model semantyczny, z którym został pierwotnie połączony. Użyj reguł wdrażania, aby wskazać raport podzielony na strony do dowolnego modelu semantycznego, w tym na przykład docelowego modelu semantycznego etapu.
Rozwiązanie: jeśli używasz raportu podzielonego na strony z semantycznym modelem sieci szkieletowej, zobacz Jak mogę utworzyć regułę wdrożenia dla raportu podzielonego na strony z semantycznym modelem sieci szkieletowej?
Opis problemu: Wdrożenie dużej liczby raportów podzielonych na strony z regułami może zakończyć się niepowodzeniem z powodu przeciążenia pojemności.
Rozwiązanie: kup wyższą jednostkę SKU lub użyj wdrożenia selektywnego.
Widok pochodzenia: usunięto źródło danych należące do przepływu danych, ale nadal widzę je w widoku pochodzenia
Przyczyna: W przepływach danych stare źródła danych nie są usuwane ze strony źródła danych przepływu danych. Aby obsługiwać widok pochodzenia przepływów danych, połączone elementy nie są usuwane.
Rozwiązanie: to zachowanie nie ma wpływu na potoki wdrażania. Nadal można odświeżać, edytować i wdrażać przepływy danych w potoku.
Opis problemu: po zmianie źródła danych przepływu danych przy użyciu reguły widok pochodzenia przepływu danych wyświetla połączenie między źródłem danych przepływu danych a źródłem danych skonfigurowanym w regule.
Rozwiązanie: to zachowanie nie ma wpływu na potoki wdrażania.
Rozwiązanie: Aby wdrożyć schemat danych, musisz być właścicielem elementu datamart.
Rozwiązanie: Istnieje element, który odwołuje się do siebie lub więcej niż jeden element zaangażowany w łańcuch cykliczny odwołań (na przykład element A odwołuje się do elementu B i elementu B odwołuje się do elementu A). Aby wdrożyć wykres datamart, usuń zależność cykliczną i ponownie wdróż.
Zawartość można wdrożyć na pustym etapie lub na etapie zawierającym zawartość. Zawartość musi znajdować się w pojemności sieci szkieletowej.
Wdrażanie na pustym etapie — dowolny licencjonowany użytkownik sieci szkieletowej , który jest członkiem lub administratorem w źródłowym obszarze roboczym.
Wdrażanie na etapie z zawartością — dowolny licencjonowany użytkownik sieci szkieletowej , który jest członkiem lub administratorem obu obszarów roboczych na źródłowych i docelowych etapach wdrażania.
Zastępowanie modelu semantycznego — wdrożenie zastępuje każdy semantyczny model uwzględniony w etapie docelowym, nawet jeśli model semantyczny nie został zmieniony. Każdy użytkownik, który jest członkiem lub administratorem obu obszarów roboczych, ale administrator dzierżawy może ograniczyć to tylko do docelowych właścicieli modeli semantycznych.
Przyczyna: Uprawnienia potoku i obszaru roboczego są zarządzane oddzielnie. Być może masz uprawnienia potoku, ale nie uprawnienia obszaru roboczego.
Rozwiązanie: Aby uzyskać więcej informacji, zapoznaj się z sekcją uprawnień .
Rozwiązanie: Aby przypisać obszar roboczy, musisz mieć co najmniej uprawnienia członka obszaru roboczego dla obszarów roboczych w sąsiednich etapach. Uprawnienia elementu członkowskiego obszaru roboczego (lub wyższego) w sąsiednich etapach są wymagane, aby umożliwić potokom wdrażania nawiązywanie połączeń między elementami na sąsiednich etapach potoku.
Rozwiązanie: Jeśli masz problemy z konfigurowaniem reguł wdrażania, odwiedź stronę Reguły wdrażania i upewnij się, że przestrzegasz ograniczeń reguł wdrażania.
Jeśli wdrożenie zakończyło się wcześniej pomyślnie i nagle kończy się niepowodzeniem z powodu uszkodzonych reguł, może to być spowodowane ponownego opublikowania modelu semantycznego. Następujące zmiany w modelu semantycznym źródłowym powodują niepowodzenie wdrożenia:
Usunięty parametr
Zmieniona nazwa parametru
W regułach wdrażania brakuje wartości. Może się tak zdarzyć, jeśli model semantyczny uległ zmianie.
Gdy wcześniejsze pomyślne wdrożenie zakończy się niepowodzeniem z powodu przerwanych łączy, zostanie wyświetlone ostrzeżenie. Możesz wybrać pozycję Konfiguruj reguły , aby przejść do okienka reguł wdrażania, w którym jest oznaczony model semantyczny, który zakończył się niepowodzeniem. Po wybraniu modelu semantycznego zostaną oznaczone uszkodzone reguły.
Aby pomyślnie wdrożyć, napraw lub usuń uszkodzone reguły i ponownie wdróż.
Przyczyna: Reguły wdrażania nie są stosowane natychmiast po ich skonfigurowaniu.
Rozwiązanie: Aby zastosować reguły wdrażania, należy wdrożyć modele semantyczne z etapu źródłowego do etapu docelowego, który obejmuje utworzone reguły wdrażania. Po skonfigurowaniu reguł wdrażania i przed wdrożeniem inny wskaźnik jest wyświetlany obok modelu semantycznego ze skonfigurowanymi regułami. Oznacza to, że należy wdrożyć ten semantyczny model z etapu źródłowego do etapu docelowego. Po wdrożeniu, jeśli nie wprowadzono żadnych innych zmian, inny wskaźnik zniknie, co oznacza, że reguły zostały zastosowane pomyślnie.
Rozwiązanie: Aby utworzyć regułę wdrożenia, musisz być właścicielem elementu, dla którego tworzysz regułę wdrażania. Jeśli nie jesteś właścicielem elementu, reguły wdrażania są wyszarzone.
Jeśli jedna z opcji reguły jest wyszarzona, może to być spowodowane następującymi przyczynami:
Reguły źródła danych — nie ma źródeł danych, dla których można skonfigurować regułę.
Reguły parametrów — nie ma parametrów, dla których można skonfigurować regułę.
Rozwiązanie: Zapisywanie reguł źródła danych może zakończyć się niepowodzeniem z jednego z następujących powodów:
Model semantyczny zawiera funkcję połączoną ze źródłem danych. W takich przypadkach reguły źródła danych nie są obsługiwane.
Źródło danych używa parametrów. Nie można utworzyć reguły źródła danych dla modelu semantycznego, który używa parametrów. Zamiast tego utwórz regułę parametru.
Nie mogę nawiązać połączenia z modelem semantycznym podczas tworzenia nowej reguły modelu semantycznego
Przyczyna: Podczas konstruowania modelu semantycznego przy użyciu programu Power BI Desktop można skonfigurować parametry połączenia. Później model semantyczny można opublikować i używać go przez potoki wdrażania w usługa Power BI. Podczas tworzenia połączenia w programie Power BI Desktop można określić dodatkowe parametry. Podczas określania parametrów źródło modelu semantycznego musi być pierwszym parametrem wymienionym na liście. Jeśli wyświetlisz listę innych parametrów przed semantycznym źródłem modelu, wystąpią błędy w usługa Power BI. W takich przypadkach podczas konfigurowania nowej reguły modelu semantycznego, jeśli wskażesz model semantyczny, który nie został prawidłowo skonfigurowany w programie Power BI Desktop, potoki wdrażania nie mogą utworzyć reguły.
Rozwiązanie: Sformatuj połączenie modelu semantycznego w programie Power BI Desktop, aby źródło modelu semantycznego było wyświetlane w pierwszym wierszu. Następnie ponownie opublikuj model semantyczny.
Ta sekcja służy do rozwiązywania problemów z utworzonymi regułami potoku. Jeśli nie widzisz nazwy komunikatu o błędzie reguły, zapoznaj się z ograniczeniami reguły wdrażania i obsługiwanymi źródłami danych dla reguł przepływu danych i reguł modelu semantycznego i spróbuj ponownie skonfigurować regułę.
Komunikat o błędzie | Rozwiązanie |
---|---|
Reguła źródła danych nie może zawierać parametru | Nie można zastosować reguły, ponieważ nazwa serwera lub nazwa bazy danych, do których odwołuje się reguła, jest kontrolowana przez parametr. Aby zmienić nazwę serwera lub bazy danych, użyj reguły parametru lub usuń parametr sterujący ze skonfigurowanego elementu. |
Niepowodzenie wykonywania źródła danych | Nie można zastosować reguły z powodu problemu podczas pobierania danych ze źródła danych. Usuń regułę i upewnij się, że model semantyczny ma prawidłowe zapytania. Następnie spróbuj ponownie utworzyć regułę. |
Właściwość reguły już nie istnieje | Niektóre właściwości reguły skonfigurowane w regule już nie istnieją. Odśwież stronę i ponownie skonfiguruj regułę. |
Niedozwolona wartość | Wartość używana w skonfigurowanej regule jest nieprawidłowa. Zweryfikuj wartości reguły i spróbuj ponownie skonfigurować regułę. |
Wiele źródeł danych nie jest obsługiwanych | Nie można zastosować reguły modelu semantycznego ze względu na konfigurację źródła danych. Usuń regułę lub zapisz ponownie zapytania modelu semantycznego przy użyciu standardowych narzędzi programu Power BI Desktop. |
Model semantyczny docelowy można zmienić tylko przez jego właściciela | Reguła zastąpi niektóre semantyczne modele w docelowym obszarze roboczym. Musisz być właścicielem dowolnego modelu semantycznego, który zostanie zastąpiony. |