دورة حياة TAFJ في Temenos Design Studio

ماذا ستخرج به من هذا المقال؟

رحلة مكوّن Temenos من التطوير في Design Studio حتى النشر المتدرج: بناء، اختبار، إصدار، وتوثيق. سنبني الفكرة من المشكلة إلى القرار ثم إلى تطبيق يمكن نقله إلى مشروع حقيقي، مع مخطط بصري ومثال عملي وقائمة تحقق في النهاية.

تخيّل مساء الثلاثاء في بنك تجزئة يعمل مباشرة. يسلّمك زميل مشروع Design Studio يضيف فحص أهلية القرض إلى نسخة الصرف (Disbursement Version). تجمّع الكود على حاسوبك المحمول، وتنسخ الفئات إلى الخادم، وتعيد تشغيل TAFJ. في نهاية دفعة دورة الليل الأولى، يُظهر تقرير المطابقة 41,730 قرضاً بعلامة أهلية فارغة: الروتين يقرأ حقلاً مرجعياً محلياً (Local Reference Field) موجوداً فقط في مساحة عمل المطوّر، فيسقط الخادم بصمت إلى القيم الافتراضية القديمة. يبدو السجل طبيعياً — غير أن البيانات خاطئة. هذا هو نمط العيب الذي توقفه دورة حياة TAFJ منضبطة قبل دفتر الأستاذ. ويمشي هذا المقال ذلك المسار — طوّر، ابنِ، اختبر، رقّم، انشر، وثّق — كما تديره فرق Temenos Transact في الإنتاج.

لماذا نحتاج فهم دورة TAFJ؟

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

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


• التراجع لا يوجد إلا إذا وُجدت الإصدارات. بلا أثر مسجَّل ولا وسم مصدر، يعني الاسترداد إعادة بناء الكود القديم من الذاكرة بينما الإنتاج متوقف.


• الدفعات الليلية تضخّم الأخطاء الصغيرة. فحص خاطئ يكتب علامات خاطئة عبر عشرات آلاف السجلات في ليلة واحدة؛ والعيب نفسه في الاختبار يكلف دقائق.


• البيئات تنحرف افتراضياً. يبدأ الاختبار أصغر، ببيانات مقنّعة ومخطط أقدم؛ نشاط دورة الحياة يبقيه صادقاً.


• الجهات الرقابية تتطلب مصدراً موثوقاً. تُدقَّق البنوك على ما عُمل في الإنتاج ومتى ومن وافق؛ دورة الحياة تجيب في أمر واحد.


• تغيير سطر واحد قد يكسر تضميناً مشتركاً. روتين صغير يظل خطراً على include تستخدمه كل الفروع؛ قيّم التغيير بمخاطره لا بحجمه.

المفاهيم الأساسية

• Design Studio — بيئة التطوير المبنية على Eclipse حيث تُنمذج مكوّنات Temenos وتُبرمَج: Versions وEnquiries وReports وحقول مرجعية محلية وأشكال وكود jBC أو Java؛ ملفات الوصف XML مع المصادر تنتمي إلى التحكم بالنسخ.


• TAFJ — Temenos Application Framework (Java)، بيئة التشغيل التي تنفّذ منطق البنك بترجمة jBC إلى Java bytecode؛ أسرع وأسهل مراقبة من بيئة jBASE القديمة التي حلّت محلها.


• المكوّن (Component) — أصغر تسليم: Version أو Enquiry أو Report أو روتين أو حقل مرجعي محلي؛ الوحدة التي تُرقَّم وتُبنى وتُختبر وتُرقَّى.


• البناء (Build) — التحويل القابل للتكرار من المصادر والوصف إلى أثر قابل للنشر (jar مع بيانات XML وصفية) بإصدار ومجموع اختباري.


• النشر (Deploy) — وضع أثر في البيئة المستهدفة وتحديث بيئة TAFJ ليصبح متاحاً؛ عملية تشغيلية على خادم، لا نسخ من بيئة التطوير.


• البيئة (Environment) — مجموعة جارية مسماة (تطوير، اختبار، UAT/تمهيد، إنتاج) بقاعدة بيانات وإعداد خاصين بها؛ الترقية تنقل الأثر صعوداً.


• الإصدار (Versioning) — وسم يُلصق بالمصدر والأثر معاً (مثلاً lending-routines-2.3.1) ويرتبط بتذكرة التغيير؛ وهو ما يجعل التراجع والتدقيق ممكنين.


• التراجع (Rollback) — الاستجابة لفشل نشر: إيقاف، ثم إعادة نشر الأثر السابق، وفحص المعطوب في بيئة أدنى؛ لا يعمل إلا إذا حُدِّد الإصدار مسبقاً.

رحلة TAFJ

لدورة الحياة اتجاه واحد للأثر (صعوداً) واتجاه واحد للتعليقات (نزولاً). يكتسب الأثر ثقةً متزايدة عند كل بوابة، بينما تعود نتائج الاختبار وتقارير العيوب إلى بيئة التطوير. الخط مفرد عمداً — dev -> test -> staging -> prod — بالثنائي نفسه في كل قفزة، كي يعني "نجح في الاختبار" شيئاً في الإنتاج. يعرض الرسم أدناه المحطات الخمس التي يمر بها كل مكوّن.

خطوة بخطوة: الرحلة

الخطوات الست أدناه هي وصف عمل المكوّن المرقّى؛ كل خطوة بوابة بقرار: هل يستحق هذا الأثر الصعود؟

الخطوة 1: طوّر في Design Studio

يجري التطوير أمام تثبيت TAFJ محلي تشغّله بيئة التطوير، فتكون الكود الذي يعمل على جهازك هو فعلاً ما ستُرقّيه — ما دام المصدر هو ما ينتقل. تعيش المكوّنات كملفات (مصادر jBC أو Java مع ملفات XML الوصفية) تحت Git أو SVN، كل تغيير على فرع ينتهي بمراجعة. مشاركة مخرجات التجميع بدل المصدر تعني أن لا أحد يستطيع المراجعة أو إعادة البناء.

git checkout -b feature/loan-eligibility

# التسليم: مصدر المكوّن وملفات الوصف XML لا غير

النتيجة: مصدر حقيقة واحد تحت التحكم بالنسخ، يستطيع أي شخص بناءه.

الخطوة 2: ابنِ الحزمة

البناء ليس النقر على Compile في بيئة التطوير. يجري بناء الإنتاج على خادم البناء (Maven أو Gradle خلف GitLab CI أو Jenkins أو Azure DevOps): يعمل مترجم TAFJ، وتُشغَّل اختبارات الوحدات، ويُدفع jar مسمّى إلى Nexus أو Artifactory. يحمل الأثر إصداراً ومجموعاً اختبارياً، والبناء قابل لإعادة الإنتاج — بناؤان للوسم نفسه متطابقان حرفياً. البناء على حاسوب محمول يعيد صنف أخطاء "يعمل على جهازي فقط" الذي وُجد الخط لإزالته.

mvn clean verify -DskipTests=false

# الأثر: lending-routines-2.3.0.jar -> Nexus (مع تسجيل sha256)

النتيجة: أثر قابل للنشر بإصدار ومجموع اختباري، يستطيع أي شخص إعادة إنتاجه.

الخطوة 3: اختبر في بيئة مخصصة

يُرقَّى الأثر إلى بيئة اختبار، أبداً مباشرة إلى الإنتاج. تُحدَّث قاعدة بيانات الاختبار من بيانات إنتاج مقنّعة على مستوى إصدار Transact نفسه، فيلتقي المكوّن بمخطط بيانات حقيقي. غطِّ المسار السعيد والحدّي (إنشاء عميل، وطلب قرض، وصرف، ونهاية يوم مصغّرة) وأتمت: الانحدار يلتقط العيب الذي لا يظهر إلا في السجل رقم 41,000 من دفعة.

pipeline/promote.ps1 -to test -artifact lending-routines-2.3.0

pipeline/regression.ps1 -scope loan-disbursement

النتيجة: العيوب التي كانت ستصل إلى الإنتاج تُحل هنا بجزء يسير من التكلفة.

الخطوة 4: انشر لبيئة أعلى

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

dev -> test -> staging -> prod      # نفس الـ jar في كل قفزة

# دلتا LRF والتجاوزات والإعداد تسافر مع الإصدار

النتيجة: التغيير يصل إلى الإنتاج تدريجياً، مرصوداً عند كل محطة.

الخطوة 5: رقّم الإصدار

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

git tag v2.3.1 && git push --tags

# v2.3.1.jar <-> وسم v2.3.1 <-> التذكرة LOAN-118؛ v2.3.0 = وحدة التراجع

النتيجة: التراجع أمر واحد، والمصدر الموثوق استعلام واحد.

الخطوة 6: وثّق ما نُشر

تُكتب ملاحظة الإصدار قبل النشر وتذكر المكوّنات والمتطلبات وترحيل البيانات والإعداد الملموس والموافِقين وخطوات التراجع. يصنّف منها فريق الدعم الحادثة التالية؛ ونشر غير موثّق يحوّل كل حادثة مستقبلية إلى تحقيق من الصفر.

release note v2.3.1 (LOAN-118)

- EB.VALIDATE.LOAN.ELIG: فحص دين-دخل جديد عند الصرف

- LRF جديد: LT.ELIG.SCORE (جدول العميل)؛ المتطلبات بالترتيب

- التراجع: إعادة نشر v2.3.0 وإزالة LRF

النتيجة: لكل بيئة حالة مدقَّقة حاضرة يثق بها الفريق كله.

مثال عملي كامل: ترقية روتين

فريق إقراض يجب أن يطلق متطلباً تنظيمياً جديداً: عند الصرف، رفض القرض إذا تجاوزت نسبة الدين إلى الدخل حداً معيناً. في Design Studio يصبح العمل ثلاثة عناصر: حقل مرجعي محلي LT.ELIG.SCORE للنسبة، وروتين EB.VALIDATE.LOAN.ELIG (بـ jBC) يقرأ الدخل والالتزامات ويصدر EB-ELIG-REJECT عند تجاوز الحد، وتغييراً على LOAN.DISBURSEMENT Version ليعمل الروتين في معالجة الإدخال. تلتزم التغييرات بفرع، وتُمرّ مراجعة، ويبني خط CI حزمة lending-routines-2.3.0.jar.

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

مقارنة: نشر عشوائي مقابل دورة

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

أخطاء شائعة

عيوب تكلف وقتاً حقيقياً في الإنتاج لدى فرق TAFJ، من مراجعات حوادث فعلية.

قائمة تحقق سريعة

استخدمها قبل أي ترقية، خصوصاً نحو الإنتاج.

• مصدر المكوّن وملفات الوصف ملتزمة في فرع حقيقي خلفها مراجعة.


• الأثر بُني بخادم البناء من وسم معروف، لا على حاسوب أحدهم.


• اختبارات الوحدات والانحدار نجحت على الأثر نفسه الذي ترقّيه.


• بيئة الاختبار تطابق الإنتاج في الإصدار والمخطط والبيانات المقنّعة.


• الثنائي نفسه رُقّي صعوداً في كل قفزة.


• الحقول المرجعية المحلية والتجاوزات والإعداد داخل حزمة الإصدار.


• الفتحة مجدولة خارج نوافذ دورة الليل ونهاية الشهر والعطل المصرفية.


• وسم المصدر ونسخة الأثر والتذكرة مسجّلة معاً.


• ملاحظة الإصدار تذكر المكوّنات والمتطلبات وخطوات التراجع قبل الفتحة.


• الأثر السابق مخزّن بأمان كوحدة تراجع.

الأسئلة الشائعة

هل Design Studio يكفي وحده؟

Design Studio بيئة تطوير: يطوّر ويجمّع محلياً ويصحّح، لكنه لا يرقّم ولا يوزّع ولا يرقّي. البناء والنشر يمران عبر بيئة TAFJ وخطها؛ معظم البنوك تُبقي ترقية الإنتاج خارج بيئة المطوّرين تماماً.

كم بيئة أحتاج؟

على الأقل تطوير واختبار وإنتاج. يضيف معظم البنوك بيئة تمهيد أو UAT بينهما، جزئياً لتعكس موافقات إدارة التغيير، وجزئياً كي لا تكون فتحة الإنتاج أول مرة يرى فيها المسؤولون الكبار الأثر.

ماذا إن فشل النشر؟

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

هل أحتاج خط CI/CD؟

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

هل يمكن لتغيير صغير تجاوز الاختبار إلى الإنتاج؟

تغيير يُقيَّم بحجمه لا بمخاطره رهان: تعديل سطر واحد في include مشترك يؤثر على كل روتين يتضمنه، وحقل جديد بلا دلتا يكسر كل روتين يقرؤه. النشر الطارئ موجود، لكنه يمر عبر مسار استثناء محدد بتراجع مكتوب.

الخلاصة

إن اختُصر المقال إلى عشر نقاط فهذه هي.

الخطوة التالية

لتكامل خارجي، راجع "تكامل تطبيق خارجي مع Temenos".

كيف تستخدم هذا المقال في عمل حقيقي؟

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

flowchart LR

    A["نظام خارجي"]

    B["طلب OFS أو API"]

    C["فحوص Temenos"]

    D["المعالجة والموافقة"]

    E["حالة المعاملة"]

    A --> B

    B --> C

    C --> D

    D --> E