مقدمة عملية في Temenos Transact R22 للمطورين

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

Transact منصة تطبيقات لا مجموعة روتينات، والمطور الفعّال هو من يعرف أي طبقة تملك سجل العمل. دليل عملي يشرح Application وVersion وEnquiry وHook ودورة حياة السجل، مع خطوات كاملة من المتطلب إلى معاملة مُتحقَّق منها على TAFJ. سنبني الفكرة من المشكلة إلى القرار ثم إلى تطبيق يمكن نقله إلى مشروع حقيقي، مع مخطط بصري ومثال عملي وقائمة تحقق في النهاية.

Temenos Transact R22 منصة تطبيقات مصرفية كاملة، وليست مجموعة من الـRoutines المتناثرة. المطور الذي يدخلها بذهنية «سأعدّل ملفًا هنا وأضيف سطرًا هناك» يبني دينًا تقنيًا خلال أسابيع قليلة. هذا المقال يرسم الخريطة الصحيحة: أي طبقة تملك سجل العمل، وأين يعيش كل نوع من التغيير، وكيف تمشي دورة تطوير كاملة من المتطلب إلى معاملة مُتحقَّق منها.

اقرأ الأقسام بالترتيب؛ كل قسم يضيف طبقة إلى الصورة، وفي النهاية ستجد قائمة تحقق جاهزة لأول مهمة تطوير حقيقية.

لماذا يتعثر المطور الجديد في Transact؟

الصعوبة ليست في اللغة. jBC قريبة من BASIC، وTAFJ يعمل فوق JVM. الصعوبة أن Transact لا يعرض كل شيء في مكان واحد: تعريف الحقل في Application، وسلوك التحقق في Version، والعرض في Enquiry، ونقطة الامتداد في Hook. من لا يعرف أي طبقة تملك ماذا ينتهي به الأمر إلى تعديل الملف الخطأ، ثم إخفاء النتيجة بأثر جانبي يصعب تتبعه.

هذه أربع علامات على خريطة ذهنية ناقصة:

• تعديل الملفات مباشرة: يُحدَّث F.ACCOUNT أو F.CUSTOMER بـScript خارجي لتجاوز قاعدة، فتختل التسويات بعد أسابيع.


• الخلط بين Version وRecord: يُنشأ Record جديد لمتطلب هو في حقيقته إعداد في Version قائمة.


• تجاوز دورة الحياة: كود يعمل عند الإدخال فقط وينهار عند الاعتماد، أو العكس.


• الجهل بفروق TAFJ: يُختبر الكود على TAFC ثم يُنشر على TAFJ، فتظهر فروق في المكتبات وسلوك التاريخ.

المفاهيم التي يجب تثبيتها قبل الكتابة

قبل أول مهمة، ثبّت هذه الطبقات كمرجع ثابت لديك:

• Application: عقد البيانات. يحدد الحقول وأنواعها وعلاقاتها، وهو المرجع الأول لسؤال «أين يسكن هذا الحقل؟».


• Record: نسخة بيانات فعلية من Application، تُخزَّن في ملفات مثل F.CUSTOMER وF.ACCOUNT وF.FUNDS.TRANSFER.


• VERSION: وجهة نظر معاملية من Application. تحدّد الحقول الظاهرة وقواعد التحقق ونقطة الاعتماد ومن يستطيع التنفيذ.


• ENQUIRY: تعريف استرجاع وعرض مضبوط، لا يغيّر البيانات ولا يمرّ بمنطق الاعتماد.


• Local Reference: جدول ربط يوجّه النظام إلى Routine محلي عند نقطة دورة حياة محددة.


• TAFJ: بيئة تشغيل Java الحديثة، تعمل فوق JVM وتدعم امتدادات Java وInfobasic.


• Deployment Package: حزمة تحمل الكود والإعدادات والRecords معًا وتُنشر كوحدة واحدة.

دورة حياة السجل: ما يحدث فعلًا عند الحفظ

كل سجل في Transact يحمل معه مجموعة حقول إدارية ثابتة: RECORD.STATUS وCURR.NO وINPUTTER وAUTHORISER وCO.CODE وDATE.TIME. هذه ليست تفاصيل ثانوية، بل هي ما يجعل التدقيق ممكنًا أصلًا.

المسار المختصر: يُدخل المستخدم البيانات، يتحقق Version من القواعد، يُحفظ السجل بحالة INAU مع CURR.NO = 1، ثم يعتمده مشرف آخر فيتحول إلى LIVE. أي تعديل لاحق لا يكتب فوق السجل، بل يرفع CURR.NO ويحفظ صورة جديدة، ولهذا يستطيع المدقق رؤية من غيّر ماذا ومتى.

خطوة بخطوة: من المتطلب إلى معاملة مُتحقَّق منها

الخطوة 1: حدد Application المالكة قبل أي شيء

اسأل: أي Application يملك هذا الحقل؟ إن كان المتطلب عن مبلغ حوالة فالمالكة هي FUNDS.TRANSFER، وإن كان عن حد ائتماني فالمالكة هي ACCOUNT. اكتب اسم الـApplication والملف المقابل له قبل أن تفتح أي محرر.

SUBROUTINE ReadAccountContext(AcctId, CustId, Currency, ErrText)

  $INSERT I_COMMON

  $INSERT I_EQUATE

  $INSERT I_F.ACCOUNT



  ErrText = ''

  CALL F.READ('F.ACCOUNT', AcctId, R.Account, 'F.ACCOUNT', '')

  IF R.Account EQ '' THEN

    ErrText = 'ACCOUNT.NOT.FOUND'

    RETURN

  END

  CustId   = R.Account<ACCT.CUSTOMER>

  Currency = R.Account<ACCT.CURRENCY>

  RETURN

END

بعد هذه الخطوة تعرف بدقة من أين تقرأ البيانات، ولن تلمس ملفًا لا تملكه.

الخطوة 2: قرر بين Version وإعداد جديد قبل كتابة أي كود

معظم المتطلبات ليست كودًا. إخفاء حقل، أو إجباره، أو تغيير نقطة الاعتماد، أو تحديد مستخدمين معينين: كلها إعدادات في Version. الكود يُحتفظ به لما لا يستطيع Version التعبير عنه.

الخطوة 3: أضف نقطة امتداد واحدة عند نقطة دورة الحياة الصحيحة

نقاط دورة الحياة محددة: عند الإدخال (V$FUNCTION = 'I')، وعند الاعتماد ('A')، وعند العرض ('S'). اختر النقطة التي يعبر المتطلب عنها فعلًا، لا التي يسهل ربط الكود بها.

SUBROUTINE FT.MOBILE.POLICY

  $INSERT I_COMMON

  $INSERT I_EQUATE

  $INSERT I_F.FUNDS.TRANSFER



  IF V$FUNCTION NE 'I' AND V$FUNCTION NE 'A' THEN RETURN

  Amount = R.NEW(FT.CREDIT.AMOUNT)

  IF Amount GT 50000 AND R.NEW(FT.CREDIT.ACCT.NO) EQ '' THEN

    ETEXT = 'FT-CREDIT.ACCOUNT.REQUIRED'

    CALL STORE.END.ERROR

  END

  RETURN

END

النتيجة المتوقعة: يُرفض السجل برسالة واحدة واضحة عند الإدخال أو الاعتماد، بدل أن يمرّ ثم يُعالج يدويًا لاحقًا.

الخطوة 4: ابنِ Enquiry للعرض بدل تعديل مسار المعاملة

إن كان المتطلب «أريد رؤية كل الحوالات المعلقة فوق مبلغ معين»، فالحل Enquiry لا Version. الـEnquiry يقرأ ويعرض ولا يكتب شيئًا، وهذا يعني أنه لا يستطيع إفساد البيانات.

SUBROUTINE EnqPendingFT(MinAmount)

  $INSERT I_COMMON

  $INSERT I_EQUATE

  $INSERT I_F.FUNDS.TRANSFER



  SELECT F.FUNDS.TRANSFER WITH RECORD.STATUS EQ 'INAU'

  LOOP

    READNEXT FtId ELSE FtId = ''

  UNTIL FtId EQ '' DO

    CALL F.READ('F.FUNDS.TRANSFER', FtId, R.Ft, 'F.FUNDS.TRANSFER', '')

    IF R.Ft<FT.CREDIT.AMOUNT> GE MinAmount THEN

      CRT FtId : ' ' : R.Ft<FT.CREDIT.AMOUNT>

    END

  REPEAT

  RETURN

END

الخطوة 5: احزم وانشر وتحقق عبر الدورة الكاملة

الحزمة ليست ملف الكود وحده. احزم معه تعريف Version، وسجل Local Reference الذي يربط النقطة بالروتين، وأي Record إعدادات أضفتها. ثم انشر إلى TAFJ واختبر الدورة كما يستخدمها الموظف: إدخال، ثم اعتماد، ثم تعديل، ثم عكس.

# بعد النشر إلى TAFJ تحقق من ثلاثة أمور بهذا الترتيب

# 1) الكود وصل إلى المسار الذي يتوقعه Runtime

ls -l $TAFJ_HOME/bnk/globus/FT.MOBILE.POLICY.jbc

# 2) سجل الربط يشير إلى الروتين المتوقع لا إلى نسخة قديمة

grep -r "FT.MOBILE.POLICY" $TAFJ_HOME/../bnk/LOCAL.REF

# 3) المعاملة الممثلة تنجح في مسارها وتُرفض بالرسالة المتوقعة في مسار الخطأ

هكذا تنتهي المهمة بدليل قابل للمراجعة، لا بانطباع «جرّبتها وبدت تعمل».

مثال عملي كامل: قاعدة اعتماد إضافية على حوالة

الفرق بين الحل الصحيح والحل الهش هو نقطة الربط. الروتين نفسه بلا نقطة صحيحة لا يعمل، ونقطة صحيحة مع روتين يكتب مباشرة في الملف تُفسد دورة الحياة.

SUBROUTINE FT.MOBILE.POLICY

  $INSERT I_COMMON

  $INSERT I_EQUATE

  $INSERT I_F.FUNDS.TRANSFER



  IF V$FUNCTION EQ 'S' THEN RETURN

  IF R.NEW(FT.CREDIT.AMOUNT) GT 50000 AND R.NEW(FT.CREDIT.ACCT.NO) EQ '' THEN

    ETEXT = 'FT-CREDIT.ACCOUNT.REQUIRED'

    CALL STORE.END.ERROR

  END

  RETURN

END

لاحظ سطر V$FUNCTION EQ 'S': هو ما يمنع رفض السجل عند العرض فقط، وهو بالضبط الخطأ الذي يشتكي منه الفريق بعد النشر.

مقارنة: Version مقابل Hook

القاعدة العملية: ابدأ من Version دائمًا، وانتقل إلى Hook فقط عندما يثبت أن Version لا يستطيع التعبير عن القاعدة.

أخطاء شائعة

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

• حدد Application المالكة واسم الملف قبل فتح المحرر.


• أجب أولًا: هل يكفي Version؟ ولا تكتب كودًا قبل هذه الإجابة.


• اختر نقطة دورة حياة واحدة وعالجها صريحًا داخل الروتين.


• استخدم R.NEW وR.OLD بدل القراءة المباشرة عند العمل على السجل الحالي.


• احزم الكود مع Version وLocal Reference وRecords الإعدادات في حزمة واحدة.


• اختبر الإدخال والاعتماد والعرض والتعديل والعكس، لا مسارًا واحدًا فقط.

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

ما الفرق بين Application وRecord؟

Application هو العقد: يحدد الحقول وأنواعها وقواعدها. Record هو نسخة بيانات فعلية من هذا العقد. تغيير Application يؤثر على كل السجلات، أما تغيير Record فيخص سجلًا واحدًا في لحظة واحدة.

متى أحتاج TAFJ بدل TAFC؟

عندما تريد تشغيل Transact فوق JVM مع امتدادات Java، أو عندما تكون نسختك R22 مبنية على TAFJ أصلًا. الفرق العملي يظهر في المكتبات وتنسيق التاريخ وسلوك إعادة التحميل، لذا اختبر على البيئة الهدف نفسها لا على بيئة المطور.

هل أستطيع تعديل سجل معتمد مباشرة؟

لا. التعديل يمرّ عبر دورة الإدخال والاعتماد ويرفع CURR.NO. أي كتابة مباشرة من Script خارجي تُفسد سلسلة التدقيق وتُبقي INPUTTER وAUTHORISER بلا معنى.

الخلاصة

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

بعد أن عرفت من يملك سجل العمل، يصبح السؤال التالي: كيف تستدعي هذه المعاملات من خارج Transact دون أن تتعلم تفاصيلها الداخلية؟ هذا موضوع المقال التالي عن OFS: كيف يعمل ومتى تستخدمه.

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

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

flowchart LR

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

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

    C["فحوص Temenos"]

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

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

    A --> B

    B --> C

    C --> D

    D --> E