تذكر وثائق Odoo الرئيسية أن خدمة قاعدة البيانات RPC القديمة تُزال في Odoo 20. وقد تم إهمال واجهات XML-RPC وJSON-RPC الأوسع نطاقًا منذ الإصدار 19.0، لكن Odoo 20 لا يزيل كل خدمة قديمة. وتوثق Odoo أن خدمتي common وobject ستبقيان متاحتين حتى Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) لذلك يجب على فرق التكامل تحديد الخدمة التي يستخدمها كل اتصال خارجي، بدلًا من التعامل مع دعم RPC القديم كأنه ميزة واحدة لها تاريخ إزالة واحد.
ذكرت صفحة حدث Odoo في الأمريكتين أن Odoo 20 سيصدر خلال حدث سان فرانسيسكو في 2 و3 سبتمبر 2026. (Oxp26 Americas Introduction) يمكن أن تأخذ خطط الترقية الآن في الحسبان إزالة خدمة قاعدة البيانات الموثقة، لكن يجب التحقق من قرارات الإنتاج وفقًا لوثائق الإصدار النهائية لـ Odoo 20.
تتعلق الإزالة بخدمة محددة
تحدد Odoo المسارات `/xmlrpc` و`/xmlrpc/2` و`/jsonrpc` كنقاط نهاية قديمة أُهملت منذ الإصدار 19.0. وضمن هذه الواجهات، تُزال خدمة قاعدة البيانات في Odoo 20، بينما من المقرر أن تبقى خدمتا common وobject حتى Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) قد يستمر تكامل يستخدم خدمة ما زالت مدعومة في العمل بعد الترقية إلى Odoo 20، لكن نقطة النهاية وحدها لا تثبت التوافق.
يمكن للنظام استخدام خدمات مختلفة عبر واجهة RPC القديمة. لذلك يجب أن يسجل فحص التكامل كلًا من نقطة النهاية والخدمة المستدعاة. إن وصف التطبيق فقط بأنه تكامل XML-RPC أو JSON-RPC لا يوضح ما إذا كان يعتمد على عملية أزيلت في Odoo 20. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API)
إن استمرار توفر خدمتي common وobject مؤقت. وتخطط Odoo لإزالتهما في Odoo 22. (Odoo master Docs: Reference External API; Odoo master Docs: Reference External Rpc API) يمكن للفرق فصل العمل العاجل على استدعاءات خدمة قاعدة البيانات عن ترحيل الخدمات المتبقية، لكن كلا الأمرين يحتاج إلى خطة.
JSON-2 يغيّر عقد الطلب
توثق Odoo JSON-2 على أنه واجهة البديل. ويكون تنسيق نقطة النهاية فيها `/json/2/<model>/<method>`، مع تضمين model وmethod في عنوان URL. (Odoo master Docs: Reference External API) لذلك فإن الترحيل يتجاوز مجرد استبدال المسار الأساسي في عميل RPC موجود. يجب ربط كل عملية بالمسار المناسب للنموذج والطريقة.
يتطلب JSON-2 معاملات مسماة في نص طلب JSON بدلًا من معاملات RPC الموضعية. (Odoo master Docs: Reference External API) قد تفترض الأغلفة الوسيطة والبرمجيات الوسيطة والعملاء المُولّدون أن ترتيب الوسائط هو الذي يحدد المعنى. وهذه المكونات تحتاج إلى مراجعة منفصلة. إن إعادة توجيه طلب قديم إلى نقطة النهاية الجديدة لن ينجح إذا استمر العميل في إنشاء معاملات موضعية.
بالنسبة لكل عملية جرى ترحيلها، ينبغي للفرق توثيق النموذج المستهدف والطريقة والمعاملات المسماة التي يتطلبها JSON-2. (Odoo master Docs: Reference External API) ثم يجب اختبار الطلبات في بيئة Odoo 20 ذات الصلة، خصوصًا عندما تنشئ مكتبة تكامل مشتركة الاستدعاءات لعدة تطبيقات. لا يمكن لمقارنات الحمولة الثابتة أن تؤكد كيفية تعامل الخادم أو العميل مع الطلب الكامل.
يجب أن يتغير التحقق من الهوية أيضًا
يستخدم JSON-2 تحقق هوية عبر bearer API-key. (وثائق Odoo master: مرجع واجهة برمجة التطبيقات الخارجية) يجب أن يشمل عمل الترحيل إنشاء المفاتيح، التخزين الآمن، التعامل مع رأس التفويض، واستبدال المفاتيح. كما يجب فحص الوكلاء والبوابات ومكتبات العميل للتأكد من أنها تحتفظ بالرأس عند تمرير الطلبات. وينبغي أيضاً مراجعة التسجيل والمراقبة ومعالجة الأخطاء حتى لا تُكشف بيانات الاعتماد.
تحدد الوثائق طريقة المصادقة، لكن على كل مؤسسة أن تحدد كيف تتلاءم مفاتيح API مع ضوابط بيانات الاعتماد لديها. (وثائق Odoo master: مرجع واجهة برمجة التطبيقات الخارجية) ويشمل ذلك تحديد المسؤولية عن المفاتيح، والتحكم في الأماكن التي يمكن استخدامها فيها، وتحديد كيفية تحديث عمليات التكامل المتأثرة عند استبدال مفتاح.
حقول binary لديها تغيير توافق منفصل
يسجل سجل تغييرات ORM في Odoo تغييراً آخر في RPC في Odoo 20: إذ تضيف تمثيلات الحقول الثنائية `BinaryValue.filename`. (وثائق Odoo master: سجل تغييرات ORM) وهذا منفصل عن إزالة خدمة قاعدة البيانات لأنه يغيّر البيانات المعادة بدلاً من توفر الخدمة. ينبغي تضمين التطبيقات التي تقرأ أو تحول أو تتحقق من الردود التي تحتوي على حقول ثنائية في اختبار التوافق.
يؤكد سجل التغييرات إضافة العضو `filename`، لكن أثره العملي يعتمد على العميل. (وثائق Odoo master: سجل تغييرات ORM) يجب أن تتحقق الاختبارات مما إذا كانت المخططات الصارمة، والمُسلسِلات، ومقارنات الردود، والتحويلات اللاحقة تقبل العضو الإضافي. قد لا تحتاج العملاء التي تتجاهل الحقول غير المعروفة إلى أي تعديل، لكن يجب التحقق من هذا السلوك بدلاً من افتراضه.
كيفية تحديد نطاق تدقيق التكامل
ابدأ بتحديد الاتصالات التي تستخدم `/xmlrpc` أو `/xmlrpc/2` أو `/jsonrpc`، وهي نقاط نهاية تصنفها Odoo على أنها مهملة. (وثائق Odoo master: مرجع واجهة برمجة التطبيقات الخارجية; وثائق Odoo master: مرجع RPC الخارجي) يجب أن تشمل الجرد التطبيقات المطورة داخلياً، والبرمجيات الوسيطة، والعمليات المجدولة، والموصلات الخارجية حيث تكون التهيئة أو الشيفرة المصدرية متاحة. خصص مالكاً لكل اتصال حتى يمكن التحقق من الغرض منه وحالته.
بعد ذلك، صنف كل اتصال حسب الخدمة القديمة. يتطلب استخدام خدمة قاعدة البيانات معالجةً لـ Odoo 20، بينما يظل استخدام الخدمة العامة وخدمة الكائن موثقاً على أنه متاح حتى Odoo 22. (وثائق Odoo master: مرجع واجهة برمجة التطبيقات الخارجية; وثائق Odoo master: مرجع RPC الخارجي) يدعم هذا خطة مرحلية: عالج عدم التوافق في Odoo 20 أولاً، ثم حدد تواريخ الترحيل للنداءات المهملة المتبقية.
بالنسبة لعمليات التكامل التي تنتقل إلى JSON-2، سجل المسار `/json/2/<model>/<method>`، ومعاملات الطلب المسماة، ومصادقة API-key بنمط bearer المطلوبة من الواجهة البديلة. (وثائق Odoo master: مرجع واجهة برمجة التطبيقات الخارجية) يجب أن تغطي حالات الاختبار الطلبات الناجحة، ورفض المصادقة، والمعاملات المسماة غير الصالحة، ومعالجة التطبيق للبيانات المعادة. أضف حالات الحقول الثنائية حيثما ظهرت تلك الحقول.
تأكيد السلوك النهائي في Odoo 20
استُمدت تفاصيل الإزالة من وثائق المطور الرئيسية في Odoo، بينما يأتي توقيت الإصدار المعلن من صفحة حدث تنص على أن Odoo 20 سيُصدر خلال حدث الأمريكتين في سبتمبر 2026. (وثائق Odoo master: مرجع واجهة برمجة التطبيقات الخارجية; وثائق Odoo master: مرجع RPC الخارجي; مقدمة Oxp26 Americas) قبل النشر، ينبغي للفرق إعادة التحقق من الوثائق الخاصة بإصدار Odoo 20 الذي تم إطلاقه، وكذلك من الطبعة والبناء الدقيقين اللذين يعتزمون استخدامهما.
إن استخدام نقطة نهاية RPC مهملة لا يثبت بحد ذاته أن عملية التكامل ستتوقف عن العمل في Odoo 20، لأن الخدمة العامة وخدمة الكائن تظلان موثقتين حتى Odoo 22. وعلى العكس، فإن التشغيل الناجح على إصدار أقدم لا يثبت التوافق لنداء خدمة قاعدة البيانات بعد إزالتها. (وثائق Odoo master: مرجع واجهة برمجة التطبيقات الخارجية; وثائق Odoo master: مرجع RPC الخارجي)
قائمة التحقق لقرار الترقية
قبل الموافقة على ترقية إلى Odoo 20، ينبغي لصناع القرار طلب سجل تكامل يوضح كل نقطة نهاية مهملة، والخدمة المستدعاة، ومالكها، والمعالجة المخطط لها. يجب أن تكون تبعيات خدمة قاعدة البيانات لها بديل مختبر. ينبغي أن يكون للعمليات المتكاملة التي تبقى على الخدمات العامة أو خدمات الكائن تاريخ ترحيل منفصل يعكس إزالتها الموثقة في Odoo 22. (وثائق Odoo master: مرجع واجهة برمجة التطبيقات الخارجية؛ وثائق Odoo الرئيسية: مرجع واجهة برمجة التطبيقات RPC الخارجية)
يجب أن يؤكد المراجعة أن تطبيقات JSON-2 تضع النموذج والطريقة في عنوان URL، وتستخدم وسائط JSON مسماة، وتتحقق من الهوية باستخدام مفتاح API من نوع bearer. وعندما تكون الحقول الثنائية موجودة، يجب أن يأخذ الاختبار في الاعتبار إضافة `BinaryValue.filename`. (وثائق Odoo الرئيسية: مرجع الواجهة البرمجية الخارجية؛ وثائق Odoo الرئيسية: سجل تغييرات ORM) تميز هذه الفحوصات بين الإزالة الفورية لخدمة قاعدة بيانات Odoo 20 وبين الإيقاف اللاحق للخدمات القديمة المتبقية.