تقادم XML-RPC وJSON-RPC في أودو: كيف تُرحّل إلى JSON-2

ثمة تصحيح مهم ينبغي أن يعرفه المطورون قبل التخطيط لترحيل تكاملات أودو 20:

لم يُزِل أودو في الإصدار 20 كل خدمات XML-RPC/JSON-RPC الخارجية القديمة.

تنص الوثائق الرسمية الحالية على ما يلي:

• أُزيلت خدمة db القديمة في أودو 20؛
• خدمتا common وobject متقادمتان، ومن المقرر حالياً إزالتهما في أودو 22؛
• واجهة JSON-2 الخارجية هي البديل المعتمد.

قد تعرض مواد أودو القديمة ومقالات الجهات الخارجية جدولاً زمنياً سابقاً. اعتمد على الوثائق الرسمية الحالية عند التخطيط لأعمال الإنتاج.

ما المتقادم فعلاً؟

ينطبق التقادم في أودو على نقاط النهاية والخدمات الخارجية القديمة لـ RPC.

لا تفترض تلقائياً أن كل متحكم JSON مخصص في وحدة أودو قد أُزيل لمجرد أن "JSON-RPC متقادم".

فمتحكمات التطبيقات المخصصة وواجهة API الخارجية القديمة مفهومان منفصلان، ويجب مراجعتهما في ضوء وثائق المتحكمات الحالية.

لماذا الترحيل قبل الإزالة؟

الانتظار حتى إصدار الإزالة النهائي يخلق ضغطاً لا داعي له.

أما الترحيل المبكر فيمنحك الوقت من أجل:

• جرد العملاء غير الموثقين؛
• إنشاء اختبارات للعقود؛
• إعادة تصميم المصادقة؛
• تقليص الصلاحيات؛
• إصلاح أنماط التكامل الضعيفة؛
• تشغيل المسارين القديم والجديد في مقارنة مضبوطة؛
• ترقية مكتبات العملاء.

والترحيل أيضاً فرصة للتوقف عن كشف طبقة النماذج العامة في أودو على نطاق أوسع من اللازم.

الخطوة 1 — اعثر على كل عميل قديم

ابحث في الشيفرة والبنية التحتية عن:

• /xmlrpc؛
• /xmlrpc/2؛
• /jsonrpc؛
• common؛
• object؛
• db؛
• execute_kw؛
• مكتبات RPC القديمة الخاصة بأودو؛
• سكربتات cron؛
• مهام ETL؛
• الأنظمة الخلفية لتطبيقات الجوال؛
• البرمجيات الوسيطة؛
• جداول البيانات وسكربتات الأتمتة.

لا تنسَ التكاملات التي يملكها قسم آخر أو مورّد آخر.

أنشئ جرداً:

كل ما يستخدم db يستحق اهتماماً فورياً في أودو 20، لأن الوثائق الحالية تنص على أن هذه الخدمة أُزيلت.

الخطوة 2 — وثّق العقد الحالي قبل إعادة كتابته

سجّل لكل عميل:

• المصادقة؛
• النموذج/الدوال؛
• النطاقات (domains)؛
• الحقول؛
• السياق (context)؛
• التقسيم إلى صفحات؛
• حمولات الكتابة؛
• الأخطاء المتوقعة؛
• سلوك إعادة المحاولة؛
• التعامل مع المناطق الزمنية؛
• التعامل مع البيانات الثنائية والمستندات.

ثم اكتب اختبارات تغطي هذا السلوك.

فالترحيل من دون عقد قديم معروف ينتهي إلى عبارة "يبدو أن التكامل الجديد يعمل".

وهذا لا يكفي لنظام حرج.

الخطوة 3 — أعد تقييم الصلاحيات

كثيراً ما تعمل التكاملات القديمة بمستخدمين تراكمت لديهم صلاحيات مفرطة.

استغل الترحيل لإنشاء مستخدم تكامل بأقل قدر من الصلاحيات.

اختبر:

• حقوق الوصول؛
• قواعد السجلات؛
• الحدود بين الشركات المتعددة؛
• السجلات المؤرشفة؛
• النماذج الحساسة.

لا تستبدل بيانات اعتماد مدير قديمة بمفتاح API جديد لمدير ثم تسمّي ذلك تحديثاً.

الخطوة 4 — اربط العمليات بـ JSON-2

استخدم وثائق JSON-2 الرسمية الحالية لربط كل عملية مطلوبة.

تجنّب ترجمة الاستدعاءات آلياً إذا كانت بنية التكامل القديم ضعيفة.

فعلى سبيل المثال، إذا كان العميل ينفّذ خمس عمليات كتابة منخفضة المستوى لمحاكاة عملية أعمال واحدة، ففكّر في كشف دالة أودو مُتحقَّق منها أو استدعائها لتنفّذ العملية بشكل ذرّي.

حافظ على دلالات الأعمال، لا على بنية الطلبات المتقادمة.

الخطوة 5 — صمّم مراعياً حدود المعاملات

استدعاءات HTTP المنفصلة هي نقاط فشل منفصلة.

إذا كان يجب ألا تحدث العملية B أبداً من دون العملية A، ففكّر في تنفيذ دالة أعمال على جانب الخادم تؤدي العمليتين معاً ضمن قواعد المعاملات والأعمال في أودو.

لا تجعل عميلاً خارجياً مسؤولاً عن إعادة بناء الثوابت الداخلية لنظام ERP.

الخطوة 6 — حسّن معالجة الأخطاء

كثيراً ما تتعامل التكاملات القديمة مع كل فشل على أنه "خطأ RPC".

ينبغي أن يصنّف العميل الجديد الأخطاء إلى:

• المصادقة؛
• التفويض؛
• التحقق من الصحة؛
• سجل مفقود؛
• طلب مشوّه؛
• تعارض/حالة أعمال؛
• الشبكة/انتهاء المهلة؛
• فشل الخادم.

أعد المحاولة فقط في حالات الفشل القابلة فعلاً لإعادة المحاولة.

الخطوة 7 — اختبر السلوك القديم مقابل الجديد

في العمليات الآمنة، قارن:

• السجلات المُعادة؛
• الحقول؛
• الترتيب حيثما كان مهماً؛
• سلوك النطاقات؛
• سلوك السياق والشركات؛
• القيم المُنشأة؛
• نتيجة سير العمل؛
• دلالات الأخطاء.

أما في أنظمة الإنتاج كثيفة الكتابة، فاستخدم بيئة التجهيز بدلاً من الكتابة المزدوجة على البيانات الحية.

الخطوة 8 — انتقل إلى الإنتاج مع إمكانية المراقبة

قبل التحويل:

• أضف ربط الطلبات وتسجيلها؛
• راقب معدلات الأخطاء؛
• راقب زمن الاستجابة؛
• حدّد آلية التراجع على مستوى العميل أو الإعدادات حيثما أمكن؛
• أبقِ العميل القديم متاحاً فقط خلال نافذة الانتقال المخططة؛
• أزل الأسرار ونقاط النهاية القديمة بعد الاستقرار.

لا تترك التكامل المتقادم يعمل إلى الأبد "تحسّباً لأي طارئ".

ماذا عن أودو 20 تحديداً؟

لأودو 20 أهمية خاصة لأن خدمة db القديمة قد أُزيلت فيه بالفعل وفقاً للوثائق الرسمية الحالية.

أما بالنسبة لـ common وobject، فالمسألة الآنية ليست أن "أودو 20 يعطّل كل شيء"، بل إنهما متقادمتان مع توجّه موثّق نحو إزالتهما.

وهذا يمنح الفرق نافذة للترحيل، فاستفد منها.

ماذا عن متحكمات JSON-RPC المخصصة؟

تعامل معها بشكل منفصل.

إذا كانت وحدتك المخصصة تكشف مساراً لتطبيق جوال أو لـ webhook، فافحص إطار عمل HTTP/المتحكمات الحالي في أودو وطريقة تنفيذ المسار.

لا تُعِد كتابة نقطة نهاية مخصصة تعمل جيداً لمجرد أن خدمة خارجية قديمة لا علاقة لها بها تشترك معها في عبارة "JSON-RPC".

الجدول الزمني الحالي للتقادم

قد تكون المقالات القديمة حول هذا الموضوع غير محدّثة. والجدول الزمني الرسمي الحالي هو:

ويؤكد سجل وثائق أودو أن الإزالة الأوسع كانت مقررة في الأصل في موعد أبكر ثم أُرجئت. ولهذا قد تكون مقالات أودو 20 القديمة خاطئة الآن.

مطابقة object RPC مع JSON-2

المفهوم القديم:

object.execute_kw(
  database, uid, credential,
  model, method, args, kwargs
)

مفهوم JSON-2:

POST /json/2/<model>/<method>
Authorization: bearer <API_KEY>
JSON body with named arguments

يُلغي الترحيل تسلسل تسجيل الدخول ثم استدعاء object القديم، ويغيّر طريقة المصادقة وبنية الطلب.

لا تترجم كل استدعاء منخفض المستوى ترجمة آلية حرفية، بل حافظ على العملية التجارية نفسها.

حالة خاصة: خدمة db المُزالة

اجرد السكربتات التي تسرد قواعد البيانات أو تنشئها أو تحذفها أو تنسخها أو تديرها بأي شكل آخر عبر خدمة db القديمة.

ولا تفترض وجود بديل مقابل لها في نماذج JSON-2 لإدارة قواعد البيانات. بل أعد تصميم سير العمل هذا حول آليات الإدارة والنشر المدعومة حاليًا.

هل ينبغي لمستخدمي أودو 20 أن يقلقوا؟

لا. إذا كان التكامل يستخدم فقط خدمتَي common/object المتقادمتين، فإن أودو 20 لا يعني تلقائيًا أنه سيتوقف عن العمل. لكنه دَين تقني موثّق له مسار إزالة محدد.

والتسلسل المعقول هو:

الجرد ← اختبارات العقد ← عميل JSON-2 ← المقارنة في بيئة التجهيز ← الانتقال المضبوط إلى الإنتاج ← إبطال بيانات الاعتماد القديمة.

الترحيل يحافظ على الدلالة لا على الصياغة

قد يبدو الاستدعاء القديم هكذا:

execute_kw(model, method, args, kwargs)

والهدف ليس إنتاج مقابل في JSON-2 يطابقه سطراً بسطر.

اسأل أولاً: ما عملية الأعمال التي ينفّذها العميل القديم؟

فإذا كان العميل القديم:

1. يبحث عن عميل؛
2. ينشئ طلباً؛
3. ينشئ بنود الطلب؛
4. يعدّل الحالة؛
5. يطلق استدعاءً آخر؛

فقد يكون الهدف الأفضل دالة أودو مصممة لهذا الغرض تمثّل عملية الأعمال كاملة.

وهذه فرصة لتبسيط العقد.

شغّل مجموعة اختبارات للعقد

في عمليات القراءة، قارن بين العميلين القديم والجديد على بيانات بيئة التجهيز نفسها من حيث:

• معرّفات السجلات؛
• الحقول المهمة؛
• التصفية بالنطاقات (domains)؛
• السياق (context)؛
• سلوك الشركات؛
• التقسيم إلى صفحات.

وفي عمليات الكتابة، تحقّق من حالة أودو الناتجة بدلاً من الاكتفاء بمقارنة استجابات HTTP.

مثال:

Input: external order ABC-123
Expected:
- one Odoo order
- correct customer
- three lines
- expected currency/company
- no duplicate on retry

وهذا اختبار ترحيل أقوى بكثير من "أعاد الطلب نتيجة ناجحة".

خطّط للانتقال إلى الإنتاج لكل تكامل على حدة

ليس على كل العملاء أن يتحولوا في اليوم نفسه.

ومن التسلسلات الأقل خطورة:

1. ترحيل عملاء القراءة فقط والتقارير؛
2. ترحيل عملاء الكتابة منخفضي الأثر؛
3. ترحيل عملاء الكتابة الحرجين للإيرادات أو العمليات؛
4. إزالة بيانات الاعتماد والمكتبات القديمة بعد الاستقرار.

فهذا يقلّل عدد المجهولات أثناء الانتقال إلى الإنتاج في ترقية أودو إلى إصدار رئيسي جديد.

اجرد الاعتماديات الخفية

كثيراً ما يبقى RPC القديم حياً في أماكن غير متوقعة:

• Excel/VBA؛
• سكربتات Python المجدولة؛
• خدمات الجوال القديمة؛
• ETL؛
• أدوات أتمتة شبيهة بـ Zapier؛
• البرمجيات الوسيطة لدى الموردين؛
• سكربتات المراقبة.

ابحث في مستودعات الشيفرة المصدرية والخوادم ومتغيرات CI والتوثيق، لا في التطبيق الرئيسي وحده.

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

هل أُزيل XML-RPC في أودو 20؟

تنص الوثائق الرسمية الحالية على أن خدمة db أُزيلت في أودو 20. أما خدمتا common وobject المتقادمتان فمن المقرر حالياً إزالتهما في أودو 22.

ما البديل عن RPC القديم في أودو؟

البديل المعتمد في أودو لواجهة API الخارجية هو JSON-2.

هل يجب أن نرحّل أثناء الترقية إلى أودو 20؟

ليس بالضرورة أن تُعاد كتابة كل تكامل قديم يعتمد على common/object خلال عملية الانتقال إلى الإنتاج نفسها، لكن ينبغي أن تجرد هذه التكاملات وتخطط لترحيلها. أما كل ما يستخدم خدمة db المُزالة فيتطلب إعادة تصميم من أجل أودو 20.

هل MCP هو البديل عن XML-RPC؟

لا. يخدم MCP مسارات عمل أدوات الذكاء الاصطناعي الخارجية، أما JSON-2 فهو البديل المعتمد لواجهة API الخاصة بالتطبيقات الخارجية.

الخلاصة

لا ترحّل لأن مدونة قديمة تقول إن "XML-RPC اختفى في أودو 20".

بل رحّل لأن واجهات API القديمة متقادمة، ولأن إحدى الخدمات أُزيلت بالفعل، ولأن البديل موجود، ولأن التحديث المضبوط أكثر أماناً من انتظار الموعد النهائي.

هل تخطط لمشروع على أودو 20؟ تساعد Octivex Tech الشركات في ترقيات أودو، وترحيل الوحدات المخصصة، والتكاملات، وسير العمل المدعوم بالذكاء الاصطناعي. تصفّح خدماتنا في أودو أو تواصل مع فريقنا الهندسي لمناقشة بيئتك.