دليل Whats360 VCash SMS Patterns: شرح Regex واستخراج بيانات التحويلات المالية وأتمتة المدفوعات

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

هنا تظهر أهمية أنماط الرسائل (SMS Patterns) داخل ميزة المحافظ الإلكترونية Whats360 VCash. فبدلًا من التعامل مع كل رسالة باعتبارها نصًا مستقلًا، يمكن تعريف قواعد مطابقة باستخدام التعبيرات النمطية (Regular Expressions أو Regex) لاستخراج أجزاء محددة من الرسالة، ثم ربط هذه الأجزاء بحقوق بيانات مثل المبلغ ورقم العملية ورقم الهاتف من خلال إعدادات JSON Mapping.

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

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

ما هو SMS Patterns داخل Whats360 VCash؟

أنماط الرسائل (SMS Patterns) هي إعدادات تُستخدم لتعريف قواعد التعرف على صيغ محددة من الرسائل النصية واستخراج البيانات المطلوبة منها.

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

وفق وصف الواجهة المتاح، تتضمن الصفحة أدوات لإضافة الأنماط المخصصة، وتحديد مزود الخدمة ونوع الحركة، وإدخال Regex Pattern، وتكوين JSON Mapping، إلى جانب أداة للاختبار السريع وقسم للأنماط العامة.

ما المشكلة التي تحلها أنماط الرسائل؟

رسائل المحافظ الإلكترونية ليست قواعد بيانات منظمة؛ إنها نصوص مكتوبة وفق قالب تحدده الجهة المرسلة.

على سبيل المثال، قد تحتوي رسالة افتراضية على النص التالي:

تم استلام مبلغ 750 جنيه من رقم 01012345678
رقم العملية TX987654

يمكن للإنسان قراءة الرسالة وفهم أن المبلغ هو 750 جنيهًا، وأن رقم الهاتف هو 01012345678، وأن رقم العملية هو TX987654.

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

يمكن تلخيص المهمة في ثلاث مراحل:

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

ما الفرق بين الأنماط المخصصة والأنماط العامة؟

وفق وصف الواجهة المقدّم، توجد مجموعتان رئيسيتان:

• أنماطي: الأنماط التي ينشئها المستخدم لتناسب صيغة رسالة معينة أو متطلبات تشغيلية خاصة.
• الأنماط العامة: أنماط جاهزة توفرها المنصة لصيغ رسائل مدعومة.

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

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

مكونات إعداد النمط

بحسب وصف الواجهة، تشمل عملية إنشاء النمط مجموعة من الحقول، أهمها:

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

كيف تتحول رسالة SMS إلى بيانات منظمة؟

لفهم SMS Patterns بطريقة عملية، من الضروري الفصل بين المراحل المختلفة التي تمر بها الرسالة.

استقبال الرسالة

تبدأ العملية بوصول رسالة SMS إلى بيئة استقبال الرسائل المرتبطة بسير العمل.

في سيناريو يعتمد على VCash Gateway، يجب أن تكون الرسالة متاحة للنظام الذي سيعالجها. إذا لم تصل الرسالة أصلًا إلى بيئة المعالجة، فلن يستطيع Regex تحليلها مهما كانت دقته.

وهذا يوضح الفرق بين مشكلة الاستقبال ومشكلة المطابقة:

• إذا لم تصل الرسالة، فالمشكلة في مرحلة الاستقبال أو التشغيل.
• إذا وصلت الرسالة ولم يتعرف عليها النمط، فالمشكلة قد تكون في صيغة الرسالة أو Regex أو شروط المطابقة.
• إذا نجحت المطابقة لكن الحقول غير صحيحة، فالمشكلة قد تكون في مجموعات الالتقاط أو JSON Mapping.

هذا الفصل مهم عند تشخيص الأعطال؛ لأنه يمنع إضاعة الوقت في تعديل التعبير النمطي بينما المشكلة الحقيقية تقع في مرحلة أخرى.

التعرف على صيغة الرسالة

بعد إتاحة النص للنظام، يحتاج سير العمل إلى تحديد القاعدة المناسبة لتحليله.

قد تحتوي الرسائل المالية على كلمات متكررة، مثل:

• تم استلام مبلغ.
• تم استقبال مبلغ.
• Received.
• EGP.
• رقم العملية.
• Transaction ID.

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

استخراج الحقول باستخدام Regex

يبحث التعبير النمطي عن أجزاء تطابق القواعد المحددة، مثل مبلغ مالي يتكون من أرقام وفواصل، أو رقم هاتف، أو معرف معاملة يتكون من أحرف وأرقام.

على سبيل المثال، يمكن استخدام النمط التالي لالتقاط قيمة مالية افتراضية:

مبلغ\s+([\d,.]+)

يتعرف هذا التعبير على كلمة «مبلغ»، ثم مسافة أو أكثر، ثم مجموعة من الأرقام أو الفواصل أو النقاط.

إذا كان النص:

تم استلام مبلغ 750.50 جنيه

فإن الجزء الملتقط سيكون:

750.50

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

ربط البيانات بالحقول

بعد استخراج المجموعات، تأتي مرحلة تفسير كل مجموعة وربطها بالمعنى المناسب.

على سبيل المثال، قد يكون المطلوب أن تصبح البيانات على الصورة التالية:

{
  "amount": "750.50",
  "phone": "01012345678",
  "tx_id": "TX987654"
}

هذا مثال توضيحي للبيانات التي يمكن أن تنتج عن عملية استخراج وربط ناجحة، وليس ادعاءً بأن هذه هي الاستجابة الفعلية التي تعرضها واجهة Whats360.

التحقق من المعاملة

هذه المرحلة مستقلة منطقيًا عن Regex.

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

هذا مخطط معماري توضيحي، وليس وصفًا تفصيليًا مؤكدًا لجميع المكونات الداخلية لمنصة Whats360.

مشاهدة تطبيقية على VCash

يمكن الاستفادة من الفيديو التالي للتعرف على السياق العملي لربط Vodafone Cash وأتمتة المدفوعات ضمن منظومة Whats360:

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

أين تقع VCash ضمن منظومة Whats360؟

تضم منظومة Whats360 وظائف مرتبطة بإدارة واتساب والأتمتة وواجهات API وCRM. أما VCash، فيرتبط بسياق أتمتة التعامل مع إشعارات المحافظ الإلكترونية وفق الإمكانات المتاحة في الخدمة.

للتعرف على لوحة Whats360 Pro وسياق أدواتها المختلفة، يمكن مشاهدة:

الغرض من هذا الفيديو في المقال هو توضيح السياق العام للمنصة، وليس إثبات تفاصيل داخلية غير موثقة عن كيفية تنفيذ Regex أو معالجة المعاملات.

هندسة Regex: كيف تقرأ التعبيرات النمطية رسائل المحافظ الإلكترونية؟

التعبيرات النمطية (Regular Expressions أو Regex) هي وسيلة لوصف أنماط النصوص باستخدام قواعد تحدد الأحرف والترتيب والتكرار والمجموعات التي نريد التقاطها.

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

المكونات الأساسية للتعبير النمطي

من المهم معرفة أن سلوك بعض الرموز قد يختلف باختلاف محرك Regex وخيارات تشغيله. لذلك لا يكفي أن يكون التعبير صحيحًا في لغة برمجة معينة؛ بل يجب اختباره في البيئة التي ستنفذه فعليًا.

مثال: التقاط مبلغ مالي

لنفترض أن الرسالة تحتوي على:

تم استلام مبلغ 1,250.50 جنيه

يمكن تجربة التعبير التالي:

مبلغ\s+([\d,.]+)\s*جنيه

يتكون التعبير من أربعة أجزاء:

• مبلغ: يبحث عن الكلمة المحددة.
• \s+: يتطلب وجود مسافة بيضاء واحدة أو أكثر.
• ([\d,.]+): يلتقط سلسلة تتكون من أرقام أو فواصل أو نقاط.
• \s*جنيه: يسمح بوجود مسافات اختيارية قبل كلمة «جنيه».

القيمة التي يُتوقع التقاطها هي:

1,250.50

لكن هذا التعبير لا يتحقق من صحة تنسيق الرقم؛ إذ يمكنه التقاط بعض السلاسل غير الصالحة حسابيًا، مثل 1,,250..50. ولهذا يجب ألا نخلط بين التقاط النص والتحقق من أن النص يمثل مبلغًا صالحًا.

كذلك، إذا كانت الرسالة تستخدم كلمة «جنيه مصري» أو اختصارًا مختلفًا للعملة، فقد تحتاج القاعدة إلى التعديل.

مثال: التقاط رقم العملية

لنفترض أن النص هو:

رقم العملية TX987654

يمكن استخدام:

رقم العملية\s+([A-Za-z0-9]+)

يلتقط الجزء الأخير سلسلة مكونة من أحرف لاتينية وأرقام. لكن هذه القاعدة مناسبة فقط إذا كانت معرفات العمليات الفعلية تتبع هذا الشكل.

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

مثال: التقاط رقم هاتف

قد تحتوي رسالة على:

من رقم 01012345678

يمكن استخدام:

من رقم\s*(\d+)

لكن التعبير السابق يلتقط أي سلسلة متصلة من الأرقام بعد العبارة، ولا يتحقق من أن السلسلة رقم هاتف مصري صالح.

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

مجموعات الالتقاط المسماة والمجموعات المرقمة

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

(?<amount>[\d,.]+)

وتدعم محركات أخرى صيغًا مختلفة للمجموعات المسماة. أما مجموعات الالتقاط التقليدية فتستخدم الأقواس:

مبلغ\s+([\d,.]+).*رقم العملية\s+([A-Za-z0-9]+)

في هذا المثال، تلتقط المجموعة الأولى المبلغ، وتلتقط المجموعة الثانية رقم العملية، إذا كان النص يطابق بقية التعبير.

لكن هناك تفصيلًا مهمًا: قد تعتمد آلية JSON Mapping في النظام على أرقام المجموعات أو على أسلوب مختلف لتسمية المجموعات. لذلك لا يجوز افتراض أن كل محرك يقبل الصيغة نفسها.

وإذا كانت واجهة Whats360 تعرض أمثلة تستخدم مجموعات ذات أسماء رقمية مثل (?<1>...)، فينبغي اختبار الصيغة كما هي داخل أداة الاختبار السريع. لا تُحوّلها تلقائيًا إلى صيغة أخرى قبل معرفة قواعد المحرك الذي تعتمد عليه.

تحليل نموذج فودافون كاش بالعربية

من الأمثلة الواردة في وصف الواجهة:

تم استلام مبلغ (?<1>[\d,.]+)\s*جنيه من رقم(?<3>[\d]+)\s*الرقم المسلسل (?<7>[^\s]+)\s*رقم العملية (?<2>[a-zA-Z0-9]+)

يصف هذا التعبير شكلًا متوقعًا لرسالة تتضمن مبلغًا ماليًا، ورقمًا مرتبطًا بالمحوّل، ورقمًا مسلسلًا، ورقم عملية.

يمكن قراءة أجزائه على النحو التالي:

• تم استلام مبلغ: عبارة حرفية تشير إلى صيغة الرسالة المتوقعة.
• (?<1>[\d,.]+): محاولة التقاط سلسلة المبلغ.
• \s*جنيه من رقم: البحث عن العملة والعبارة التالية لها.
• (?<3>[\d]+): التقاط سلسلة رقمية بعد عبارة «من رقم».
• (?<7>[^\s]+): التقاط سلسلة لا تحتوي على مسافة، بعد عبارة «الرقم المسلسل».
• (?<2>[a-zA-Z0-9]+): التقاط معرف يتكون من أحرف لاتينية وأرقام بعد عبارة «رقم العملية».

هذه القراءة تشرح المقصود من أجزاء التعبير، لكنها لا تثبت أن الصيغة ستعمل كما هي في كل محرك Regex. كما أن القاعدة لا تسمح، في شكلها الحالي، بكل الاحتمالات الممكنة لتنسيق الرسالة.

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

تحليل نموذج إنستا باي بالعربية

المثال الوارد:

تم استقبال مبلغ (?<1>[\d,.]+)\s*جم في حسابك من (?<3>[^:]+)\s*رقم العملية (?<2>[a-zA-Z0-9]+)

يختلف هذا التعبير عن المثال السابق في العبارة الافتتاحية، واختصار العملة، والجزء المستخدم لالتقاط هوية المحوّل.

تسمح المجموعة (?<3>[^:]+) بالتقاط سلسلة من المحارف حتى تصل إلى النقطتين الرأسيتين أو نهاية الجزء الذي تسمح به بقية القاعدة.

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

هذه نقطة عملية مهمة: اسم الحقل لا يغير معنى البيانات التي التقطها Regex. فإذا التقط التعبير اسمًا، فلن يحوله تعيينه إلى phone إلى رقم هاتف.

تحليل نموذج فودافون كاش بالإنجليزية

المثال الوارد:

Received (?<1>[\d,.]+)\s*EGP\s*from\s*(?<3>[\d]+)\s*Txn\s*ID\s*(?<2>[a-zA-Z0-9]+)

يعتمد التعبير على كلمات إنجليزية مثل Received وEGP وTxn ID، ويتوقع وجود مبلغ ورقم بعد from ثم معرف للعملية.

إذا كانت الرسالة تحتوي على كلمة مختلفة مثل Transaction ID بدلًا من Txn ID، فقد يفشل التعبير. وإذا احتوى المبلغ على رمز العملة أو تنسيق آخر، فقد يحتاج إلى تعديل.

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

لماذا لا نستخدم تعبيرًا واحدًا لكل الرسائل؟

قد يبدو من الأسهل بناء Regex عام يبحث عن مبلغ وأي رقم طويل، لكن هذا الأسلوب يرفع احتمال التقاط قيم غير مقصودة.

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

لهذا السبب، يكون النمط المرتبط بصيغة رسالة معروفة أكثر قابلية للضبط من قاعدة عامة تحاول التعامل مع جميع الرسائل.

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

JSON Mapping: تحويل مجموعات الالتقاط إلى حقول مفهومة

يحدد Regex أجزاء النص التي نريد التقاطها، بينما يحدد JSON Mapping كيفية ربط تلك الأجزاء بالحقول التي يتوقعها النظام.

يمكن فهم الفرق من خلال المثال التالي:

الرسالة:
تم استلام مبلغ 750 جنيه من رقم 01012345678
رقم العملية TX987654

لنفترض أن التعبير التقط ثلاث مجموعات:

• المجموعة الأولى: 750
• المجموعة الثانية: TX987654
• المجموعة الثالثة: 01012345678

يمكن تمثيل الربط المفاهيمي هكذا:

{
  "1": "amount",
  "2": "tx_id",
  "3": "phone"
}

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

لماذا يعد ترتيب المجموعات مهمًا؟

افترض أن التعبير يلتقط المبلغ أولًا، ثم رقم الهاتف، ثم رقم العملية. إذا افترض JSON Mapping أن المجموعة الثانية هي رقم العملية، فسيحدث خطأ في تفسير البيانات.

قد تكون المطابقة قد نجحت تمامًا، ومع ذلك تكون النتيجة التشغيلية خاطئة.

لذلك يجب مراجعة ثلاثة أشياء بصورة مستقلة:

لا ينبغي اعتبار نجاح الاختبار دليلًا كافيًا على صحة جميع هذه المراحل ما لم تكن نتيجة الاختبار تعرض القيم الفعلية ويمكن مقارنتها بالقيم المتوقعة.

الفرق بين القيمة النصية والقيمة الرقمية

قد يصل المبلغ على هيئة:

1,250.50

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

يجب الحذر من افتراض أن الفاصلة تعني دائمًا فاصل آلاف؛ ففي بعض التنسيقات تُستخدم الفاصلة للفصل العشري، بينما تستخدم تنسيقات أخرى النقطة.

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

أما رقم العملية ورقم الهاتف، فالأفضل غالبًا الاحتفاظ بهما كسلاسل نصية، لأنهما معرفان وليسا قيمتين لإجراء عمليات حسابية عليهما.

التعامل مع الحقول غير الموجودة

ليس من الآمن افتراض أن كل رسالة ستحتوي على جميع الحقول المطلوبة.

قد تحتوي بعض الرسائل على المبلغ ورقم العملية دون رقم هاتف، أو قد تعرض اسم المحوّل بدلًا من رقمه.

يجب أن تحدد سياسة المعالجة ما إذا كان غياب حقل معين يؤدي إلى رفض الرسالة، أو تحويلها إلى مراجعة بشرية، أو التعامل معها وفق مسار بديل موثق.

ولا ينبغي إنشاء قيم افتراضية تبدو حقيقية لتعويض البيانات المفقودة.

قائمة تحقق قبل حفظ JSON Mapping

• هل رقم المجموعة يشير إلى القيمة المقصودة فعلًا؟
• هل الحقل المستهدف مناسب لنوع القيمة؟
• هل يمكن أن تلتقط المجموعة أكثر من معلومة؟
• هل يمكن أن تكون القيمة فارغة أو مفقودة؟
• هل يحتاج المبلغ إلى تطبيع قبل المقارنة؟
• هل يجب الاحتفاظ بالرسالة الأصلية لأغراض التدقيق؟
• هل يؤدي غياب رقم العملية إلى منع التأكيد الآلي؟

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

إنشاء SMS Pattern جديد واختباره داخل Whats360

يجب أن تبدأ عملية إنشاء النمط من رسالة فعلية، لا من تخمين صيغة الإشعار.

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

https://whats360.live/user/vcash/patterns

إدخال بيانات النمط

بحسب وصف الواجهة، افتح نموذج الإضافة من زر «+ إضافة»، ثم أدخل اسم النمط، ومزود الخدمة، ونوع الحركة، والتعبير النمطي، وJSON Mapping، واسم المرسل المتوقع، ومثال الرسالة.

اجعل اسم النمط واضحًا بحيث يميز مزود الخدمة واللغة ونوع الرسالة، وفق أسلوب تسمية يناسب إدارة الأنماط لديك.

اختبار التعبير

استخدم أداة الاختبار السريع الموصوفة في الواجهة، وأدخل اسم المرسل ونص الرسالة الفعلي.

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

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

اختبار الحالات السلبية

اختبر رسائل لا ينبغي أن تُقبل، مثل رسالة لا تحتوي على رقم العملية المطلوب، أو رسالة غير مالية تشترك مع النمط في بعض الكلمات.

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

مراجعة الربط ثم الحفظ

بعد التأكد من صحة المطابقة والحقول، راجع JSON Mapping واحفظ النمط إذا كانت النتائج متوافقة مع متطلباتك.

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

تحليل الأعطال: لماذا يفشل Regex رغم أن الرسالة تبدو صحيحة؟

فشل المطابقة ليس مشكلة واحدة. وقد يكون ناتجًا عن اختلاف في النص أو إعدادات المرسل أو بنية التعبير أو طريقة تفسير مجموعات الالتقاط.

اختلاف اسم المرسل

إذا كان النمط مرتبطًا باسم مرسل محدد، فقد يؤدي اختلاف الاسم إلى عدم تطبيق القاعدة على الرسالة.

قد يكون الاختلاف ناتجًا عن تغيير اسم المرسل أو وجود مسافة إضافية أو اختلاف في طريقة عرض الرسالة داخل بيئة الاستقبال.

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

اختلاف المسافات

هناك فرق بين:

\s+

وبين:

\s*

الأول يشترط وجود مسافة بيضاء واحدة أو أكثر، بينما يسمح الثاني بعدم وجود مسافة أو وجود مسافات متعددة.

قد يكون استخدام \s* مناسبًا في موضع تتغير فيه المسافات، لكنه ليس حلًا عامًا لكل مشكلة؛ فالتساهل الزائد قد يسمح بمطابقة نصوص غير مقصودة.

كذلك لا تفترض أن المسافة البيضاء تعني المسافة العادية فقط؛ إذ قد تختلف المحارف الفعلية بين النصوص المنسوخة والرسائل المستلمة.

اختلاف ترتيب الجمل

إذا كانت إحدى الرسائل تقول:

تم استلام مبلغ 750 جنيه من رقم 01012345678

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

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

مشكلة تنسيق المبلغ

التعبير:

[\d,.]+

يسمح بالتقاط الأرقام والفواصل والنقاط، لكنه لا يتحقق من صحة ترتيب هذه الرموز.

يمكن أن يلتقط مثلًا:

1,,250..50

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

ولا تستخدم تنسيقًا رقميًا موحدًا على جميع العملات واللغات دون معرفة طريقة كتابة المبالغ في الرسائل الفعلية.

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

قد تظهر الأرقام بصيغ مختلفة، مثل:

123456

أو:

١٢٣٤٥٦

يعتمد سلوك \d على محرك Regex وخياراته، ولذلك يجب اختبار كلا الشكلين إذا كانت الرسائل قد تحتوي عليهما.

إذا كان المحرك لا يتعرف على الصيغة المطلوبة، فيمكن تقييم دعم نطاقات Unicode المناسبة أو تطبيع الأرقام قبل المطابقة، بشرط أن تسمح بيئة التشغيل بذلك وألا يؤدي التطبيع إلى تغيير بيانات مهمة.

مشكلة مجموعة الالتقاط

قد ينجح Regex في المطابقة لكنه يلتقط نصًا أطول أو أقصر من المطلوب.

على سبيل المثال، قد تلتقط المجموعة الثالثة اسم المحوّل مع نص إضافي، ثم يربط JSON Mapping هذه المجموعة بالحقل phone.

هنا ليست المشكلة بالضرورة في JSON، بل في تعريف المجموعة أو افتراض معناها.

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

طريقة عملية لتشخيص الفشل

1. تأكد من وصول الرسالة إلى بيئة المعالجة.
2. راجع اسم المرسل وشروط اختيار النمط.
3. قارن نص الرسالة الفعلي بالنص المتوقع.
4. اختبر التعبير النمطي على النص وحده.
5. راجع قيم مجموعات الالتقاط.
6. افحص JSON Mapping.
7. اختبر الرسائل الصحيحة والخاطئة.
8. وثق التعديل وكرر الاختبارات.

هذا الترتيب يمنع الخلط بين أخطاء الاستقبال وأخطاء المطابقة وأخطاء تفسير البيانات.

بناء Test Matrix قبل تشغيل الأتمتة

اختبار Regex برسالة واحدة لا يكفي لإثبات ملاءمته للاستخدام المستمر. الأفضل إعداد مجموعة اختبارات تغطي الحالات الطبيعية والحالات الحدية والحالات التي ينبغي رفضها.

هذه معايير اختبار مقترحة وليست وصفًا مؤكدًا لما تعرضه لوحة Whats360 في نتيجة الاختبار.

ما المقصود بالمطابقة الخاطئة؟

المطابقة الخاطئة (False Positive) تحدث عندما يتعرف النظام على رسالة باعتبارها مطابقة، رغم أنها لا تنتمي إلى النوع الذي صُمم النمط لمعالجته.

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

لهذا يجب أن يتضمن الاختبار رسائل غير مطابقة، وليس الرسائل الصحيحة فقط.

ماذا عن التكرار؟

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

إذا كان النظام سيستخدم البيانات المستخرجة لتغيير حالة طلب أو تسجيل عملية مالية، فمن المهم تقييم آلية منع التكرار (Idempotency) أو أي ضابط مكافئ متاح.

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

من تحليل الرسالة إلى تأكيد المعاملة: أين تقع حدود Regex؟

هذه هي النقطة الأكثر أهمية في أي مشروع يعتمد على إشعارات SMS ضمن عمليات مالية.

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

أربع مراحل يجب الفصل بينها

لا ينبغي دمج هذه المراحل في خطوة واحدة؛ لأن كل مرحلة تعالج نوعًا مختلفًا من الأخطاء.

ضوابط عملية موصى بها

عند تصميم سير عمل مالي، يمكن تقييم الضوابط التالية بحسب طبيعة النظام:

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

هذه توصيات هندسية عامة، ولا تعني أن جميع هذه الضوابط مدمجة تلقائيًا في Whats360 VCash.

مثال على قرار آمن

لنفترض أن النظام استخرج مبلغًا قدره 750 جنيهًا ورقم عملية من رسالة مطابقة.

قبل تغيير حالة الطلب إلى «مدفوع»، يمكن أن يتحقق سير العمل من أن:

1. الطلب المتوقع يستحق المبلغ نفسه.
2. الحركة من النوع المطلوب.
3. رقم العملية لم يُستخدم سابقًا.
4. مصدر الرسالة يطابق قواعد التشغيل.
5. مستوى الثقة في الإشعار مناسب للإجراء المطلوب، أو توجد وسيلة تحقق إضافية عند الحاجة.

إذا غابت معلومات ضرورية، فلا ينبغي تعويضها بالتخمين. يمكن بدلًا من ذلك تعليق الإجراء الآلي لحين استكمال البيانات.

لماذا لا ينبغي الاعتماد على لقطة الشاشة أو نص الرسالة وحده في جميع الحالات؟

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

إذا كان سير العمل يتخذ قرارات مالية مؤثرة، فيجب تقييم مصدر الإشعار وآلية وصوله ومستوى التحقق المتاح، بدلًا من اعتبار وجود مبلغ ورقم عملية دليلًا كافيًا على اكتمال التحويل.

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

هل يمكن استخدام SMS Patterns مع بنوك ومحافظ خارج مصر؟

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

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

ما الذي يتغير بين مزود وآخر؟

• لغة الإشعار.
• اسم المرسل.
• ترتيب الكلمات.
• اسم العملة واختصارها.
• طريقة كتابة المبلغ.
• شكل رقم العملية.
• وجود اسم المحوّل أو رقم هاتفه.
• استخدام رموز أو علامات ترقيم إضافية.
• وجود معلومات أخرى مثل الرصيد المتبقي.

لذلك لا يكفي أخذ Regex خاص بفودافون كاش واستبدال اسم العملة به لتكوين نمط صالح لبنك آخر.

مثال على التكيف مع صيغة مختلفة

لنفترض أن رسالة افتراضية تستخدم النص:

Payment received: AED 250.00
Reference: AB12345

يمكن بناء تعبير مبدئي يبحث عن المبلغ بعد AED وعن المعرف بعد Reference.

لكن يجب اختبار:

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

هذه الأسئلة تحدد جودة النمط أكثر من مجرد قدرته على مطابقة مثال واحد.

ما الذي يجب التحقق منه في مصر والسعودية والإمارات؟

عند تقييم استخدام الأنماط مع خدمات مالية في أي دولة، يجب التحقق من الصيغ الفعلية للإشعارات، وحقولها، وتوافر استقبال الرسائل في بيئة التشغيل، وأي قيود مرتبطة بمصدر الإشعار أو سياسة الخدمة.

يمكن أن تكون فكرة Regex قابلة للتطبيق في سياقات متعددة، لكن التوافق الفعلي مع مزود معين يحتاج إلى اختبار وتحقق مستقلين.

لذلك، لا ينبغي وصف SMS Patterns بأنها متوافقة تلقائيًا مع جميع البنوك والمحافظ في العالم دون أدلة تشغيلية لكل حالة.

دور VCash Gateway: استقبال الرسالة ليس هو تحليلها

يجب التعامل مع VCash Gateway وSMS Patterns باعتبارهما مفهومين مختلفين في التدفق التشغيلي الموصوف.

• بيئة استقبال الرسائل: تتيح وصول الرسالة إلى النظام الذي سيعالجها.
• SMS Patterns: تصف قواعد تحليل النص والتقاط الحقول المطلوبة منه.

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

هذا التمييز يساعد في تحديد موضع العطل بدلًا من تغيير إعدادات متعددة دون معرفة السبب.

للتعرف على السياق التشغيلي المرتبط بـVCash Gateway، يمكن مشاهدة الفيديو التالي:

يجب مراجعة محتوى الفيديو نفسه عند الحاجة إلى تفاصيل تقنية محددة. ولا يمكن استنتاج آلية الصلاحيات أو تفاصيل الاتصال أو طريقة نقل الرسائل من عنوان الفيديو وحده.

كيف تحدد موضع المشكلة؟

هذا الجدول إطار تشخيص عام؛ ويجب مواءمته مع سجلات النظام والوظائف المتاحة فعليًا.

متى يكون SMS Patterns مناسبًا، ومتى تحتاج إلى حل آخر؟

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

إطار قرار سريع

1. هل تصل رسالة SMS فعلية؟
2. هل تحتوي على الحقول المطلوبة؟
3. هل يمكن مطابقة الصيغة بصورة متكررة؟
4. هل يمكن التحقق من صحة الحقول المستخرجة؟
5. هل يوجد ضابط مناسب لمنع التكرار؟
6. هل مستوى التحقق مناسب لقيمة المعاملة ومخاطرها؟

إذا كانت الإجابة عن سؤال أساسي بالنفي، فالأفضل معالجة الفجوة قبل تفعيل الإجراء الآلي.

أفضل الممارسات لإدارة أنماط الرسائل على المدى الطويل

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

احتفظ بأمثلة مرجعية

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

وثق سبب كل تعديل

إذا تغير التعبير النمطي، دوّن المشكلة التي يعالجها التغيير، والرسائل التي اختُبر عليها، وما إذا كان التعديل قد أثر على مجموعات الالتقاط أو JSON Mapping.

لا توسع النمط دون داعٍ

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

راقب التغيرات في صيغة الرسائل

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

افصل بين الاختبار والتشغيل

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

راعِ الخصوصية

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

الأسئلة الشائعة حول Whats360 VCash SMS Patterns

مقالات ذات صلة

الخاتمة: من قراءة الرسائل إلى أتمتة مالية أكثر انضباطًا

تمثل أنماط الرسائل SMS Patterns طبقة مهمة لفهم كيفية تحويل إشعارات المحافظ الإلكترونية من نصوص عادية إلى بيانات قابلة للاستخدام البرمجي. ومن خلال Regex يمكن وصف صيغ الرسائل والتقاط المبلغ ورقم العملية والحقول الأخرى، بينما يحدد JSON Mapping كيفية ربط القيم المستخرجة بمعانيها داخل سير العمل.

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

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

الكلمات المفتاحية

الأسئلة الشائعة التي يجيب عنها المقال

{
  "amount": "750.00",
  "tx_id": "TX123456",
  "phone": "01000000000"
}