دليل المطورين 2026-04-16 11 دقيقة قراءة

تشريح هندسي: لماذا تفشل تخصيصات Frappe عند التوسع التشغيلي؟

كتابة تطبيق Frappe مخصص هو أمر مباشر نسبياً. لكن صيانة هذا التطبيق عبر 20 سيرفر إنتاج (Production Servers) لعملاء مختلفين، بينما يتلقى الإطار الأساسي (Core Framework) تحديثات إصدارات كبرى، هو كابوس تشغيلي مرعب. إذا كانت شركتك تغرق في تذاكر الدعم الفني، وأعطال السيرفرات في منتصف الليل، ودورات عمل العملاء المكسورة، فالمشكلة ليست في إطار عمل Frappe—بل في بنية النشر (Deployment Architecture) الخاصة بك. يقدم هذا الدليل تشريحاً هندسياً للأخطاء المعمارية السبعة الأكثر شيوعاً التي يرتكبها المطورون عند نشر تخصيصات ERPNext، وكيف يؤدي تبني فلسفة CI/CD قوية من خلال مانجلي إلى حلها بشكل دائم.

الفشل الأول: تعديل الكود الأساسي (Core) بدلاً من بناء تطبيق معزول

الخطأ الأكثر كارثية الذي يرتكبه المطورون المبتدئون هو تعديل ملفات ERPNext الأساسية مباشرة عبر SSH لتلبية طلب سريع من العميل. هذا هو 'الدين التقني' (Technical Debt) في أنقى صوره.

بمجرد تشغيل أمر 'bench update'، يكتشف Git تعارضات (Conflicts) في الملفات المعدلة ويوقف عملية التحديث. أنت الآن متجمد في الزمن، غير قادر على تطبيق التحديثات الأمنية أو الميزات الجديدة دون حل التعارضات يدوياً. يجب أن تكون التخصيصات موجودة بشكل صارم في تطبيقات Frappe معزولة تماماً تستخدم الـ Hooks والـ Overrides والـ Custom DocTypes.

فخ الكود المدمج (The Monolith Trap)

إذا قمت بتعديل الملفات الأساسية، فأنت لم تعد تشغل ERPNext؛ أنت تدير نسخة مشوهة (Fork) خاصة بك غير قابلة للصيانة.

الفشل الثاني: ترقيع الامتثال الضريبي (ETA/ZATCA) في سكربتات مخصصة

نظراً لأن ERPNext الافتراضي يفتقر إلى توطين عميق لبيئة الشرق الأوسط، يبني المطورون غالباً تطبيقات مخصصة للتعامل مع ربط مصلحة الضرائب المصرية (ETA) أو هيئة الزكاة السعودية (ZATCA). البنية تكون هشة عادةً: روابط API ثابتة (Hardcoded)، تخزين محلي للشهادات على ملفات السيرفر، ومكالمات API متزامنة (Synchronous) أثناء حفظ الفاتورة.

عندما تُحدث الحكومة هيكل XML الخاص بها، ينكسر السكربت. إذا تأخر رد الـ API، تفشل عملية حفظ الفاتورة بالكامل. الامتثال الضريبي يتطلب طوابير مهام غير متزامنة (Asynchronous Queues) وإدارة API مركزية. من خلال الاعتماد على محركات مانجلي الضريبية المدمجة في صميم المنصة، أنت تتخلص من هذا العبء المعماري بالكامل.

الفشل الثالث: انعدام بيئة الاختبار (Sandbox) وخطط التراجع (Rollback)

تشغيل `bench update` مباشرة على سيرفر إنتاج (Production Server) دون بيئة اختبار منفصلة (Staging) يشبه لعب الروليت الروسي ببيانات العميل المحاسبية.

غالباً ما تقوم ترحيلات قواعد البيانات (Database Migrations) بإسقاط أعمدة، أو دمج جداول، أو تغيير الهياكل بشكل لا رجعة فيه. إذا فشل الترحيل في منتصف التنفيذ، تُترك قاعدة البيانات في حالة تالفة. البنية الاحترافية تتطلب دفع التغييرات إلى بيئة Staging أولاً، وتشغيل اختبارات آلية، ثم النشر للإنتاج فقط عند التحقق. مانجلي تؤتمت مسار الاختبار المعتمد على الحاويات (Containerized Pipeline) بشكل أصلي.

الفشل الرابع: كارثة منح صلاحيات الـ SSH Root

إعطاء العميل أو مستشار طرف ثالث صلاحيات دخول الـ SSH (Root) لإصلاح مشكلة بسيطة هو كارثة أمنية وتشغيلية. نرى بانتظام حالات يقوم فيها 'مستشار' خارجي بمسح ذاكرة التخزين المؤقت (Redis) عن طريق الخطأ في منتصف معاملة مالية، أو التلاعب بسجلات MariaDB مباشرة، أو إفساد إعدادات Nginx لفتح منافذ داخلية.

تجريد البنية التحتية

يجب ألا يمتلك المستخدمون النهائيون والمستشارون الخارجيون أي وصول على مستوى نظام التشغيل (OS). مانجلي تجرد السيرفر تماماً، وتقصر التفاعلات على واجهة الويب الآمنة وعمليات النشر عبر Git CI/CD.

الفشل الخامس: ربط الملكية الفكرية بالبنية التحتية (حالة الرهينة)

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

البنية المعمارية السليمة تفصل بيئة التشغيل عن التخزين. مع مانجلي، يحتفظ المطور بكود المصدر بأمان في مستودع Git الخاص به، ويمنح منصة العميل تصريحاً للقراءة فقط (Read-only Token) لسحب الكود داخل حاوية معزولة. تظل الملكية الفكرية محمية، ويحتفظ العميل بملكية البنية التحتية.

الفشل السادس: تجاهل طوابير المهام الخلفية (Worker Queues)

غالباً ما تتضمن التطبيقات المخصصة معالجة بيانات ثقيلة—مثل إنشاء تقارير PDF معقدة، أو مزامنة آلاف السجلات مع API خارجي، أو تحديث الأسعار بالجملة. تنفيذ هذه العمليات بشكل متزامن يعيق سيرفرات الويب (Gunicorn)، مما يؤدي إلى أخطاء (502 Bad Gateway).

يجب على المطورين تصميم المهام الثقيلة لاستخدام الوظائف الخلفية في Frappe (إرسالها إلى طوابير Redis التي يعالجها عمال Celery/RQ). الفشل في القيام بذلك يضمن انهيار تطبيقك تحت الضغط.

الفشل السابع: نموذج شركات التنفيذ غير القابل للتوسع (الفوترة بالساعة)

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

تصبح إيراداتك محدودة بعدد الساعات المتاحة لكبار المطورين لديك. بنقل عملائك إلى منصة مُدارة مثل مانجلي، أنت تقضي على عبء الـ DevOps. تتوقف عن إصدار فواتير لـ 'ترقيع السيرفرات' وتبدأ في تحقيق إيرادات من بناء 'منطق أعمال' قوي وقابل للتوسع وتطبيقه على مئات العملاء فوراً.