أخطاء Salesforce Workbench: استكشاف أخطاء أدوات واجهة برمجة التطبيقات وإصلاحها أثناء فترة التوقف

تم التحقق في 16 سبتمبر 2026. من السهل إساءة فهم أخطاء Workbench أثناء حدوث مشكلة في Salesforce. قد يكون سبب فشل تسجيل الدخول انتهاء صلاحية الجلسة، أو بيئة غير صحيحة، أو خلل في مسار Workbench، أو انقطاع في واجهة برمجة تطبيقات Salesforce. يشير الطلب الذي يُرجع 503 Service Unavailableقيمة إلى اتجاه مختلف عن قيمة 401 Invalid Session، على الرغم من أن كليهما قد يظهر عندما يحاول المطور العمل بسرعة.

لا يهدف استكشاف الأخطاء وإصلاحها إلى فرض تنفيذ طلب واحد، بل إلى تحديد الطبقة التي تعاني من خلل، وحماية البيانات أثناء عدم استقرار النظام، ومعرفة متى تكون الأدلة قوية بما يكفي للانتظار، أو تغيير الأدوات، أو الاتصال بقناة الدعم المناسبة.

التشخيص السريع: ما الذي يشير إليه الخطأ على الأرجح؟

هذا الجدول هو نقطة انطلاق، وليس تشخيصًا. قد يكون لنفس رمز HTTP أسباب مختلفة تبعًا لنقطة النهاية، وطريقة المصادقة، وسياسة المؤسسة.

أولاً، افهم حدود دعم برنامج Workbench

Workbench عبارة عن مجموعة أدوات تعمل عبر المتصفح للتفاعل مع مؤسسات Salesforce من خلال العديد من واجهات برمجة التطبيقات (APIs)، بما في ذلك REST وSOAP وBulk وStreaming وMetadata وأدوات Apex. مع ذلك، يُشير موقع Workbench إلى أنه ليس منتجًا رسميًا من Salesforce، وأن دعم Salesforce غير متوفر لـ Workbench نفسه. كما تُحذّر صفحة "نبذة عنا" المستخدمين من استخدام التطبيق مع بيانات الإنتاج.

يُغيّر هذا التحذير طريقة استجابتك أثناء فترات التوقف. يمكن لفريق دعم Salesforce التحقيق في مشكلة تتعلق بخدمة Salesforce أو مثيلها أو واجهة برمجة التطبيقات (API)، ولكنه قد لا يُعالج جميع مشاكل واجهة Workbench. في المقابل، قد تكون المشكلة التي يُبلغ عنها Workbench فقط ناتجة عن Workbench نفسه أو عن مسار المتصفح وليس عن منصة Salesforce.

اجعل قسم استكشاف الأخطاء وإصلاحها للقراءة فقط كلما أمكن ذلك. لا تقم بلصق كلمات المرور، أو أسرار OAuth، أو معرّفات الجلسات، أو رموز الوصول، أو سجلات العملاء، أو رؤوس الطلبات غير المنقحة في لقطات الشاشة، أو رسائل الدردشة، أو تقارير المشكلات العامة.

الخطوة 1: تحقق من حالة ثقة Salesforce قبل تغيير إعدادات Workbench

افتح صفحة حالة الثقة في Salesforce في علامة تبويب منفصلة. تُوجه وثائق مساعدة Salesforce العملاء إلى هذه الصفحة في حالة انقطاع المنتجات أو تراجع مستوى الخدمة، ويمكن لموقع الثقة عرض معلومات عن المنتجات بالإضافة إلى حالات محددة.

تحقق من عرضين:

1. نظرة عامة على المنتج: ابحث عن حادث أو تدهور في الخدمة أو انقطاع أو حدث صيانة يؤثر على خدمة Salesforce التي تستخدمها.
2. عرض مثيلك: ابحث عن مثيلك أو نطاقي وافتح النتيجة المطابقة.

لا يضمن وجود حالة " متاح" أن تعمل جميع عمليات واجهة برمجة التطبيقات (API). بل يعني ذلك أن الحالة وخدماتها متاحة وفقًا لتعريف حالة Salesforce. يشير "تدهور الأداء" إلى أن الوصول قد يعمل مع تأخير أو بوظائف جزئية؛ بينما يعني "انقطاع الخدمة" أن الحالة غير متاحة؛ أما "الصيانة" فتشير إلى عملية صيانة قد تؤثر أو لا تؤثر على الوصول.

الخطوة الثانية: تأكد من البيئة والمؤسسة قبل إعادة المحاولة

يمكن لـ Workbench الاتصال ببيئات Salesforce المختلفة. قبل استنتاج أن واجهة برمجة التطبيقات (API) معطلة، تأكد مما إذا كان الطلب الفاشل يستهدف بيئة الإنتاج، أو بيئة الاختبار، أو أي بيئة أخرى معتمدة. إن نجاح الاختبار في بيئة ما لا يعني بالضرورة حل المشكلة في البيئة التي بها العطل.

استخدم مُعرّف نطاقي أو مُعرّف المثيل للمؤسسة المتأثرة. تُشير وثائق Salesforce إلى إمكانية استخدام بادئة نطاقي في حالة الثقة، بينما يُمكن للمسؤول العثور على المثيل في الإعدادات ضمن معلومات الشركة . دوّن معلومات المثيل، والبيئة، وإصدار واجهة برمجة التطبيقات، والوقت التقريبي للعطل، ونقطة النهاية. يُجنّب هذا السجل البسيط خطأً شائعًا: مُقارنة خطأ في بيئة الإنتاج بحالة بيئة الاختبار السليمة.

إذا كانت صفحة تسجيل الدخول إلى Workbench تُظهر طريقة تسجيل دخول غير مدعومة أو تُعيد توجيه المستخدم إلى شاشة تسجيل الدخول، فاعتبر ذلك مشكلة منفصلة في المصادقة أو في Workbench إلى أن يُشير وضع الثقة وتسجيل الدخول المباشر إلى Salesforce إلى خلاف ذلك. تجنّب إرسال بيانات الاعتماد بشكل متكرر أثناء انقطاع الخدمة المُحتمل؛ فقد تؤدي المحاولات المُفرطة إلى حظر المستخدم أو تُشتّت التحقيق.

الخطوة الثالثة: تصنيف استجابة واجهة برمجة التطبيقات بدلاً من التخمين

توضح وثائق واجهة برمجة تطبيقات REST الخاصة بـ Salesforce أن رأس الاستجابة يحتوي على رمز حالة HTTP، وأن نص الاستجابة عادةً ما يحتوي على رسالة، وعند الاقتضاء، على الحقل أو الكائن المرتبط بالخطأ. احتفظ بكلا الدليلين.

الخطوة الرابعة: إجراء اختبار مقارنة آمن

بمجرد معرفة الحالة والبيئة، استخدم أصغر اختبار مسموح به للقراءة فقط. تتميز المقارنة الجيدة بثلاث خصائص: استهداف المؤسسة المتأثرة، وعدم تعديل البيانات، وبساطتها التي تقلل من احتمالية حدوث خطأ في تنسيق الطلب.

1. كرر نفس الطلب غير الضار مرة واحدة بعد تسجيل الاستجابة الأولى.
2. إذا أعاد الطلب الرمز 401، فابدأ عملية مصادقة جديدة مصرح بها بدلاً من إعادة استخدام جلسة قديمة.
3. إذا أعاد 400 أو 403 أو 404، فافحص نقطة النهاية وإصدار واجهة برمجة التطبيقات واسم الكائن والأذونات ونص الطلب.
4. إذا أعاد 500 أو 502 أو 503 بشكل متكرر، فقم بمقارنة الوقت والحالة مع حالة الثقة.
5. إذا كانت واجهة المستخدم الخاصة بالمتصفح تعمل ولكن برنامج Workbench يفشل، فقم باختبار مسار API المعتمد نفسه باستخدام عميل داخلي معتمد أو تشخيص التكامل.

لا تستخدم طلبات الكتابة أو الحذف أو التحديث المجمع أو نشر البيانات الوصفية أو الترحيل كفحص سلامة النظام. أثناء وقوع حادث، قد تؤدي عملية الكتابة إلى نتائج جزئية أو تكرار العمل أو إعطاء انطباع خاطئ باستعادة النظام.

متى يجب عليك تغيير أسلوبك في حل المشكلات؟

غيّر النهج عندما تُظهر حالة الثقة وقوع حادث

توقف عن إعادة تصميم الاستعلام إلا إذا كان لديك دليل مستقل على أن الطلب غير صحيح. احفظ رقم الحادث، والخدمة المتأثرة، والمثيل، ووقت البدء، وآخر تحديث. اتبع رسائل الاسترداد من Salesforce، واحمِ المهام المُجدولة من المحاولات المتكررة.

غيّر أسلوبك عندما تكون حالة الثقة متاحة ولكن برنامج Workbench وحده لا يعمل

ركّز على Workbench، أو المتصفح، أو الشبكة، أو المصادقة، أو السياسة المحلية. جرّب نافذة متصفح خاصة، ومتصفحًا بديلًا مدعومًا، ومقارنة شبكة مسموح بها. يُحيل موقع Workbench الدعم الخاص بـ Workbench إلى موارد مجتمع المصادر المفتوحة، بينما يبقى مركز مساعدة Salesforce هو المصدر الرئيسي للدعم الخاص بمنتجات وحسابات Salesforce.

غيّر أسلوبك عندما يكون الخطأ 401 أو 403 بشكل متكرر

انتقل إلى تحليل الهوية والتفويض. تأكد من المستخدم، وسياسة التطبيق المتصل، ونطاق OAuth، وعمر الجلسة، وإمكانية الوصول إلى واجهة برمجة التطبيقات، وملف التعريف أو مجموعة الأذونات، وحدود المؤسسة. لن يؤدي تحديث المتصفح بشكل متكرر إلى إصلاح إذن مفقود أو رمز مميز غير صالح.

غيّر النهج عندما تفشل إحدى نقاط النهاية بينما تعمل عمليات القراءة البسيطة.

تحقق من نقطة النهاية، والكائن، والحقل، ومشاركة السجلات، وإصدار واجهة برمجة التطبيقات، ونص الطلب، ونص الاستجابة. لا يكفي وجود عطل جزئي لتصنيف Salesforce على أنه معطل بشكل عام. قلل حجم الطلب حتى تتمكن من تحديد ما إذا كانت المشكلة تتعلق بالبنية، أو الوصول، أو البيانات، أو خدمة تابعة.

ما هي الأدلة التي يجب عليك إرسالها إلى قسم الدعم؟

إذا استمرت مشكلة Salesforce، فاستخدم إرشادات دعم Salesforce الرسمية للقناة المتاحة ضمن خطة النجاح الخاصة بك. تتضمن هذه الإرشادات ما يلي:

• معرّف المؤسسة، والمثيل، والبيئة
• التوقيت العالمي المنسق (UTC) والمنطقة الزمنية المحلية الخاصة بك
• صفحة Workbench أو عملية API ذات صلة
• رمز HTTP، رمز الخطأ، ونص الاستجابة بعد تنقيحه
• سواء فشلت واجهة مستخدم Salesforce أو مستخدم آخر أو عميل معتمد آخر
• رقم حادثة حالة الثقة أو ملاحظة تفيد بعدم وجود حدث مطابق ظاهر

قم بإزالة بيانات الاعتماد، ومعرّفات الجلسات، ورموز الوصول، وأسماء العملاء، ومعرّفات السجلات، والبيانات الحساسة قبل إرسال السجلات. إذا كانت المشكلة تقتصر على Workbench فقط، فاستخدم مسار الدعم الموضح في صفحة مساعدة Workbench ؛ إذ لا تُقدّم Salesforce دعمًا فنيًا لـ Workbench نفسه.

كيفية التحقق من الاسترداد

يُعدّ مؤشر الحالة الأخضر مُشجعاً، ولكنه ليس نهاية المطاف. تحقق من التعافي على مراحل:

1. تأكد من أن صفحة الحادث تعرض حلاً أو أن الحالة تعود إلى حالة "متاح".
2. قم بتسجيل الدخول من خلال مسار Salesforce أو Workbench المعتمد دون إعادة استخدام جلسة قديمة.
3. قم بتشغيل نفس طلب القراءة فقط غير الضار الذي فشل سابقًا.
4. قارن رمز HTTP ووقت الاستجابة ومحتوى الاستجابة مع الفشل المسجل.
5. تحقق من عمليات التكامل، والوظائف الموجودة في قائمة الانتظار، والإشعارات اللاحقة بحثًا عن أي عمل متأخر أو مكرر.

النتيجة التي تريدها ليست مجرد "فتح الصفحة". أنت تريد أن تنجح العملية الأصلية المصرح بها، مع الاستجابة المتوقعة وبدون أي آثار جانبية غير مراجعتها.

قائمة التحقق من الفحص الذاتي

• النطاق: هل قمت بفحص كل من صفحة الثقة على مستوى المنتج والنسخة المتأثرة؟
• البيئة: هل تأكدت من بيئة الإنتاج مقابل بيئة الاختبار، ومن صحة نطاقي أو مثيلي؟
• الدليل: هل قمت بحفظ رمز HTTP الدقيق، ورمز الخطأ، والوقت، والاستجابة المنقحة؟
• السلامة: هل تجنبت طلبات الكتابة والحذف والتحميل والنشر والترحيل أثناء الحادث؟
• القرار: هل ميزت بين سلوك Workbench فقط وفشل واجهة برمجة تطبيقات Salesforce؟
• الاستعادة: هل قمت بإعادة اختبار العملية الأصلية وفحصت الأعمال اللاحقة المتأخرة؟

الخلاصة

في حال حدوث أخطاء في Salesforce Workbench أثناء فترة التوقف، ابدأ بفحص حالة الثقة والمثيل المتأثر، ثم صنّف استجابة HTTP قبل تغيير بيانات الاعتماد أو إعادة كتابة الطلبات. تكرار ظهور الأخطاء 500 أو 502 أو 503 في اختبارات القراءة فقط، بالإضافة إلى وجود حادثة ثقة مطابقة، يدعم تفسيرًا من جانب Salesforce. أما الأخطاء 401 أو 403 أو 400، أو فشل Workbench فقط، فيستدعي عادةً استكشاف أخطاء المصادقة أو الأذونات أو الطلب أو المتصفح أو Workbench نفسه وإصلاحها. ولأن Workbench ليس منتجًا مدعومًا من Salesforce، فاحرص على إبقاء بيانات الإنتاج بعيدة عنه، ووثّق حدوده بوضوح، واستخدم أحدث المعلومات الرسمية حول حالة النظام وإرشادات الدعم عند حدوث أي تغيير في الأدلة.

مصادر رسمية

• صفحة "نبذة عن Workbench" وقيود الدعم
• مساعدة ورشة العمل
• حالة ثقة Salesforce
• مساعدة Salesforce: استخدم موقع Salesforce Trust
• مساعدة Salesforce: عرض حالة مثيلك
• مطورو Salesforce: رموز الحالة واستجابات الأخطاء