حين يصل طلب من متجرك الإلكتروني إلى اودو، ينبغي أن يظهر برقمه الأصلي في المتجر وبحالته بين النظامين. فتعرف المالية أي طلب تقصد، ويعرف المالك أين توقف، ويعرف الموظف المسؤول عن متابعته. ويتطلب ذلك التفريق بين أربع حالات: وصل الطلب، وتأكد، وشُحن، وسُدد. فوصول الطلب ليس بيعًا محققًا ولا فاتورة مدفوعة. في تودو اوبس - ToDoOps نبدأ ربط الأنظمة من هذا السؤال، ويمكنك التعرف على عملنا من الصفحة الرئيسية.
ما الفرق بين الربط بنظام خارجي والعمل داخل تطبيقات اودو؟
داخل اودو تعمل المبيعات والمخزون والفوترة على قاعدة بيانات واحدة، وتنتقل المستندات بينها بإعداد التطبيقات نفسها. راجع تطبيقات اودو لمعرفة ما يغطيه كل منها، وتتيح محاكاة تودو اوبس رؤية ترابط المبيعات والمخزون ببيانات افتراضية، وهي ليست ربطًا حقيقيًا بمتجر خارجي.
أما متجرك الخارجي فنظام مستقل له قاعدة بياناته وأرقامه وحالاته، وكل انتقال بينه وبين اودو شيء يُصمَّم ويُختبر. فالسؤال هنا: ماذا يحدث للطلب في كل خطوة بين النظامين؟
ما الحقول التي نتفق عليها قبل الربط؟
ابدأ بخريطة بسيطة تجعل الطلب قابلًا للتتبع:
- رقم الطلب الخارجي
- معرّف العميل
- رمز الصنف
- الفرع أو المستودع
- الكمية
- السعر والضريبة كما تُضبط فعليًا في منشأتك
- الحالة
ثم حدّد لكل نوع من البيانات مصدر الحقيقة واتجاه التحديث. قد يكون المتجر مصدر الطلب واودو مصدر المخزون والفاتورة، فيسير الطلب من المتجر إلى اودو وتسير الحالة من اودو إلى المتجر. هذا توزيع محتمل وليس قاعدة ثابتة. ولا تفترض أن كل البيانات تتزامن في الاتجاهين تلقائيًا، فكل اتجاه يُصمَّم ويُختبر.
هل تدعم نسخة اودو وخطتها الربط الذي تحتاجه؟
هذا أول سؤال قبل التعاقد. بحسب توثيق اودو 19.0 (مرجع اودو)، واجهة External JSON-2 API جديدة في هذا الإصدار وليست وصفًا لكل الإصدارات. والتطبيقات والحقول والطرق المتاحة تعتمد على قاعدة بياناتك. وتذكر الوثيقة أن الوصول الخارجي إلى البيانات ضمن خطط خدمة اودو متاح في Custom، وليس في One App Free أو Standard. راجع الخطة والاستضافة الفعلية مع المزوّد قبل التعاقد.
وتتبع الواجهة صلاحيات المستخدم وقواعد السجلات، وتوصي الوثيقة بمستخدم مخصص للربط بأقل صلاحيات لازمة. فإذا نقصت صلاحية ظهر ذلك في نتيجة الطلب، ولذلك نختبر هذه الحالة مبكرًا.
وأثر ذلك على قبول الطلب أن كل استدعاء يُنفَّذ معاملة مستقلة. فإذا كان الطلب يحتاج عدة خطوات، كإنشاء الطلب ثم تأكيده ثم تحديث بيانات مرتبطة بها، فنجاح خطوة لا يضمن نجاح التي بعدها، ولا يمكن جمعها في معاملة واحدة بهذه الطريقة. فقد يبقى الطلب في منتصف الطريق إن توقفت إحدى الخطوات. والإجراءات التي يجب أن تنجح معًا أو تتراجع معًا تحتاج طريقة واحدة مناسبة أو تطويرًا مخصصًا، وهذا مما نحدده في تحليل النطاق. كما أن الواجهة لا تمنع تكرار طلب خارجي تلقائيًا، وهو ما تعالجه طبقة الربط كما في القسم التالي.
ماذا يحدث إذا انقطع الاتصال بعد إنشاء الطلب؟
يرسل النظام الخارجي الطلب، فينشئه اودو، ثم تضيع الاستجابة قبل وصولها. لا تعرف الجهة المرسلة أن الطلب تم، فتعيد الإرسال، وبلا تصميم مسبق ينشأ طلب ثانٍ. تصف مكتبة AWS Builders’ Library (مرجع AWS) هذا الخطر في مقال لـ Malcolm Featonby: إعادة الإرسال بعد مهلة اتصال قد تكرر أثر عملية تمت دون أن يصل ردها. والمبدأ الموصوف أن تضع الجهة المرسلة مُعرّفًا فريدًا مع الطلب، فيُميَّز به طلب أُعيد إرساله من طلب جديد.
نسمي هذا Idempotency، ونقصد به إعادة المحاولة دون إنشاء أثر جديد للطلب نفسه. هو مبدأ تصميم موثق وليس سلوكًا افتراضيًا في واجهة JSON-2 ولا في كل ربط، فيقع على طبقة الربط عندك. وطبقة الربط هي البرنامج أو الخدمة التي تنقل الطلبات بين المتجر واودو. ومهمتها هنا:
- حفظ مرجع العملية: تسجل مرجع الطلب الخارجي مع مصدره؛ فرقم الطلب نفسه قد يتكرر في متجر آخر أو منشأة أخرى.
- منع إنشائه مرتين: فإذا وصل المرجع نفسه مرة أخرى لا ينشأ طلب ثانٍ، بل تُعاد الحالة الحالية.
- تنسيق الفحص والإنشاء: يجب أن يتم فحص وجود المرجع وإنشاء الطلب في العملية نفسها، أو بآلية مكافئة تضمن ألا تنشئه محاولتان معًا.
لا يكفي أن تستعلم عن المرجع ثم تنشئ الطلب في خطوتين منفصلتين. فلو وصلت محاولتان في اللحظة نفسها، قد تجد كلتاهما أن المرجع غير موجود، فتنشئ كل منهما طلبًا. ولذلك نعدّ اختبار الطلبين المتزامنين اختبارًا أساسيًا لا إضافيًا: يُرسل المرجع نفسه مرتين في وقت واحد، والنتيجة المقبولة طلب واحد فقط.
وللتوضيح: قد تحمي معاملة قاعدة البيانات داخل اودو عمليات تتم داخله، لكنها لا تجعل المتجر واودو وطبقة الربط معاملة واحدة. فالتنسيق بين النظامين يُصمَّم عند طبقة الربط ويُختبر.
ثلاث نقاط أخرى تحكم هذا:
- تشابه المحتوى وحده لا يثبت التكرار، فقد يريد عميلك عمليتين متشابهتين. والطلب الجديد المقصود يحمل مرجعًا جديدًا ولو بالأصناف نفسها.
- حفظ المرجع وتنفيذ الأثر يجب أن يتناسقا، فلا يُحفظ مرجع لطلب لم يُنشأ، ولا يُنشأ طلب بلا مرجع محفوظ.
- التعديل والإلغاء أحداث مستقلة تُعالج وفق حالة المستند، ولا نفترض أن تسليم المخزون ينعكس تلقائيًا.
مثال: 100 طلب فريد و105 محاولات
مثال افتراضي: وصل 100 طلب فريد، أُنشئ منها 98 في اودو وبقي 2 قيد المعالجة، وجرت 5 محاولات إعادة إرسال إضافية فبلغ عدد المحاولات 105. تبيّن الأرقام أن عدد المحاولات قد يزيد على عدد الطلبات دون أن يزيد عدد الطلبات نفسها، إذا كانت طبقة الربط تتعرف على المرجع المكرر فتعيد حالته بدل إنشاء طلب جديد. وبعد معالجة الاثنين والتحقق منهما، يمكن أن تُسجل الطلبات الـ100 في هذا الاختبار مرة واحدة لكل طلب. فيطابق المسؤول الأرقام بسهولة: لكل محاولة مرجع، ولكل مرجع طلب واحد في اودو، وما بقي قيد المعالجة له حالة واضحة ومن يتابعه.
| البند | العدد |
|---|---|
| طلبات فريدة | 100 |
| أُنشئت في اودو | 98 |
| قيد المعالجة | 2 |
| إعادة إرسال إضافية | 5 |
| إجمالي المحاولات | 105 |
كيف تختبر الربط قبل اعتماده؟
نقترح أن تتضمن تجربة قبول الربط الحالات التالية:
-
وصول طلب جديد بمرجعه وحالته الصحيحة.
-
إعادة المرجع نفسه، ثم إرساله من محاولتين متزامنتين: يبقى طلب واحد في الحالتين.
-
مرجع جديد بالأصناف نفسها: ينشأ طلب جديد.
-
تعديل أو إلغاء مع حالة متأخرة: ماذا يرى المسؤول؟
-
مستخدم ربط بصلاحية ناقصة: يظهر السبب وتبقى حالة الطلب قابلة للتفسير والمتابعة.
-
انقطاع بعد الإنشاء: تُستعاد الحالة دون تكرار.
-
سجل يمكن مطابقته، واسم من يتابع كل حالة.
-
اعتماد النتيجة في بيئة تجريبية قبل التشغيل.
الفائدة أن المالية حين تسأل عن رقم تجد الجواب في السجل لا في ذاكرة موظف.
ماذا يتولى تودو اوبس في مشروع الربط؟
نفحص أولًا قابلية الواجهات في الطرفين والنطاق والخطة. ثم نحدد البيانات والحقول والاتجاه والحالات، ونجري الاختبار ونوثّق وندرّب فريقك ضمن المشروع. ويتحدد شكل الربط وتكلفته بعد تحليل نطاق منشأتك ومنصتها. ولتقدير ميزانية تطبيق ERP مبدئيًا استخدم حاسبات تودو اوبس، ثم نحدد بنود الربط المناسبة بعد مراجعة النظامين.
ابدأ بأصعب استثناء عندك
قيمة البدء المبكر ألا تفاجئك الاستثناءات في منتصف التنفيذ: طلب يُلغى بعد الشحن، أو عميل يكرر طلبه عمدًا، أو كمية في المتجر لا تطابق المخزون. حدّد أصعب استثناء الآن يتضح نطاق التنفيذ مبكرًا. تواصل مع تودو اوبس لنراجع معك الخريطة والحالات، وجرّب الحاسبات للتقدير المبدئي، وزر الصفحة الرئيسية لمعرفة ما نقدمه.
المراجع
- اودو — توثيق الإصدار 19.0، External JSON-2 API: الصلاحيات وقواعد السجلات والمعاملات ونطاق الإتاحة.
- AWS — Making retries safe with idempotent APIs، Malcolm Featonby، AWS Builders’ Library: الرابط الأصلي.