كيفية إصلاح FIELD_CUSTOM_VALIDATION_EXCEPTION في عمليات نشر Salesforce

حجبت validation rule مخصصة في المؤسسة المستهدفة السجل، ونص الخطأ هو رسالة القاعدة نفسها.

تظهر أثناء: DML وقت التشغيل، غالبًا داخل تنفيذ اختبارات Apex

المعنى

يعني FIELD_CUSTOM_VALIDATION_EXCEPTION أن validation rule قمت أنت أو مسؤول آخر بتهيئتها رفضت السجل الجاري حفظه. يُلحق Salesforce رسالة الخطأ الدقيقة للـ validation rule بالـ exception، لذا يكون الحل عادةً مرئيًا مباشرة في نص الخطأ، بمجرد معرفة السجل والقاعدة التي تسببت فيه.

ولأن عمليات النشر إلى الإنتاج تشغّل اختبارات Apex مقابل validation rules الحقيقية والفعّالة في الإنتاج، فهذه واحدة من أكثر الطرق شيوعًا التي تحجب بها validation rule كانت تعمل جيدًا في sandbox إصدارًا: ببساطة لم تكن تلك القاعدة مفعّلة في الـ sandbox.

التشخيص

الأسباب الشائعة

بيانات الاختبار لا تحقق شروط القاعدة
تبني مصنع بيانات اختبار Apex سجلات تنتهك validation rule فعّالة في المؤسسة المستهدفة لكن ليس في sandbox المصدر.
validation rule غير متسقة عبر البيئات
تختلف حالة تفعيل القاعدة أو منطقها بين البيئات لأن تغييرًا لم يُرحَّل إلى كل مكان.
قاعدة جديدة تتعارض مع أنماط البيانات الحالية
تتعارض validation rule أُضيفت في نفس عملية النشر مع الطريقة التي تبني بها الأتمتة أو الاختبارات الحالية السجلات.

الحل

  1. اقرأ نص الخطأ الخاص بالقاعدة
    تحدد الرسالة بعد رمز الخطأ الشرط الدقيق الذي فشل؛ ابدأ من هناك بدلاً من التخمين.
  2. حدّث مصنع بيانات الاختبار
    عدّل إعداد اختبار Apex بحيث تلتزم السجلات المُولَّدة بشرط validation rule.
  3. وحّد تفعيل القاعدة عبر المؤسسات
    تأكد من أن validation rule فعّالة (أو غير فعّالة) بشكل متسق في كل بيئة تمسّها عملية النشر.
من واقع الاستخدام

إزاي Serpent بتمنع ده

يُظهر Serpent AI رسالة validation rule الدقيقة أثناء الفحص المسبق preflight، قبل تشغيل عملية النشر الفعلية، حتى تصلح القاعدة أو البيانات مرة واحدة بدلاً من التخمين. راجع مكتبة أخطاء نشر Salesforce.

الـ metadata والبيانات في مسار نشر واحد داخل Serpent

الوقاية

انشر validation rules بنفس الصرامة التي تُنشر بها Apex
تتبّع تغييرات validation rules في نظام التحكم بالمصدر ورقِّها عبر نفس خط الأنابيب المستخدم للكود، بدلاً من تعديلها ارتجاليًا في Setup مؤسسة واحدة.
ابنِ مصانع بيانات الاختبار من القواعد الفعّالة للكائن، لا من المعرفة المتوارثة
راجع كل validation rule فعّالة على الكائن عند كتابة مصنع بيانات اختباره، بدلاً من الاعتماد على ما نجح مصادفة في الماضي.
تحقق مقابل sandbox شبيهة بالإنتاج قبل الإصدار
شغّل عملية نشر check-only مقابل sandbox كاملة مع تفعيل validation rules الحقيقية للإنتاج، حتى تظهر أي فجوة في القواعد قبل نافذة الإصدار، لا أثناءها.
أسئلة شائعة

FIELD_CUSTOM_VALIDATION_EXCEPTION، بالإجابات

هل من الآمن مجرد تعطيل validation rule أثناء النشر؟
فقط كملاذ أخير، وأبدًا في الإنتاج. إصلاح بيانات الاختبار أو السجل الأساسي أكثر أمانًا من إيقاف قاعدة تحمي بيانات حقيقية.
هل يمكن أن تنشط validation rule على حقل غير مرئي في page layout؟
نعم. تقيّم validation rules قيم حقول السجل المحفوظة بغض النظر عن ظهورها في page layout، لذا يمكن لحقل مخفي أن يحجب الحفظ.
لماذا ينجح نفس الاختبار عند تشغيله بمفرده لكنه يفشل في المجموعة الكاملة؟
على الأرجح غيّر اختبار سابق في التشغيل حالة مشتركة، أو custom setting، أو سجلاً تتحقق منه validation rule، والذي تنتهكه الآن بيانات الاختبار الفاشل. اعزل الاختبار السابق للتأكد.

ابدأ مجانًا. بدون بطاقة ائتمان، وبدون تثبيت، وبدون التزام.

يتم الإعداد في أقل من 15 دقيقة. دون الحاجة لتوظيف متخصص DevOps.

هل تريد معرفة كيف يمكنكم الشحن أسرع قبل البدء؟ لنتحدث

بدون التزام.