AR
EnglishENNederlandsNLالعربيةARFrançaisFRDeutschDE
ابدأ مجانًا

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

تم حذف الـ metadata أو السجل الذي تشير إليه عملية النشر، أو أنه موجود في الـ Recycle Bin، في المؤسسة المستهدفة.

تظهر أثناء: DML وقت التشغيل وعمليات نشر metadata التي تشير إلى مكوّن تم حذفه لاحقًا

المعنى

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

يمكن أن يظهر على أي من المستويين: استعلام Apex أو عبارة DML تصادف سجلًا محذوفًا حذفًا ناعمًا لا يزال في الـ Recycle Bin، أو عملية نشر عبر Metadata API تشير إلى مكوّن سبق أن أزاله ملف destructiveChanges.xml من المؤسسة المستهدفة.

التشخيص

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

metadata محلية قديمة
تم حذف حقل أو كائن أو record type مباشرة في المؤسسة المستهدفة بعد آخر عملية retrieve، لذا لا تزال metadata المحلية تشير إليه.
بيانات اختبار محذوفة في منتصف المعاملة
يحذف اختبار Apex أو trigger سجلاً تحاول خطوة لاحقة في نفس المعاملة الاستعلام عنه أو تحديثه.
تغييرات هدمية تُنفَّذ بترتيب خاطئ
يُنفَّذ حذف عبر destructiveChanges.xml قبل metadata لا تزال تعتمد على المكوّن الذي يجري حذفه.

الحل

  1. أعِد المزامنة قبل النشر
    استرجع metadata الحالية من المؤسسة المستهدفة للتأكد من أن المكوّن لا يزال موجودًا فعليًا هناك.
    sf project retrieve start --target-org myOrgAlias --metadata CustomField:Account.Legacy_Score__c
  2. أزل المرجع أو استعده
    احذف المرجع القديم من metadata الخاصة بك، أو استعد المكوّن من الـ Recycle Bin إذا كان يفترض أن يظل موجودًا.
  3. رتّب التغييرات الهدمية بشكل صحيح
    انشر تغييرات metadata التابعة أولاً، ثم نفّذ عمليات الحذف الهدمية بعد ذلك، متبعًا نمط النشر الهدمي المكوّن من خطوتين في Salesforce.
من واقع الاستخدام

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

يسحب Serpent AI حالة المؤسسة الحية قبل كل مهمة ويُعلِّم أي مكوّن محذوف كتعارض diff يجب حله، بدلاً من تركه يفشل في منتصف عملية النشر. راجع مكتبة أخطاء نشر Salesforce.

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

الوقاية

استرجع قبل كل سير عمل retrieve-and-modify، ولا تفترض الحداثة أبدًا
تعامل مع metadata المخزّنة محليًا كأنها قابلة للتخلص منها؛ اسحب حالة حديثة من المؤسسة المستهدفة مباشرة قبل بناء عملية نشر ضدها.
أعِد الاستعلام عن السجلات بعد أي حذف ضمن نفس المعاملة
لا تفترض أبدًا أن سجلاً تم الاستعلام عنه سابقًا في طريقة Apex لا يزال موجودًا بعد تنفيذ عبارة حذف لاحقًا في نفس المعاملة؛ أعِد الاستعلام أو أعِد هيكلة المنطق.
وحّد على destructiveChangesPre/Post.xml لكل عملية حذف
قسّم عمليات الحذف دائمًا باستخدام ملفات التغيير الهدمي pre وpost الموثقة من Salesforce بدلاً من ترتيب حذف مرتجل.

أخطاء ذات صلة

DEPENDENCY_EXISTSالحظر الذي يمنع حدوث هذا الخطأ من الأساس، عندما يكتشف Salesforce التبعية قبل الحذف.DELETE_FAILEDالنسخة على مستوى السجل من عملية حذف يتم حظرها بدلاً من نجاحها بصمت خارج الترتيب الصحيح.INVALID_CROSS_REFERENCE_KEYفشل ذو صلة عندما يشير مرجع إلى شيء لم يكن موجودًا في المؤسسة المستهدفة على الإطلاق.CANNOT_UPDATE_CONVERTED_LEADحظر آخر قائم على الحالة: لا يزال السجل موجودًا، لكن التحويل جعله للقراءة فقط.
أسئلة شائعة

ENTITY_IS_DELETED، بالإجابات

هل يمكنني استعادة مكوّن تم حذفه عن طريق الخطأ؟
إذا تم حذفه مؤخرًا، تحقق أولاً من الـ Recycle Bin الخاص بالمؤسسة. تبقى مكوّنات metadata والسجلات قابلة للاستعادة هناك لفترة محدودة.
إلى متى يبقى السجل أو مكوّن الـ metadata المحذوف في الـ Recycle Bin؟
تبقى السجلات عادةً قابلة للاستعادة لمدة 15 يومًا قبل حذفها نهائيًا؛ ولبعض أنواع metadata فترات احتفاظ خاصة بها، لذا تحقق من Setup لمعرفة نوع المكوّن المحدد.
هل يتجنب الاستعلام عن سجل من الـ Recycle Bin باستخدام ALL ROWS هذا الخطأ؟
يمكن ذلك، بالنسبة لاستعلامات SOQL. تسمح إضافة ALL ROWS للاستعلام برؤية السجلات المحذوفة حذفًا ناعمًا، لكن أي تحديث أو حذف DML عليها لا يزال يفشل حتى تتم استعادة السجل.

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

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

ابدأ مجانًااحجز عرضًا تجريبيًا

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

بدون التزام.