بديل Kannel بواجهة رسومية وفوترة وعلامة بيضاء

ظلّ Kannel ينقل رسائل SMS في العالم بهدوء منذ أكثر من عشرين عامًا، وإذا كنت تشغّل بوابة SMS ذاتية الاستضافة جادّة، فمن المرجّح جدًا أن يكون Kannel أو Jasmin في حزمتك التقنية الآن، يحملان روابط SMPP دون أن يشكوا قط. لذا حين يبحث مشغّل عن بديل لـ Kannel، فهو نادرًا ما يقصد فعلًا استبدال محرّك النقل. ما يقصده أنه تجاوز كل ما لم يُصمَّم محرّك النقل (bearer) ليكونه عن قصد: إدارة رسومية، وحسابات عملاء، وفوترة، وبوابات بعلامة بيضاء، وشخصًا يتصل به في الثانية فجرًا. يتناول هذا الدليل تلك الفجوة تحديدًا، والطرق الصادقة لسدّها دون أن ترمي المحرّك الذي يعمل بالفعل.

ما الذي يبرع فيه Kannel وJasmin

لنُعطِ محرّكات النقل مفتوحة المصدر حقّها، فالتظاهر بأنها ضعيفة هو أفضل طريقة لإهدار المال في استبدالها. يُنهي BearerBox في Kannel بروتوكول SMPP منذ ما قبل وجود معظم شركات المراسلة الناشئة. يحمل روابط دائمة إلى SMSC لديك، ويُبقيها حيّة، ويعيد الاتصال حين يُسقط مشغّل الجلسة، ويوزّع التدفق عبر الاتصالات، وينقل أحجامًا هائلة على عتاد متواضع. مكتوب بلغة C، ومستقر إلى حدّ الملل، والملل هو بالضبط ما تريده من الطبقة التي تلامس المشغّلين.

أما Jasmin فهو الأخ الأصغر، مكتوب بلغة Python، بنموذج تهيئة أنظف، وواجهة سطر أوامر للإدارة، وواجهة API أكثر ودّية يجدها كثير من الفرق أسهل في الاستيعاب. لإنهاء SMPP الخام، كلاهما خيار مشروع ومهني، ولن يكون أيٌّ منهما السبب في انهيار بوابتك.

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

الأشياء الستة التي لن يفعلها محرّك النقل لك أبدًا

عند التثبيت المجرّد، يترك نشرٌ خام لـ Kannel أو Jasmin ست فجوات. ولا واحدة منها عيب في البرمجية. هي ببساطة الأجزاء التي لم تكن قط ضمن النطاق، وتصادف أنها الأجزاء التي يبيعها النشاط التجاري.

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

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

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

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

تقارير يستطيع العميل قراءتها. يكتب Kannel سجلات (logs). والسجلات ليست تقرير تسليم يمكن للعميل فتحه وتصفيته وفهمه دون أن يتصل بك. تحويل سجلات الوصول الخام وأحداث DLR إلى لوحات معلومات لكل عميل، وسجلات قابلة للتصدير، ونِسَب تسليم مقروءة، هو طبقة تقارير لا توجد حتى تبنيها أنت.

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

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

الترحيل الذي يحافظ على روابط SMSC لديك

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

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

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

لا تستبدل محرّك النقل في أي لحظة من ذلك التسلسل، ولا تُسقط رابطًا. أنت تضيف طبقة الأعمال التي كانت مفقودة دائمًا، فوق طبقة الاتصالات التي كانت على ما يرام دائمًا. ولأن Smppcube رخصة لمرة واحدة تملكها بالكامل لا لوحة مستأجَرة، فإن المنصة التي تُرحّل إليها تبقى هي أيضًا على خادمك الخاص، ما يحافظ على وضع العزل الشبكي (air-gap) أو DMZ الذي دفعك إلى اختيار الاستضافة الذاتية في المقام الأول.

ابقَ على Kannel (أو Jasmin) إذا…

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

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

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