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