Грешки в Salesforce Workbench: Отстраняване на неизправности в API инструменти по време на престой

Грешки в Salesforce Workbench по време на престой: започнете с разграничаване на повредата на инструмента от повредата на платформата

Когато Salesforce Workbench внезапно спре да влиза в системата, REST Explorer върне грешка или заявка, която е работила преди минути, започне да изтича, най-бързият път е да не продължавате да кликвате върху „Опитай отново“. Първо определете кой слой не работи: уеб приложението Workbench, вашият браузър или мрежа, удостоверяването на Salesforce, вашият конкретен екземпляр на Salesforce или самата API заявка.

Това разграничение е важно, защото Workbench е уеб-базирана API програма, поддържана от общността, а не напълно поддържан продукт на Salesforce. Salesforce изрично заявява, че не поддържа Workbench и препоръчва поддържани алтернативи като Salesforce CLI, Code Builder и Salesforce Extensions for Visual Studio Code. Самият проект Workbench също описва инструмента като само за поддръжка. Вижте ръководството за подмяна на Workbench на Salesforce и оригиналното хранилище с изходен код на Workbench .

Използвайте тази страница като практическо ръководство, когато има съмнение за прекъсване или влошена услуга. Целта е да се запазят доказателства, да се избегнат ненужни повторни опити и да се реши дали да се изчака, да се сменят инструментите или да се поправи нещо локално.

Контролен списък за бърз триаж

1. Проверете доверието в Salesforce, преди да промените конфигурацията си

Отидете на официалния сайт за доверително управление на Salesforce и потърсете екземпляра, домейна, под-а или клиента, съответстващ на вашата организация. Инцидентите в Salesforce могат да бъдат регионални или специфични за екземпляр, така че зеленият статус за несвързан екземпляр не доказва, че вашата организация е в добро състояние.

Ако Trust съобщи за прекъсване на услугата, влошаване на производителността, проблем с влизането или поддръжка, засягащи вашата среда, запишете идентификационния номер и часа на инцидента. След това избягвайте да правите спекулативни промени в свързани приложения, идентификационни данни, профили, набори от разрешения, мрежови правила или версии на API, освен ако грешката не сочи конкретно към тези настройки. Промените в конфигурацията, направени по време на прекъсване, могат да създадат втори проблем след възстановяването на платформата.

2. Запазете точната грешка на Workbench и я класифицирайте

Workbench често пропуска отговорите за грешки на Salesforce API с малко интерпретация. Това е полезно за отстраняване на проблеми: точният HTTP статус, кодът за грешка в Salesforce, крайната точка и съобщението обикновено ви казват повече от общ банер на браузъра.

Грешка в връзката, изтичане на времето за изчакване или HTTP 5xx

Отговор от типа „timeout“, код 502, 503 или друг код 5xx може да е свързан с влошаване на услугата, претоварена инфраструктура или междинна мрежова повреда. Не приемайте, че код 5xx доказва прекъсване в целия Salesforce. Сравнете същата „lehka“ заявка от друг одобрен клиент и проверете „Trust“ (Доверие). Ако няколко клиента се провалят едновременно в един и същ Salesforce екземпляр, доказателствата сочат далеч от Workbench.

Грешки 401 или невалидна сесия

Те обикновено сочат към проблеми с удостоверяването или сесията. Удостоверете отново с OAuth, вместо да копирате стари идентификатори на сесии между браузърите. Ако нормалното влизане в Salesforce също е неуспешно и Trust отчете въздействие върху влизането, изчакайте възстановяване на услугата, преди да завъртите идентификационните данни. Ако влизането в Salesforce работи, но Workbench OAuth не, проверете пътя на свързаното приложение в Workbench или използвайте поддържан алтернативен клиент.

403 и грешки при оторизация

Код 403 обикновено означава, че заявката е достигнала до услуга, която я е отказала. Проверете потребителските разрешения, правилата за свързаните приложения, ограниченията за IP адреси и точния код на грешката в Salesforce. Един известен пример, специфичен за Workbench, е OAUTH_APP_BLOCKED, което може да възникне, когато администратор блокира свързаното приложение Workbench. Ръководството за свързани приложения на проекта Workbench описва този сценарий.

3. Намалете теста до най-малката безопасна API заявка

По време на предполагаем прекъсване, не извършвайте диагностика с групово зареждане, внедряване на метаданни, дълга SOQL заявка или многоетапен скрипт. Започнете с крайна точка само за четене, която е лесна за изпълнение. В REST Explorer, заявка като GET /services/data/проверява основната достъпност на API. Заявка като GET /services/data/v66.0/limitsможе да ви помогне да проверите ограниченията на организацията, когато API функционира.

Salesforce документира Workbench REST Explorer като начин за извикване на REST крайни точки, но Workbench не е идеален за големи или интензивни операции. Оригиналната документация на Workbench отбелязва, че времето за изчакване на браузъра и връзката го прави по-подходящ за бързи API взаимодействия в движение, отколкото за големи зареждания или експортиране на данни.

4. Отнасяйте грешките, свързани с ограниченията на API, различно от прекъсванията

REQUEST_LIMIT_EXCEEDEDне е същото като прекъсване на платформата. Salesforce прилага разпределения на API заявки и когато дадена организация надвиши своя лимит за използване, по-нататъшни API извиквания могат да бъдат блокирани, докато използването не падне под прага. Статията за поддръжка на Salesforce от юли 2026 г. потвърждава, че извикванията на REST API, SOAP API, Bulk API и Bulk API 2.0 допринасят за потреблението на API. Вижте ръководството на Salesforce за REQUEST_LIMIT_EXCEEDED и обяснението за неговото подвижно ограничение на API .

Ако грешката е ограничение, многократните опити влошават ситуацията, като консумират повече повиквания, когато заявките все още се приемат. Идентифицирайте интеграции с голям обем, поставете на пауза несъществени задачи, където е безопасно за работа, и наблюдавайте използването в Salesforce Setup. Не чакайте инцидент с доверие, за да разрешите проблем с ограничението, специфично за наемателя.

5. Проверете за несъответствие между версията на API

UNSUPPORTED_API_VERSIONзаслужава собствен клон. Salesforce публикува статия за поддръжка от май 2026 г., обясняваща, че Workbench може по подразбиране да използва по-нова версия на API, преди производствена организация или организация за разработчици да я поддържа. Препоръчителното решение за Workbench е да се намали версията на API по подразбиране до такава, поддържана от целевата организация. Вижте статията за отстраняване на неизправности UNSUPPORTED_API_VERSION на Salesforce .

Това е важно по време на прозорците за пускане на пазара, защото несъответствието между API и версията може да изглежда като прекъсване, ако се фокусирате само върху времето. Проверете самата грешка във версията, преди да изчакате възстановяване на платформата.

6. Сравнете Workbench с поддържан клиент

Ако задачата е спешна и Workbench е единственият компонент, който се поврежда, възпроизведете най-малката заявка, използвайки Salesforce CLI или друг поддържан, одобрен клиент. Целта е диагностика, а не заобикаляне на истински прекъсване на Salesforce. Ако и двата клиента се провалят в една и съща организация със сравними грешки от страна на сървъра, е малко вероятно смяната на инструменти да възстанови услугата. Ако CLI е успешен, докато Workbench се проваля, имате по-силни доказателства, че проблемът е в хостинга на Workbench, сесията на браузъра или пътя на свързаното приложение.

7. Използвайте дисциплина при повторни опити вместо бури от повторни опити

По време на потвърдено прекъсване на услугата, агресивните ръчни повторни опити рядко помагат. За автоматизирани клиенти използвайте ограничени повторни опити с експоненциално отлагане и трептене, където вашият дизайн на интеграция го позволява. За ръчно използване на Workbench изчакайте смислена актуализация на състоянието или разумен интервал, преди да повторите същата заявка.

За операции по запис, бъдете особено внимателни. Времето за изчакване не винаги доказва, че Salesforce не е направил нищо; клиентът може да е загубил отговора, след като сървърът е обработил заявката. Преди да изпратите отново създаване, актуализиране, изтриване или внедряване, проверете дали оригиналното действие е извършено. Дублираните записи често са по-вредни от забавения повторен опит.

Чести симптоми и следващи действия

Какви доказателства трябва да съберете за фиш за инцидент?

• UTC времеви отпечатък и вашата местна часова зона.
• Идентификатори на организации и екземпляри на Salesforce, които са безопасни за вътрешно споделяне.
• Точната крайна точка и HTTP метод, с премахнати чувствителни параметри.
• HTTP статус, Salesforce errorCodeи кратък откъс от отговора.
• Дали нормалното влизане в Salesforce работеше.
• Дали същата минимална заявка е била неуспешна от втори одобрен клиент.
• Съответен идентификационен номер на инцидент в Salesforce Trust или бележка, че не е видим съответстващ инцидент.
• Дали операцията е била само за четене или е могла да извърши запис.

Никога не поставяйте токени за достъп, пароли, идентификатори на сесии, кодове за оторизация на OAuth или пълни чувствителни полезни данни в споделени билети или чат канали.

Кога да спрете отстраняването на проблеми в Workbench и да смените инструментите

Преминете от Workbench към Workbench, когато повредата е ясно изолирана, когато операцията е твърде голяма за браузър-базирана помощна програма, когато се нуждаете от повтарящо се скриптово поведение или когато се нуждаете от поддържан работен процес за разработка. Собственото ръководство за замяна на Salesforce насочва разработчиците специално към Code Builder, Salesforce CLI и Salesforce Extensions за VS Code.

Не сменяйте инструменти само за да продължите да затруднявате недостъпна услуга на Salesforce. Различен клиент не може да отстрани прекъсване от страна на сървъра, а многократните повиквания могат да направят диагнозата по-шумна. По време на прекъсване, най-добрият резултат е ясна класификация: потвърден инцидент на платформата, повреда само на Workbench, проблем с локалната мрежа/браузъра, несъответствие между версиите на API, проблем с разрешенията/удостоверяването, изчерпване на лимита на API или повреда, специфична за заявката.

Долен ред

Грешките в Salesforce Workbench са по-лесни за обработка, когато се третират като сигнали, а не като диагнози. Проверете доверието в Salesforce, запазете точната грешка, намалете заявката, сравнете с един поддържан клиент и следвайте кода на грешката. Тази последователност ви помага да избегнете ненужни промени в конфигурацията по време на прекъсвания, като същевременно откривате проблеми, които изглеждат като прекъсване, но всъщност са специфични за наемателя или Workbench.