داخل كل تطبيق Oracle Forms تقريباً يوجد إجراء يُسمى شيئاً مثل validate_line_item أو calc_interest_accrual، مُغلَّف في حزمة PL/SQL قام أحد عشر شخصاً مختلفاً بتحريرها منذ عام 2003. هذا الإجراء هو المكان الذي تعيش فيه الأعمال فعلاً. كل شيء آخر — اللوحة، LOVs، المحفزات — هو سباكة حوله.
تنجح الهجرة أو تفشل بناءً على ما يحدث لذلك الإجراء. تعني إعادة الكتابة أن مطوراً يقرأه، ويبني نموذجاً ذهنياً، ويعيد كتابته في TypeScript. هذا هو المكان الذي يختفي فيه بهدوء إعفاء GST الأسترالي المُضاف في عام 2014. تعني الترجمة أن النظام يقرأ PL/SQL، ويُحدد الأنماط الهيكلية، ويُصدر TypeScript يُنفذ سلوكاً مماثلاً. المنطق يبقى. اللغة تتغير. البنية تتحسن.
ما يتغير
وقت التشغيل. يُنفَّذ PL/SQL داخل Oracle Database. يُنفَّذ TypeScript في Node.js أو المتصفح. هذا التحول الواحد يفتح كشف واجهات برمجة التطبيقات، والقياس الأفقي، والنشر المُحتوى — ثلاث قدرات لم يُصمم محرك قاعدة البيانات لتوفيرها قط.
نظام الأنواع. تتطابق أنواع PL/SQL بسلاسة مع الأنواع الأولية المُعرَّفة في دليل TypeScript. NUMBER يصبح number. VARCHAR2 يصبح string. DATE يصبح Date. تصبح أنواع السجلات واجهات. التعيين ميكانيكي، وليس تفسيرياً.
في عام 2002، خلال أول إعادة هيكلة جدية لحزمة PL/SQL، أعدت تسمية متغير NUMBER واحد من p_amt إلى p_amount في حزمة تسعير مشتركة وأعدت النشر في منتصف الليل. في الصباح التالي، بدأت ثلاثة تطبيقات لاحقة في إلقاء أخطاء PLS-00306 لأنها كانت تستدعي الإجراء بربط مواقعي مقابل نصف دزينة من التوقيعات المُحمَّلة بشكل زائد. قضيت إحدى عشرة ساعة في التراجع وإعادة محاذاة التحميلات الزائدة، مدفوعاً بأسوأ قهوة ماكينة بيع في كراكوف. هذا هو الأسبوع الذي تعلمت فيه أنه في PL/SQL، العقد الحقيقي ليس الكود، بل التوقيع، وأي هجرة تتجاهل اتفاقيات الربط ستدفع الثمن لاحقاً.
معالجة الأخطاء. استثناءات PL/SQL تصبح كتل try/catch منظمة. يصبح RAISE_APPLICATION_ERROR استجابات أخطاء مُكتَّبة مع أكواد حالة HTTP يمكن للأنظمة اللاحقة استهلاكها فعلاً.
الوصول إلى البيانات. يصبح SQL المُضمَّن استدعاءات لواجهات برمجة التطبيقات. SELECT FROM contractors WHERE... يصبح this.api.getContractors(filters). لا يزال الاستعلام يصل إلى نفس جداول Oracle، لكن عبر طبقة REST مُحكمة بدلاً من الاقتران المباشر بقاعدة البيانات. الشيء الوحيد الذي لا يمكن لطبقة الوصول إلى البيانات تخطيه بأمان هو محفزات قاعدة البيانات وحالة الحزمة التي اعتمدت عليها النماذج لعقود — هذا الجانب عادة ما يحتوي على كود أكثر 2-3 مرات من ملفات .fmb.
ما يبقى كما هو
كل قاعدة اعتماد. إذا كان PL/SQL يتطلب مبلغاً موجباً، فإن TypeScript يفعل ذلك أيضاً. لقد فصّلنا نمط المحفز الذي يحمل الجزء الأكبر من منطق أعمال Forms في دليلنا لترجمة WHEN-VALIDATE-ITEM إلى مُعتمِدات TypeScript.
كل حساب. إذا حسب PL/SQL الضريبة كـ amount * rate / 100، فإن TypeScript يُجري حساباً مماثلاً بدقة مماثلة.
كل فرع شرطي. إذا كان لدى PL/SQL CASE WHEN status = 'APPROVED' THEN...، فإن TypeScript يحمل نفس البنية الشرطية.
كل خطوة سير عمل. إذا احتاجت الطلبات التي تزيد عن 50 ألف دولار إلى موافقة نائب الرئيس قبل تغيير الحالة، فإن الكود الجديد يُطبق نفس البوابة. السلوك متماثل لأن القواعد متماثلة.
ما تفتحه الهجرة
البنية الجديدة ليست مجرد تبديل لغة. إنها تُمكّن قدرات لم يتمكن Oracle Forms من توفيرها أبداً:
- اختبار الوحدات. يصبح كل اعتماد دالة قابلة للاختبار بشكل مستقل. جعلت Forms تغطية الاختبار الفعلية شبه مستحيلة.
- التحكم في الإصدارات. يعيش TypeScript في Git. كل تغيير له التزام ومؤلف ومقارنة. لم يكن PL/SQL داخل ملفات .fmb يمتلك أياً من ذلك.
- كشف واجهات برمجة التطبيقات. المنطق الذي كان محصوراً داخل قاعدة البيانات يصبح قابلاً للاستدعاء من تطبيقات الجوال وأنظمة الشركاء ووكلاء الذكاء الاصطناعي.
- التطوير المتوازي. يعمل عدة مهندسين على وحدات مختلفة في وقت واحد دون التعدي على ملفات بعضهم البعض.
التحفظات الصادقة
هل تُترجم كل سطر بسلاسة؟ لا. يحتوي Oracle Forms على خصوصيات — التزامات ضمنية، وتدفق الشاشة المُدار بالمتصفح، وتحديد المواقع بإحداثيات اللوحة — ليس لها مُكافئات حديثة مباشرة. تتطلب هذه قرارات معمارية أثناء الهجرة، ونتخذها عمداً.
لكن منطق الأعمال الأساسي — القواعد والحسابات والاعتمادات وسير العمل الذي تعتمد عليه الشركة فعلاً — يُترجم بشكل موثوق. الرياضيات هي الرياضيات. القيد على حد ائتمان هو قيد على حد ائتمان، بغض النظر عن اللغة التي تُطبقه. هذا الحفاظ الميكانيكي هو السبب في أن الهجرة المنظمة تتفوق على إعادة الكتابة اليدوية وترجمة الكود.