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

سجل واحد سيئ في دفعة أُرسلت بخيار allOrNone=true تسبب في التراجع عن كل سجل في تلك الدفعة، بما فيها السجلات الصحيحة.

يظهر أثناء: عمليات DML الجماعية، وتحميل البيانات، وإعداد اختبارات Apex

المعنى

يعني ALL_OR_NONE_OPERATION_ROLLED_BACK أن عملية DML أُرسلت وقيمة allOrNone فيها true، وأن سجلاً واحدًا على الأقل في الدفعة فشل في التحقق، فقام Salesforce بالتراجع عن الدفعة بأكملها بدلاً من تثبيت السجلات الصحيحة فرديًا. هذا هو السلوك المتوقع لخيار allOrNone، وليس خللاً، لكنه قد يكون مكلفًا في الدفعات الكبيرة.

يظهر أينما تعمل عمليات DML الجماعية: استدعاء Database.insert(records, true) في Apex، أو مهمة Bulk API بخيار allOrNone مفعّلاً، أو جلسة Data Loader مع تعطيل "Insert null values" والنجاح الجزئي معًا. صف واحد سيئ في أي مكان بالدفعة يُسقط المعاملة بأكملها معه.

التشخيص

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

سجل واحد في دفعة كبيرة يفشل في التحقق
قيمة قائمة اختيار خاطئة، أو حقل مطلوب مفقود، أو قاعدة تحقق فاشلة على سجل واحد تُبطل دفعة allOrNone بأكملها.
لم يتم التحقق مسبقًا من أنواع السجلات المختلطة
تجمع الدفعة سجلات من مصادر أو أشكال مختلفة دون فحص كل واحد منها مقابل قواعد التحقق الخاصة بالكائن أولاً.
لم يتم تقسيم الدفعات إلى أجزاء
ترسل خطوة البيانات في عملية نشر كبيرة دفعة واحدة ضخمة جدًا بدلاً من تقسيمها إلى أجزاء أصغر ومعزولة عن الأعطال بشكل أفضل.

الحل

  1. تحقق من السجلات من جهة العميل قبل الإرسال
    افحص شروط الفشل الواضحة، الحقول المطلوبة، قيم قوائم الاختيار، مقابل قواعد الكائن قبل إرسال الدفعة.
  2. اضبط allOrNone=false أثناء جولات الترحيل
    شغّل عمليات الترحيل بخيار allOrNone=false حتى لا تمنع الإخفاقات الفردية باقي الدفعة، ثم راجع السجلات الفاشلة وأصلحها.
  3. قسّم الدفعات الكبيرة إلى مجموعات أصغر
    قسّم عملية بيانات كبيرة إلى دفعات أصغر بحيث لا يؤثر السجل السيئ الواحد إلا على جزء صغير من الحمولة الإجمالية.
    List<SObject> chunk = new List<SObject>();
    for (Integer i = 0; i < records.size(); i++) {
        chunk.add(records[i]);
        if (chunk.size() == 200 || i == records.size() - 1) {
            Database.insert(chunk, false);
            chunk.clear();
        }
    }
من واقع الاستخدام

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

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

لوحة الإصدارات مع تنبيهات التعارض في Serpent

الوقاية

اجعل allOrNone=false هو الخيار الافتراضي في التحميلات الجماعية
تعامل مع allOrNone=true كاستثناء للحالات التي يكون فيها النجاح الجزئي غير مقبول فعليًا، لا كإعداد افتراضي لكل مهمة دفعية.
تحقق مسبقًا قبل الإرسال
مرّر السجلات الواردة عبر فحص مخطط خفيف، الحقول المطلوبة، قيم قوائم الاختيار، قبل أن تصل إلى استدعاء DML على الإطلاق.
صمّم عمليات الترحيل بأحجام أجزاء ثابتة منذ اليوم الأول
ابنِ تحميلات البيانات لإرسالها في أجزاء ذات حجم ثابت، من 200 إلى 2000 سجل، منذ البداية بدلاً من إضافة التقسيم لاحقًا بعد حدوث فشل.
أسئلة شائعة

ALL_OR_NONE_OPERATION_ROLLED_BACK، تمت الإجابة

هل يُعد allOrNone دائمًا الإعداد الخاطئ؟
لا. إنه الخيار الصحيح عندما يكون النجاح الجزئي غير مقبول، مثل مجموعة من السجلات المالية التي يجب ترحيلها معًا؛ إنه فقط مكلف عند استخدامه على دفعات كبيرة وغير محكمة التحقق.
هل يتراجع allOrNone=true أيضًا عن الآثار الجانبية لمشغلات Apex؟
نعم. يتراجع Salesforce عن المعاملة بأكملها، بما في ذلك أي عملية DML نفذها مشغل على كائنات أخرى، وليس فقط السجلات المُرسلة مباشرة.
كيف أجد أي سجل تحديدًا فشل في دفعة كبيرة؟
تحتوي مصفوفة SaveResult (أو نتيجة مهمة Bulk API) على إدخال واحد لكل سجل تم إرساله، لكل منها علامة نجاح وقائمة أخطاء خاصة به؛ مرّ عبرها لعزل الفشل.

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

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

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

بدون التزام.