البنية المعمارية للتطبيق

نظام Nama ERP هو تطبيق ويب واحد مكتوب بلغة Java. يصل إليه المستخدمون عبر المتصفح، وتتشارك جميع وحداته قاعدة بيانات واحدة، ولا يوجد ما يُركَّب على جهاز المستخدم العادي. هذه الجملة تختصر معظم البنية المعمارية، وبقية هذه الصفحة تكمل ما وراءها.

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

الصورة من الخارج

الرسم التالي يوضح الشكل العام (المصطلحات فيه بالإنجليزية كما تظهر في الخوادم فعليًا):

      Browsers            POS terminals        Phones / tablets      Branch devices
    (Chrome, Edge…)       (Nama POS app)        (Nama Mobile)      (attendance, scales)
          │                      │                     │                    │
          └──────────────────────┴──────────┬──────────┴────────────────────┘
                                            │  HTTP / HTTPS
                                 ┌──────────▼───────────┐
                                 │    Apache Tomcat     │
                                 │  ┌────────────────┐  │
                                 │  │  erp           │  │  user interface
                                 │  ├────────────────┤  │
                                 │  │ basic-services │  │  business logic,
                                 │  └────────────────┘  │  services, jobs
                                 └──────────┬───────────┘
                                            │ JDBC
                    ┌───────────────────────┼───────────────────────┐
                    │                       │                       │
          ┌─────────▼─────────┐   ┌─────────▼─────────┐   ┌─────────▼─────────┐
          │  SQL Server       │   │  Attachments      │   │ External systems  │
          │  (one database,   │   │  folder           │   │ mail, SMS, tax    │
          │   all modules)    │   │  (documents,      │   │ authority,        │
          └───────────────────┘   │   images)         │   │ e-commerce…       │
                                  └───────────────────┘   └───────────────────┘

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

المكوّنات التقنية

الطبقة	ما نستخدمه
خادم التطبيقات	Apache Tomcat 10
بيئة التشغيل	Java 21 (واجهات Jakarta EE)
إطار العمل	Spring
طبقة الحفظ	Hibernate فوق JDBC
قاعدة البيانات	Microsoft SQL Server 2016 أو أحدث (يُنصح بـ 2022)
واجهة المستخدم	Vue 3 مع مكتبة المكونات Quasar، تعمل داخل المتصفح
التقارير	JasperReports لطباعة المستندات، إضافة إلى معالج تقارير مدمج ولوحات معلومات تحليلية
خدمات الويب	نقاط اتصال REST و SOAP للتكامل

قاعدة بيانات MySQL مدعومة أيضًا، إلا أن SQL Server هي الخيار الافتراضي والبيئة المختبَرة — راجع الدعم الفني قبل اختيار غيرها، كما هو موضّح في دليل التركيب.

كيف يُقسَّم التطبيق إلى طبقات

داخليًا يُنظَّم التطبيق بالشكل التقليدي — طبقة عرض، وطبقة منطق أعمال، وطبقة وصول إلى البيانات — مع إضافة واحدة لها أثر كبير في الواقع العملي: طبقة الإعدادات التي تمتد عبر الطبقات الثلاث.

   ┌───────────────────────────────────────────────┐    ┌─────────────────────┐
   │ Presentation                                  │    │  Configuration      │
   │ screens, list views, dashboards, printed docs │◄───┤                     │
   ├───────────────────────────────────────────────┤    │  screen layouts     │
   │ Business logic                                │    │  document terms     │
   │ document rules, accounting and inventory      │◄───┤  entity flows       │
   │ effects, pricing, payroll, costing            │    │  approval cycles    │
   ├───────────────────────────────────────────────┤    │  security profiles  │
   │ Data access                                   │◄───┤  scheduled tasks    │
   │ one data model, one database                  │    │  field settings     │
   └───────────────────────────────────────────────┘    └─────────────────────┘

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

لماذا يهم هذا عند مراجعة الترقيات

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

الوحدات الوظيفية

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

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

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

ماذا يحدث عند حفظ مستند

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

   User saves a sales invoice
             │
             ▼
   Document stored  ──────►  Business requests queued
   (user carries on)                    │
                          ┌─────────────┴──────────────┐
                          ▼                            ▼
              Accounting effect               Inventory effect
           (the ledger transaction)      (quantities, cost of goods)
                          └─────────────┬──────────────┘
                                        ▼
                            Processing status on the document
                     (failures are visible and retryable in the
                              Business Requests view)

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

وإلى جانب هذه الآثار المؤجلة، تشغّل الآلية نفسها في الخلفية المهام المجدولة: المستندات المتكررة، وجولات الإشعارات، وإعادة احتساب التكلفة، واستطلاع أنظمة التكامل، وما شابهها من أعمال دورية. وكلها تعمل داخل عملية Tomcat نفسها — لا يوجد خادم مهام منفصل يحتاج إلى نشر.

التطبيقات المرافقة

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

• Nama POS — تطبيق سطح مكتب لنقاط البيع، يواصل العمل خلال انقطاعات الشبكة القصيرة ثم يزامن بياناته مع الخادم. راجع وحدة نقاط البيع.
• تطبيق نما للهاتف — تطبيق لنظامي Android و iOS للموظفين خارج المكتب: الاعتمادات، وإدخال البيانات الميدانية، والاستعلامات. راجع تطبيق نما للهاتف.
• وكيل الحضور والانصراف — خدمة صغيرة تُركَّب في الفرع لتجميع البصمات من أجهزة الحضور ودفعها إلى الخادم، للمواقع التي لا تستطيع أجهزتها الوصول إلى النظام مباشرة. راجع وكيل الحضور attcron.
• أدوات الأجهزة الطرفية — برامج محلية صغيرة لطباعة الملصقات والباركود، وموازين الوزن، وشاشات المطابخ، تُركَّب فقط حيث توجد تلك الأجهزة.

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

كيف ترتبط الأنظمة الأخرى

نادرًا ما يعمل Nama ERP وحده، وسطح التكامل فيه محدَّد وموثَّق عن قصد:

• واجهة برمجية REST لقراءة السجلات وكتابتها برمجيًا — راجع واجهة Nama ERP البرمجية.
• الاستيراد والتصدير عبر الملفات للتحميلات الكبيرة والتبادل الدوري — راجع الاستيراد والتصدير.
• روابط جاهزة مع المتاجر الإلكترونية، وبوابات الدفع، والفاتورة الإلكترونية لدى الجهات الضريبية، ومزودي الرسائل للبريد والرسائل النصية وواتساب.
• الربط على مستوى قاعدة البيانات حيث يكون ذلك هو الطريق العملي الوحيد — راجع الاتصال بقاعدة بيانات Oracle.

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

قاعدة بيانات واحدة، شركات وفروع متعددة

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

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

التقارير والتحليل

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

ملاحظة عند تقدير السعة

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