نافذة الرابعة فجراً
في عام 1994، كانت المعالجة المجمّعة الليلية هي الإجابة الصحيحة. كانت قوة الحوسبة باهظة الثمن، والتخزين نادراً، وأرخص طريقة لتسوية معاملات اليوم هي إغلاق النوافذ والسماح لـ PL/SQL بالطحن حتى الفجر. شُحنت هذه البنية إلى آلاف من عمليات نشر Oracle Forms ولم تغادر أبداً. يُشغّل موزع شمال أمريكي نعمل معه اليوم 217 وظيفة مجمّعة ليلية. أطولها، إعادة تقييم المخزون، يستغرق 3 ساعات و40 دقيقة. تنتظر كل وظيفة أخرى منها. وعندما يفشل شيء ما، تبدأ ورديات المستودع الصباحية عمياء.
هذه هي البنية التي ورثتها معظم بيئات Oracle Forms من التسعينيات. الترحيل هو الفرصة العملية الوحيدة لتغييرها.
لماذا أصبحت المعالجة المجمّعة هي الافتراضية
صُممت تطبيقات Oracle Forms عندما كانت المعالجة الليلية أرخص طريقة للقيام بالعمل الثقيل. التقطت الشاشات التعاملية البيانات خلال النهار. وطحنتها حزم PL/SQL في الليل. كانت النتيجة بسيطة، وقابلة للتصحيح، ويمكن التنبؤ بها — إلى أن فاقت الأحجام النافذة.
معظم المؤسسات التي نعمل معها لديها وظيفة مجمّعة واحدة على الأقل نمت لتستهلك 60% من الفترة الزمنية المخصصة لها. وعندما تفشل، يكون التعافي يدوياً.
الحجة للبنية المدفوعة بالأحداث
تقلب البنية المدفوعة بالأحداث النموذج. بدلاً من تراكم العمل لتشغيل ليلي، تُشغّل كل معاملة المعالجة اللاحقة فوراً. يُنشئ أمر الشراء حدثاً. يُشغّل الحدث تخصيص المخزون، وفحص الائتمان، وإشعار المورد بالتوازي. تتقلص النافذة الليلية أو تختفي.
الفوائد معروفة جيداً: زمن استجابة أقل، ومرونة أعلى، واستخدام أفضل للموارد. السؤال الأصعب هو ما إذا كان ينبغي لمشروع ترحيل تناول هذا الأمر في الوقت نفسه مع إعادة بناء الواجهة الأمامية.
متى يجب تجميع التحول المعماري
الإجابة الصادقة هي: أحياناً. تجميع إعادة التصميم المدفوعة بالأحداث مع ترحيل Oracle Forms يضيف من 20 إلى 40% إلى الجدول الزمني للمشروع. كما أنه يُحقّق وفورات يصعب التقاطها بعد ذلك.
العامل الحاسم هو ما إذا كانت نافذة المعالجة المجمّعة قيداً تجارياً بالفعل. إذا كان إغلاق نهاية الشهر يتأخر، وإذا كان المستودع ينتظر تحديثات المخزون، وإذا كانت التقارير المواجهة للعميل قديمة بمقدار 24 ساعة — فإن النهج المجمّع يُسدّد نفسه خلال عامين. إذا كانت المعالجة المجمّعة مريحة، فأجّل إعادة التصميم وقم بشحن الترحيل أولاً.
يعمل نمط الخانق هنا
أنظف مسار هو نمط الخانق المُطبّق على الوظائف المجمّعة. يُصدر تطبيق TypeScript الجديد أحداثاً لكل تغيير حالة. في البداية، تُغذي هذه الأحداث قائمة انتظار تستنزفها وظائف PL/SQL المجمّعة الحالية. لا شيء يتكسر. لا تزال التقارير تعمل في الرابعة فجراً.
على مدى الـ 6 إلى 12 شهراً التالية، تُعاد كتابة الوظائف المجمّعة الفردية كمستهلكين للأحداث. ينتقل كل منها من “تعمل ليلياً” إلى “تعمل باستمرار.” تتقلص نافذة الرابعة فجراً وظيفة واحدة في كل مرة. وتصبح سلسلة التصعيد أقصر.
ما الذي يتغير تشغيلياً
تتطلب الأنظمة المدفوعة بالأحداث ممارسات تشغيلية مختلفة. تنتقل المراقبة من “هل انتهت الوظيفة؟” إلى “ما هو عمق قائمة الانتظار وتأخر المستهلك؟” تتحول أنماط الفشل من فشل المجموعة الكامل إلى تدهور جزئي. يجب إعادة كتابة دليل المناوبة.
نوصي أي مؤسسة تقوم بهذا التحول بالاستثمار في أدوات الرصد — التتبع الموزع، ومقاييس قائمة الانتظار، ومعالجة الرسائل الميتة — قبل تحويل الوظيفة الأولى. تركيب الرصد بأثر رجعي مؤلم.
طبقة البيانات لا تزال مهمة
يمكن تشغيل الواجهات الأمامية المدفوعة بالأحداث فوق نفس قاعدة بيانات Oracle التي استضافت تطبيق Oracle Forms الأصلي. لا تتطلب الأحداث Kafka أو مخزن بيانات جديداً في اليوم الأول. جدول بريد وارد بسيط في قاعدة البيانات الحالية، يستنزفه عامل خفيف، يكفي للبدء.
يهمّ هذا لأنه يسمح بأن يحدث التحول المعماري تدريجياً، دون مشروع بنية تحتية موازٍ.
خلاصة القول
الترحيل من Oracle Forms هو اللحظة النادرة التي يمكن فيها للمؤسسة إعادة النظر في بنيتها المجمّعة دون مقاومة سياسية. الفرق التي تنتهز الفرصة تشحن بشكل أسرع، وتنام بشكل أفضل، وتُطلق قدرات في الوقت الفعلي لا يستطيع النموذج المجمّع الوصول إليها.