حسابات SMPP للعملاء: روابط bind وTPS وإشعارات DLR والفوترة

في اللحظة التي يسألك فيها عميل تقني «هل يمكنني الارتباط عبر SMPP؟»، تكفّ منصّتك عن أن تكون لوحة ويب وتصبح في نظره مشغّلًا. حسابات SMPP للعملاء هي الميزة التي تكسب بها المصارف، ومورّدي خدمات OTP، والمجمّعين الآخرين، وأي مطوّر لديه بالفعل مكتبة عميل SMPP، وهي أيضًا الموضع الذي يضرّ فيه الإعداد المتهاون أكثر من غيره: عميل بلا سقف للإنتاجية، وbind بوضع receiver لم يضبطه أحد، وإشعارات لا تذهب إلى أي مكان، ودفتر يتجاوزه الـbind. هذا الدليل قائمة التحقّق لتنفيذ ذلك كما ينبغي، من الـbind الذي تصدره إلى الاختبار الذي تجريه قبل أن تطلب من العميل بدء العمل الفعلي.

ما هي حسابات SMPP للعملاء فعلًا

عبر واجهة HTTP API يرسل العميل طلبًا واحدًا لكل رسالة ويتلقّى استجابة. أما عبر SMPP فيفتح العميل جلسة TCP طويلة العمر مع خادم SMPP لديك، ويصادق مرة واحدة بمعرّف system_id وكلمة مرور، ثم يبثّ الرسائل عبر تلك الجلسة كحزم ثنائية تُسمّى PDU. على منصّتك أن تشغّل خادم SMPP (خادم Smppcube يستمع على المنفذ 2775 وهو مرسوم في صفحة المنصّة)، وأن تقبل الـbind، وأن تتحقّق من كل submit_sm مقابل حساب العميل، وأن تضعه في الطابور ضمن خط المعالجة نفسه الذي تغذّيه واجهة HTTP API، ثم أن تعيد لاحقًا إشعار التسليم عبر الجلسة نفسها على هيئة deliver_sm.

إذن فحساب SMPP ليس منتجًا منفصلًا بفوترته الخاصة. إنه بيانات اعتماد على حساب عميل قائم، إضافة إلى مجموعة من الحدود: أي أوضاع bind، ومن أي عناوين IP، وكم جلسة، وبأي سرعة. بيانات الاعتماد هي الجزء الصغير. أما الحدود فهي الحساب.

أنواع bind وما تسمح به

يعرّف SMPP ثلاثة أوضاع لـ bind، وينبغي أن يحدّد إعداد الحساب لديك أيّها يحقّ للعميل استخدامه:

• وضع transmitter: إرسال فقط. يرسل العميل الرسائل ويتلقّى استجابات الإرسال (معرّف الرسالة) ولا شيء غير ذلك. بسيط، وهو سبب ضياع الإشعارات، لأن الـtransmitter لا يملك قناة لاستقبال deliver_sm.
• وضع receiver: استقبال فقط. يتلقّى العميل إشعارات التسليم والرسائل الواردة (الردود الصادرة من الهواتف المحمولة، إن كنت توجّه إليه أيًّا منها) ولا يستطيع الإرسال.
• وضع transceiver: الاثنان معًا على جلسة واحدة. هذا ما تفتحه معظم مكتبات العملاء الحديثة افتراضيًا، وما ينبغي أن توصي به، لأن جلسة واحدة تحمل الإرسال والإشعارات معًا فلا يبقى ما يمكن أن يختلّ تطابقه.

النمط التقليدي المكوّن من bind بوضع transmitter وآخر بوضع receiver لا يزال قائمًا، عادةً لأن حزمة عميل أقدم كُتبت بتلك الطريقة. اسمح به، لكن احتسبه جلستين من حدّ الحساب، وتأكّد من أن الـbind بوضع receiver مفتوح فعلًا قبل أن تفترض أن الإشعارات تُسلَّم.

حدود الجلسات أهم مما يتوقّعه الناس. العميل الذي يفتح عشرة روابط bind بوضع transceiver «للاحتياط» يحجز عشر خانات في جدول الاتصالات لدى خادمك، ويستطيع دفع عشرة أضعاف الإنتاجية التي قصدتها. من جلستين إلى أربع جلسات لكل حساب قيمة افتراضية معقولة؛ والعميل الذي يحتاج أكثر من ذلك عميل ينبغي أن يكون على باقة أعلى.

الإنتاجية والنوافذ وتقييد المعدّل

الإنتاجية في SMPP دالة لأمرين: عدد حزم PDU التي يُسمح للعميل بإبقائها قيد النقل قبل انتظار الإقرارات (النافذة)، والمعدّل الذي تسمح به. يشرح دليل SMPP مقابل HTTP لماذا يستطيع bind واحد حسن الإدارة دفع مئات الرسائل في الثانية؛ أما النقطة هنا فهي أنك، على منصّتك، الطرف الذي تُدفع إليه هذه الحركة.

امنح كل حساب SMPP سقفًا للرسائل في الثانية مأخوذًا من العقد، لا مما يستطيع خادمك فعله. العميل الذي يدفع مقابل 10 msg/s يحصل على 10 msg/s؛ وحين يتجاوزها، أجب بخطأ تقييد المعدّل الذي يعرّفه البروتوكول (ESME_RTHROTTLED) بدل وضع الفائض في الطابور بهدوء. مكتبة العميل المكتوبة جيدًا تعامل هذا الخطأ على أنه طلب «أبطئ» فتتراجع. أما المكتوبة بشكل سيئ فتواصل الإرسال بإلحاح، وينبغي أن يقطع خادمك الـbind بعد مخالفات متكررة ويسجّل السبب، لأن البديل هو أن تتحوّل حلقة إعادة المحاولة سيئة الضبط لدى عميل واحد إلى تأخير يعانيه الجميع.

رقمان آخران ينتميان إلى الحساب. حجم النافذة (من 10 إلى 20 حزمة PDU غير مُقَرّة هو المعتاد لـ bind موجّه للعملاء؛ وقد يسمح المشغّلون في الأعلى بأكثر من ذلك)، وفاصل enquire_link، وهو النبضة التي تُبقي الجلسة الخاملة حيّة. أبلغ العميل بالثلاثة كلها حين تُصدر بيانات الاعتماد. أكثر تذاكر «SMPP لا يعمل» شيوعًا هي مكتبة عميل مضبوطة على نافذة لا يمنحها خادمك، فتنتهي مهلتها عند كل رسالة عاشرة وتبلّغ عن ذلك على أنه عطل في المنصّة.

إلى أين تذهب إشعارات التسليم

إشعار التسليم (DLR) عبر SMPP ليس استجابة لعملية الإرسال التي أجراها العميل. إنه يصل لاحقًا، دون طلب، على هيئة deliver_sm على bind العميل بوضع receiver أو transceiver، ويطابقه العميل مع الرسالة الأصلية عبر معرّف الرسالة الذي أعاده خادمك وقت الإرسال. ويترتّب على ذلك ثلاثة أمور.

أولًا: يجب أن يكون للإشعار مكان يذهب إليه. إذا كان العميل مرتبطًا بوضع transmitter فقط ولا يوجد لديه bind مفتوح بوضع receiver، فلا مسار للإشعار. قرّر السياسة مسبقًا: اشترط روابط bind بوضع transceiver، أو احتفظ بالإشعارات لفترة قصيرة إلى أن يظهر bind بوضع receiver، أو قدّم webhook قناةً للإشعارات للعملاء الذين لا يستطيعون تشغيل receiver. التخلّص من الإشعارات بصمت هو الخيار الوحيد الذي سيعود إليك على شكل نزاع.

ثانيًا: الإشعار ملكك قبل أن يكون ملك العميل. تحتاج منصّتك إلى إشعار المشغّل لتسوية الرسالة في الدفتر، ولعرض الحالة في لوحة تحكم العميل، ولتغذية تقارير جودة التسليم الخاصة بك لكل مسار. خزّنه، وحدّث الرسالة، ثم مرّره. التصميم الذي يكتفي بتمرير الإشعارات إلى الـbind ولا يحتفظ بشيء تصميم لا جواب لديه حين يقول العميل «حمّلتني ثمن 4,000 رسالة لم تصل قط».

ثالثًا: تصل الإشعارات بمعدّل يقارب معدّل الإرسال، وتصل إشعارات الحملة بعد الحملة. العميل الذي يطلق 50,000 رسالة في خمس دقائق سيتلقّى 50,000 حزمة deliver_sm خلال الدقائق العشر التالية. إذا كان bind الـreceiver لديه بطيئًا في الإقرار، فإن طابور الإشعارات الصادرة لديك يكبر؛ اجعله طابورًا بعمق مرئي لا ذاكرة وسيطة بلا حدود، وأطلق تنبيهًا بحسب عمر الإشعارات، كي يظهر bind العميل المتعطّل على لوحة المعلومات لديك قبل أن يفتح العميل تذكرة.

معرّفات المرسل والترميز والأمور التي يخطئ فيها العملاء

يحتاج حساب SMPP أيضًا إلى مجموعة قواعد. ما عناوين المصدر (معرّفات المرسل) التي يحقّ للعميل استخدامها، أبجدية رقمية أم رقمية، وهل يعيد خادمك كتابة المعرّف غير المعروف أم يرفضه؟ ما ترميزات البيانات المسموحة (GSM 7-bit مقابل UCS-2 للكتابات غير اللاتينية)، وكيف تُقسَّم الرسائل الطويلة (الربط عبر UDH، الذي تتولّاه مكتبة العميل عادةً لكنها لا تفعل أحيانًا)؟ ما فترة الصلاحية وما علامة التسليم المسجّل (registered delivery) التي تشترطها كي تُطلب الإشعارات أصلًا؟

ينبغي أن تُحفظ هذه القواعد على الحساب وأن تُفرض وقت الإرسال، مع إعادة رمز خطأ واضح، بدل قبول الرسالة ثم فشلها بصمت لدى المشغّل. وكما تعيد واجهة HTTP API الجيدة الرمز 400 مع السبب، يرفض خادم SMPP الجيد حزمة submit_sm بالحالة الصحيحة ويترك للعميل إصلاح الخلل من جهته. كل قاعدة تُفرض عند حافة منصّتك نزاعٌ لن تواجهه لاحقًا.

الفوترة لكل bind: الحساب يملك الدفتر

هذا هو الجزء الذي يسوء حين يُلحَق خادم SMPP إلى جانب المنصّة بدل أن يُبنى داخلها. يجب أن تُسعَّر الرسالة التي تدخل عبر SMPP وتُخصم تمامًا مثل الرسالة التي تدخل عبر لوحة التحكم أو واجهة HTTP API: خطة التسعير نفسها، والرصيد نفسه، والهامش نفسه مسجّلًا مقابل المسار نفسه. أوضاع الفوترة الثلاثة الواردة في دليل الفوترة (CreditRoute وWalletRoute وAutoRoute) تنطبق على الحساب، ويرثها الـbind. وحين يبلغ الرصيد الصفر، يجب أن يرفض خادم SMPP الإرسال بخطأ مناسب بدل قبول حركة في طابور لن يُدفع ثمنها أبدًا.

الـbind في SMPP باب إلى حساب العميل، لا حساب منفصل. إذا لم يستطع الدفتر رؤية الباب، فالباب منفذ يتسرّب منه المال.

أما حيث يستحق SMPP بندًا تجاريًا خاصًا به فهو الباقة المحيطة بالـbind: التزام شهري أدنى مقابل سقف إنتاجية أعلى، ورسم لكل جلسة إضافية، وعلاوة سعرية لمسار مخصّص أو لرمز قصير (short code). سعّر هذه البنود كشروط للحساب، كي يسجّل الدفتر الرسم والحركة في كشف الحساب نفسه، وكي يرى العميل الذي ينتقل من HTTP إلى SMPP فاتورة واحدة ببند إضافي واحد، لا علاقة جديدة.

تهيئة العميل: حزمة بيانات الاعتماد

حين تتم الموافقة على عميل لاستخدام SMPP، أرسل مستندًا واحدًا، واجعله المستند نفسه في كل مرة:

1. المضيف والمنفذ، وما يُتوقّع بشأن TLS إن كنت تُنهي TLS أمام خادم SMPP.
2. معرّف system_id وكلمة المرور (تُسلَّم عبر قناة غير البريد الإلكتروني الذي يحمل بقية المعلومات).
3. أوضاع bind المسموحة والحد الأقصى لعدد الجلسات.
4. عناوين IP التي ستقبل منها روابط bind، وكيفية تغييرها.
5. سقف الإنتاجية بوحدة msg/s، وحجم النافذة، وفاصل enquire_link.
6. معرّفات المرسل المسموحة، وقواعد الترميز، ومعالجة الرسائل الطويلة، وعلامة التسليم المسجّل المطلوبة.
7. وجهة الإشعارات، ورموز الأخطاء التي ينبغي أن يتوقّعها العميل ويعالجها.
8. مسار الاختبار وأرقام الاختبار التي تُستخدم قبل بدء العمل الفعلي.

نصف هذه البنود أرقام سيكتبها مهندس العميل في ملف إعداد خلال الساعة التالية. تقديمها كلها دفعة واحدة هو الفرق بين تكامل يستغرق يومًا واحدًا وسلسلة رسائل بريد إلكتروني تمتد أسبوعين.

الاختبار قبل بدء العمل الفعلي

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

مسار الاختبار نفسه هو ما تستخدمه لإعادة إنتاج مشكلة العميل لاحقًا. العميل الذي يقول «توقّفت الإشعارات» يستطيع الارتباط بمسار الاختبار، وإرسال رسالة واحدة، ومشاهدة الإشعار يعود في لوحة التحكم، وهذا يحوّل تذكرة مبهمة إلى فحص لمدة عشر دقائق للـbind بوضع receiver لديه.

متى لا ينبغي أن يحصل العميل على SMPP

ليس كل عميل يطلب SMPP ينبغي أن يحصل عليه. فريق تسويق يرسل من متصفح لا حاجة له إلى bind؛ والمطوّر الذي يرسل 300 رسالة OTP يوميًا تخدمه واجهة HTTP API على نحو أفضل، فهي لا تحتاج إلى جلسة دائمة وتعيد أخطاء يستطيع قراءتها. بروتوكول SMPP مخصّص للعملاء أصحاب الأحجام الكبيرة، أو لمن لديهم حزمة SMPP قائمة، أو لمن لديهم سبب يتعلّق بالامتثال للإبقاء على علاقة مباشرة على مستوى البروتوكول. أما الجميع غيرهم فيحصلون على واجهة API، ويخفّ بذلك طابور الدعم لديك.

ما يجعل العرض موثوقًا هو أن المنصّة نفسها تعمل في الأسفل، وأن خادم SMPP مع ترخيص الاستضافة الذاتية مُضمَّن بدل أن يُباع كمستوى منفصل. العميل الذي يبدأ على واجهة HTTP API ثم ينمو إلى bind عبر SMPP يحتفظ بحسابه ورصيده وخطة تسعيره وتقاريره؛ فالـbind قناة إضافية إلى حساب متعدد القنوات يمكنه أيضًا أن يحمل حركته على WhatsApp وRCS في الدفتر نفسه. هذه الاستمرارية هي ما لا يستطيع الموزّع الذي يستأجر لوحة تقديمه عادةً، وهي السبب غير المُعلن لبقاء العملاء التقنيين.