Strona główna
» Technologia
»
Błędy Salesforce Workbench: rozwiązywanie problemów z narzędziami API podczas przestoju
Błędy Salesforce Workbench: rozwiązywanie problemów z narzędziami API podczas przestoju
Zweryfikowano 16 września 2026 r. Błędy Workbencha łatwo zinterpretować podczas incydentu związanego z Salesforce. Nieudane logowanie może wynikać z wygasłej sesji, nieprawidłowego środowiska, uszkodzonej ścieżki Workbencha lub awarii interfejsu API Salesforce. Żądanie, które zwraca 503 Service Unavailablepunkty w innym kierunku niż 401 Invalid Session, mimo że oba te błędy mogą wystąpić, gdy programista stara się szybko pracować.
Celem rozwiązywania problemów nie jest wymuszone przetworzenie jednego żądania. Chodzi o zidentyfikowanie warstwy, która zawodzi, ochronę danych w czasie niestabilności systemu oraz o ustalenie, kiedy dowody są wystarczająco silne, aby poczekać, zmienić narzędzie lub skontaktować się z odpowiednim kanałem wsparcia.
Szybka diagnoza: co najprawdopodobniej wskazuje na błąd?
Co widzisz
Najbardziej prawdopodobna warstwa
Najlepszy następny ruch
Strona warsztatu nie ładuje się
Witryna Workbench, przeglądarka, DNS lub ścieżka sieciowa
Otwórz Salesforce Trust Status i przetestuj witrynę z poziomu dozwolonej sieci alternatywnej.
Workbench się ładuje, ale logowanie kończy się niepowodzeniem z błędem 401
Sesja, OAuth, nazwa użytkownika, hasło lub przepływ logowania
Rozpocznij nowe autoryzowane logowanie i potwierdź wybrane środowisko.
Żądanie API zwraca 403
Uprawnienia, zasady dotyczące aplikacji połączonych lub limity API
Sprawdź limity użytkownika, podłączonej aplikacji i żądań. Nie traktuj tego jako dowodu przestoju.
Kilka wywołań API zwraca 500, 502 lub 503
Platforma Salesforce, routing brzegowy, konserwacja lub przeciążenie
Porównaj czas wystąpienia błędu ze stanem swojego wystąpienia i produktu w Trust.
Tylko jedno zapytanie lub obiekt nie działa
Żądanie składni, dostępu do obiektu, udostępniania rekordów lub problemu z danymi
Zredukuj żądanie do nieszkodliwego, znanego dobrego odczytu i sprawdź treść odpowiedzi.
Ta tabela stanowi punkt wyjścia, a nie diagnozę. Ten sam kod HTTP może mieć różne przyczyny w zależności od punktu końcowego, metody uwierzytelniania i polityki organizacji.
Najpierw zrozum granice wsparcia Workbench
Workbench to oparty na przeglądarce pakiet do interakcji z organizacjami Salesforce za pośrednictwem kilku interfejsów API, w tym REST, SOAP, Bulk, Streaming, Metadata i narzędzi Apex. Na stronie Workbench podano jednak, że nie jest to oficjalny produkt Salesforce i że wsparcie Salesforce nie jest dostępne dla samego Workbench. Strona „Informacje” ostrzega również użytkowników przed używaniem aplikacji z danymi produkcyjnymi.
To ostrzeżenie zmienia sposób reagowania w czasie przestoju. Wsparcie Salesforce może zbadać problem z usługą Salesforce, instancją lub interfejsem API, ale może nie rozwiązać wszystkich problemów z interfejsem Workbench. Z drugiej strony, problem zgłoszony tylko przez Workbench może dotyczyć Workbench lub ścieżki przeglądarki, a nie platformy Salesforce.
W miarę możliwości przechowuj informacje o rozwiązywaniu problemów w trybie tylko do odczytu. Nie wklejaj haseł, tajnych kluczy OAuth, identyfikatorów sesji, tokenów dostępu, rekordów klientów ani nieocenzurowanych nagłówków żądań do zrzutów ekranu, wiadomości czatu ani publicznych raportów o problemach.
Zacznij od zidentyfikowania ścieżki logowania do Workbencha i wybranego środowiska. Przedstawiony interfejs to przykładowa makieta, a nie ekran logowania na żywo ani prośba o podanie danych logowania do obrazu artykułu.
Krok 1: Sprawdź status zaufania Salesforce przed zmianą ustawień Workbench
Otwórz Status zaufania Salesforce w osobnej karcie. Dokumentacja pomocy Salesforce kieruje klientów na tę stronę w przypadku awarii produktu lub pogorszenia jakości usług, a witryna „Zaufanie” może zawierać informacje zarówno o produktach, jak i o konkretnych przypadkach.
Sprawdź dwa widoki:
Szeroki widok produktu: sprawdź, czy wystąpił incydent, pogorszenie jakości usług, przerwa w działaniu lub zdarzenie konserwacyjne, które ma wpływ na używaną przez Ciebie usługę Salesforce.
Widok Twojej instancji: wyszukaj swoją instancję lub Moją domenę i otwórz pasujący wynik.
Oznaczenie instancji jako „Dostępna” nie gwarantuje, że każda operacja API będzie działać. Oznacza to, że instancja i jej usługi są dostępne zgodnie z definicją statusu w Salesforce. „Pogorszenie wydajności” sugeruje, że dostęp może działać z opóźnieniem lub z ograniczoną funkcjonalnością; „Przerwa w świadczeniu usług” oznacza, że instancja jest niedostępna; „Konserwacja” oznacza zdarzenie konserwacyjne, które może, ale nie musi, wpłynąć na dostęp.
Krok 1 — Porównaj ogólne informacje o statusie zaufania z instancją organizacji, której dotyczy problem. Pokazany ekran jest ilustracją udokumentowanego procesu wyszukiwania, a nie dowodem rzeczywistego incydentu.
Krok 2: Przed ponowną próbą sprawdź środowisko i organizację
Workbench może łączyć się z różnymi środowiskami Salesforce. Zanim stwierdzisz, że API nie działa, sprawdź, czy nieudane żądanie dotyczy środowiska produkcyjnego, piaskownicy, czy innego autoryzowanego środowiska. Test zakończony sukcesem w jednym środowisku nie czyści środowiska, w którym wystąpił błąd.
Użyj identyfikatora „Moja domena” lub instancji dla organizacji, której dotyczy problem. Salesforce dokumentuje, że prefiks „Moja domena” można użyć w polu „Status zaufania”, a administrator może znaleźć instancję w sekcji „ Informacje o firmie” w sekcji „Konfiguracja”. Zapisz instancję, środowisko, wersję API, przybliżony czas awarii i punkt końcowy. Ten niewielki zapis zapobiega częstemu błędowi: porównywaniu błędu produkcyjnego ze stanem poprawnego środowiska testowego.
Jeśli strona logowania Workbench wyświetla nieobsługiwaną metodę logowania lub powraca do ekranu logowania, należy traktować to jako osobny problem z uwierzytelnianiem lub Workbench, dopóki status zaufania i bezpośrednie logowanie do Salesforce nie wskażą inaczej. Nie należy wielokrotnie przesyłać danych uwierzytelniających w przypadku podejrzenia awarii; nadmierne ponawianie prób może spowodować blokady lub utrudnić dochodzenie.
Krok 3: Klasyfikuj odpowiedź API zamiast zgadywać
Dokumentacja interfejsu API REST firmy Salesforce wyjaśnia, że nagłówek odpowiedzi zawiera kod statusu HTTP, a treść zazwyczaj zawiera komunikat oraz, w stosownych przypadkach, pole lub obiekt powiązany z błędem. Zachowaj oba dowody.
Kod
Udokumentowana wskazówka Salesforce
Jak to interpretować w czasie przestoju
400
Żądanie nie mogło zostać zrozumiane, często dlatego, że treść JSON lub XML była nieprawidłowa.
Zwykle należy naprawić zgłoszenie zanim potraktujesz je jako awarię.
401
Identyfikator sesji lub token OAuth wygasł lub jest nieprawidłowy.
Dokonaj ponownego uwierzytelnienia za pomocą zatwierdzonego przepływu; sam błąd 401 nie stanowi dowodu na awarię platformy.
403
Prośba została odrzucona, często ze względu na uprawnienia lub limity API.
Przed zgłoszeniem problemu z dostępnością sprawdź dostęp i limity.
500
Wystąpił błąd na platformie Lightning.
Ponów próbę dopiero po zapisaniu odpowiedzi; porównaj powtarzające się błędy ze statusem zaufania.
502
Salesforce Edge nie mógł nawiązać komunikacji z instancją.
Możliwe są problemy z trasowaniem lub po stronie platformy, szczególnie w przypadku wielu żądań.
503
Serwer jest niedostępny. Możliwe, że trwają prace konserwacyjne lub serwer jest przeciążony.
Sprawdź, czy nie wystąpił incydent lub zdarzenie konserwacyjne i unikaj ponownych prób, które mogą skutkować zniszczeniem urządzenia.
Krok 3 — Zapisz kod HTTP i znaczenie odpowiedzi przed zmianą danych logowania lub żądań. Przykład nie zawiera tokena, danych klienta ani rzeczywistego identyfikatora incydentu.
Krok 4: Przeprowadź bezpieczny test porównawczy
Znając status i środowisko, użyj najmniejszego dozwolonego testu tylko do odczytu. Dobre porównanie ma trzy cechy: dotyczy organizacji, której dotyczy problem, nie modyfikuje danych i jest na tyle proste, że błąd w formacie żądania jest mało prawdopodobny.
Powtórz tę samą nieszkodliwą prośbę jeszcze raz po nagraniu pierwszej odpowiedzi.
Jeśli żądanie zwróci kod błędu 401, należy rozpocząć nowy proces uwierzytelniania zamiast ponownego używania starej sesji.
Jeśli zwróci kod 400, 403 lub 404, sprawdź punkt końcowy, wersję interfejsu API, nazwę obiektu, uprawnienia i treść żądania.
Jeśli wielokrotnie zwracana jest wartość 500, 502 lub 503, porównaj czas i wystąpienie ze stanem zaufania.
Jeśli interfejs użytkownika przeglądarki działa, ale Workbench nie działa, przetestuj tę samą autoryzowaną ścieżkę API przy użyciu zatwierdzonego wewnętrznego klienta lub diagnostyki integracji.
Nie należy używać żądania zapisu, usunięcia, zbiorczej aktualizacji, wdrożenia metadanych ani migracji jako kontroli stanu. Podczas incydentu, zapis może prowadzić do częściowych wyników, duplikacji pracy lub błędnego wrażenia, że nastąpiło odzyskanie.
Kiedy należy zmienić podejście do rozwiązywania problemów?
Zmień podejście, gdy status zaufania wskazuje na incydent
Przestań przeprojektowywać zapytanie, chyba że masz niezależne dowody na to, że żądanie jest nieprawidłowe. Zapisz numer incydentu, usługę, której dotyczy problem, instancję, godzinę rozpoczęcia i ostatnią aktualizację. Postępuj zgodnie z komunikatami odzyskiwania Salesforce i chroń zadania w kolejce przed duplikowaniem prób.
Zmień podejście, gdy status zaufania jest dostępny, ale sam Workbench zawodzi
Skoncentruj się na Workbenchu, przeglądarce, sieci, uwierzytelnianiu lub polityce lokalnej. Wypróbuj prywatne okno przeglądarki, obsługiwaną przeglądarkę alternatywną i porównanie dozwolonych sieci. Witryna Workbench kieruje pomoc techniczną dotyczącą Workbencha do zasobów społeczności open source, podczas gdy Salesforce Help pozostaje drogą do uzyskania pomocy technicznej dotyczącej produktu i konta Salesforce.
Zmień podejście, gdy błąd stale wynosi 401 lub 403
Przejdź do analizy tożsamości i autoryzacji. Potwierdź użytkownika, zasady połączonej aplikacji, zakres OAuth, wiek sesji, dostęp do API, profil lub zestaw uprawnień oraz limity organizacji. Wielokrotne odświeżanie przeglądarki nie naprawi brakującego uprawnienia ani nieprawidłowego tokena.
Zmień podejście, gdy jeden punkt końcowy ulegnie awarii, ale proste odczyty działają
Zbadaj punkt końcowy, obiekt, pole, udostępnianie rekordów, wersję API, treść żądania i treść odpowiedzi. Wąska awaria nie wystarczy, aby globalnie zablokować Salesforce. Zmniejszaj żądanie, aż będziesz w stanie określić, czy problem dotyczy składni, dostępu, danych, czy usługi zależnej.
Krok 4 — Przestrzegaj ograniczeń dotyczących wsparcia i bezpieczeństwa Workbench. Korzystaj z zatwierdzonego wsparcia Salesforce w przypadku incydentów na platformie oraz zasobów społeczności open source dotyczących zachowań specyficznych dla Workbench.
Kod HTTP, kod błędu i zredagowana treść odpowiedzi
Czy interfejs użytkownika Salesforce, inny użytkownik lub inny zatwierdzony klient również zawiedzie
Numer zdarzenia dotyczącego statusu zaufania lub informacja o braku widocznego pasującego zdarzenia
Przed wysłaniem logów usuń dane uwierzytelniające, identyfikatory sesji, tokeny dostępu, nazwy klientów, identyfikatory rekordów i poufne dane. Jeśli problem dotyczy tylko Workbencha, skorzystaj z pomocy technicznej wskazanej na stronie pomocy Workbencha . Salesforce nie zapewnia pomocy technicznej dla samego Workbencha.
Jak zweryfikować odzyskiwanie
Zielony wskaźnik statusu napawa optymizmem, ale nie oznacza to mety. Sprawdź regenerację warstwami:
Sprawdź, czy strona incydentu wskazuje rozwiązanie, w przeciwnym razie instancja powróci do statusu Dostępne.
Zaloguj się za pomocą zatwierdzonego przepływu pracy Salesforce lub Workbench bez konieczności ponownego korzystania z nieaktualnej sesji.
Uruchom to samo nieszkodliwe żądanie tylko do odczytu, które wcześniej się nie powiodło.
Porównaj kod HTTP, czas odpowiedzi i treść odpowiedzi z zarejestrowanym błędem.
Sprawdź integracje, zadania w kolejce i powiadomienia dotyczące opóźnionych lub zduplikowanych zadań.
Oczekiwany rezultat to nie tylko „otwarcie strony”. Chcesz, aby oryginalna autoryzowana operacja zakończyła się sukcesem, przyniosła oczekiwaną reakcję i nie wywołała żadnych niesprawdzonych efektów ubocznych.
Lista kontrolna samokontroli
Zakres: Czy sprawdziłeś stronę zaufania na poziomie produktu i problematyczny przypadek?
Środowisko: Czy potwierdzono środowisko produkcyjne, środowisko testowe i prawidłową domenę My Domain lub instancję?
Dowód: Czy zapisałeś dokładny kod HTTP, kod błędu, czas i zredagowaną odpowiedź?
Bezpieczeństwo: Czy podczas incydentu udało Ci się uniknąć żądań zapisu, usuwania, masowego wdrażania i migracji?
Decyzja: Czy rozróżniłeś zachowanie typowe dla Workbench od awarii interfejsu API Salesforce?
Odzyskiwanie: Czy ponownie przetestowałeś oryginalną operację i sprawdziłeś opóźnione prace następcze?
Podsumowanie
W przypadku błędów Salesforce Workbench występujących podczas przestoju, należy zacząć od stanu zaufania i odpowiedniej instancji, a następnie sklasyfikować odpowiedź HTTP przed zmianą danych uwierzytelniających lub ponownym zapisaniem żądań. Powtarzające się błędy 500, 502 lub 503 w prostych testach tylko do odczytu i odpowiadający im incydent zaufania uzasadniają wyjaśnienie po stronie Salesforce. Błąd 401, 403, 400 lub błąd dotyczący tylko Workbench zazwyczaj wymaga uwierzytelnienia, uprawnień, żądania, przeglądarki lub rozwiązania problemu z Workbench. Ponieważ Workbench nie jest produktem obsługiwanym przez Salesforce, należy unikać danych produkcyjnych, jasno udokumentować granice i korzystać z najnowszych oficjalnych informacji o stanie i pomocy technicznej w przypadku zmiany danych.