ข้อผิดพลาดของ Salesforce Workbench: การแก้ไขปัญหาเครื่องมือ API ระหว่างช่วงเวลาที่ระบบหยุดทำงาน

ตรวจสอบแล้วเมื่อวันที่ 16 กันยายน 2026ข้อผิดพลาดใน Workbench นั้นง่ายต่อการตีความผิดระหว่างเหตุการณ์ที่เกิดขึ้นใน Salesforce การเข้าสู่ระบบล้มเหลวอาจเกิดจากเซสชันหมดอายุ สภาพแวดล้อมที่ไม่ถูกต้อง เส้นทาง Workbench ที่เสียหาย หรือการหยุดทำงานของ Salesforce API คำขอที่ส่งคืนค่าจะชี้ไป503 Service Unavailableในทิศทางที่แตกต่างจาก401 Invalid Sessionแม้ว่าทั้งสองอย่างอาจปรากฏขึ้นเมื่อนักพัฒนาพยายามทำงานอย่างรวดเร็วก็ตาม

เป้าหมายของการแก้ไขปัญหาไม่ใช่การบังคับให้คำขอใดคำขอหนึ่งผ่านไปได้ แต่เป็นการระบุว่าเลเยอร์ใดล้มเหลว ปกป้องข้อมูลในขณะที่ระบบไม่เสถียร และรู้ว่าเมื่อใดที่หลักฐานมีความชัดเจนเพียงพอที่จะรอ เปลี่ยนไปใช้เครื่องมืออื่น หรือติดต่อช่องทางการสนับสนุนที่ถูกต้อง

วิเคราะห์อย่างรวดเร็ว: ข้อผิดพลาดนี้บ่งชี้ถึงอะไรมากที่สุด?

ตารางนี้เป็นเพียงจุดเริ่มต้น ไม่ใช่การวินิจฉัยโรค รหัส HTTP เดียวกันอาจมีสาเหตุแตกต่างกัน ขึ้นอยู่กับปลายทาง วิธีการตรวจสอบสิทธิ์ และนโยบายขององค์กร

ขั้นแรก ให้ทำความเข้าใจขอบเขตการสนับสนุนของ Workbench ก่อน

Workbench เป็นชุดเครื่องมือบนเว็บเบราว์เซอร์สำหรับการโต้ตอบกับองค์กร Salesforce ผ่าน API หลายประเภท รวมถึง REST, SOAP, Bulk, Streaming, Metadata และเครื่องมือที่เกี่ยวข้องกับ Apex อย่างไรก็ตาม เว็บไซต์ของ Workbench ระบุว่าไม่ใช่ผลิตภัณฑ์อย่างเป็นทางการของ Salesforce และไม่มีการสนับสนุนจาก Salesforce สำหรับ Workbench เอง นอกจากนี้ หน้าเกี่ยวกับ (About) ยังเตือนผู้ใช้ไม่ให้ใช้แอปพลิเคชันนี้กับข้อมูลที่ใช้งานจริง

คำเตือนดังกล่าวจะเปลี่ยนวิธีการตอบสนองของคุณในช่วงเวลาที่ระบบหยุดทำงาน ฝ่ายสนับสนุนของ Salesforce สามารถตรวจสอบปัญหาของบริการ อินสแตนซ์ หรือ API ของ Salesforce ได้ แต่พวกเขาอาจไม่สามารถแก้ไขปัญหาพฤติกรรมของอินเทอร์เฟซ Workbench ทุกอย่างได้ ในทางกลับกัน ปัญหาที่รายงานโดย Workbench เท่านั้น อาจเป็นปัญหาของ Workbench หรือเส้นทางของเบราว์เซอร์มากกว่าแพลตฟอร์ม Salesforce

ควรตั้งค่าการแก้ไขปัญหาเป็นแบบอ่านอย่างเดียวทุกครั้งที่ทำได้ ห้ามวางรหัสผ่าน ข้อมูลลับ OAuth รหัสเซสชัน โทเค็นการเข้าถึง บันทึกข้อมูลลูกค้า หรือส่วนหัวคำขอที่ไม่ถูกปกปิดลงในภาพหน้าจอ ข้อความแชท หรือรายงานปัญหาแบบสาธารณะ

ขั้นตอนที่ 1: ตรวจสอบสถานะความน่าเชื่อถือของ Salesforce ก่อนเปลี่ยนแปลงการตั้งค่า Workbench

เปิดสถานะความน่าเชื่อถือของ Salesforceในแท็บใหม่ เอกสารช่วยเหลือของ Salesforce แนะนำให้ลูกค้าเข้าชมหน้านี้สำหรับกรณีที่ผลิตภัณฑ์ขัดข้องหรือบริการมีคุณภาพลดลง และเว็บไซต์ความน่าเชื่อถือยังสามารถแสดงข้อมูลสำหรับผลิตภัณฑ์ต่างๆ รวมถึงกรณีเฉพาะได้อีกด้วย

ตรวจสอบสองมุมมอง:

1. ภาพรวมของผลิตภัณฑ์:มองหาเหตุการณ์ การลดลงของบริการ การหยุดชะงัก หรือเหตุการณ์การบำรุงรักษาที่ส่งผลกระทบต่อบริการ Salesforce ที่คุณใช้งานอยู่
2. ดูรายละเอียดอินสแตนซ์ของคุณ:ค้นหาอินสแตนซ์ของคุณหรือโดเมนของฉัน แล้วเปิดผลลัพธ์ที่ตรงกัน

สถานะ "พร้อมใช้งาน"ไม่ได้หมายความว่าการทำงานของ API ทุกอย่างจะราบรื่นเสมอไป หมายความว่าอินสแตนซ์และบริการต่างๆ พร้อมใช้งานตามคำจำกัดความสถานะของ Salesforce สถานะ " ประสิทธิภาพลดลง"บ่งชี้ว่าการเข้าถึงอาจใช้งานได้แต่มีความล่าช้าหรือทำงานได้เพียงบางส่วน สถานะ " บริการหยุดชะงัก " หมายความว่าอินสแตนซ์ไม่พร้อมใช้งาน สถานะ " การบำรุงรักษา"บ่งชี้ว่ามีการบำรุงรักษาซึ่งอาจส่งผลกระทบต่อการเข้าถึงหรือไม่ก็ได้

ขั้นตอนที่ 2: ตรวจสอบสภาพแวดล้อมและองค์กรก่อนลองใหม่อีกครั้ง

Workbench สามารถเชื่อมต่อกับสภาพแวดล้อม Salesforce ที่แตกต่างกันได้ ก่อนที่จะสรุปว่า API ขัดข้อง ให้ตรวจสอบว่าคำขอที่ล้มเหลวนั้นมุ่งเป้าไปที่สภาพแวดล้อมการผลิต สภาพแวดล้อมทดสอบ หรือสภาพแวดล้อมที่ได้รับอนุญาตอื่นๆ การทดสอบที่สำเร็จในสภาพแวดล้อมหนึ่งไม่ได้หมายความว่าสภาพแวดล้อมที่ล้มเหลวจะไม่ได้รับผลกระทบ

ใช้ชื่อโดเมนของฉันหรือตัวระบุอินสแตนซ์สำหรับองค์กรที่ได้รับผลกระทบ เอกสารของ Salesforce ระบุว่าสามารถใช้คำนำหน้าโดเมนของฉันในสถานะความน่าเชื่อถือได้ ในขณะที่ผู้ดูแลระบบสามารถค้นหาอินสแตนซ์ได้ในการตั้งค่าภายใต้ข้อมูลบริษัทจดบันทึกอินสแตนซ์ สภาพแวดล้อม เวอร์ชัน API เวลาที่เกิดความล้มเหลวโดยประมาณ และเอนด์พอยต์ บันทึกเล็ก ๆ นี้จะช่วยป้องกันข้อผิดพลาดทั่วไป: การเปรียบเทียบข้อผิดพลาดในสภาพแวดล้อมการผลิตกับสถานะแซนด์บ็อกซ์ที่ปกติ

หากหน้าเข้าสู่ระบบ Workbench แสดงวิธีการเข้าสู่ระบบที่ไม่รองรับ หรือวนกลับไปที่หน้าจอเข้าสู่ระบบ ให้ถือว่าเป็นปัญหาการตรวจสอบสิทธิ์หรือปัญหาของ Workbench แยกต่างหาก จนกว่าสถานะความน่าเชื่อถือและการเข้าสู่ระบบ Salesforce โดยตรงจะระบุเป็นอย่างอื่น อย่าส่งข้อมูลประจำตัวซ้ำๆ ในระหว่างที่สงสัยว่าระบบขัดข้อง การลองใหม่มากเกินไปอาจทำให้ระบบล็อกเอาต์หรือเพิ่มความสับสนในการตรวจสอบ

ขั้นตอนที่ 3: จัดประเภทการตอบสนองของ API แทนการเดา

เอกสารประกอบการใช้งาน REST API ของ Salesforce อธิบายว่าส่วนหัวของการตอบกลับจะมีรหัสสถานะ HTTP และส่วนเนื้อหาโดยทั่วไปจะมีข้อความ และหากเกี่ยวข้อง ก็จะมีฟิลด์หรืออ็อบเจ็กต์ที่เกี่ยวข้องกับข้อผิดพลาดนั้นด้วย โปรดเก็บหลักฐานทั้งสองส่วนนี้ไว้

ขั้นตอนที่ 4: ดำเนินการทดสอบเปรียบเทียบอย่างปลอดภัย

เมื่อคุณทราบสถานะและสภาพแวดล้อมแล้ว ให้ใช้การทดสอบแบบอ่านอย่างเดียวที่เล็กที่สุดที่อนุญาต การเปรียบเทียบที่ดีควรมีคุณสมบัติสามประการ ได้แก่ ต้องกำหนดเป้าหมายไปยังองค์กรที่ได้รับผลกระทบ ต้องไม่แก้ไขข้อมูล และต้องเรียบง่ายพอที่จะลดโอกาสเกิดข้อผิดพลาดในรูปแบบคำขอ

1. หลังจากบันทึกคำตอบแรกแล้ว ให้กล่าวคำขอที่ไม่เป็นอันตรายแบบเดิมซ้ำอีกครั้งหนึ่ง
2. หากคำขอส่งคืนรหัส 401 ให้เริ่มต้นกระบวนการตรวจสอบสิทธิ์ที่ได้รับอนุญาตใหม่แทนที่จะใช้เซสชันเก่าซ้ำ
3. หากได้รับรหัสข้อผิดพลาด 400, 403 หรือ 404 ให้ตรวจสอบเอนด์พอยต์ เวอร์ชัน API ชื่อวัตถุ สิทธิ์การเข้าถึง และเนื้อหาคำขอ
4. หากพบรหัสข้อผิดพลาด 500, 502 หรือ 503 ซ้ำๆ ให้เปรียบเทียบเวลาและเหตุการณ์กับสถานะความน่าเชื่อถือ
5. หาก UI ของเบราว์เซอร์ทำงานได้ แต่ Workbench ล้มเหลว ให้ทดสอบเส้นทาง API ที่ได้รับอนุญาตเดียวกันกับไคลเอ็นต์ภายในที่ได้รับอนุมัติ หรือใช้เครื่องมือวินิจฉัยการผสานรวม

อย่าใช้คำขอเขียน ลบ อัปเดตจำนวนมาก การปรับใช้เมตาเดต้า หรือการย้ายข้อมูลเป็นเครื่องมือตรวจสอบสถานะระบบ ในระหว่างเหตุการณ์ฉุกเฉิน การเขียนข้อมูลอาจทำให้เกิดผลลัพธ์ที่ไม่สมบูรณ์ งานซ้ำซ้อน หรือความเข้าใจผิดว่าการกู้คืนระบบเสร็จสมบูรณ์แล้ว

คุณควรเปลี่ยนวิธีการแก้ไขปัญหาเมื่อใด?

เปลี่ยนแนวทางเมื่อสถานะความน่าเชื่อถือแสดงเหตุการณ์ผิดปกติ

หยุดการออกแบบคิวรีใหม่จนกว่าคุณจะมีหลักฐานที่แน่ชัดว่าคำขอมีรูปแบบไม่ถูกต้อง บันทึกหมายเลขเหตุการณ์ บริการที่ได้รับผลกระทบ อินสแตนซ์ เวลาเริ่มต้น และการอัปเดตล่าสุด ปฏิบัติตามข้อความการกู้คืนของ Salesforce และป้องกันงานที่อยู่ในคิวจากการลองใหม่ซ้ำซ้อน

เปลี่ยนวิธีการเมื่อสถานะความน่าเชื่อถือพร้อมใช้งาน แต่เวิร์กเบนช์เพียงอย่างเดียวใช้งานไม่ได้

มุ่งเน้นไปที่ Workbench, เบราว์เซอร์, เครือข่าย, การตรวจสอบสิทธิ์ หรือนโยบายภายในเครื่อง ลองใช้หน้าต่างเบราว์เซอร์แบบส่วนตัว เบราว์เซอร์ทางเลือกที่รองรับ และการเปรียบเทียบเครือข่ายที่ได้รับอนุญาต เว็บไซต์ Workbench จะส่งต่อการสนับสนุนเฉพาะ Workbench ไปยังแหล่งข้อมูลชุมชนโอเพนซอร์ส ในขณะที่ Salesforce Help ยังคงเป็นช่องทางหลักสำหรับการสนับสนุนผลิตภัณฑ์และบัญชี Salesforce

เปลี่ยนวิธีการแก้ไขเมื่อพบข้อผิดพลาด 401 หรือ 403 อย่างต่อเนื่อง

ดำเนินการต่อเพื่อวิเคราะห์ข้อมูลประจำตัวและการอนุญาต ยืนยันผู้ใช้ นโยบายแอปที่เชื่อมต่อ ขอบเขต OAuth อายุเซสชัน การเข้าถึง API โปรไฟล์หรือชุดสิทธิ์ และข้อจำกัดขององค์กร การรีเฟรชเบราว์เซอร์ซ้ำๆ จะไม่สามารถแก้ไขปัญหาการขาดสิทธิ์หรือโทเค็นที่ไม่ถูกต้องได้

เปลี่ยนวิธีการเมื่อปลายทางหนึ่งล้มเหลว แต่การอ่านข้อมูลแบบง่ายๆ ยังใช้งานได้

ตรวจสอบเอนด์พอยต์ อ็อบเจ็กต์ ฟิลด์ การแชร์เรคอร์ด เวอร์ชัน API เนื้อหาคำขอ และเนื้อหาการตอบกลับ ความล้มเหลวที่จำกัดเพียงอย่างเดียวไม่เพียงพอที่จะระบุว่า Salesforce ล่มทั้งระบบ ลดขนาดคำขอลงจนกว่าคุณจะสามารถระบุได้ว่าปัญหาเกิดจากไวยากรณ์ การเข้าถึง ข้อมูล หรือบริการที่เกี่ยวข้อง

คุณควรส่งหลักฐานอะไรบ้างให้ฝ่ายสนับสนุน?

หากปัญหายังคงอยู่กับ Salesforce โปรดใช้คำแนะนำจากฝ่ายสนับสนุนอย่างเป็นทางการของ Salesforceสำหรับช่องทางที่มีอยู่ในแผนความสำเร็จของคุณ โดยระบุข้อมูลดังต่อไปนี้:

• ตัวระบุองค์กร อินสแตนซ์ และสภาพแวดล้อม
• เวลา UTC และเขตเวลาท้องถิ่นของคุณ
• เกี่ยวข้องกับหน้าเวิร์กเบนช์หรือการดำเนินการ API
• รหัส HTTP, รหัสข้อผิดพลาด และเนื้อหาการตอบกลับที่ถูกปกปิดบางส่วน
• ไม่ว่าจะเป็น Salesforce UI ผู้ใช้รายอื่น หรือลูกค้าที่ได้รับการอนุมัติรายอื่น ก็อาจล้มเหลวเช่นกัน
• หมายเลขเหตุการณ์สถานะความน่าเชื่อถือ หรือหมายเหตุที่ระบุว่าไม่พบเหตุการณ์ที่ตรงกัน

ลบข้อมูลประจำตัว รหัสเซสชัน โทเค็นการเข้าถึง ชื่อลูกค้า รหัสบันทึก และข้อมูลสำคัญอื่นๆ ก่อนส่งบันทึก หากปัญหาเกิดจาก Workbench เท่านั้น ให้ใช้ช่องทางการสนับสนุนที่ระบุไว้ในหน้าความช่วยเหลือของ Workbenchเนื่องจาก Salesforce ไม่ได้ให้การสนับสนุนผลิตภัณฑ์สำหรับ Workbench โดยตรง

วิธีตรวจสอบการกู้คืน

ตัวบ่งชี้สถานะสีเขียวเป็นเรื่องที่น่ายินดี แต่ไม่ใช่จุดสิ้นสุด ตรวจสอบการฟื้นตัวทีละขั้นตอน:

1. ตรวจสอบว่าหน้ารายละเอียดเหตุการณ์แสดงผลลัพธ์การแก้ไขแล้ว หรือสถานะของระบบกลับสู่ "พร้อมใช้งาน"
2. เข้าสู่ระบบผ่านขั้นตอนที่ได้รับอนุมัติจาก Salesforce หรือ Workbench โดยไม่ต้องใช้เซสชันที่หมดอายุแล้วซ้ำอีก
3. เรียกใช้คำขออ่านอย่างเดียวที่ไม่เป็นอันตรายแบบเดียวกันกับที่ล้มเหลวก่อนหน้านี้
4. เปรียบเทียบรหัส HTTP เวลาตอบสนอง และเนื้อหาการตอบกลับกับข้อผิดพลาดที่บันทึกไว้
5. ตรวจสอบการผสานรวม งานที่อยู่ในคิว และการแจ้งเตือนปลายทางเพื่อหาการทำงานที่ล่าช้าหรือซ้ำซ้อน

ผลลัพธ์ที่คุณต้องการไม่ใช่แค่ “หน้าเว็บเปิดขึ้น” คุณต้องการให้การดำเนินการที่ได้รับอนุญาตครั้งแรกประสบความสำเร็จ โดยมีการตอบสนองตามที่คาดหวัง และไม่มีผลข้างเคียงที่ไม่ได้รับการตรวจสอบ

รายการตรวจสอบตนเอง

• ขอบเขต:คุณได้ตรวจสอบทั้งหน้า Trust ระดับผลิตภัณฑ์และอินสแตนซ์ที่ได้รับผลกระทบแล้วหรือไม่?
• สภาพแวดล้อม:คุณได้ตรวจสอบแล้วหรือยังว่าเป็นการใช้งานจริงหรือสภาพแวดล้อมทดสอบ และโดเมนของฉันหรืออินสแตนซ์ที่ถูกต้อง?
• หลักฐาน:คุณได้บันทึกรหัส HTTP รหัสข้อผิดพลาด เวลา และข้อมูลการตอบกลับที่ถูกปกปิดไว้อย่างครบถ้วนหรือไม่?
• ความปลอดภัย:ในระหว่างเหตุการณ์ดังกล่าว คุณได้หลีกเลี่ยงคำขอเขียน ลบ ดำเนินการเป็นกลุ่ม การปรับใช้ และการย้ายข้อมูลหรือไม่?
• ข้อสรุป:คุณได้แยกแยะพฤติกรรมที่เกิดขึ้นเฉพาะใน Workbench ออกจากความล้มเหลวของ Salesforce API หรือไม่?
• การแก้ไขปัญหา:คุณได้ทดสอบการทำงานเดิมซ้ำและตรวจสอบงานที่ล่าช้าในขั้นตอนถัดไปแล้วหรือไม่?

สรุป

สำหรับข้อผิดพลาดของ Salesforce Workbench ระหว่างช่วงเวลาที่ระบบหยุดทำงาน ให้เริ่มต้นด้วยสถานะความน่าเชื่อถือและอินสแตนซ์ที่ได้รับผลกระทบ จากนั้นจำแนกประเภทการตอบสนอง HTTP ก่อนที่จะเปลี่ยนข้อมูลรับรองหรือเขียนคำขอใหม่ ข้อผิดพลาด 500, 502 หรือ 503 ที่เกิดขึ้นซ้ำๆ ในการทดสอบแบบอ่านอย่างเดียว และเหตุการณ์ความน่าเชื่อถือที่ตรงกัน สนับสนุนคำอธิบายจากฝั่ง Salesforce ข้อผิดพลาด 401, 403, 400 หรือความล้มเหลวเฉพาะ Workbench มักต้องแก้ไขปัญหาเกี่ยวกับการตรวจสอบสิทธิ์ สิทธิ์การเข้าถึง คำขอ เบราว์เซอร์ หรือ Workbench แทน เนื่องจาก Workbench ไม่ใช่ผลิตภัณฑ์ที่ได้รับการสนับสนุนจาก Salesforce จึงควรหลีกเลี่ยงการใช้ข้อมูลการผลิต บันทึกขอบเขตให้ชัดเจน และใช้สถานะอย่างเป็นทางการและคำแนะนำการสนับสนุนล่าสุดเมื่อหลักฐานเปลี่ยนแปลง

แหล่งข้อมูลอย่างเป็นทางการ

• หน้าเกี่ยวกับ Workbench และข้อจำกัดด้านการสนับสนุน
• ความช่วยเหลือ Workbench
• สถานะความน่าเชื่อถือของ Salesforce
• ความช่วยเหลือจาก Salesforce: ใช้เว็บไซต์ Salesforce Trust
• ความช่วยเหลือของ Salesforce: ดูสถานะของอินสแตนซ์ของคุณ
• นักพัฒนา Salesforce: รหัสสถานะและการตอบกลับข้อผิดพลาด