تطوير تطبيق صيانة وإصلاح دون استبدال نظام إدارة الموارد (ERP) القديم

نظرة عامة

ثلاثة تطبيقات حديثة, بوابة ربط واحدة, ومصدر واحد للحقيقة

اعتمدت المنصة بنية طبقية (Layered Architecture) حيث يدير كل تطبيق PWA الصلاحيات الخاصة به, ونموذج البيانات المحلي, واستراتيجيات التخزين المؤقت, بينما يظل SQL Server المصدر المعتمد والوحيد للحقيقة للبيانات التشغيلية والمحاسبية.

التحدي والحل

حدود الربط والتكامل لحماية منطق العمل القديم

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

بالإضافة إلى ذلك, تطلبت عمليات الفنيين الميدانيين أداءً سلسًا بدون انقطاع في البيئات ذات الاتصال الضعيف أو المنعدم بالإنترنت. وقد تحقق ذلك من خلال تصميم نموذج PWA يعمل بأسلوب Offline-First, حيث يتم حفظ البيانات محلياً وتزامن تلقائياً بمجرد استعادة الاتصال.

تطبيق PWA يعمل بأسلوب Offline-first

العمل بدون إنترنت كحالة أساسية وليس كاستثناء

تم تصميم تطبيق الفنيين ليعمل بسلاسة كاملة أثناء انقطاع الاتصال بالشبكة. يُمنح كل إجراء معرفاً فريداً UUID ويُكتب في IndexedDB قبل إرساله عبر الشبكة, حيث يظل في قائمة الانتظار لحين تأكيده باستجابة رسمية من الخادم.

  { "client_action_id": "60a9f923-7fac-4f70-84fe-2f6ea945ef1a", "aggregate_type": "work_order", "aggregate_id": "WO-18472", "operation": "record_part_usage", "expected_version": "0x000000000001A74B", "occurred_at": "2026-09-10T14:18:22Z", "payload": { "part_id": 381, "quantity": 1 } }  

Paymob + بوابة الرسائل SMS

سير عمل موثوق وآمن للعمليات المالية والإشعارات آمن ضد إعادة الإرسال

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

تقتصر استجابات التطبيقات على تقديم التغذية الراجعة للواجهة, بينما تُعتبر إشعارات الويب الموقعة رقمياً Webhooks التأكيد المعتمد لمعالجة عمليات الدفع.

1. 1

   التحقق من الفاتورة

   التحقق من ملكية السجل, والمبالغ المستحقة, وتطابق العملة, وحالة الدفع مباشرة مع قاعدة بيانات SQL Server.

2. 2

   بدء محاولة الدفع محلياً

   إنشاء مرجع تجاري فريد Merchant Reference ورمز الدفع الخاص بـ Paymob Checkout Token.

3. 3

   المعالجة المعتمدة عبر Webhook

   التحقق من التوقيعات الرقمية HMAC, ومبالغ المعاملات, والعملات, مع منع تكرار المعالجة عبر التحقق من الـ Idempotency.

4. 4

   تسوية الدفتر وإرسال الأحداث

   تحديث حالة الدفع, وتسوية الفاتورة, وإرسال أحداث Outbox ضمن معاملة واحدة موحدة في قاعدة البيانات.

النتائج

تحديث مسارات العمل الأساسية دون مخاطر إعادة بناء النظام بالكامل

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

• إنشاء قناة تواصل مباشرة للعملاء لطلب إصلاح الأجهزة المنزلية, وتتبع تقدم العمليات في الوقت الفعلي, ومراجعة وفواتير الإصلاح ودفعها بشفافية.

• تمهيد الطريق للانتقال التدريجي للميزات من نظام ERP القديم بمرور الوقت, مما يقلل من المخاطر التشغيلية المرتبطة بالاستبدال المباشر الشامل للأنظمة.

استقبل الأوامر بموثوقية, وطبقها دون تكرار (Idempotently), وقارنها بالحالة المعتمدة ورسّخها, واجعل كل تحول في الحالة قابلاً للرصد والملاحظة.

رأي العميل

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

الأسئلة الشائعة

أسئلة مكررة