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

مكوّن بيانات وصفية، أو نوع يشير إليه، غير صالح أو غير مفعّل في المؤسسة الهدف.

يظهر أثناء: التحقق من صحة نشر البيانات الوصفية، قبل أي DML أو تشغيل اختبارات

المعنى

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

يحدث هذا غالبًا عند ترقية بيانات وصفية من مؤسسة إنتاج غنية بالميزات، أو نسخة بيئة اختبار كاملة منها، إلى مؤسسة scratch أو بيئة اختبار Developer Edition لم تُهيَّأ مجموعة ميزاتها وتراخيصها لتتطابق قط.

التشخيص

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

ميزة غير مفعّلة في المؤسسة الهدف
تعتمد البيانات الوصفية على ميزة مثل Person Accounts أو Multi-Currency مفعّلة في المؤسسة المصدر لكنها معطّلة في الهدف.
عدم تطابق في إصدار API
يشير إصدار API الخاص بالبيانات الوصفية إلى حقل أو إمكانية لا يتعرّف عليها إصدار API المدعوم في المؤسسة الهدف.
كائن أو حقل قياسي مفقود بالنسبة للإصدار
الكائن أو الحقل القياسي المُشار إليه متاح فقط في إصدار Salesforce أو ترخيص لا تملكه المؤسسة الهدف.

الحل

  1. تأكد من تفعيل الميزة
    تحقق من أن المؤسسة الهدف تملك نفس الميزة أو الترخيص، مثل Person Accounts أو Multi-Currency أو ما شابه، مفعّلة كما في المصدر.
  2. طابِق إصدار API
    طابِق إصدار API للبيانات الوصفية في package.xml مع إصدار تدعمه المؤسسة الهدف بالكامل.
    <Package xmlns="http://soap.sforce.com/2006/04/metadata">
      <types>
        <members>*</members>
        <name>CustomObject</name>
      </types>
      <version>62.0</version>
    </Package>
  3. تحقق من توافق الإصدار
    تأكد من أن إصدار Salesforce الخاص بالمؤسسة الهدف يتضمن الكائن أو الحقل القياسي الذي يعتمد عليه المكوّن.
من واقع الاستخدام

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

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

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

الوقاية

طابِق تعريفات ميزات مؤسسة scratch مع الميزات المفعّلة في الإنتاج
حافظ على تزامن ميزات وإعدادات إصدار scratch-org-def.json مع ما هو مفعّل فعليًا في الإنتاج، وراجعها كلما تم تفعيل ميزة جديدة.
ثبّت package.xml على إصدار API مقصود، وليس الأحدث دائمًا
اختر إصدار API تدعمه سلسلة أدواتك بالكامل وكل مؤسسة هدف، وارفعه عمدًا بدلاً من تركه ينجرف إلى ما يعتمده CLI افتراضيًا.
وثّق الاعتماديات المرتبطة بالإصدار على المكوّن نفسه
دوّن في وصف البيانات الوصفية أو في مستندات المخطط متى يعتمد مكوّن على إصدار أو ترخيص معيّن، بحيث يكون ذلك واضحًا قبل محاولة الترقية.
أسئلة شائعة

INVALID_TYPE، بالتفصيل

هل يعني INVALID_TYPE أن XML البيانات الوصفية مشوّه؟
لا. عادةً ما يكون XML صالحًا؛ النوع الذي يعلنه أو يشير إليه ببساطة غير مدعوم من إصدار المؤسسة الهدف أو ميزاتها أو إصدار API الخاص بها.
هل يمكنني تفعيل ميزة مفقودة بنفسي، أم يتطلب ذلك دعم Salesforce؟
يعتمد ذلك على الميزة. بعضها، مثل Multi-Currency، ذاتي الخدمة في الإعداد لكنه غير قابل للتراجع عمليًا؛ وبعضها الآخر، مثل Person Accounts، يتطلب فتح حالة دعم لدى Salesforce لتفعيله.
هل يؤدي خفض إصدار API في package.xml إلى مشاكل جديدة أحيانًا؟
نعم، يمكن أن يحجب الوصول إلى حقول أو أنواع بيانات وصفية أحدث يحتاجها الكود فعليًا. طابِق الإصدار مع ما تدعمه المؤسسة الهدف بدلاً من الخفض أكثر من اللازم.

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

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

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

بدون التزام.