الترحيل من أودو 19 إلى أودو 20: دليل تقني لقواعد البيانات المخصصة

لا يكتمل الترحيل من أودو 19 إلى أودو 20 بمجرد وصول قاعدة البيانات القياسية إلى الإصدار 20. فإذا كان النظام يتضمن وحدات مخصصة أو تكاملات أو بيانات مخصصة تاريخية، فيجب أن تصل ثلاثة أشياء معاً إلى الإصدار المستهدف:

1. قاعدة بيانات أودو القياسية؛
2. الشيفرة المصدرية المخصصة ونموذج البيانات؛
3. الأنظمة الخارجية وسير العمل التشغيلي المحيط بها.

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

لذلك فالسؤال المهم بالنسبة للمطورين ليس "هل تُثبَّت الوحدة على أودو 20؟" بل هو:

"هل تحافظ شيفرة أودو 20 على السلوك المقصود والبيانات التاريخية لتنفيذ أودو 19؟"

يركّز هذا الدليل على هذا الترحيل التقني.

ملاحظة حول الإصدار: لا تزال وثائق أودو 20 وأدوات الترقية الخاصة به قيد التطوير. أعد مراجعة الوثائق الرسمية للإصدار 20.0/master وتحقّق من توفر مسار الترقية الدقيق الخاص بك قبل الانتقال إلى الإنتاج.

الترحيل في نظرة واحدة

يمكن تنظيم ترحيل مخصص موثوق من 19 → 20 في ستة مسارات عمل:

إن إبقاء مسارات العمل هذه منفصلة يجعل تتبّع الأخطاء أسرع بكثير.

الخطوة 1 — جمّد قاعدة شيفرة أودو 19 وجرد الفروقات

يوصي أودو بتجميد التطوير عند بدء ترقية مخصصة، باستثناء إصلاحات الأخطاء الضرورية.

أنشئ فرع ترحيل من نسخة إنتاج معروفة، واجرد كل وحدة مخصصة.

سجّل لكل وحدة:

• الغرض منها والمسؤول عنها؛
• الاعتماديات؛
• النماذج والحقول المضافة أو المُعاد تعريفها؛
• الواجهات والتقارير؛
• المتحكمات ونقاط نهاية API؛
• شيفرة JavaScript/Owl؛
• الإجراءات المجدولة وإجراءات الخادم؛
• قواعد الأمان؛
• التكاملات الخارجية؛
• تغطية الاختبارات؛
• ما إذا كان أودو 20 يوفّر الآن هذا التخصيص بشكل أصلي.

البند الأخير مهم.

فالوحدة التي لم تعد ضرورية ينبغي في العادة إيقافها بدلاً من ترحيلها.

الخطوة 2 — أنشئ خط أساس نظيفاً للتوافق مع أودو 20

قبل إدخال بيانات العميل المُرقّاة، اجعل كل وحدة مخصصة مطلوبة قابلة للتثبيت على قاعدة بيانات أودو 20 فارغة.

يوصي أودو بذلك صراحةً لأنه يعزل توافق الشيفرة المصدرية عن مشكلات البيانات والإعدادات التاريخية.

ينبغي أن يكشف الاختبار على قاعدة نظيفة من الإصدار المستهدف ما يلي:

• الاعتماديات المفقودة؛
• واجهات برمجة إطار العمل التي أُعيدت تسميتها أو أُزيلت؛
• الواجهات غير الصالحة؛
• أخطاء Python وتحذيراتها؛
• الأصول المعطّلة؛
• مشكلات JS/Owl؛
• معرّفات XML المفقودة؛
• مشكلات تعريفات الأمان؛
• فشل الاختبارات.

ولا تجمع الوحدة مع قاعدة بيانات العميل المُرقّاة إلا بعد أن تعمل بشكل صحيح على أودو 20 نظيف.

الخطوة 3 — راجع تغييرات ORM الموثّقة في أودو 20

يحدّد سجل تغييرات ORM الرسمي من أودو بالفعل تغييرات ينبغي لمطوري التخصيصات البحث عنها.

إزالة Model._table_query

يُزيل أودو 20 الخاصية Model._table_query.

إذا كان نموذج تقارير مخصص أو نموذج قائم على SQL يعتمد على هذه الآلية، فلا تنتظر ظهور خطأ في بيئة الإنتاج. ابحث في قاعدة الشيفرة أثناء الترحيل وأعد تصميم التنفيذ باستخدام النهج المدعوم في أودو 20.

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

تغيّر تمثيل الحقول الثنائية في RPC

يضيف أودو 20 الخاصية BinaryValue.filename ويحدّث صيغة RPC للحقول الثنائية.

وهذا مهم لما هو أبعد من شيفرة Python. فالعميل الخارجي الذي يفترض شكلاً محدداً لحمولة البيانات الثنائية قد يحتاج إلى اختبار انحدار.

تحقّق من:

• تطبيقات الجوال؛
• البرمجيات الوسيطة للبوابة؛
• تكاملات المستندات؛
• خدمات الاستيراد والتصدير؛
• المتحكمات المخصصة أو مستهلكي RPC.

تغيّر سلوك الترجمة

يوثّق سجل تغييرات أودو 20 أيضاً تبسيط التعامل مع الترجمات وتغييرات في طريقة تخزين مصطلحات الترجمة في ملف البيان (manifest).

إذا كانت الوحدات المخصصة تتعامل مع الترجمات برمجياً أو تتضمن بيانات توطين كبيرة، فأدرج الترجمات في خطة اختبار الترحيل بدلاً من افتراض أنها مجرد ملفات ثابتة.

أداة populate الجديدة

يضيف أودو 20 سكربت populate لتوليد بيانات اختبار وهمية.

هذا لا يعيق الترحيل، لكنه مفيد هندسياً: فالبيانات المولّدة الواقعية يمكن أن تحسّن اختبارات الأداء والانحدار دون نسخ سجلات الإنتاج الحساسة إلى كل بيئة تطوير.

الخطوة 4 — راجع كامل نطاق الوحدة المخصصة

سجل تغييرات ORM نقطة بداية، وليس فرقاً كاملاً للترحيل.

راجع كل طبقة بعناية.

Python وORM

ابحث عن:

• إعادة تعريف create وwrite وunlink وsearch ومنطق الحساب؛
• الافتراضات حول قيم الحقول وأنواعها؛
• النماذج القائمة على SQL؛
• السلوك المعتمد على السياق (context)؛
• المنطق المعتمد على الشركة؛
• سلوك الوصول والأمان؛
• الترقيعات الديناميكية (monkey patches) أو الاستيراد من وحدات داخلية.

فضّل واجهات البرمجة العامة المدعومة على تفاصيل التنفيذ الداخلية.

واجهات XML

تحقّق من:

• أهداف الواجهات الموروثة؛
• تعبيرات XPath؛
• توفّر الحقول؛
• سلوك المعدّلات والظهور؛
• الإجراءات والقوائم؛
• واجهات البحث؛
• واجهات الإعدادات؛
• تخطيطات kanban/form/list.

قد يصمد تعبير XPath هشّ لسنوات ثم يفشل فور تغيّر الواجهة الأصلية.

JavaScript/Owl والأصول

راجع:

• عمليات الاستيراد؛
• السجلات (registries) والخدمات؛
• الترقيعات (patches)؛
• القوالب؛
• الحزم (bundles)؛
• امتدادات نقاط البيع وعميل الويب؛
• افتراضات RPC؛
• أخطاء وحدة تحكم المتصفح.

لا يكتمل ترحيل الواجهة الخلفية إذا فقدت الواجهة الأمامية سلوكاً مخصصاً دون أن يلاحظ أحد.

التقارير

تحقّق من العرض ومن القيم معاً.

بالنسبة لتقارير QWeb/PDF/XLSX أو منطق التقارير المخصص، تحقّق من:

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

الأمان

أعد اختبار:

• قوائم التحكم في الوصول (ACL)؛
• قواعد السجلات؛
• المجموعات؛
• المجموعات الضمنية؛
• استخدام sudo؛
• حدود الشركات؛
• الوصول عبر البوابة والوصول العام.

الترحيل الذي يوسّع صلاحيات الوصول عن غير قصد أخطر من ترحيل يعطّل زراً.

الخطوة 5 — رحّل البيانات المخصصة التاريخية بشكل صريح

هنا يفترق "يعمل على قاعدة بيانات نظيفة" عن "يعمل لدى العميل".

توصي وثائق أودو الخاصة بالترقية المخصصة باستخدام سكربتات الترقية عندما تتغيّر البيانات التقنية بين الإصدارات.

ومن الحالات النموذجية:

• الحقول التي أُعيدت تسميتها؛
• النماذج التي أُعيدت تسميتها؛
• المعرّفات الخارجية/معرّفات XML التي أُعيدت تسميتها؛
• النماذج التي دُمجت أو أُزيلت؛
• قيم الاختيار التي تغيّرت؛
• البيانات التي نُقلت بين النماذج؛
• السجلات المخصصة التي يجب إعادة حسابها؛
• سجلات الإعدادات التي تحتاج إلى قيم جديدة.

توفّر مكتبة Upgrade Utils من أودو دوال مساعدة مثل rename_field() وrename_model() وrename_xmlid() لتقليل مخاطر إعادة كتابة مراجع قاعدة البيانات يدوياً.

يبدو النمط المبسّط كما يلي:

from odoo.upgrade import util

def migrate(cr, version):
    util.rename_field(cr, "your.model", "old_field", "new_field")

لا تنسخ هذا إلى الإنتاج دون تمحيص. فالدالة المساعدة المناسبة ومرحلة الترحيل تعتمدان على التغيير في الشيفرة أو البيانات. تحقّق من واجهة Upgrade Utils الحالية واختبر السكربت على قاعدة بيانات مُرقّاة مؤقتة يمكن التخلص منها.

لماذا لا يكفي SQL المباشر دائماً

قد تحافظ إعادة تسمية عمود يدوياً على القيمة الظاهرة في الجدول، بينما تُغفل المراجع غير المباشرة أو البيانات الوصفية لأودو.

ومن أسباب وجود الدوال المساعدة للترقية الحفاظ على اتساق المراجع المرتبطة.

استخدم SQL الخام عندما يكون فعلاً الأداة الصحيحة، لا لمجرد أنه أقصر.

الخطوة 6 — تعامل مع سجلات noupdate بوعي

تنبّه إرشادات أودو للترقية المخصصة تحديداً إلى السجلات المخصصة الموسومة بـ noupdate.

قد لا تُحدَّث هذه السجلات تلقائياً عند ترقية الوحدة.

وقد يكون لذلك أثر على:

• سجلات الإعدادات؛
• إجراءات الخادم؛
• الإجراءات المجدولة؛
• قوالب البريد الإلكتروني؛
• التسلسلات؛
• القواعد؛
• البيانات الافتراضية.

إذا كان سجل noupdate من أودو 19 يجب أن يعكس تعريفاً جديداً في أودو 20، فخطّط لترحيل صريح.

ويشير أودو إلى دوال مساعدة مثل update_record_from_xml() لهذا النوع من الحالات.

والقاعدة العامة بسيطة:

لا تفترض أن تغيّر بيانات XML في الشيفرة المصدرية يعني أن السجلات التاريخية في قاعدة البيانات تغيّرت أيضاً.

تحقّق من السجل الفعلي بعد الترقية.

الخطوة 7 — افحص الواجهات المعطّلة في تقرير الترقية

أثناء ترقية قاعدة البيانات القياسية، قد تُعطَّل الواجهات المخصصة التي تسبّب مشكلات.

ويوجّه أودو المطورين إلى فحص تقرير الترقية (Upgrade Report) بحثاً عن هذه الحالات.

قرّر لكل واجهة معطّلة:

1. هل لا يزال هذا التخصيص مطلوباً؟
2. هل لا تزال الواجهة الأم الموروثة موجودة؟
3. هل لا يزال تعبير XPath صالحاً؟
4. هل جعل أودو 20 القياسي هذا التخصيص زائداً عن الحاجة؟
5. هل ينبغي ترحيلها وإعادة تفعيلها، أم حذفها؟

لا تُعِد تفعيل الواجهات القديمة تلقائياً.

فالواجهة المعطّلة قد تكون إشارة مفيدة إلى أن سير العمل القياسي الأساسي قد تغيّر.

الخطوة 8 — دقّق التكاملات بمعزل عن توافق الوحدات

قد يُبقي الترحيل من أودو 19 → 20 الوحدة المخصصة سليمة بينما يعطّل تطبيقاً خارجياً.

اجرد كل تكامل حسب البروتوكول.

XML-RPC / JSON-RPC القديمة

تذكر وثائق أودو الرسمية الحالية أن خدمتَي XML-RPC وJSON-RPC الخارجيتين مُهملتان.

والجدول الزمني المهم هو:

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

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

أما إذا كان التكامل يستخدم خدمة db القديمة، فإن أودو 20 يعنيه مباشرة.

متحكمات JSON-RPC المخصصة

لا تخلط بين خدمات RPC الخارجية القديمة وكل متحكم JSON مخصص.

فإشعار الإهمال من أودو يميّز صراحةً بين المتحكمات المخصصة ونقاط نهاية الخدمات الخارجية المُهملة.

راجع المتحكمات المخصصة وفق واجهة HTTP/المتحكمات الحالية، لا بتطبيق إهمال RPC الخارجي عليها دون تمييز.

JSON-2

بالنسبة للتكاملات التي تعمل على تحديثها، قيّم واجهة External JSON-2 API من أودو.

لا تجمع تلقائياً بين ترحيل الإنتاج من أودو 19→20 وإعادة كتابة كاملة لواجهة API. فأحياناً يقلّل الفصل بين ترقية الإصدار وتحديث التكامل من المخاطر.

وفي أحيان أخرى تكون الترقية هي اللحظة المناسبة لإزالة اعتمادية مُهملة.

اتخذ هذا القرار لكل تكامل على حدة.

تكاملات البيانات الثنائية والمستندات

بما أن أودو 20 يغيّر تمثيل الحقول الثنائية في RPC، فاختبر صراحةً التكاملات التي ترفع المستندات أو تنزّلها أو تعتمد على افتراضات حول حمولة البيانات الثنائية.

الخطوة 9 — اختبر قاعدة بيانات العميل المُرقّاة

بمجرد أن تعمل الشيفرة المخصصة بشكل نظيف على أودو 20 وتتوفر الترقية القياسية لقاعدة البيانات، اجمع بينهما.

لم يعد الهدف "هل تُثبَّت؟"

بل الهدف هو صحة البيانات التاريخية.

اختر سجلات قديمة وحديثة تمثيلية:

• سجلات أُنشئت قبل التخصيصات الرئيسية؛
• الطلبات المفتوحة؛
• الطلبات المُسلّمة جزئياً؛
• الفواتير والإشعارات الدائنة القديمة؛
• المنتجات ذات المسارات والمتغيرات؛
• أرقام الدفعات والأرقام التسلسلية؛
• أوامر التصنيع؛
• الموظفون والعقود حيثما ينطبق ذلك؛
• سجلات الشركات المتعددة؛
• السجلات المؤرشفة؛
• السجلات التي تحتوي على حقول مخصصة.

اختبر القراءة والتعديل والانتقالات بين الحالات والتقارير.

الخطوة 10 — ابنِ مصفوفة اختبار للترحيل حسب الأثر على الأعمال

لكل وحدة مخصصة، اربط الشيفرة بأثرها على الأعمال.

يمنع هذا فريق الترحيل من إعلان النجاح لأن اختبارات الوحدات نجحت بينما تغيّرت النتيجة التشغيلية.

الخطوة 11 — شغّل الاختبارات القياسية وأضف اختبارات خاصة بالترحيل

يوصي أودو بأن تنجح الاختبارات القياسية أثناء ترحيل الوحدات المخصصة.

أضف اختبارات لمخاطر الترحيل التي تهم وحدتك تحديداً.

أمثلة مفيدة:

• ظهور بيانات الحقل القديم في الحقل المُعاد تسميته؛
• تحلّل معرّفات XML المُعاد تسميتها بشكل صحيح؛
• احتفاظ السجلات القديمة بملكية الشركة الصحيحة؛
• بقاء حالات سير العمل المخصصة صالحة؛
• احتواء إعدادات noupdate على القيمة المستهدفة المتوقعة؛
• تطابق إجماليات التقارير مع بيانات اختبار معروفة؛
• منع قواعد الوصول تسرّب البيانات بين الشركات.

بالنسبة لوحدة معقدة، قد يكون اختبار خاص بالترحيل أقل تكلفة من اكتشاف خطأ البيانات نفسه مراراً خلال اختبار قبول المستخدم (UAT) اليدوي.

الخطوة 12 — أجرِ تجربة كاملة للترحيل من 19 → 20

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

أعد تشغيل:

1. ترقية الاختبار القياسية؛
2. نشر شيفرة الإصدار المستهدف؛
3. تحديث الوحدات المخصصة؛
4. سكربتات الترقية pre/post/end؛
5. التعامل مع مخزن الملفات (filestore) حيثما ينطبق ذلك؛
6. خطوات الإعداد؛
7. الاختبارات الآلية؛
8. اختبارات الفحص التقني السريع؛
9. اختبار قبول المستخدم التمثيلي؛
10. فحوصات التكامل.

سجّل كل إجراء يدوي.

إذا كان هناك أمر SQL يدوي غير موثّق مطلوباً، فالترحيل لم يصبح قابلاً لإعادة الإنتاج بعد.

حوّله إلى عملية آلية، أو اكتب له سكربتاً، أو أضفه رسمياً إلى إجراء الانتقال إلى الإنتاج.

الخطوة 13 — الانتقال إلى الإنتاج

يعتمد تسلسل الإنتاج على الاستضافة، لكن المبادئ الهندسية تبقى نفسها:

• جمّد التغييرات على أودو 19؛
• أوقف الأنظمة الخارجية التي تكتب البيانات أو تحكّم بها؛
• حدّد نسخة الشيفرة الدقيقة؛
• شغّل ترقية الإنتاج أو استعدها عبر العملية المدعومة؛
• انشر شيفرة أودو 20 المُختبرة؛
• نفّذ سكربتات الترقية المُختبرة؛
• تحقّق من السجلات؛
• أجرِ اختبارات الفحص التقني السريع؛
• أجرِ اختبارات الفحص السريع لعمليات الأعمال الحرجة؛
• أعد تفعيل التكاملات بوعي؛
• احصل على موافقة الأعمال على الإطلاق.

قِس مدة التوقف من التجربة بدلاً من تقديرها من ترحيل شركة أخرى.

قائمة تحقق المطور للترحيل من أودو 19 → 20

المستودع

• جمّد خط أساس الترحيل.
• أزل الوحدات والتخصيصات المتقادمة.
• حدّث ملفات البيان والاعتماديات.
• ابحث عن استخدامات إطار العمل المُزالة أو المُهملة.
• راجع استخدام _table_query.
• راجع افتراضات RPC للبيانات الثنائية.
• راجع التعامل مع الترجمات.
• راجع إعادة تعريفات ORM في Python.
• راجع وراثة XML/XPath.
• راجع JS/Owl والأصول.
• راجع المتحكمات.
• راجع التقارير.
• راجع الأمان.
• شغّل الاختبارات على أودو 20 نظيف.

البيانات

• اربط النماذج المُعاد تسميتها.
• اربط الحقول المُعاد تسميتها.
• اربط معرّفات XML المُعاد تسميتها.
• حدّد نماذج البيانات المُزالة أو المدمجة.
• راجع سجلات noupdate.
• راجع الواجهات المعطّلة في تقرير الترقية.
• اكتب سكربتات الترقية واختبرها.
• تحقّق من السجلات المخصصة التاريخية.

التكاملات

• اجرد عملاء RPC القديمة.
• حدّد أي استخدام لخدمة db المُزالة.
• خطّط للتحديث إلى JSON-2 حيثما يكون مناسباً.
• اختبر المتحكمات المخصصة بشكل منفصل.
• اختبر حمولات البيانات الثنائية والمستندات.
• اختبر المصادقة.
• اختبر المهام المجدولة ومهام webhook والبرمجيات الوسيطة.

القبول

• شغّل الاختبارات القياسية.
• شغّل الاختبارات الآلية الخاصة بالترحيل.
• أجرِ اختبار قبول المستخدم لعمليات الأعمال من البداية إلى النهاية.
• طابق البيانات الحرجة.
• أجرِ التجربة من نسخة حديثة من الإنتاج.
• سجّل مدة الانتقال إلى الإنتاج.
• أكمل اختبارات الفحص السريع في الإنتاج.

أخطاء شائعة في الترحيل من أودو 19 إلى 20

اعتبار التثبيت اكتمالاً للترحيل

إن تثبيت وحدة على قاعدة بيانات فارغة لا يثبت إلا جزءاً من التوافق.

تعديل البيانات التاريخية يدوياً حتى ينجح الاختبار

إذا كانت التغييرات نفسها مطلوبة في الإنتاج، فضمّنها في سكربتات ترقية قابلة لإعادة التنفيذ.

ترحيل تخصيصات متقادمة

قارن الوحدة بما يقدمه أودو 20 قبل الاستثمار في نقلها.

تجاهل الواجهات المعطّلة

اقرأ تقرير الترقية. فالتخصيص المفقود ربما عُطّل ببساطة أثناء الترقية القياسية.

نسيان noupdate

تغيّر مصدر XML لا يضمن تحديث السجل التاريخي المقابل.

إعادة كتابة كل التكاملات خلال عملية التحويل نفسها

حدّث التكاملات بتأنٍّ. وتجنّب مضاعفة مخاطر الترحيل ما لم يكن هناك سبب للجمع بين التغييرات.

افتراض أن RPC القديمة اختفت تماماً في أودو 20

الوثائق الرسمية الحالية أدقّ من ذلك: أُزيلت db في الإصدار 20، بينما من المقرر حالياً إزالة خدمتَي common وobject المُهملتين في الإصدار 22.

اختبار السجلات الجديدة فقط

البيانات التاريخية هي السبب في وجوب اختبار قاعدة بيانات العميل المُرقّاة بعد التحقق من التوافق على قاعدة نظيفة من الإصدار المستهدف.

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

هل يمكن ترقية أودو 19 إلى أودو 20؟

أودو 20 هو الإصدار الرئيسي التالي بعد 19، لكن يجب عند التخطيط للإنتاج التحقق من أن أدوات الترقية الرسمية تدعم حالياً المسار الدقيق لقاعدة البيانات والاستضافة لديك قبل الالتزام بموعد.

هل تحتاج الوحدات المخصصة لأودو 19 إلى تغييرات في الشيفرة من أجل أودو 20؟

ربما نعم. يتضمن أودو 20 تغييرات موثّقة في ORM وإطار العمل، وينبغي اختبار أي وحدة مخصصة على قاعدة بيانات نظيفة من الإصدار المستهدف وعلى قاعدة بيانات العميل المُرقّاة.

ماذا حدث لـ _table_query في أودو 20؟

يذكر سجل تغييرات ORM الرسمي أن Model._table_query أُزيلت في أودو 20. وينبغي تحديد الوحدات المخصصة التي تستخدمها أثناء مراجعة الشيفرة وترحيلها إلى النهج المدعوم في الإصدار المستهدف.

هل ينبغي أن نستخدم سكربتات الترقية؟

استخدمها عندما تتطلب تغييرات الشيفرة المصدرية تغييرات مقابلة في البيانات التاريخية، مثل إعادة تسمية الحقول أو النماذج أو معرّفات XML. ويوفّر أودو مكتبة Upgrade Utils للمساعدة في تنفيذ هذه العمليات بشكل متسق.

هل اختفت XML-RPC وJSON-RPC في أودو 20؟

ليس تماماً. تذكر الوثائق الرسمية الحالية أن خدمة db أُزيلت في أودو 20، بينما من المقرر إزالة خدمتَي common وobject المُهملتين في أودو 22. وواجهة JSON-2 هي الاتجاه البديل.

هل ينبغي ترحيل تكامل API لدينا إلى JSON-2 أثناء الترقية إلى أودو 20؟

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

الخلاصة

أكثر الطرق أماناً للتفكير في الترحيل من أودو 19 → 20 هي:

التوافق على شيفرة نظيفة أولاً، ثم التوافق مع البيانات التاريخية ثانياً، ثم قبول الأعمال ثالثاً.

يمنح هذا الترتيب المطورين مساراً أوضح بكثير لتتبّع الأخطاء.

إذا فشلت الوحدة على أودو 20 نظيف، فأصلح الشيفرة المصدرية.

وإذا عملت على قاعدة نظيفة لكنها فشلت على بيانات العميل المُرقّاة، فافحص سكربتات الترحيل والسجلات التاريخية.

وإذا عملت الطبقة التقنية لكن نتيجة الأعمال تغيّرت، فافحص سير العمل.

إن إبقاء هذه المشكلات منفصلة هو ما يحوّل ترقية الإصدار من تجربة وخطأ إلى عملية هندسية.

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