الرئيسية
» تكنولوجيا
»
أخطاء Salesforce Workbench: استكشاف أخطاء أدوات واجهة برمجة التطبيقات وإصلاحها أثناء فترة التوقف
أخطاء Salesforce Workbench: استكشاف أخطاء أدوات واجهة برمجة التطبيقات وإصلاحها أثناء فترة التوقف
تم التحقق في 16 سبتمبر 2026. من السهل إساءة فهم أخطاء Workbench أثناء حدوث مشكلة في Salesforce. قد يكون سبب فشل تسجيل الدخول انتهاء صلاحية الجلسة، أو بيئة غير صحيحة، أو خلل في مسار Workbench، أو انقطاع في واجهة برمجة تطبيقات Salesforce. يشير الطلب الذي يُرجع 503 Service Unavailableقيمة إلى اتجاه مختلف عن قيمة 401 Invalid Session، على الرغم من أن كليهما قد يظهر عندما يحاول المطور العمل بسرعة.
لا يهدف استكشاف الأخطاء وإصلاحها إلى فرض طلب واحد، بل إلى تحديد الطبقة التي تعاني من خلل، وحماية البيانات أثناء عدم استقرار النظام، ومعرفة متى تكون الأدلة قوية بما يكفي للانتظار، أو تغيير الأدوات، أو الاتصال بقناة الدعم المناسبة.
التشخيص السريع: ما الذي يشير إليه الخطأ على الأرجح؟
ما تراه
الطبقة الأكثر احتمالاً
أفضل خطوة تالية
صفحة ورشة العمل لا يتم تحميلها
موقع Workbench، أو المتصفح، أو نظام أسماء النطاقات (DNS)، أو مسار الشبكة
افتح حالة الثقة في Salesforce واختبر الموقع من شبكة بديلة مسموح بها.
يتم تحميل بيئة العمل، لكن تسجيل الدخول يفشل مع ظهور الخطأ 401
جلسة، أو OAuth، أو اسم المستخدم، أو كلمة المرور، أو عملية تسجيل الدخول
ابدأ عملية تسجيل دخول جديدة مصرح بها وقم بتأكيد البيئة المختارة.
يُرجع طلب واجهة برمجة التطبيقات رمز الخطأ 403
الأذونات، أو سياسة التطبيقات المتصلة، أو حد واجهة برمجة التطبيقات
تحقق من المستخدم والتطبيق المتصل وحدود الطلب؛ لا تعتبر ذلك دليلاً على توقف الخدمة.
تُرجع العديد من استدعاءات واجهة برمجة التطبيقات (API) الرموز 500 أو 502 أو 503
منصة Salesforce، أو توجيه الحافة، أو الصيانة، أو التحميل الزائد
قارن وقت الخطأ مع حالة مثيلك ومنتجك على منصة Trust.
فشل استعلام واحد أو كائن واحد فقط
طلب بناء الجملة، أو الوصول إلى الكائنات، أو مشاركة السجلات، أو مشكلة في البيانات
قلل الطلب إلى قراءة غير ضارة ومعروفة الجودة، وافحص نص الاستجابة.
هذا الجدول هو نقطة انطلاق، وليس تشخيصًا. قد يكون لنفس رمز HTTP أسباب مختلفة تبعًا لنقطة النهاية، وطريقة المصادقة، وسياسة المؤسسة.
أولاً، افهم حدود دعم برنامج Workbench
Workbench عبارة عن مجموعة أدوات تعمل عبر المتصفح للتفاعل مع مؤسسات Salesforce من خلال العديد من واجهات برمجة التطبيقات (APIs)، بما في ذلك REST وSOAP وBulk وStreaming وMetadata وأدوات Apex. مع ذلك، يُشير موقع Workbench إلى أنه ليس منتجًا رسميًا من Salesforce، وأن دعم Salesforce غير متوفر لـ Workbench نفسه. كما تُحذّر صفحة "نبذة عنا" المستخدمين من استخدام التطبيق مع بيانات الإنتاج.
يُغيّر هذا التحذير طريقة استجابتك أثناء فترات التوقف. يمكن لفريق دعم Salesforce التحقيق في مشكلة تتعلق بخدمة Salesforce أو مثيلها أو واجهة برمجة التطبيقات (API)، ولكنه قد لا يُعالج جميع مشاكل واجهة Workbench. في المقابل، قد تكون المشكلة التي يُبلغ عنها Workbench فقط ناتجة عن Workbench نفسه أو عن مسار المتصفح وليس عن منصة Salesforce.
اجعل قسم استكشاف الأخطاء وإصلاحها للقراءة فقط كلما أمكن ذلك. لا تقم بلصق كلمات المرور، أو أسرار OAuth، أو معرّفات الجلسات، أو رموز الوصول، أو سجلات العملاء، أو رؤوس الطلبات غير المنقحة في لقطات الشاشة، أو رسائل الدردشة، أو تقارير المشكلات العامة.
ابدأ بتحديد مسار تسجيل الدخول إلى Workbench والبيئة المختارة. الواجهة المعروضة هي نموذج توضيحي، وليست شاشة تسجيل دخول حقيقية أو طلبًا لإدخال بيانات الاعتماد في صورة مقال.
الخطوة 1: تحقق من حالة ثقة Salesforce قبل تغيير إعدادات Workbench
افتح صفحة حالة الثقة في Salesforce في علامة تبويب منفصلة. تُوجه وثائق مساعدة Salesforce العملاء إلى هذه الصفحة في حالة انقطاع المنتجات أو تراجع مستوى الخدمة، ويمكن لموقع الثقة عرض معلومات عن المنتجات بالإضافة إلى حالات محددة.
تحقق من وجهتي النظر التاليتين:
نظرة عامة على المنتج: ابحث عن حادث أو تدهور في الخدمة أو انقطاع أو حدث صيانة يؤثر على خدمة Salesforce التي تستخدمها.
عرض مثيلك: ابحث عن مثيلك أو نطاقي وافتح النتيجة المطابقة.
لا يضمن وجود حالة " متاح" أن تعمل جميع عمليات واجهة برمجة التطبيقات (API). بل يعني ذلك أن الحالة وخدماتها متاحة وفقًا لتعريف حالة Salesforce. يشير "تدهور الأداء" إلى أن الوصول قد يعمل مع تأخير أو بوظائف جزئية؛ بينما يعني "انقطاع الخدمة" أن الحالة غير متاحة؛ أما "الصيانة" فتشير إلى عملية صيانة قد تؤثر أو لا تؤثر على الوصول.
الخطوة 1 - قارن معلومات حالة الثقة العامة مع حالة المؤسسة المتأثرة. الشاشة المعروضة هي دليل توضيحي لسير عمل البحث الموثق، وليست دليلاً على وقوع حادثة فعلية.
الخطوة الثانية: تأكد من البيئة والمؤسسة قبل إعادة المحاولة
يمكن لـ Workbench الاتصال ببيئات Salesforce المختلفة. قبل استنتاج أن واجهة برمجة التطبيقات (API) معطلة، تأكد مما إذا كان الطلب الفاشل يستهدف بيئة الإنتاج، أو بيئة الاختبار، أو أي بيئة أخرى معتمدة. إن نجاح الاختبار في بيئة ما لا يعني بالضرورة حل المشكلة في البيئة التي بها العطل.
استخدم مُعرّف نطاقي أو مُعرّف المثيل للمؤسسة المتأثرة. تُشير وثائق Salesforce إلى إمكانية استخدام بادئة نطاقي في حالة الثقة، بينما يُمكن للمسؤول العثور على المثيل في الإعدادات ضمن معلومات الشركة . دوّن معلومات المثيل، والبيئة، وإصدار واجهة برمجة التطبيقات، والوقت التقريبي للعطل، ونقطة النهاية. يُجنّب هذا السجل البسيط خطأً شائعًا: مُقارنة خطأ في بيئة الإنتاج بحالة بيئة الاختبار السليمة.
إذا كانت صفحة تسجيل الدخول إلى Workbench تُظهر طريقة تسجيل دخول غير مدعومة أو تُعيد توجيه المستخدم إلى شاشة تسجيل الدخول، فاعتبر ذلك مشكلة منفصلة في المصادقة أو في Workbench إلى أن يُشير وضع الثقة وتسجيل الدخول المباشر إلى Salesforce إلى خلاف ذلك. تجنّب إرسال بيانات الاعتماد بشكل متكرر أثناء انقطاع الخدمة المُحتمل؛ فقد تؤدي المحاولات المُفرطة إلى حظر المستخدم أو تُشتّت التحقيق.
الخطوة الثالثة: تصنيف استجابة واجهة برمجة التطبيقات بدلاً من التخمين
توضح وثائق واجهة برمجة تطبيقات REST الخاصة بـ Salesforce أن رأس الاستجابة يحتوي على رمز حالة HTTP، وأن نص الاستجابة عادةً ما يحتوي على رسالة، وعند الاقتضاء، على الحقل أو الكائن المرتبط بالخطأ. احتفظ بكلا الدليلين.
شفرة
دليل موثق من Salesforce
كيفية تفسير ذلك أثناء فترة التوقف
400
لم يكن من الممكن فهم الطلب، وغالبًا ما يكون ذلك بسبب عدم صلاحية نص JSON أو XML.
عادةً ما يتم إصلاح الطلب قبل اعتباره انقطاعاً في الخدمة.
401
انتهت صلاحية معرف الجلسة أو رمز OAuth أو أصبح غير صالح.
أعد المصادقة من خلال مسار معتمد؛ فالرمز 401 وحده لا يُعد دليلاً على انقطاع الخدمة في المنصة.
403
تم رفض الطلب، غالباً بسبب الأذونات أو قيود واجهة برمجة التطبيقات (API).
تحقق من صلاحيات الوصول والحدود قبل تصعيد الأمر إلى حادثة تتعلق بتوفر الخدمة.
500
حدث خطأ في منصة Lightning.
أعد المحاولة فقط بعد تسجيل الاستجابة؛ قارن حالات الفشل المتكررة بحالة الثقة.
502
لم يتمكن Salesforce Edge من الاتصال بنجاح مع المثيل.
من المحتمل وجود مشكلة في التوجيه أو في جانب النظام الأساسي، خاصة عند التعامل مع طلبات متعددة.
503
الخادم غير متاح؛ قد يكون ذلك بسبب أعمال صيانة أو ضغط زائد.
تحقق من وجود حادث أو حدث صيانة وتجنب عمليات إعادة المحاولة المدمرة.
الخطوة 3 — سجّل رمز HTTP ومعنى الاستجابة قبل تغيير بيانات الاعتماد أو الطلبات. لا يحتوي المثال على رمز مميز أو بيانات عميل أو مُعرّف حادثة حقيقي.
الخطوة الرابعة: إجراء اختبار مقارنة آمن
بمجرد معرفة الحالة والبيئة، استخدم أصغر اختبار مسموح به للقراءة فقط. تتميز المقارنة الجيدة بثلاث خصائص: استهداف المؤسسة المتأثرة، وعدم تعديل البيانات، وبساطتها التي تقلل من احتمالية حدوث خطأ في تنسيق الطلب.
كرر نفس الطلب غير الضار مرة واحدة بعد تسجيل الاستجابة الأولى.
إذا أعاد الطلب الرمز 401، فابدأ عملية مصادقة جديدة مصرح بها بدلاً من إعادة استخدام جلسة قديمة.
إذا أعاد رمز الخطأ 400 أو 403 أو 404، فافحص نقطة النهاية وإصدار واجهة برمجة التطبيقات واسم الكائن والأذونات ونص الطلب.
إذا أعاد 500 أو 502 أو 503 بشكل متكرر، فقم بمقارنة الوقت والحالة مع حالة الثقة.
إذا كانت واجهة المستخدم الخاصة بالمتصفح تعمل ولكن برنامج Workbench يفشل، فقم باختبار مسار API المعتمد نفسه باستخدام عميل داخلي معتمد أو تشخيص التكامل.
لا تستخدم طلبات الكتابة أو الحذف أو التحديث المجمع أو نشر البيانات الوصفية أو الترحيل كفحص سلامة النظام. أثناء وقوع حادث، قد تؤدي عملية الكتابة إلى نتائج جزئية أو تكرار العمل أو إعطاء انطباع خاطئ باستعادة النظام.
متى يجب عليك تغيير أسلوبك في حل المشكلات؟
غيّر النهج عندما تُظهر حالة الثقة وقوع حادث
توقف عن إعادة تصميم الاستعلام إلا إذا كان لديك دليل مستقل على أن الطلب غير صحيح. احفظ رقم الحادث، والخدمة المتأثرة، والمثيل، ووقت البدء، وآخر تحديث. اتبع رسائل الاسترداد من Salesforce، واحمِ المهام المُجدولة من المحاولات المتكررة.
غيّر أسلوبك عندما تكون حالة الثقة متاحة ولكن برنامج Workbench وحده لا يعمل
ركّز على Workbench، أو المتصفح، أو الشبكة، أو المصادقة، أو السياسة المحلية. جرّب نافذة متصفح خاصة، ومتصفحًا بديلًا مدعومًا، ومقارنة شبكة مسموح بها. يُحيل موقع Workbench الدعم الخاص بـ Workbench إلى موارد مجتمع المصادر المفتوحة، بينما يبقى مركز مساعدة Salesforce هو المصدر الرئيسي للدعم الخاص بمنتجات وحسابات Salesforce.
غيّر أسلوبك عندما يكون الخطأ 401 أو 403 بشكل متكرر
انتقل إلى تحليل الهوية والتفويض. تأكد من المستخدم، وسياسة التطبيق المتصل، ونطاق OAuth، وعمر الجلسة، وإمكانية الوصول إلى واجهة برمجة التطبيقات، وملف التعريف أو مجموعة الأذونات، وحدود المؤسسة. لن يؤدي تحديث المتصفح بشكل متكرر إلى إصلاح إذن مفقود أو رمز مميز غير صالح.
غيّر النهج عندما تفشل إحدى نقاط النهاية بينما تعمل عمليات القراءة البسيطة.
تحقق من نقطة النهاية، والكائن، والحقل، ومشاركة السجلات، وإصدار واجهة برمجة التطبيقات، ونص الطلب، ونص الاستجابة. لا يكفي وجود عطل جزئي لتصنيف Salesforce على أنه معطل بشكل عام. قلل حجم الطلب حتى تتمكن من تحديد ما إذا كانت المشكلة تتعلق بالبنية، أو الوصول، أو البيانات، أو خدمة تابعة.
الخطوة الرابعة - احترام حدود الدعم والسلامة في Workbench. استخدم دعم Salesforce المعتمد لحوادث المنصة وموارد مجتمع المصادر المفتوحة للسلوكيات الخاصة بـ Workbench.
ما هي الأدلة التي يجب عليك إرسالها إلى قسم الدعم؟
إذا استمرت مشكلة Salesforce، فاستخدم إرشادات دعم Salesforce الرسمية للقناة المتاحة ضمن خطة النجاح الخاصة بك. تتضمن هذه الإرشادات ما يلي:
معرّف المؤسسة، والمثيل، والبيئة
التوقيت العالمي المنسق (UTC) والمنطقة الزمنية المحلية الخاصة بك
صفحة Workbench أو عملية API ذات صلة
رمز HTTP، رمز الخطأ، ونص الاستجابة بعد تنقيحه
سواء فشلت واجهة مستخدم Salesforce أو مستخدم آخر أو عميل معتمد آخر
رقم حادثة حالة الثقة أو ملاحظة تفيد بعدم وجود حدث مطابق ظاهر
قم بإزالة بيانات الاعتماد، ومعرّفات الجلسات، ورموز الوصول، وأسماء العملاء، ومعرّفات السجلات، والبيانات الحساسة قبل إرسال السجلات. إذا كانت المشكلة تقتصر على Workbench فقط، فاستخدم مسار الدعم الموضح في صفحة مساعدة Workbench ؛ إذ لا تُقدّم Salesforce دعمًا فنيًا لـ Workbench نفسه.
كيفية التحقق من الاسترداد
يُعدّ مؤشر الحالة الأخضر مُشجعاً، ولكنه ليس نهاية المطاف. تحقق من التعافي على مراحل:
تأكد من أن صفحة الحادث تعرض حلاً أو أن الحالة تعود إلى حالة "متاح".
قم بتسجيل الدخول من خلال مسار Salesforce أو Workbench المعتمد دون إعادة استخدام جلسة قديمة.
قم بتشغيل نفس طلب القراءة فقط غير الضار الذي فشل سابقًا.
قارن رمز HTTP ووقت الاستجابة ومحتوى الاستجابة مع الفشل المسجل.
تحقق من عمليات التكامل، والوظائف الموجودة في قائمة الانتظار، والإشعارات اللاحقة بحثًا عن أي عمل متأخر أو مكرر.
النتيجة التي تريدها ليست مجرد "فتح الصفحة". أنت تريد أن تنجح العملية الأصلية المصرح بها، مع الاستجابة المتوقعة وبدون أي آثار جانبية غير مراجعتها.
قائمة التحقق الذاتي
النطاق: هل قمت بفحص كل من صفحة الثقة على مستوى المنتج والنسخة المتأثرة؟
البيئة: هل تأكدت من بيئة الإنتاج مقابل بيئة الاختبار، ومن صحة نطاقي أو مثيلي؟
الدليل: هل قمت بحفظ رمز HTTP الدقيق، ورمز الخطأ، والوقت، والاستجابة المنقحة؟
السلامة: هل تجنبت طلبات الكتابة والحذف والتحميل والنشر والترحيل أثناء الحادث؟
القرار: هل ميزت بين سلوك Workbench فقط وفشل واجهة برمجة تطبيقات Salesforce؟
الاستعادة: هل قمت بإعادة اختبار العملية الأصلية وفحصت الأعمال اللاحقة المتأخرة؟
خلاصة القول
في حال حدوث أخطاء في Salesforce Workbench أثناء فترة التوقف، ابدأ بفحص حالة الثقة والمثيل المتأثر، ثم صنّف استجابة HTTP قبل تغيير بيانات الاعتماد أو إعادة كتابة الطلبات. تكرار ظهور الأخطاء 500 أو 502 أو 503 في اختبارات القراءة فقط، بالإضافة إلى وجود حادثة ثقة مطابقة، يدعم تفسيرًا من جانب Salesforce. أما الأخطاء 401 أو 403 أو 400، أو فشل Workbench فقط، فيستدعي عادةً استكشاف أخطاء المصادقة أو الأذونات أو الطلب أو المتصفح أو Workbench نفسه وإصلاحها. ولأن Workbench ليس منتجًا مدعومًا من Salesforce، فاحرص على إبقاء بيانات الإنتاج بعيدة عنه، ووثّق حدوده بوضوح، واستخدم أحدث المعلومات الرسمية حول حالة النظام وإرشادات الدعم عند حدوث أي تغيير في الأدلة.