كيف تصل رسالة واتساب إلى تطبيقك فوراً

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

المسار الذي تسلكه الرسالة

1. تستدعي Meta خطّاف الويب عندما يرسل العميل رسالة.
2. يوضع الطلب في الطابور فوراً ويُؤكَّد استلامه. الردّ السريع بـ 200 مهم: تعيد Meta المحاولة عند التأخّر، ما يسبّب تكراراً.
3. يعالج العامل المهمة — يخزّن الرسالة، وينفّذ مسار الروبوت، ويحدّد من يجب أن يراها.
4. تُنشر الرسالة على قناة، عادةً قناة خاصة بالموظف المسؤول أو قناة مشتركة للفريق.
5. يستقبلها كل متصفح مشترك عبر اتصال WebSocket القائم أصلاً. دون أي استعلام متكرر.

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

لماذا تهمّ وحدة طبقة الاتصال

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

مع PubSub ينشر مُرحِّل واتساب عبر واجهة القنوات العادية — نفسها التي يستخدمها كود تطبيقك. يشترك متصفح الموظف باتصال واحد ويستقبل عليه رسائل واتساب وأحداث منتجك معاً.

const channel = pusher.subscribe("private-team-support");

channel.bind("message.new", (msg) => {
  appendToInbox(msg);
});

channel.bind("message.status", (status) => {
  updateTicks(status);
});

حالة التسليم لا الرسائل فقط

يُبلغ واتساب عن إرسال الرسالة وتسليمها وقراءتها. تصل هذه عبر خطّافات إضافية وتُرحَّل كأحداث message.status، وهي ما يحرّك علامات الصحّ في واجهة الموظف. لذا تُنتج الرسالة الصادرة الواحدة عدّة أحداث فورية — وهو أمر يستحق الانتباه لأنه يؤثّر في طريقة احتساب الاستهلاك.

الروبوتات والبشر على محادثة واحدة

لأن الروبوت وواجهة الموظف يقرآن المحادثة نفسها، يمكن للمسار أن يرحّب بالعميل ويؤهّله ويجيب عن الأسئلة الشائعة ثم يحوّله إلى موظف عند الحاجة. والتحويل نفسه حدث، فيتحدّث صندوق الموظف لحظة استلام المحادثة.