خطافات الويب أم قواعد الأتمتة في أودو 20: كيف تبني تكاملات لا تكرّر الطلبات

استخدم قواعد الأتمتة في أودو 20 للتغييرات المحددة بوضوح داخل أودو، واستخدم خطافات الويب للإشعار بالأحداث بين الأنظمة، واعتمد على خدمة تكامل أو وحدة مخصصة عندما يجب أن تصمد النتيجة أمام التكرار والتوقف والرسائل غير المرتبة والأعطال الجزئية. خطاف الويب (Webhook) وسيلة لإيصال الرسائل، وليس في حد ذاته ضمانًا لإنشاء الطلب مرة واحدة، أو لتحديث المخزون بشكل صحيح، أو لإتمام المطابقة على الفاتورة.

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

تصف وثائق قواعد الأتمتة الرسمية في أودو 20 مشغّلات تغيير السجلات، والقواعد الزمنية، ومشغّلات خطافات الويب الواردة، وإجراءً صادرًا باسم إرسال إشعار خطاف الويب (Send Webhook Notification). هذه لبنات بناء مفيدة، لكن القرار الهندسي الحقيقي هو اختيار الحدود الصحيحة من حولها.

أربع آليات تبدو متشابهة لكنها تحل مشكلات مختلفة

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

يوثّق دليل القواعد الرسمي في أودو 20 خمس فئات للمشغّلات: القيم المحدَّثة (Values Updated)، وأحداث البريد الإلكتروني (Email Events)، وشروط التوقيت (Timing Conditions)، والمخصص (Custom)، والخارجي (External). وينتمي خطاف الويب في Studio إلى الفئة الخارجية. أما الإشعار الصادر فهو إجراء يُتخذ بعد المشغّل. هذان اتجاهان متعاكسان في الاتصال، وليسا إعدادين قابلين للتبادل.

من أين يبدأ تكرار الأتمتة: المشغّل

تبدأ مشكلة شائعة بقاعدة مُعدّة لتعمل عند الإنشاء والتعديل (On create and edit). يُحفظ السجل، فتحدّث القاعدة حقلًا، ثم تحفظ عملية أخرى السجل نفسه، فتعمل القاعدة مرة أخرى. وإذا كانت القاعدة تُنشئ أيضًا سجل متابعة أو ترسل طلبًا خارجيًا، فقد يتحول المشغّل المتكرر إلى إجراء تجاري مكرر.

تقدّم وثائق أودو 20 تحذيرًا مباشرًا: عند إعداد عند الإنشاء والتعديل (On create and edit) دون اختيار حقول في عند تحديث الحقل (When updating field)، قد تُنفَّذ الأتمتة عدة مرات لكل سجل. كما تميّز بين نطاق ما قبل التحديث (Before Update Domain) ونطاق التطبيق على (Apply on)، إذ يصف كلٌّ منهما الشروط قبل التغيير وبعده. ولا يُفحص شرط ما قبل التحديث عند إنشاء السجل لأول مرة. راجع مرجع المشغّلات والشروط.

لسير عمل محلي مثل "إشعار قسم المشتريات عندما يدخل طلب الشراء حالة الاعتماد لأول مرة":

1. اختر حقل الحالة الدقيق الذي يمثّل الانتقال.
2. حدّد الحالة المتوقعة قبل التحديث وبعده، حيثما يدعم المشغّل المختار ذلك.
3. اجعل الإجراء غير ضار إذا استُدعي مرة أخرى للسجل نفسه والانتقال نفسه.
4. اختبر تعديلًا آخر على السجل المعتمد مسبقًا: يجب ألا يُرسل إشعار اعتماد آخر عن طريق الخطأ.

لا تفترض أن مشغّل عند التغيير في الواجهة (On UI change) يغطي عمليات الاستيراد أو الكتابة عبر API أو المهام المجدولة أو أتمتة أخرى. فأودو يوثّق هذا المشغّل تحديدًا على أنه تفاعل يدوي في نموذج العرض، لا أداة عامة للاستماع إلى التغييرات على الخادم.

نجاح المشغّل لا يعني نجاح التكامل

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

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

مثال عملي على استيراد الطلبات

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

يكون المسار المستهدف المتين على النحو التالي:

Shopify event
   -> verify the sender and parse the payload
   -> record the event/delivery identity durably
   -> enqueue a processing job
   -> find or create the corresponding Odoo order
   -> record the Odoo order reference and job result
   -> reconcile periodically against Shopify

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

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

منع التكرار على مستويين مختلفين

هوية إرسال خطاف الويب تجيب عن السؤال: هل رأينا هذا الإشعار من قبل؟

هوية الكائن التجاري تجيب عن السؤال: هل أُنشئ الطلب المقابل بالفعل؟

بالنسبة إلى Shopify، يوثّق دليل التحقق من الإرسال الرسمي الترويسة X-Shopify-Webhook-Id لاكتشاف عمليات الإرسال المكررة، ويوضح أن الاشتراكات المنفصلة قد تُنتج معرّفات إرسال مختلفة للحدث الأصلي نفسه.

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

استخدم قيد تفرّد في قاعدة البيانات أو آلية أخرى لعدم التكرار (Idempotency) قائمة على المعاملات لهذا الربط حيثما تدعم بنية النشر ذلك. ويجب تصميم نموذج أودو الدقيق وعملية الترحيل واختبارهما قبل التثبيت؛ فلا تنسخ قيد SQL عامًا إلى بيئة الإنتاج دون فحص البيانات الموجودة.

التعامل مع الأحداث التي تصل بغير ترتيبها

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

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

• النظام المرجعي لكل حقل أو حالة؛
• مراجعة خارجية أو وقت الحدث أو أي مؤشر ترتيب آخر حين يدعمه المزوّد؛
• ما إذا كان ينبغي تجاهل الرسالة القديمة أو إعادة تشغيلها أو إعادة تحميل البيانات من API المصدر؛
• ما إذا كان الإلغاء أو استرداد المبلغ أو الإرجاع عملية تجارية منفصلة وليس مجرد استبدال للحالة.

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

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

الأمان: عنوان نقطة الاستقبال ليس سياسة كاملة

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

مع المزوّد الذي يوقّع عمليات الإرسال، مثل Shopify، تحقق من التوقيع مقابل جسم الطلب الخام قبل الوثوق بحقول الحمولة. ويشرح دليل التحقق الرسمي من Shopify الترويسة X-Shopify-Hmac-SHA256 واشتراط استخدام الجسم الخام. ولا تتعامل أبدًا مع مثال JSON منسوخ على أنه مُدخل مُصادَق عليه.

ويحتاج التصميم الآمن أيضًا إلى الإجابة عن الأسئلة التالية:

• ما الأنظمة المصدر المسموح لها باستدعاء نقطة الاستقبال؟
• هل يستطيع هذا الحدث إنشاء سجلات، أم يقتصر على تحديث سجلات مرتبطة مسبقًا بمعرّف خارجي معروف؟
• ما الشركة والمستودع المسموح بهما؟
• ما الحقول التي يستطيع المرسل تغييرها؟
• كيف تُدوَّر بيانات الاعتماد والأسرار والمفاتيح؟
• ما الذي يُسجَّل، وكيف تُستبعد البيانات الشخصية وبيانات الدفع من السجلات غير الضرورية؟

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

متى يكفي Studio ومتى تكون الوحدة المخصصة مبرَّرة

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

أما طبقة التكامل المخصصة فتكون مبرَّرة حين يمكن لطلب واحد فاشل أو مكرر أن يُلحق ضررًا ماليًا أو بالمخزون أو بخدمة العملاء. ومن المؤشرات على ذلك:

• إعادة محاولة دائمة أو طابور للرسائل المتعذّرة (dead-letter queue)؛
• منع التكرار بصرامة عبر عمال متزامنين؛
• التحقق من الطلبات الموقّعة بشكل يجب فرضه قبل أي تعديل على السجلات؛
• حدود معاملات تمتد عبر عدة سجلات مترابطة في أودو؛
• ربط معقد بين عدة شركات أو عدة مستودعات؛
• أدوات لإعادة التشغيل ومقاييس وسجلات تدقيق؛
• حجم أحداث مرتفع أو متطلبات للتحكم في الضغط (backpressure).

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

يغطي دليل Octivex لواجهة JSON-2 API في أودو الاستدعاءات الحتمية من التطبيقات إلى أودو. ولكلٍّ من JSON-2 وخطافات الويب في Studio ووحدات التحكم المخصصة دور مختلف: فواجهة API الخارجية أداة لتنفيذ عمليات صريحة، بينما خطاف الويب آلية للإشعار أو للتشغيل عند وقوع حدث. ويمكن استخدامها معًا.

الإجراءات المجدولة أداة استعادة وليست بديلًا عن تصميم الأحداث

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

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

قد تقضي سياسة معقولة بفحص الطلبات المدفوعة حديثًا وعمليات الاستيراد المعلّقة، لكن التكرار الدقيق يعتمد على حدود الطلبات في النظام المصدر وقيود الاستضافة وحجم الطلبات المتوقع وزمن الاستعادة المطلوب. ولا تَعِد بمزامنة "فورية" لمجرد أن مهمة cron تعمل كل بضع دقائق.

اختبر الأعطال قبل أن يكتشفها العميل

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

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

تشخيص خطاف ويب "نجح" لكنه أنتج نتيجة خاطئة

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

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

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

اختر أبسط تصميم يمكن إثبات صحته

يوفّر أودو 20 مشغّلات أتمتة وإجراءات خطافات ويب مفيدة، فاستخدمها حيث تناسب. لكن مع الطلبات والمدفوعات والفواتير والمخزون والسجلات الحساسة للهوية، حدّد عقد الأعطال أولًا: مرجعًا خارجيًا ثابتًا، وانتقالات حالة مسموحًا بها، ومصادقة، ومنع التكرار، وحالة معالجة دائمة، ومسارًا للمطابقة.

يستطيع خطاف الويب أن يُخبر أودو بأن شيئًا ما قد حدث. أما التكامل الموثوق فيضمن أن يحدث الشيء الصحيح مرة واحدة، في الشركة الصحيحة، مع أثر يستطيع فريق الدعم تفسيره.

إذا كنت تخطط لتكامل بين أودو وShopify، أو مع منصة دفع أو خدمات لوجستية أو تطبيق جوال، فبإمكان خدمات التكامل والتخصيص من Octivex Tech مساعدتك في تحديد عقد الأحداث، واختبار حالات الأعطال، وتقرير أين تنتهي الأتمتة الأصلية ومن أين ينبغي أن تبدأ الهندسة المخصصة.