هندسة الأنظمة المؤسسية التي لا تتوقف: كيف نصمم ERP يعمل بكفاءة في بيئات الاتصال المتقطع؟

لماذا تفشل الأنظمة السحابية التقليدية في البيئات الميدانية الحرجة؟

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

في رحلة بناء منظومة السرايا (Saraya ERP Suite)، كان القرار المعماري الأول هو: لا يجوز أن يتوقف العمل الميداني أبداً بسبب الشبكة، ولا يجوز أن يؤدي تذبذب الشبكة إلى تكرار أي عملية مالية أو تشغيلية.

الركيزة الأولى: مفاتيح منع التكرار (Idempotency Keys) كخط دفاع أول

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

بدون حماية معمارية، ستحصل على قيدين ماليين مكررين. لمعالجة ذلك في SarayaManager وSaraya Livestock، قمنا ببناء معترض مركزي (IdempotencyInterceptor) في طبقة NestJS:

// نموذج مبسط لمنطق التحقق من مفتاح عدم التكرار قبل تنفيذ العملية المالية
async intercept(context: ExecutionContext, next: CallHandler) {
  const request = context.switchToHttp().getRequest();
  const idempotencyKey = request.headers['x-idempotency-key'];

  if (!idempotencyKey) return next.handle();

  const existingRecord = await this.prisma.idempotencyRecord.findUnique({
    where: { key: idempotencyKey },
  });

  if (existingRecord) {
    // إعادة نفس النتيجة السابقة دون إعادة تنفيذ القيد المحاسبي!
    return of(existingRecord.responsePayload);
  }

  return next.handle().pipe(
    tap(async (response) => {
      await this.prisma.idempotencyRecord.create({
        data: { key: idempotencyKey, responsePayload: response },
      });
    }),
  );
}

بهذه الآلية، حتى لو أعاد العميل إرسال الطلب 10 مرات بسبب ضعف الشبكة، يضمن الخادم تنفيذ القيد المحاسبي مرة واحدة فقط وبشكل ذري (Atomic).

الركيزة الثانية: الجمع بين قوة الويب وتطبيقات سطح المكتب (Electron + Local LAN)

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

1. 01خادم محلي داخل المؤسسة (On-Premise LAN Server) أو خادم سحابي خاص.
2. 02تطبيق سطح مكتب رسمي لنظام ويندوز (Electron 34 / Inno Setup) يتصل بالخادم المحلي بسرعة البرق مع آليات تخزين مؤقت ذكية ومراقبة حية لحالة الاتصال (ConnectivityModule).

الركيزة الثالثة: الدقة الحسابية الصارمة (وداعاً لأخطاء Floating-Point)

في الأنظمة المالية وحسابات العلائق وتكاليف الخدمات الطبية، استخدام أرقام الجافاسكربت العادية (Number) يؤدي إلى أخطاء عشرية تراكمية مثل 0.1 + 0.2 = 0.30000000000000004.

لذلك اعتمدنا في كافة أنظمة السرايا:

• نوع Decimal(18, 3) في قاعدة بيانات PostgreSQL (مناسب تماماً للدينار الليبي والعملات ذات الثلاث خانات عشرية).
• مكتبة decimal.js في كل عملية حسابية داخل الخادم والواجهة قبل الحفظ أو العرض.

خلاصة

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