Uwaga
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
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 | Potok wdrażania |
---|---|---|
Ogólne ograniczenia | ogólne ograniczenia usługi Git | ograniczenia pipeline'ów wdrożeniowych |
Wymagane uprawnienia | Uprawnienia | Uprawnienia |
Ograniczenia obszaru roboczego | obszary robocze | obszary robocze |
Obsługiwane elementy fabryki | obsługiwane elementy | obsługiwane elementy |
Model semantyczny | Ograniczenia modelu semantycznego |
Integracja z usługą Git
Problemy z dostępem
Nie mogę uzyskać dostępu do repozytorium usługi Azure DevOps
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 zintegrować 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.
Przekroczono limit szybkości usługi Git
Opis problemu: Podczas próby zaktualizowania lub zatwierdzenia w usłudze Git pojawia się komunikat o błędzie informujący o przekroczeniu limitu szybkości usługi Git.
Przyczyna: Dostawca usługi Git ogranicza liczbę akcji usługi Git, które można wykonać w danym czasie. Limit szybkości można osiągnąć, wykonując dużą liczbę operacji git lub wykonując operacje obejmujące dużą liczbę elementów. Aby uzyskać informacje o limitach szybkości usługi GitHub, zobacz About primary rate limits (Informacje o podstawowych limitach szybkości). Aby uzyskać informacje o limitach usługi Azure DevOps, zobacz Limity szybkości i użycia.
Rozwiązanie: Zaczekaj czas określony w komunikacie o błędzie, a następnie spróbuj ponownie. Jeśli ten błąd będzie nadal wyświetlany, skontaktuj się z dostawcą usługi Git, aby uzyskać więcej informacji.
Problemy z połączeniem
Błąd połączenia: Nie można nawiązać połączenia z repozytorium
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.
Błąd połączenia: mówi się, że wystąpił problem podczas próby nawiązania połączenia
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 połączyć się, ma podkatalogi, ale nie ma elementów Fabric, 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.
Ikona kontroli źródła nie ma liczby
Opis problemu: Liczba na ikonie kontroli źródła oznacza 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.
Rozgałęzianie: nie widzę gałęzi, z którą chcę nawiązać połączenie
Opis problemu: Nie widzę obszaru roboczego, z którym chcę się połączyć, w zakładce rozgałęziania na panelu kontroli źródła.
Przyczyna: na liście rozgałęziania są wyświetlane tylko obszary robocze, do których masz uprawnienia do wyświetlania.
Rozwiązanie: Sprawdź, czy istnieje obszar roboczy, który chcesz zobaczyć, i czy masz uprawnienia do jego wyświetlania. Jeśli nie, poproś właściciela obszaru roboczego o udzielenie Ci uprawnień. Aby uzyskać więcej informacji, zobacz Ograniczenia gałęzi.
Rozgałęzianie: Mój nowy obszar roboczy nie został zsynchronizowany z repozytorium Git
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 usługi Git, ponieważ administrator dzierżawy usługi Git może powierzyć kontrolę nad przełącznikiem administratorom 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ę Git w ustawieniach swojego nowego obszaru roboczego.
Problemy z folderem połączeń
Niepowodzenie połączenia: pyta, czy chcę utworzyć nowy folder podczas próby połączenia z gałęzią 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.
Mój status Git wskazuje, że mam niezatwierdzone zmiany, ale nie wprowadziłem żadnych zmian w moim środowisku pracy.
Opis problemu: Chcę zaktualizować mój obszar roboczy, ale pojawia się informacja, że mam niezapisane zmiany. Nie wprowadzono żadnych zmian w obszarze roboczym.
Przyczyna: jeśli obszar roboczy ma foldery, a połączony folder Git nie ma jeszcze podfolderów, są one uważane za inne. Jeśli obszar roboczy zawiera foldery, ale gałąź Git nie zawiera, zobaczysz komunikat niezatwierdzonych zmian. Jeśli spróbujesz zaktualizować obszar roboczy przed zatwierdzeniem zmian, wystąpi konflikt. Gdy folder Git ma taką samą strukturę folderów jak obszar roboczy, ten komunikat nie będzie już wyświetlany.
Rozwiązanie: aby rozwiązać ten problem, zatwierdź zmiany w usłudze Git. Jeśli nie możesz wprowadzać zmian bezpośrednio w połączonej gałęzi, zalecamy użycie opcji gałęzi roboczej. Aby uzyskać więcej informacji, zobacz Bezpieczne zarządzanie zmianami folderów.
Zgłoś problemy
Przycisk Zatwierdź jest wyłączony
Opis problemu: jeśli w gałęzi Git wprowadzono aktualizacje, zatwierdzenia są wyłączone do momentu zaktualizowania obszaru roboczego.
Rozwiązanie: Aby włączyć zatwierdzanie zmian, zaktualizuj obszar roboczy.
Przekroczono maksymalny rozmiar komitu
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ą.
Problemy z aktualizacją
Przyciski Zatwierdź i Aktualizuj są wyłączone
Opis problemu: Zmiana tego samego elementu w obszarze roboczym i gałęzi Git może prowadzić do potencjalnego konfliktu. 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: Napraw zduplikowane identyfikatory logiczne
Opis problemu: Podczas próby aktualizacji zostanie wyświetlone okno dialogowe wskazujące niepowodzenie, ponieważ katalog Git zawiera elementy z zduplikowanymi identyfikatorami logicznymi.
Przyczyna: logiczny identyfikator każdego elementu w obszarze roboczym musi być unikatowy. Podczas kopiowania elementu w obszarze roboczym identyfikator logiczny jest automatycznie zmieniany na unikatowy identyfikator. Podczas kopiowania katalogu elementu w usłudze Git identyfikator logiczny nie jest zmieniany. Jeśli skopiujesz plik elementu w Git, a następnie spróbujesz zaktualizować go do przestrzeni roboczej, duplikowany jest logiczny identyfikator, co powoduje błąd.
Rozwiązanie: aby rozwiązać ten problem, przed zaktualizowaniem obszaru roboczego należy zmienić identyfikator logiczny zduplikowanego elementu lub elementów w usłudze Git. Dostępne są dwie opcje:
Jeśli masz uprawnienia do bezpośredniego zatwierdzania zmian w gałęzi, wybierz Napraw z bezpośrednim zatwierdzeniem. Spowoduje to zmodyfikowanie pliku systemowego elementu w celu utworzenia unikatowego identyfikatora logicznego w usłudze Git. Dane obszaru roboczego nie zostaną zmodyfikowane, dopóki nie zostaną zaktualizowane z usługi Git.
Jeśli nie masz uprawnień do wprowadzania bezpośrednich zatwierdzeń zmian w gałęzi, wybierz pozycję Utwórz gałąź i przejdź do Git. Spowoduje to otwarcie nowej gałęzi i zmianę identyfikatora logicznego. Następnie należy scalić zmiany w usłudze Git, zanim będą widoczne w usłudze Fabric. Następnie po zaktualizowaniu z usługi Git dane obszaru roboczego zostaną zmodyfikowane.
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 łącza zależności.
Rozwiązanie: Otwórz widok Rodowód, aby znaleźć element lub elementy, które zostaną usunięte z obszaru roboczego podczas 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.
Niepowodzenie aktualizacji postu: zależności nie wskazują na właściwe elementy
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 ProxyDataset w repozytorium Git, aby wskazywać prawidłowy zestaw danych, a następnie w obszarze roboczym zaktualizuj z Git, aby otrzymać zmianę.
- Użyj API aktualizacji źródła danych, aby zaktualizować szczegóły połączenia modelu proxy w obszarze roboczym.
Rozwiązywanie błędów
Napraw zduplikowane identyfikatory logiczne
Opis problemu: Podczas próby zatwierdzenia zmian w usłudze Git zostanie wyświetlony komunikat o błędzie informujący, że w obszarze roboczym znajdują się zduplikowane identyfikatory logiczne.
Przyczyna: Identyfikator logiczny jest unikatowym identyfikatorem dla każdego elementu w obszarze roboczym. Podczas kopiowania elementu w usłudze Git cały folder jest dokładnie duplikowany, łącznie z identyfikatorem logicznym. Podczas próby zaktualizowania obszaru roboczego system sprawdza zduplikowane identyfikatory logiczne i uniemożliwia zatwierdzanie zmian w przypadku znalezienia.
Rozwiązanie: Aby rozwiązać ten problem, należy zmienić identyfikator logiczny jednego z elementów.
Jeśli masz uprawnienia do zapisu w repozytorium, wybierz pozycję Napraw z bezpośrednim zatwierdzeniem. Zostanie automatycznie utworzona nowa gałąź. Zmień identyfikator logiczny skopiowanego elementu w nowej gałęzi, a następnie zatwierdź zmiany.
Jeśli nie masz uprawnień do zapisu w repozytorium, wybierz pozycję Utwórz gałąź i przejdź do usługi Git*. Zostanie automatycznie utworzona nowa gałąź. Zmień identyfikator logiczny skopiowanego elementu w nowej gałęzi, a następnie utwórz żądanie ściągnięcia, aby scalić zmiany.
Cofnij działania powodujące problemy
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 w karcie Zmiany istnieje niezapisana zależność, która nie została wybrana 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łąź" pojawi się okno dialogowe informujące o niepowodzeniu, ponieważ akcja spowoduje przerwanie zależności.
Opis problemu: Po cofnięciu, aktualizacji lub przełączeniu 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 dziedziczenia, aby znaleźć elementy wybrane do cofnięcia, które są połączone z nienaznaczonymi elementami.
Aby rozwiązać ten problem, usuń problematyczne elementy:
- Jeśli element, który nie jest wybrany, jest obsługiwany przez usługę Git (na przykład raporty), wybierz go, aby również został usunięty.
- 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.
Potok wdrażania
Nie widzę przycisku kanałów wdrażania
Aby wyświetlić przycisk potoków wdrożeniowych, należy spełnić następujące warunki.
Masz licencję Fabric.
Masz uprawnienia administratora dla potoku wdrażania, do którego przypisany jest obszar roboczy.
Nie widzę tagu etapu przepływu w obszarze roboczym
Potoki wdrożeniowe wyświetlają tag etapu potoku w obszarach roboczych przypisanych do potoków. Aby wyświetlić te tagi, musisz być administratorem Pipeline. Tagi dla etapów Development i Test są zawsze widoczne. Jednak tag Produkcja jest widoczny tylko wtedy, gdy masz dostęp do potoku.
Utracone połączenia po wdrożeniu
Opis problemu: W pełnym potoku, po odłączeniu obszaru roboczego z etapu, a następnie jego wdrożeniu, potoki wdrażania ponownie nawiązują połączenia między elementami w etapie źródłowym, z którego zostało wykonane wdrożenie, i etapem docelowym. Jednak czasami potoki wdrażania nie mogą ponownie nawiązywać połączeń między elementami na etapach źródłowych i docelowych. Może się to zdarzyć, na przykład w przypadku przypadkowego usunięcia elementu.
Rozwiązanie: Aby przywrócić te połączenia, usuń przypisanie i ponownie przypisz ten sam obszar roboczy na etapie docelowym.
Nie mogę przypisać obszaru roboczego do etapu
Przyczyna: Po przypisaniu obszaru roboczego do etapu potoków wdrażania, potoki te sprawdzają elementy (takie jak raporty i pulpity nawigacyjne) w obszarze roboczym. Jeśli w sąsiednim etapie są dwa elementy tego samego typu o tej samej nazwie, potoki wdrażania nie mogą określić, który z nich powinien pasować do elementu w przypisanym obszarze roboczym i pojawia się komunikat o błędzie nie można przypisać 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 Fabric.
Widzę symbol "inny" po przypisaniu obszaru roboczego z modelami semantycznymi, podobnymi do tych 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 semantycznego (wersja 1), procesy wdrażania nie mogą ocenić, czy model semantyczny jest podobny na kolejnych 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.
Nie widzę wszystkich moich obszarów roboczych, gdy próbuję przypisać obszar roboczy do pipeline'u.
Przyczyna: Istnieje kilka powodów, dla których nie widzisz obszaru roboczego w spisie obszarów roboczych, które można przypisać do potoku.
Rozwiązanie: Aby przypisać obszar roboczy do pipeline'u, muszą zostać spełnione następujące warunki:
Jesteś administratorem obszaru roboczego
Przestrzeń robocza nie jest przypisana do żadnego innego pipeline'u.
Obszar roboczy znajduje się w pojemności Fabric
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ć.
Moje pierwsze wdrożenie nie powiodło się
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 zarządzania pojemnością. | Jeśli pracujesz w organizacji, która ma pojemność Fabric, poproś administratora pojemności o dodanie twojego obszaru roboczego do pojemności lub poproś o uprawnienia do przypisania pojemności. Gdy obszar roboczy uzyska odpowiednią pojemność, przeprowadź ponowne wdrożenie.
Jeśli nie pracujesz w organizacji z pojemnością Fabric, rozważ zakup usługi Premium na użytkownika (PPU). |
Nie masz uprawnień do obszaru roboczego. | Aby wdrożyć, musisz być członkiem środowiska pracy. Poproś administratora obszaru roboczego o przyznanie Ci odpowiednich uprawnień. |
Administrator Fabric wyłączył tworzenie obszarów roboczych. | Skontaktuj się z administratorem Fabric, aby uzyskać pomoc. |
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. Niezaznaczona zawartość (taka jak modele semantyczne, raporty lub pulpity nawigacyjne) nie zostanie skopiowana do następnego etapu. Wybierz model semantyczny lub przepływ danych połączony z wybranymi elementami. Wybrane elementy zostaną skopiowane do następnego etapu. |
Mam 'nieobsługiwane elementy' w mojej przestrzeni roboczej, kiedy próbuję wdrożyć.
Przyczyna: Potoki wdrażania nie obsługują wszystkich elementy.
Rozwiązanie: Aby uzyskać kompleksową listę elementów obsługiwanych w potokach wdrażania, zobacz poniższe sekcje:
Żaden element, który nie znajduje się na liście obsługiwanych elementów, nie jest kopiowany do następnego etapu.
Chcę zmienić źródło danych na etapach potoku danych
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.
Naprawiłem usterkę w produkcji, ale teraz przycisk "wdrożenie na poprzednim etapie" jest wyłączony.
Przyczyna: Możesz wdrażać tylko wstecz na pustą scenę. 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 rozwoju, aby opracować twoją zawartość, oraz etapu testowania, aby ją ocenić 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 wyłącznie pełne wdrożenie. Nie obsługuje selektywnego wdrażania
Komunikat o błędzie: "kontynuuj wdrażanie"
Przyczyna: Zmiany powodujące złamanie schematu źródłowego etapu, takie jak zmiana typu kolumny z liczby całkowitej na ciąg, 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 łamiące schemat 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 nieudanym wdrożeniu z powodu zmian w schemacie, 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 kontynuacji wdrożenia, który został wyświetlony podczas nieudanego wdrożenia.
Komunikat o błędzie: "Nie można uruchomić 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 zpliku 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 — Wprowadź swoje zmiany bezpośrednio w modelu semantycznym w docelowym etapie.
Moja wizualizacja uległa awarii po wdrożeniu modelu semantycznego lub przepływu danych
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, natomiast dane nie są. W rezultacie, po wdrożeniu, model semantyczny lub przepływ danych może nie zawierać żadnych danych, a wizualizacja raportu, która polega na tych danych, może wyglądać na błędną.
Rozwiązanie: Aby rozwiązać ten problem, odśwież przepływ danych, a następnie odśwież model semantyczny na etapie docelowym.
Jak usunąć potok danych, który nie posiada właściciela (osierocony potok danych)?
Przyczyna: Podczas pracy z potokami wdrażania może się zdarzyć, że pipeline nie będzie miał właściciela. Na przykład, pipeline może pozostać bez właściciela, gdy użytkownik, który go posiadał, opuszcza firmę bez przekazania własności. Gdy potok nie ma właściciela, inni użytkownicy nie mogą uzyskać do niego dostępu. Jako że obszar roboczy można przypisać tylko do jednego potoku, jeśli został przypisany do potoku bez właściciela, nikt nie może go od-przypisać 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, skorzystaj z 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ądzaj dostępem do potoku - Dodaj dowolnego użytkownika do przestrzeni roboczej w potoku.
Odzyskaj własność obszaru roboczego — możesz dodać dowolnego użytkownika do obszaru roboczego w przepływie pracy, który nie ma właściciela, co pozwoli go odblokować.
Aby użyć tego skryptu, należy podać nazwę obszaru roboczego i nazwę główną użytkownika (UPN). Skrypt znajduje pipeline przypisany do obszaru roboczego i dodaje uprawnienia administratora do użytkownika, którego określiłeś.
Błąd niezgodności: Niezgodność wersji formatu semantycznego modelu między źródłem a celem
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żaniowe nie mogą wdrażać 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.
Błąd niezgodności: Tryb łączności źródła danych nie jest zgodny
Opis problemu: Podczas wdrażania, jeśli potoki wdrażania wykryją, że tryb łączności źródła danych na etapie docelowym nie jest taki sam jak tryb źródła 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 bezpośrednim połączeniem lub trybem łączności w czasie rzeczywistym, potoki wdrażania nie mogą zmienić trybu łączności docelowego źródła danych.
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 w fazie źródłowej, lub usuń źródło danych w fazie docelowej, aby wdrożenie je zastąpiło.
Wdrożenie modelu semantycznego nie powiodło się
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 w formacie dużego 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 go wdroż.
- Jeśli model semantyczny zawiera zależność cykliczną lub samodzielną, usuń zależność i ponownie wdróż.
Mam semantyczny model w trybie DirectQuery lub w trybie łączności Kompozytowym, korzystający z tabel wariantów lub automatycznych dat/czasów.
Przyczyna: Modele semantyczne korzystające z trybu łączności DirectQuery lub trybu łączności złożonej i mają tabele wariantów lub automatyczne tabele 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.
Raporty wielostronicowe
Nie mogę wdrożyć raportu podzielonego na strony
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 stronicowany dla etapu docelowego wyświetla dane z modelu semantycznego Fabric 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, który jest połączony z semantycznym modelem Fabric, nadal wskazuje on na semantyczny model, z którym był pierwotnie połączony. Użyj zasad wdrażania, aby skierować raport ze stronicowaniem do dowolnego modelu semantycznego, 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?
Niepowodzenie wdrażania: duża liczba raportów podzielonych na strony kończy się niepowodzeniem
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.
Przepływy danych
Widok pochodzenia: usunąłem źródło danych należące do przepływu danych, jednak nadal widzę je w widoku pochodzenia
Przyczyna: W przepływach danych stare źródła danych nie są usuwane ze strony źródeł 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 procesy wdrażania. Nadal możesz odświeżać, edytować i wdrażać przepływy danych w potoku.
Widzę dwa źródła danych połączone z moim przepływem danych po użyciu reguł przepływu danych.
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 pierwotnym źródłem danych przepływu a źródłem danych skonfigurowanym w regule.
Rozwiązanie: to zachowanie nie ma wpływu na procesy wdrażania.
Magazyny danych
Problem z wdrażaniem: nie mogę wdrożyć datamartu w potoku
Rozwiązanie: Aby wdrożyć datamart, musisz być właścicielem datamartu.
Problem z wdrożeniem: wdrożenie elementu datamart nie powiodło się z powodu zależności cyklicznej
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ć datamart, usuń zależność cykliczną i ponownie wdroż.
Uprawnienia
Kto może wdrażać zawartość między etapami?
Zawartość można rozmieścić na pustym etapie lub na etapie z zawartością. Zawartość musi znajdować się na zasobie Fabric.
Wdrażanie na pustym środowisku — dowolny licencjonowany użytkownik Fabric, który jest członkiem lub administratorem w źródłowym obszarze roboczym.
Wdrażanie na etapie z zawartością — każdy licencjonowany użytkownik Fabric, który jest członkiem lub administratorem obu obszarów roboczych na etapie wdrażania źródłowego i docelowego.
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, może to zrobić, ale administrator dzierżawy może ograniczyć to tylko do właścicieli docelowych modeli semantycznych.
Nie widzę obszaru roboczego w pipeline
Przyczyna: Uprawnienia pipeline'u i obszaru roboczego są zarządzane oddzielnie. Być może masz uprawnienia do potoku, ale nie uprawnienia do obszaru roboczego.
Rozwiązanie: Aby uzyskać więcej informacji, zapoznaj się z sekcją uprawnień .
Komunikat o błędzie: "wymagane uprawnienia członka obszaru roboczego"
Rozwiązanie: Aby przypisać obszar roboczy, musisz mieć co najmniej uprawnienia członka obszaru roboczego dla obszarów roboczych w sąsiednich etapach. Uprawnienia członka zespołu (lub wyższe) w sąsiednich etapach są wymagane, aby umożliwić potokom wdrożeniowym nawiązywanie połączeń między etapami w sąsiednich częściach potoku.
Reguły
Niepowodzenie wdrażania z powodu uszkodzonych reguł
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:
Reguły parametrów
Usunięty parametr
Zmieniona nazwa parametru
Reguły źródła danych
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óż.
Problem z wdrażaniem: skonfigurowano reguły, ale nie wdrożono
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.
Reguły wdrażania są wyszarzone
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 przedmiotu, reguły wdrażania są wyszarzone.
Jeśli jedna z opcji reguły jest wyszarzona, może to wynikać z następujących przyczyn:
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łę.
Moja reguła źródła danych dla modelu semantycznego nie powiodła się
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ą wspierane.
Twoje ź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ć przez potoki wdrażania w usłudze 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łudze 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, wątki wdrożeniowe 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.
Rozwiązywanie problemów
Ta sekcja służy do rozwiązywania problemów z regułami potoku, które utworzyłeś. 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 przetwarzania ź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. |