بنية البنية التحتية
تجيب هذه الصفحة عن السؤال الذي يحتاج مسؤول النظم إلى إجابته فعلًا: ما الذي يجب تجهيزه، وفتحه، والنسخ الاحتياطي له، ومراقبته حتى يعمل Nama ERP.
الإجابة المختصرة أبسط مما يتوقعه كثيرون. يحتاج النظام إلى خادم Windows واحد يعمل عليه Apache Tomcat و SQL Server، ومجلد للمرفقات، ووجهة للنسخ الاحتياطي — وإذا كان المستخدمون يعملون من خارج المكتب، فاسم نطاق ومنفذان مفتوحان. ومعظم التركيبات، بما فيها الكبيرة، لا تتجاوز ذلك أبدًا.
التوزيع القياسي
عند الغالبية العظمى من العملاء يكون خادم التطبيقات وخادم قاعدة البيانات هما الجهاز نفسه. إبقاؤهما معًا يلغي قفزة شبكية من كل نداء لقاعدة البيانات، وهو العامل الأكبر تأثيرًا في إحساس المستخدم بسرعة النظام.
Internet
│
ports 80, 443
┌────────▼────────┐
│ Router/firewall │
└────────┬────────┘
│
Office LAN ──────────────┼──────────────────────────┐
│ │
┌────────────▼─────────────┐ ┌────────▼────────┐
│ Windows Server │ │ Client devices │
│ │ │ │
│ Apache Tomcat + Java 21 │ │ browsers │
│ Nama ERP application │ │ POS terminals │
│ SQL Server + database │ │ phones/tablets │
│ Attachments folder │ └─────────────────┘
│ Local backup folder │
└────────────┬─────────────┘
│ scheduled upload
┌────────▼────────┐
│ Cloud storage │
│ (off-site copy)│
└─────────────────┘هناك تنويعتان شائعتان على هذا الشكل وكلتاهما مدعومتان:
فصل خادم التطبيقات عن خادم قاعدة البيانات. حين تفرض سياسة المؤسسة أن تعيش قواعد البيانات على منصة مُدارة مستقلة، يمكن تشغيل SQL Server على جهاز خاص به. ضع الجهازين على القطاع السريع نفسه من الشبكة المحلية — فالتطبيق كثير الحديث مع قاعدة بياناته، وأي وصلة بطيئة أو عالية الكمون بينهما سيشعر بها كل مستخدم.
الاستضافة السحابية. يمكن تركيب Nama ERP على خادم افتراضي خاص أو خادم مخصص لدى أي مزود، كما توفر نماسوفت استضافة على بنيتها الخاصة، ومراكز البيانات المستخدمة أساسًا في أوروبا (ألمانيا وفرنسا وفنلندا). القيد الوحيد الذي يستحق التصريح به بوضوح: يجب ألا تكون استضافة ويب مشتركة. يحتاج النظام إلى جهاز — افتراضي أو غيره — تتحكم فيه أنت.
ما الذي يجب تجهيزه
تفاصيل التحجيم موجودة في الحد الأدنى لمتطلبات النظام، وخلاصتها أن خادم الإنتاج ينبغي أن يعتمد معالجًا من فئة الخوادم، وذاكرة 64 جيجابايت كحد أدنى ويُنصح بـ 128 جيجابايت أو أكثر، وأقراص SSD لنظام التشغيل وقاعدة البيانات، وتخزينًا أبطأ منفصلًا للنسخ الاحتياطية.
أما البرمجيات على ذلك الجهاز فهي:
| المكوّن | الإصدار |
|---|---|
| نظام التشغيل | Windows 64-bit؛ يُنصح بـ Windows Server 2022 أو أحدث |
| Java | JDK 21 أو أحدث |
| خادم التطبيقات | Apache Tomcat 10 |
| قاعدة البيانات | Microsoft SQL Server 2016 أو أحدث؛ يُنصح بـ 2022 أو أحدث |
يتولى التركيب نفسه برنامج مثبِّت رسومي ينشئ قاعدة البيانات ومستخدمها، ويعدّ مهام النسخ الاحتياطي، وينشر التطبيق، ويستطيع استخراج شهادة SSL — والخطوات الكاملة في دليل التركيب.
الشبكة والمنافذ
| الاتجاه | المنفذ | الغرض |
|---|---|---|
| وارد | 8080 | منفذ Tomcat الافتراضي للتطبيق. افتحه في جدار حماية Windows للوصول من الشبكة المحلية. |
| وارد | 443 | HTTPS بعد تركيب شهادة SSL. هذا ما ينبغي أن يستخدمه المستخدمون البعيدون. |
| وارد | 80 | تحتاجه الجهة المصدِرة للشهادة لإصدار شهادة Let's Encrypt وتجديدها. |
| داخلي | 1433 | SQL Server. يكفي أن يكون متاحًا من خادم التطبيقات فقط — لا تعرضه للإنترنت أبدًا. |
| صادر | 443 | تنزيل الإصدارات والترقيات، ورفع النسخ الاحتياطية إلى السحابة، والفاتورة الإلكترونية، وروابط المتاجر الإلكترونية. |
| صادر | البريد/الرسائل | خادم البريد لديك ومزوّد الرسائل، للإشعارات وإرسال المستندات. |
لكي يصل المستخدمون إلى النظام من خارج المكتب تحتاج إلى عنوان IP ثابت واسم نطاق يشير إليه، مع تمرير المنفذين 80 و 443 من الراوتر. وإن لم يتوفر عنوان ثابت، فخدمة DNS الديناميكي تفي بالغرض. وتُصدر الشهادات عبر Let's Encrypt من خلال المثبِّت وتتجدد تلقائيًا.
لا تعرض قاعدة البيانات للإنترنت
الشيء الوحيد الذي ينبغي أن يكون متاحًا من الإنترنت هو التطبيق عبر HTTPS. أما منفذ SQL Server فمكانه الشبكة الداخلية، والوصول الإداري إلى الخادم نفسه مكانه خلف شبكة افتراضية خاصة (VPN).
أين تعيش البيانات
يحفظ Nama ERP البيانات في ثلاثة مواضع، وأي خطة تعافٍ كاملة يجب أن تشملها جميعًا.
قاعدة البيانات تحتوي كل سجل يديره النظام — الملفات الرئيسية والمستندات والإعدادات وتصميمات الشاشات وقواعد الأمان وسجل التدقيق. هي مركز الثقل: باستعادتها يعود النظام.
مجلد المرفقات يحتوي الملفات التي يرفقها المستخدمون بالسجلات: المستندات الممسوحة ضوئيًا والعقود والصور. وهو مجلد عادي على القرص، وموضعه إعداد على مستوى الخادم، فيمكن وضعه على القرص الذي تتوفر فيه مساحة. ولأن هذه الملفات ليست داخل قاعدة البيانات، فيجب إدراجها في خطة النسخ الاحتياطي صراحةً — نسخة قاعدة البيانات وحدها لن تعيدها. ومدد الاحتفاظ وحدود الأحجام تُضبط في إعدادات المرفقات.
السجلات (Logs) تُكتب في ملف سجل التطبيق على الخادم. وهي أول ما يُراجع عند حدوث خلل، وفيها تُسجَّل عبارات SQL البطيئة عند تفعيل حدود التوقيت.
النسخ الاحتياطي والتعافي
يهيئ المثبِّت منظومة نسخ احتياطي عبر SQL Server Agent، ومن المفيد فهمها لا مجرد وراثتها:
- نسخة كاملة بجدولة ليلية.
- نسخ تفاضلية كل ساعتين إلى ثلاث خلال يوم العمل، بحيث تُقاس أسوأ الحالات بالساعات لا باليوم كاملًا.
- مهمة تنظيف تحذف ملفات النسخ القديمة حتى لا يمتلئ قرص النسخ الاحتياطي بصمت.
- رفع اختياري إلى تخزين سحابي — Google Drive أو Dropbox أو OneDrive أو ما شابه — وهو ما يحوّل النسخ الاحتياطي إلى خطة تعافٍ حقيقية. فالنسخة الموجودة على قرص ثانٍ داخل الخادم نفسه لا تنجو من الحوادث التي تؤمّن نفسك ضدها.
ويستحق أمران أن يُضافا إلى ما يعدّه المثبِّت. أولهما إدراج مجلد المرفقات ضمن النسخة الخارجية. وثانيهما تجربة الاستعادة قبل أن تحتاج إليها؛ فالنسخة الاحتياطية غير المختبَرة مجرد افتراض.
الإتاحة والتعافي من الكوارث
لنكن صريحين هنا، فهذه هي النقطة التي يضغط عليها المراجعون. التوزيع القياسي المدعوم هو خادم تطبيقات واحد. لا يُشغَّل Nama ERP عادةً كعنقود موزَّع خلف موزِّع أحمال، ولذلك تُبنى المرونة في الطبقة الأدنى من التطبيق: شغّل الخادم كجهاز افتراضي على مضيف يدعم التحويل التلقائي عند الأعطال واللقطات (Snapshots)، وحافظ على منظومة النسخ الاحتياطي أعلاه، واحتفظ بإجراء موثَّق لإعادة البناء.
هذا المزيج يمنح معظم المؤسسات زمن تعافٍ يُقاس بالساعات ونقطة تعافٍ في حدود ساعتين. وإن كانت متطلباتك أشد من ذلك، فيجب الاتفاق على التصميم مع الدعم الفني قبل بناء البيئة لا بعده.
الترقيات
يُرقَّى Nama ERP في مكانه، وكل التركيبات تعمل بالنسخة نفسها — فلا توجد نسخة متفرّعة لكل عميل تحتاج إلى توفيق. يبدأ المسؤول الترقية من صفحة الأدوات داخل النظام، فيُنزَّل الإصدار الجديد ويُطبَّق؛ كما تتوفر أداة ترقية عبر سطر الأوامر للخوادم التي لا يناسبها ذلك. والطريقتان موضحتان في دليل التركيب.
وتُطبَّق تغييرات مخطط قاعدة البيانات تلقائيًا عند بدء تشغيل النسخة المرقَّاة، فتصبح الترقية المعتادة: خذ نسخة احتياطية طازجة، طبّق الترقية، أعد التشغيل، ثم تحقق. والتفصيل الوحيد الذي يوقع الناس في حيرة هو أن خدمة Tomcat يجب أن تعمل تحت حساب Local System حتى تعمل الترقية من داخل النظام — فإذا توقفت الترقية الذاتية عن العمل، فهذا الإعداد هو السبب في الغالب.
احتفظ ببيئة اختبارية
نسخة SQL Server Developer Edition مجانية للاستخدام غير الإنتاجي، مما يجعل التركيبة الاختبارية زهيدة التكلفة. واستعادة نسخة الأمس الإنتاجية داخلها تمنحك مكانًا واقعيًا لتجربة الترقيات وتغييرات الإعدادات قبل أن تصل إلى البيانات الحية.
التوزيع على مواقع متعددة
حيث تكون الفروع مرتبطة بوصلات موثوقة — وهذا حال معظمها اليوم — فإنها ببساطة تستخدم التركيبة المركزية عبر الشبكة، ولا شيء إضافي يحتاج إلى نشر. أما حيث يتعذر الاعتماد على الاتصال فعلًا، فيدعم النظام تشغيل تركيبة في الموقع مع Replication للمستندات والملفات الرئيسية مع المركز الرئيسي. وهذا يضيف تعقيدًا تشغيليًا حقيقيًا: قاعدتا بيانات للنسخ الاحتياطي، ووصلة تحتاج إلى مراقبة، وقواعد لحسم التعارضات. تعامل معه كاستثناء مدروس وصمّمه مع الدعم الفني — راجع Replication.
التشغيل اليومي
تتم الإدارة الروتينية من داخل التطبيق لا من وحدة تحكم الخادم. فصفحة الأدوات تحمل أدوات الترقية والتشخيص والصيانة؛ والأعمال الخلفية مرئية وقابلة لإعادة المحاولة عبر شاشتي طلبات الأعمال والمهام المجدولة؛ وأدوات إعادة المعالجة موجودة لحالات التعافي. والمراجع ذات الصلة هي الأدوات والمهام المجدولة وقسما إعادة المعالجة وحل المشكلات.
أما على الخادم نفسه فالمهام المتكررة هي ما يحتاجه أي خادم Windows: تأكد من تنفيذ النسخ الاحتياطي، وراقب المساحة الحرة على أقراص قاعدة البيانات والنسخ الاحتياطية، وأبقِ نظام التشغيل محدَّثًا، ولا تجدد الشهادة يدويًا — فهي تجدد نفسها.