Salesforce Workbench hibák: API eszközök hibaelhárítása leállás közben

Salesforce Workbench hibák leállás közben: kezdjük az eszközhiba és a platformhiba elkülönítésével

Amikor a Salesforce Workbench hirtelen leáll a bejelentkezéssel, a REST Explorer hibát ad vissza, vagy egy percekkel ezelőtt működő lekérdezés időtúllépést jelez, a leggyorsabb megoldás az, ha nem kattintunk folyamatosan az Újra gombra. Először állapítsuk meg, hogy melyik réteg hibázik: a Workbench webalkalmazás, a böngésző vagy a hálózat, a Salesforce hitelesítés, az adott Salesforce-példány vagy maga az API-kérés.

Ez a megkülönböztetés azért fontos, mert a Workbench egy közösség által karbantartott, webalapú API-segédprogram, nem pedig egy teljes mértékben támogatott Salesforce termék. A Salesforce kifejezetten kijelenti, hogy nem tartja karban a Workbench-et, és olyan támogatott alternatívákat ajánl, mint a Salesforce CLI, a Code Builder és a Salesforce Extensions for Visual Studio Code. Maga a Workbench projekt is csak karbantartásra szánt eszközként írja le az eszközt. Lásd a Salesforce Workbench cseréjére vonatkozó útmutatót és az eredeti Workbench forráskód-tárházat .

Használja ezt az oldalt gyakorlati referenciaként, ha szolgáltatáskiesés vagy romló teljesítmény gyanúja merül fel. A cél a bizonyítékok megőrzése, a felesleges újrapróbálkozások elkerülése, valamint annak eldöntése, hogy várjon-e, eszközt váltson, vagy valami helyi problémát javítson-e.

Gyors triázs ellenőrzőlista

1. A konfiguráció módosítása előtt ellenőrizze a Salesforce Trust beállítást

Látogasson el a hivatalos Salesforce Trust állapot webhelyre , és keresse meg a szervezetéhez kapcsolódó példányt, tartományt, podot vagy bérlőt. A Salesforce incidensek lehetnek regionálisak vagy példányspecifikusak, így egy nem kapcsolódó példány zöld állapota nem bizonyítja, hogy a szervezete egészséges.

Ha a Trust szolgáltatáskiesést, teljesítményromlást, bejelentkezési problémát vagy a környezetet érintő karbantartást jelent, jegyezze fel az incidens azonosítóját és időpontját. Ezután kerülje a csatlakoztatott alkalmazások, hitelesítő adatok, profilok, engedélykészletek, hálózati házirendek vagy API-verziók spekulatív módosítását, kivéve, ha a hiba kifejezetten ezekre a beállításokra mutat. A kiesés során végrehajtott konfigurációs módosítások a platform helyreállása után egy második problémát okozhatnak.

2. Őrizze meg a pontos Workbench hibát, és osztályozza azt

A Workbench gyakran kevés értelmezéssel továbbítja a Salesforce API hibaválaszokat. Ez hasznos a hibaelhárításhoz: a pontos HTTP állapot, a Salesforce hibakód, a végpont és az üzenet általában többet elárul, mint egy általános böngésző banner.

Kapcsolati hiba, időtúllépés vagy HTTP 5xx

Az időtúllépés, az 502-es, 503-as vagy más 5xx-es válasz a szolgáltatás romlására, a túlterhelt infrastruktúrára vagy egy köztes hálózati hibára utalhat. Ne feltételezze, hogy az 5xx egy Salesforce-szintű kimaradást bizonyít. Hasonlítsa össze ugyanazt a könnyűsúlyú kérést egy másik jóváhagyott klienstől, és ellenőrizze a Megbízhatóságot. Ha több kliens is meghibásodik ugyanazon Salesforce-példányon egyszerre, a bizonyítékok a Workbench-től eltérően szólnak.

401-es vagy érvénytelen munkamenet-hibák

Ezek általában hitelesítési vagy munkamenet-problémákra utalnak. Végezzen újra hitelesítést OAuth használatával a régi munkamenet-azonosítók böngészők közötti másolása helyett. Ha a normál Salesforce bejelentkezés is sikertelen, és a Trust bejelentkezési hatást jelez, várja meg a szolgáltatás helyreállítását, mielőtt lecserélné a hitelesítő adatokat. Ha a Salesforce bejelentkezés működik, de a Workbench OAuth nem, vizsgálja meg a Workbench csatlakoztatott alkalmazás elérési útját, vagy használjon egy támogatott alternatív klienst.

403-as és engedélyezési hibák

A 403-as hiba általában azt jelenti, hogy a kérés elért egy olyan szolgáltatást, amely elutasította azt. Ellenőrizze a felhasználói engedélyeket, a csatlakoztatott alkalmazásra vonatkozó szabályzatot, az IP-korlátozásokat és a pontos Salesforce hibakódot. Egy ismert Workbench-specifikus példa a OAUTH_APP_BLOCKED, amely akkor fordulhat elő, amikor egy rendszergazda blokkolja a Workbench csatlakoztatott alkalmazását. A Workbench projekt csatlakoztatott alkalmazásokra vonatkozó útmutatója ezt a forgatókönyvet írja le.

3. Csökkentse a tesztet a legkisebb biztonságos API-kérésre

Gyanított leállás esetén ne végezzen diagnózist tömeges betöltéssel, metaadat-telepítéssel, hosszú SOQL-lekérdezéssel vagy többlépéses szkripttel. Kezdjen egy csak olvasható végponttal, amely olcsón végrehajtható. A REST Explorerben egy olyan kérés, mint a , az GET /services/data/alapvető API-elérhetőséget ellenőrzi. Egy olyan kérés, mint a , GET /services/data/v66.0/limitssegíthet a szervezeti korlátok vizsgálatában, amikor az API működik.

A Salesforce dokumentálja a Workbench REST Explorert a REST végpontok meghívásának módjaként, de a Workbench nem ideális nagyméretű vagy teljesítményigényes műveletekhez. Az eredeti Workbench dokumentáció megjegyzi, hogy a böngésző és a kapcsolat időtúllépései miatt jobban alkalmas a gyors, menet közbeni API-interakciókhoz, mint a nagy adatbetöltésekhez vagy -exportálásokhoz.

4. Az API-korláttal kapcsolatos hibákat a leállástól eltérően kezelje

REQUEST_LIMIT_EXCEEDEDnem ugyanaz, mint egy platformkiesés. A Salesforce API-kérések allokációját alkalmazza, és amikor egy szervezet túllépi a gördülő használati korlátját, a további API-hívások blokkolhatók, amíg a használat a küszöbérték alá nem esik. A Salesforce 2026. júliusi támogatási cikke megerősíti, hogy a REST API, a SOAP API, a Bulk API és a Bulk API 2.0 hívások mind hozzájárulnak az API-fogyasztáshoz. Lásd a Salesforce REQUEST_LIMIT_EXCEEDED utasítással és a hozzá tartozó gördülő API-korlát magyarázatával kapcsolatos útmutatóját .

Ha a hiba egy határérték, az ismételt újrapróbálkozások súlyosbítják a helyzetet azáltal, hogy több hívást fogyasztanak, amikor a kérések még elfogadottak. Azonosítsa a nagy volumenű integrációkat, szüneteltesse a nem létfontosságú feladatokat, ahol működésileg biztonságos, és figyelje a használatot a Salesforce beállításaiban. Ne várjon egy bizalmi incidensre a bérlőre jellemző korlátozási probléma megoldásához.

5. Ellenőrizze az API-verzió eltérését

UNSUPPORTED_API_VERSIONMegérdemel egy külön ágat. A Salesforce 2026 májusában közzétett egy támogatási cikket, amely elmagyarázza, hogy a Workbench alapértelmezés szerint egy újabb API-verzióra válthat, mielőtt egy éles vagy fejlesztői kiadású szervezet támogatná azt. A Workbench ajánlott javítása az alapértelmezett API-verzió lecsökkentése a célszervezet által támogatott verzióra. Lásd a Salesforce UNSUPPORTED_API_VERSION hibaelhárítási cikkét .

Ez a kiadási ablakok alatt fontos, mivel az API-verzió eltérése kiesésnek tűnhet, ha csak az időzítésre koncentrál. Mielőtt a platform helyreállítására várna, ellenőrizze magát a verzióhibát.

6. Hasonlítsa össze a Workbench-et egy támogatott klienssel

Ha a feladat sürgős, és a Workbench az egyetlen meghibásodó komponens, akkor reprodukálja a legkisebb kérést a Salesforce CLI vagy egy másik támogatott, jóváhagyott kliens segítségével. A cél a diagnózis, nem pedig egy valódi Salesforce-kiesés megkerülése. Ha mindkét kliens ugyanazon szervezet ellen hibázik hasonló szerveroldali hibákkal, az eszközök közötti váltás valószínűleg nem fogja helyreállítani a szolgáltatást. Ha a CLI sikeres, miközben a Workbench meghibásodik, akkor erősebb bizonyítéka van arra, hogy a Workbench-tárhely, a böngésző munkamenet vagy a csatlakoztatott alkalmazás elérési útja a probléma.

7. Újrapróbálkozási fegyelmet alkalmazzon az újrapróbálkozási viharok helyett

Megerősített szolgáltatáskimaradás esetén az agresszív manuális újrapróbálkozások ritkán segítenek. Automatizált kliensek esetén korlátozott újrapróbálkozásokat használjon exponenciális várakozással és időbeli ingadozással, ahol az integrációs terv ezt lehetővé teszi. Manuális Workbench használat esetén várjon egy érdemi állapotfrissítésre vagy egy ésszerű időközönként, mielőtt megismételné ugyanazt a kérést.

Írási műveletek esetén legyen különösen óvatos. Az időtúllépés nem mindig bizonyítja, hogy a Salesforce nem tett semmit; előfordulhat, hogy az ügyfél elvesztette a választ, miután a szerver feldolgozta a kérést. Mielőtt újraküldené a létrehozási, frissítési, törlési vagy telepítési műveletet, ellenőrizze, hogy az eredeti művelet végrehajtásra került-e. A duplikált írások gyakran károsabbak, mint a késleltetett újrapróbálkozások.

Gyakori tünetek és a következő teendők

Milyen bizonyítékokat kell gyűjteni egy baleseti jegyhez?

• UTC időbélyeg és a helyi időzóna.
• Belsőleg biztonságosan megosztható Salesforce szervezeti és példányazonosítók.
• A pontos végpont és HTTP-metódus, a bizalmas paraméterek eltávolításával.
• HTTP állapot, Salesforce errorCodeés egy rövid válaszrészlet.
• Hogy működött-e a normál Salesforce bejelentkezés.
• Azt jelzi, hogy ugyanaz a minimális kérés sikertelen volt-e egy második jóváhagyott klienstől.
• Releváns Salesforce Trust incidensazonosító, vagy egy megjegyzés, miszerint nem látható egyező incidens.
• Azt jelzi, hogy a művelet írásvédett volt-e, vagy írást is lehetett volna végrehajtani.

Soha ne illesszen be hozzáférési tokeneket, jelszavakat, munkamenet-azonosítókat, OAuth engedélyezési kódokat vagy teljes bizalmas adatmennyiségeket megosztott jegyekbe vagy csevegőcsatornákba.

Mikor kell abbahagyni a Workbench és a Switch Tools hibaelhárítását?

Váltson el a Workbenchről, ha a hiba egyértelműen a Workbenchre korlátozódik, ha a művelet túl nagy egy böngészőalapú segédprogramhoz, ha ismételhető szkriptelt viselkedésre van szüksége, vagy ha támogatott fejlesztési munkafolyamatra van szüksége. A Salesforce saját csereútmutatója kifejezetten a Code Builder, a Salesforce CLI és a Salesforce Extensions for VS Code felé irányítja a fejlesztőket.

Ne válts eszközöket csak azért, hogy folyamatosan zaklass egy elérhetetlen Salesforce szolgáltatást. Egy másik kliens nem tudja elhárítani a szerveroldali leállást, és az ismételt hívások zajosabbá tehetik a diagnózist. Leállás esetén a legjobb eredmény egy egyértelmű besorolás: megerősített platformincidens, csak Workbench-hiba, helyi hálózati/böngészős probléma, API-verzióeltérés, engedély/hitelesítési probléma, API-korlát kimerülése vagy kérés-specifikus hiba.

A lényeg

A Salesforce Workbench hibái könnyebben kezelhetők, ha jelzésként, nem pedig diagnózisként kezeljük őket. Ellenőrizzük a Salesforce Trust funkciót, őrizzük meg a pontos hibát, csökkentsük a kérést, hasonlítsuk össze egy támogatott klienssel, és kövessük a hibakódot. Ez a sorrend segít elkerülni a felesleges konfigurációs változtatásokat a leállások során, miközben azokat a problémákat is kiszűri, amelyek leállásnak tűnnek, de valójában bérlő- vagy Workbench-specifikusak.