غريزة ربط الأنظمة مباشرة ببعضها
حين يحتاج نظامان إلى التواصل، تكون الغريزة الأولى غالبًا ربطهما مباشرة ببعضهما. يدخل نظام إلى قاعدة بيانات الآخر. يتشاركان بيانات الاعتماد. يتشاركان المنطق. يعمل الأمر في اليوم الأول. ثم يصبح الشيء الذي يخشى الجميع لمسه.
هناك طريقة أهدأ لبناء الاتصال. أبقِ النظامين مستقلين. دعهما لا يتشاركان شيئًا سوى طابور من المهام.
كيف يعمل اتصال قائم على طابور
الفكرة بسيطة. لا يسجّل النظام الخارجي الدخول إلى Odoo ويبدأ بتغيير السجلات. بدلًا من ذلك، يُدرج مهمة في طابور. تحدد المهمة ما يجب أن يحدث. يلتقط Odoo المهمة وفق شروطه الخاصة وينجز العمل. تعمل الحركة في الاتجاه الآخر بالطريقة نفسها.
هذا يبقي السطح بين النظامين صغيرًا جدًا. هناك مكان واحد تصل إليه المهام. ذلك هو الباب الوحيد. لا يحتاج النظام البعيد أبدًا إلى بيانات اعتماد Odoo الداخلية. لا يحتاج أبدًا إلى معرفة كيف يخزّن Odoo أي شيء. لا يحتاج Odoo أبدًا إلى معرفة كيف يعمل النظام البعيد داخليًا. يمكن لكل جانب أن يتغير، أو يُرقّى، أو ينتقل دون كسر الآخر، طالما بقي شكل المهمة كما هو.
استخدمنا هذا النمط بعينه في نشر تصنيعي مع رابط ثنائي الاتجاه بنظام تخطيط خارجي، Skyplanner. يمر الاتصال عبر بوابة واحدة موثّقة. تدفع الأنظمة الخارجية وتسحب عبر ذلك الباب الحاكم الواحد. خلفه، تصطف المهام في طابور وتُعالَج بالترتيب.
لماذا يتوسع هذا ويبقى رخيص الصيانة
يصبح التكامل القائم على مشاركة كل شيء أكثر هشاشة مع تطور كلا النظامين. أما القائم على الطابور فلا. تبقى مساحة الصيانة ضئيلة، لأن هناك عقدًا واحدًا فقط يجب حمايته. حين يرتفع الحِمل، يمتص الطابور الارتفاعات المفاجئة بدلًا من قصف قاعدة البيانات في الوقت الفعلي.
بُني معظم ذلك النشر نفسه باستخدام أدوات Studio الخاصة بـ Odoo، مع عدد قليل فقط من الوحدات المبرمجة يدويًا للمهام التي لا يستطيع Studio تغطيتها. البوابة واحدة منها، وتستحق مكانها. اعتمد الإعداد افتراضيًا، واحتفظ بالكود للأشياء القليلة التي تحتاجه فعليًا حقًا، وأبقِ الأنظمة منفصلة عن بعضها. تبني Majorbird التكاملات بهذه الطريقة عن قصد. إذا كنت تصل Odoo بنظام آخر وتريده أن يدوم، فلنتحدث.