نظام إشعارات متعدد القنوات: القوالب، إعادة المحاولة، التفضيلات

ما الذي يحلّه نظام الإشعارات الموحد

عندما تُبنَى ميزات البريد الإلكتروني وSMS وتيليجرام كميزات منفصلة، تظهر الفجوات بسرعة. نفس التنبيه قد ينتهي بصياغة مختلفة، توقيت مختلف، وقواعد مختلفة حول من يحصل عليه. فرق الدعم تضطر بعدها لمتابعة ثلاث نسخ من الحقيقة: واحدة عند مزود البريد، واحدة عند بوابة الـSMS، وواحدة في سجل البوت.

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

معظم الفرق تحتاج للأساس نفسه، بغض النظر عن القناة التي بدأوا بها: قوالب مؤرخة مع متغيرات، تتبع حالة التسليم ("تم الإرسال، تم التسليم، فشل، لماذا"), استراتيجيات إعادة محاولة واعية وبدائل، تفضيلات المستخدم مع الموافقة وساعات الهدوء، وسجل تدقيق حتى يتمكن الدعم من رؤية ما حدث بدون تخمين.

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

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

المفاهيم الأساسية ونموذج بيانات بسيط

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

ابدأ بـ الحدث. الحدث هو مُشغل مسمّى مثل order_shipped أو password_reset. حافظ على الأسماء متسقة: أحرف صغيرة، underscores، وصيغة الماضي عندما تناسب. اعتبر الحدث كعقد ثابت تعتمد عليه القوالب وقواعد التفضيل.

من حدث واحد، أنشئ سجل الإشعار. هذا هو المقصد الموجه للمستخدم: لمن هو، ماذا حدث، وما البيانات اللازمة لتصيير المحتوى (رقم الطلب، تاريخ التسليم، رمز إعادة التعيين). خزّن الحقول المشتركة هنا مثل user_id، event_name، locale، priority، و scheduled_at.

ثم قسم إلى رسائل لكل قناة. قد تُنتج الإشعار 0 إلى 3 رسائل (بريد إلكتروني، SMS، تيليجرام). تحتفظ الرسائل بالحقول الخاصة بالقناة مثل الوجهة (عنوان البريد، الهاتف، Telegram chat_id)، template_id، والمحتوى المَصيّر (subject/body للبريد، نص قصير للـSMS).

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

نموذج بسيط غالبًا يناسب في أربع جداول أو مجموعات:

• Event (فهرس أسماء الأحداث المسموح بها والإعدادات الافتراضية)
• Notification (واحد لكل قصد مستخدم)
• Message (واحد لكل قناة)
• DeliveryAttempt (واحد لكل محاولة)

خطط للـ idempotency مبكرًا. امنح كل إشعار مفتاحًا حتميًا مثل (event_name, user_id, external_ref) حتى لا تُنشئ إعادة المحاولات من الأنظمة العلوية نسخًا مكررة. إذا أعيد تشغيل خطوة سير العمل، مفتاح اللاازدواجية يمنع إرسال SMS مرتين.

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

تدفق عملي من البداية للنهاية (خطوة بخطوة)

يعمل نظام الإشعارات متعدد القنوات بشكل أفضل عندما يعامل "تحديد ما نرسله" منفصلاً عن "إرساله." هذا يبقي تطبيقك سريعًا ويجعل التعامل مع الأخطاء أسهل.

تبدو سلسلة الخطوات العملية كالتالي:

1. يُنشىء مُصدر الحدث طلب إشعار. يمكن أن يكون "إعادة تعيين كلمة المرور" أو "فاتورة مدفوعة" أو "تذكرة محدثة." يتضمن الطلب معرّف المستخدم، نوع الرسالة، وبيانات السياق (رقم الطلب، المبلغ، اسم وكيل الدعم). خزّن الطلب فورًا حتى يكون لديك أثر تدقيقي.

2. الموجّه يحمل قواعد المستخدم والرسالة. يبحث عن تفضيلات المستخدم (القنوات المسموح بها، الاشتراكات، ساعات الهدوء) وقواعد الرسالة (مثال: تنبيهات الأمان يجب أن تحاول البريد أولًا). يقرر الموجّه خطة القنوات، مثل تيليجرام ثم SMS ثم بريد إلكتروني.

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

4. عمّال القناة يرسلُون عبر المزودين. يذهب البريد إلى SMTP أو API بريد إلكتروني، يذهب SMS إلى بوابة SMS، ويُرسل تيليجرام عبر البوت. يجب أن تكون العمالات idempotent، حتى لا تتسبب إعادة المحاولة في تكرار الإرسال.

5. تتدفّق تحديثات الحالة إلى مكان واحد. يسجل العمال الحالات queued، sending، failed، وعندما تتوفر، delivered. إذا أكد المزود فقط "accepted" فسجّل ذلك أيضًا وعامله بشكل مختلف عن delivered.

6. تشغّل البدائل وإعادة المحاولات من نفس الحالة. إذا فشل تيليجرام، يمكن للموجّه (أو عامل إعادة المحاولة) جدولة SMS تاليًا دون فقدان السياق.

مثال: يغيّر المستخدم كلمة مروره. يُصدر backend طلبًا واحدًا بالمستخدم وعنوان IP. يرى الموجّه أن المستخدم يفضّل تيليجرام لكن ساعات الهدوء تمنعها لليل، فيجدول البريد الآن وتيليجرام صباحًا، مع تتبع كلاهما تحت نفس سجل الإشعار.

إذا كنت تنفّذ هذا في AppMaster، احتفظ بالجدول الطلبات، الوظائف، وحالات الحالة في Data Designer وعبّر عن منطق التوجيه وإعادة المحاولة في Business Process Editor، مع التعامل مع الإرسال بشكل غير متزامن حتى تبقى واجهة المستخدم سريعة.

بنية القالب العملية عبر القنوات

نظام قوالب جيد يبدأ بفكرة واحدة: أنت تُخطر عن حدث، ليس "ترسل بريدًا" أو "ترسل SMS." أنشئ قالبًا واحدًا لكل حدث (Password reset, Order shipped, Payment failed)، ثم خزّن متغيرات القناة تحت نفس الحدث.

حافظ على نفس المتغيرات عبر كل نسخة قناة. إذا استخدم البريد first_name وorder_id، يجب أن تستخدم SMS وتيليجرام نفس الأسماء بالضبط. هذا يمنع الأخطاء الطفيفة حيث تظهر قناة بشكل سليم وأخرى فارغة.

شكل قالب بسيط وقابل للتكرار

لكل حدث، عرّف مجموعة صغيرة من الحقول لكل قناة:

• البريد الإلكتروني: subject، preheader (اختياري)، HTML body، نص بديل
• SMS: نص عادي
• تيليجرام: نص عادي، بالإضافة إلى أزرار اختيارية أو بيانات قصيرة

الشيء الوحيد الذي يتغير بين القنوات هو التنسيق، ليس المعنى.

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

الترجمة دون تكرار منطق العمل

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

وضع معاينة يدفع ثمنه. اصنع معاينة للقوالب ببيانات عينة (بما فيها حالات الحافة مثل الاسم الطويل) حتى يتحقق الدعم من نسخ البريد وSMS وتيليجرام قبل الإطلاق.

حالة التسليم الموثوقة والقابلة للتصحيح

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

ابدأ بمجموعة صغيرة من الحالات المشتركة التي تعني نفس الشيء عبر البريد، SMS، وتيليجرام:

• queued: قبول من نظامك، ينتظر عاملًا
• sending: محاولة تسليم جارية
• sent: تم تسليمها إلى API المزود بنجاح
• failed: انتهت المحاولة بخطأ يمكن التعامل معه
• delivered: لديك دليل أنها وصلت للمستخدم (عند الإمكان)

احتفظ بهذه الحالات على سجل الرسالة الرئيسي، لكن تتبّع كل محاولة في جدول تاريخ. هذا التاريخ هو ما يجعل استكشاف الأخطاء سهلاً: المحاولة #1 فشلت (timeout)، المحاولة #2 نجحت، أو كانت SMS ناجحة بينما ظل البريد يرد بالارتداد.

ماذا تُخزّن عن كل محاولة

وحّد استجابات المزودين حتى تتمكن من البحث وتجميع المشاكل حتى عندما يستخدم المزودون كلمات مختلفة.

• provider_name و provider_message_id
• response_code (رمز موحّد مثل TIMEOUT، INVALID_NUMBER، BOUNCED)
• raw_provider_code و raw_error_text (لحالات الدعم)
• started_at، finished_at، duration_ms
• channel (email, sms, telegram) و destination (مقنّع)

خطط للنجاح الجزئي. قد ينشئ إشعار واحد ثلاث رسائل قناة تشترك في نفس parent_id والسياق التجاري (order_id, ticket_id, alert_type). إذا أُرسلت SMS وفشل البريد، تظل القصة كاملة في مكان واحد، وليس ثلاث حوادث منفصلة.

ماذا يعني "تم التسليم" بالفعل

"تم الإرسال" ليس "تم التسليم." بالنسبة لتيليجرام، قد تعرف فقط أن الـAPI قبل الرسالة. بالنسبة للـSMS والبريد، غالبًا يعتمد التسليم على webhooks أو ردود المزود، وليس كل المزودين بنفس الموثوقية.

حدد معنى delivered لكل قناة مسبقًا. استخدم تأكيدات الويب هوك عندما تكون متاحة؛ وإلا اعتبر delivered مجهولًا واستمر في الإبلاغ كـ sent. هذا يحافظ على صدق تقاريرك وإجابات الدعم.

إعادة المحاولات، البدائل، ومتى تتوقف

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

ابدأ بتصنيف الإخفاقات. نفاد الوقت من مزود البريد، 502 من بوابة SMS، أو خطأ مؤقت في API تيليجرام عادة ما تكون قابلة لإعادة المحاولة. عنوان بريد خاطئ مُشكّل، رقم هاتف يفشل في التحقق، أو محادثة تيليجرام حجبت البوت ليست كذلك. معاملة هذه بنفس الطريقة تُهدر المال وتفيض السجلات.

خطة إعادة المحاولة العملية محدودة وتستخدم تراجعا زمنياً (backoff):

• المحاولة 1: الإرسال الآن
• المحاولة 2: بعد 30 ثانية
• المحاولة 3: بعد دقيقتين
• المحاولة 4: بعد 10 دقائق
• توقف بعد عمر أقصى (مثال: 30-60 دقيقة للتنبيهات)

يجب أن يكون للتوقف مكان حقيقي في نموذج بياناتك. علّم الرسالة كـ dead-letter (أو failed-permanently) عندما تتجاوز حدود المحاولات. احتفظ بآخر رمز خطأ ورسالة خطأ قصيرة حتى يتصرف الدعم دون تخمين.

امنع الإرسال المتكرر بعد النجاح عبر idempotency. أنشئ مفتاح لاازدواجية لكل رسالة منطقية (غالبًا notification_id + user_id + channel). إذا استجاب المزود متأخرًا وأعدت المحاولة، يجب التعرف على المحاولة الثانية كنسخة مكررة وتُتخطى.

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

تفضيلات المستخدم، الموافقة، وساعات الهدوء

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

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

تحتاج معظم الأنظمة في النهاية لمجموعة مضغوطة من الحقول: نوع الإشعار (security, marketing, billing)، القنوات المسموح بها لكل نوع (email, SMS, Telegram)، الموافقة لكل قناة (تاريخ/وقت، المصدر، وإثبات إذا لزم)، سبب إلغاء الاشتراك لكل قناة (خيار المستخدم، بريد مرتد، رد "STOP"), وقاعدة ساعات الهدوء (بداية/نهاية بالإضافة إلى المنطقة الزمنية للمستخدم).

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

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

مثال: يجب أن تُرسل إعادة تعيين كلمة المرور فورًا إلى أسرع قناة مسموح بها. يجب أن ينتظر ملخص أسبوعي حتى الصباح ويتجنّب SMS ما لم يُفعّل المستخدم ذلك صراحة.

العمليات: المراقبة، السجلات، وسير عمل الدعم

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

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

مقاييس تكتشف المشاكل مبكرًا

نادراً ما تظهر الانقطاعات كخطأ واحد واضح. راقب مجموعة صغيرة من الأرقام وراجعها بانتظام:

• معدل الإرسال لكل قناة (رسائل في الدقيقة)
• معدل الفشل لكل مزود ورمز فشل
• معدل إعادة المحاولات (كم رسالة احتاجت محاولة ثانية)
• زمن التسليم (من queued إلى delivered، p50 و p95)
• معدل الإسقاط (توقفت بسبب تفضيلات المستخدم، الموافقة، أو تجاوز المحاولات)

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

إعادة الإرسال الداعمة للدعم بدون مفاجآت

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

أساسيات الأمان والخصوصية للإشعارات

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

تجنّب وضع بيانات حساسة داخل القوالب كلما أمكن. يجب أن يكون القالب قابلاً لإعادة الاستخدام وبسيطًا: "رمزك هو {{code}}" جيد، لكن تجنّب تضمين تفاصيل حساب كاملة، رموز طويلة، أو أي شيء يمكن استخدامه للاستيلاء على حساب. إذا كان يجب تضمين رمز لمرة واحدة أو توكن إعادة تعيين، خزّن فقط ما تحتاجه للتحقق (مثال: تجزئة وانتهاء صلاحية)، وليس القيمة الخام.

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

ضوابط دنيا تمنع معظم الحوادث

• وصول قائم على الأدوار: فقط مجموعة صغيرة من الأدوار يمكنها رؤية نص الرسائل والمستلم الكامل.
• فصل وصول التصحيح عن وصول الدعم حتى لا يتحول استكشاف الأخطاء إلى تسريب خصوصية.
• حماية نقاط webhooks: استخدم ردود موقّعة أو أسرار مشتركة، تحقق من الطوابع الزمنية، وارفض المصادر المجهولة.
• تشفير الحقول الحساسة عند الراحة واستخدم TLS أثناء النقل.
• عرّف قواعد الاحتفاظ: احتفظ بالسجلات التفصيلية لفترة قصيرة، ثم احتفظ فقط بالملخصات أو المعرفات المجزأة.

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

سيناريو نموذجي: إنذار واحد، ثلاث قنوات، نتائج حقيقية

العميلة مايا لديها نوعان من الإشعارات مفعلين: إعادة تعيين كلمة المرور وتسجيل دخول جديد. تفضّل تيليجرام أولًا ثم البريد. تريد SMS كحل احتياطي لإعادة تعيين كلمة المرور فقط.

في مساءٍ ما، تطلب مايا إعادة تعيين كلمة المرور. ينشئ النظام سجل إشعار واحد بمعرّف ثابت، ثم يوسّع إلى محاولات القنوات بناءً على تفضيلاتها.

ما تراه مايا بسيط: رسالة تيليجرام تصل خلال ثوانٍ مع رمز إعادة التعيين ووقت الانقضاء. لا يصل شيء آخر لأن تيليجرام نجح ولم يكن هناك حاجة لبديل.

ما يسجّله النظام أكثر تفصيلاً:

• Notification: type=PASSWORD_RESET, user_id=Maya, template_version=v4
• Attempt #1: channel=TELEGRAM, status=SENT ثم DELIVERED
• لم تُنشأ محاولات بريد أو SMS (السياسة: التوقف بعد النجاح الأول)

في وقت لاحق من الأسبوع، يحدث تنبيه تسجيل دخول جديد من جهاز جديد. تفضيلات مايا لهذا التنبيه تيليجرام فقط. يرسل النظام تيليجرام، لكن مزود تيليجرام يرد بخطأ مؤقت. يعيد النظام المحاولة مرتين مع تراجع زمني، ثم يعلّم المحاولة كـ FAILED ويتوقف (لا يُسمح بالبديل لهذا النوع).

والآن فشل حقيقي: تطلب مايا إعادة تعيين أخرى أثناء سفرها. يُرسل تيليجرام، لكن تم تكوين بديل SMS إذا لم يُسلم تيليجرام خلال 60 ثانية. يتعطل مزود SMS (timeout). يسجّل النظام نفاد الوقت، يعيد المحاولة مرة، وتنجح المحاولة الثانية. تتلقى مايا رمز SMS بعد دقيقة.

عندما تتواصل مايا مع الدعم، يبحثون حسب المستخدم والفترة الزمنية ويرون فورًا تاريخ المحاولات: الطوابع الزمنية، رموز استجابة المزود، عدد المحاولات، والنتيجة النهائية.

قائمة تحقق سريعة، أخطاء شائعة، والخطوات التالية

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

قائمة التحقق السريعة

• أسماء أحداث واضحة وملكية محددة (مثال: invoice.overdue مملوك من قبل قسم المحاسبة)
• متغيرات القالب معرفة مرة واحدة (مطلوب مقابل اختياري، القيم الافتراضية، قواعد التنسيق)
• الحالات متفق عليها مسبقًا (created, queued, sent, delivered, failed, suppressed) وما يعنيه كل واحد
• حدود إعادة المحاولة والتراجع (حد أقصى للمحاولات، التباعد، قاعدة التوقف)
• قواعد الاحتفاظ (كم من الوقت تحتفظ بنصوص الرسائل، استجابات المزود، وتاريخ الحالة)

إذا فعلت شيئًا واحدًا فقط، اكتب الفرق بين sent وdelivered بكلمات بسيطة. Sent هو ما فعله نظامك. Delivered هو ما أبلغ عنه المزود (ويمكن أن يتأخر أو يكون مفقودًا). خلط هذين سيشوّش فرق الدعم والمساهمين.

أخطاء شائعة تجنّبها

• اعتبار sent كنجاح والإبلاغ عن معدلات توصيل مبالغ فيها
• ترك قوالب القنوات تنحرف حتى تتعارض البريد، SMS، وتيليجرام
• إعادة المحاولة بدون idempotency، مما يتسبب في تكرارات عندما يتأخر المزود ثم يقبل الرسالة
• إعادة المحاولة إلى الأبد، تحويل عطل مؤقت إلى حادث مزعج
• تخزين الكثير من البيانات الشخصية في السجلات وسجلات الحالة "للاحتياط"

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

إذا أردت بناء هذا دون كتابة كل جزء يدويًا، AppMaster (appmaster.io) مناسب عمليًا للأجزاء الأساسية: نمذجة الأحداث، القوالب، ومحاولات التسليم في Data Designer، تنفيذ التوجيه وإعادة المحاولة في Business Process Editor، وربط البريد، SMS، وتيليجرام كتكاملات مع الاحتفاظ بتتبع الحالة في مكان واحد.