لغة OFS في Temenos Transact

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

OFS لغة تكامل النواة في Temenos: بنية الرسالة، الوظيفة والإصدار، الحقول والفواصل، والرد والأثر. سنبني الفكرة من المشكلة إلى القرار ثم إلى تطبيق يمكن نقله إلى مشروع حقيقي، مع مخطط بصري ومثال عملي وقائمة تحقق في النهاية.

أثناء أحد التكاملات الحقيقية، حاول فريق ربط بوابة خدمات داخلية بنواة Temenos عبر الوصول المباشر لقاعدة البيانات، فانتهى الأمر بسجل مُفسَد ورد لا يمكن تتبعه، واضطر فريق التشغيل إلى تصحيح البيانات يدوياً. الحل الصحيح كان لغة OFS: القناة الرسمية التي تمر عبرها أوامر المعاملات بين الواجهات والنواة. في Temenos Transact (سابقاً T24)، لغة OFS (Open Financial Standard) ليست بروتوكول شبكة ولا واجهة REST API بل لغة نصية منظمة: ترسل سطراً منظماً وتستقبل رداً منظماً.

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

لماذا OFS مهم في Temenos؟

OFS ليست خياراً من بين بدائل متكافئة؛ إنها المسار الذي بُني عليه التكامل في Transact أصلاً. الواجهات القياسية مثل TPH وTWeb وIRIS كلها تصيغ رسالة OFS وتمررها للنواة حتى في العمليات اليومية، وصناديق الجوال والبوابات تعمل عبر القنوات التي تنتهي كلها إلى نفس اللغة. لهذا يفهم أي تكامل في البنك يعني فهم OFS:

• النواة لا تتحدث REST مباشرة. لا توجد خدمة HTTP افتراضية تقبل JSON وتكتب في F.ACCOUNT؛ كل محاولة «ذكية» للوصول المباشر تتجاوز نقاط التحقق أو تُفسد التسويات، ومثل هذه الحلول تنكسر مع أول ترقية.


• OFS جسر موحّد لكل العمليات. الإدخال والتعديل والاعتماد والاستعلام كلها تُصاغ بنفس اللغة، فيتعلمها الفريق مرة واحدة ويستخدمها لكل أنواع المعاملات في البنك.


• أتمتة bulk بلا واجهة. عمليات نهاية الشهر أو تصحيح مئات السجلات تُرسل كرسائل متسلسلة دون تدخل بشري على الشاشة، وهذا يقلص ساعات العمل اليدوي إلى دقائق.


• تكامل أنظمة خارجية بسهولة. بوابات الخدمات وتطبيقات الجوال والأنظمة المحاسبية كلها تتحدث مع النواة بنفس اللغة النصية، وتتغير الواجهة دون تغيير طريقة التحدث مع النواة.


• تحكّم دقيق بالحقول والإصدارات. كل رسالة تحمل إصداراً محدداً يحدد الحقول المتوقعة وقواعد التحقق ونقطة الاعتماد، فلا مجال للغموض في ما يُرسل للنواة.


• أثر كامل وقابل للتدقيق. لأن كل أمر يمر عبر قناة واحدة مسجلة، يستطيع فريق التشغيل الإجابة على أي سؤال «من فعل ماذا ومتى» من سجلات الأثر.

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

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

قبل كتابة أول رسالة، ثبّت هذه المصطلحات لأنها تظهر بلا استثناء في كل رسالة، ومعرفتها بدقة هي ما يفرق بين رسالة تعمل ورسالة تُرفض:

• الرسالة (Message): سطر نصي متكامل يمثل أمراً واحداً للنواة، من رأس الوظيفة حتى آخر حقل. أي خطأ في ترتيب أجزائها أو في الفواصل يعني رفضاً أو سلوكاً غير متوقع، والنواة لا تتساهل مع التنسيقات الغريبة.


• الوظيفة (Function): نوع العملية المطلوبة، مثل VERSION للتحقق والحفظ أو INPUT للإدخال عبر شاشة أو BROWSE للاستعلام. الوظيفة تحدد كيف تفسر النواة بقية الرسالة، والخلط بينها ينتج عنه أمر ينفذ شيئاً آخر مما قصدت.


• الإصدار (Version): وجهة نظر معاملية من Application تحدد الحقول الظاهرة وقواعد التحقق ونقطة الاعتماد. تغيير الإصدار يغير شكل الرسالة المتوقعة، لذا رسالة مبنية على إصدار قديم تفشل بصمت أو تملأ حقولاً في غير مواضعها.


• الحقول (Fields): أزواج اسم=قيمة أو قيم بترتيب موضعي محدد بحسب الإصدار. الحقل الخاطئ في الموضع الخاطئ يرسل القيمة إلى مكان آخر، وهذا أخطر أنواع الأخطاء لأن النواة تحفظه دون شكوى.


• الفاصل (Delimiter): الرمز الذي يفصل عناصر الرسالة؛ الفاصلة تفصل الحقول وقد تفصل بعض الرموز القيم المتعددة داخل الحقل الواحد. فاصل واحد خاطئ يكسر قراءة الرسالة كلها.


• الرد (Response): سطر عائد من النواة يحمل رمز النجاح أو رمز خطأ مع وصفه، ورقماً مرجعياً عند النجاح. قراءة الرد ومعالجته مسؤولية المتصل لا النواة، والتجاهل هو أسهل طريقة لدفن فشل صامت.

رحلة أمر OFS

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

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

خطوة بخطوة: بناء رسالة

الخطوة 1: اختر الوظيفة والإصدار

حدد أولاً ماذا تريد من النواة أن تفعل بالضبط: تحقق وحفظ؟ استعلام؟ اعتماد؟ ثم اختر Application والإصدار الذي يملك الحقول التي تحتاجها. الخطأ الشائع هنا هو اختيار إصدار «يشبه» ما تريد بدل الإصدار المعتمد في بيئة الإنتاج، فتظهر الحقول بترتيب مختلف عما تتوقعه وتفشل الرسالة بعد ساعات من الجدال مع فريق التشغيل.

VERSION,FUNDS.TRANSFER,MOBILE.INIT SOURCE/OPERATOR1/DEV,1

النتيجة: النواة تعرف العملية والإصدار والشركة المتلقية من رأس الرسالة.

الخطوة 2: رتّب الحقول بالفاصل

بعد رأس الرسالة تأتي قائمة الحقول مفصولة بفواصل. بعض الصيغ تستخدم field=value وبعضها يستخدم قيماً موضعية مرتبة بحسب تعريف الإصدار. رتّب القيم بنفس الترتيب الذي يعرضه الإصدار، وتذكر أن القيم المتعددة داخل الحقل الواحد تفصل بفاصل مختلف، والخلط بين الفاصلين خطأ لا يظهر إلا في البيانات المخزنة.

CREDIT.AMOUNT=2500,CREDIT.ACCT.NO=ACC0001,CREDIT.CURRENCY=USD

النتيجة: كل قيمة تصل إلى الحقل الصحيح ويستطيع الإصدار التحقق منها وفق قواعده.

الخطوة 3: حدّد الهوية والصلاحية

أمر OFS بلا هوية مرسل لا يجوز أن يصل إلى النواة. حدد مصدر الرسالة ومُدخلها وشركة الاستقبال حتى يعرف نظام التدقيق من فعل ماذا وفي أي سياق. كثير من البنوك تعتمد مستخدمين نظاميين مخصصين لكل وحدة خارجية — مثل مستخدم البوابة ومستخدم الجوال — ليسهل فصل الأثر وضبط الصلاحيات، وتجاهل هذه الخطوة يجعل أي رسالة لاحقة بلا معنى تدقيقي.

VERSION,FUNDS.TRANSFER,MOBILE.INIT PORTAL/APIUSER/BNK,1

النتيجة: تدقيق كامل على كل رسالة؛ كل أمر يُنسب إلى مستخدم حقيقي في فرع محدد.

الخطوة 4: مرّر الرسالة للنواة

لا تكتب في قاعدة البيانات مباشرة، ولا تقلد ما تفعله الشاشات سراً. مرر الرسالة عبر قناة OFS الرسمية — عبر بوابة العقد للمتصلين الخارجيين، أو عبر مكتبة OFS.REQUEST برمجياً من داخل Subroutine. هذه القناة هي التي تضمن مرور الرسالة بمنطق التحقق ودورة الحياة كاملة بدل تجاوزها.

CALL OFS.REQUEST('20','VERSION,FUNDS.TRANSFER,...',OutRec,Err)

النتيجة: تنفيذ داخل النواة عبر المسار الرسمي بكل نقاط التحقق مفعّلة.

الخطوة 5: اقرأ الرد

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

REJECT: OFS-ERROR : field MISSING

النتيجة: معالجة النتيجة برمجياً بشكل صريح لا ترك الأمر للصدفة.

الخطوة 6: سجّل الرسالة والرد

كل رسالة والرد المقابل لها يجب أن يسجلا معاً بربط واحد (correlation) يسمح بتتبع الرحلة من البداية إلى النهاية. عند شكوى عميل بعد شهر، تكون شاشة الأثر هي الفيصل: متى وصل الأمر وما الذي أحدثه وما الرد؟ التسجيل المتقطع أو فصل الطلب عن الرد يفقدك هذه القدرة نهائياً.

log OFS request + response بـ correlation id

النتيجة: تتبّع أي أمر عبر الزمن كاملاً، وهو أساس حل النزاعات في البنك.

مثال عملي كامل: فتح حساب

نظام إدارة علاقات العملاء (CRM) في البنك يحتاج فتح حساب جديد فور اعتماد العميل دون تدخل فريق التشغيل. بدل انتظار يد عاملة، يصيغ النظام رسالة OFS: يحدد VERSION كوظيفة وACCOUNT كتطبيق وإصدار الحساب المعتمد، ويرتب حقول العميل والعملة والفرع، ثم يمرر الرسالة عبر بوابة OFS بهوية مستخدم نظامي مخصص لنظام CRM.

تستقبل النواة الرسالة، يتحقق الإصدار من الحقول والقواعد، يُنشأ السجل بحالة إدخال تنتظر الاعتماد، ويعود الرد برقم الحساب الجديد ورقم مرجعي. سُجلت الرسالة والرد معاً، فأصبح أي سؤال لاحق عن مصدر السجل قابلاً للإجابة من سجل الأثر، دون أن يرى النظام الخارجي قاعدة البيانات أو يعرف شيئاً عن ملفات النواة الداخلية — وهذا هو العزل الصحيح الذي يقدمه OFS.

مقارنة: REST مباشر مقابل OFS

أخطاء شائعة

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

• اختر الوظيفة والإصدار الصحيحين قبل كتابة أي حرف في الرسالة.


• رتّب الحقول وفق تعريف الإصدار المعتمد وليس على الانطباع أو الذاكرة.


• حدد هوية المرسل والشركة بدقة داخل رأس الرسالة.


• مرر الرسالة عبر قناة OFS الرسمية وليس بالكتابة المباشرة في الملفات.


• اقرأ الرد وافحص رمز الحالة قبل اعتبار العملية منجزة.


• سجّل الرسالة والرد معاً بربط موحد للأثر.


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


• تحقق من التشفير والقناة الآمنة عند تمرير بيانات حساسة.


• لا تعيد المحاولة لرسالة فشلت دون فهم سبب الفشل أولاً.


• وثّق رسائل الإنتاج في مكتبة أمثلة معتمدة يرجع إليها الفريق.

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

هل OFS نص حر؟

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

كيف أختبر رسالة؟

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

هل يصلح للـ bulk؟

نعم، OFS مصمم للعمليات المتعددة؛ عمليات نهاية اليوم وتصحيحات السجلات تُرسل كرسائل متسلسلة تنفذ واحدة تلو الأخرى. لكن لا تدفع آلاف الرسائل دفعة واحدة بلا حدود — قسّمها وأعد المحاولة بفهم لسبب الفشل حتى لا يتضاعف الأثر.

ما الفرق بين INPUT وVERSION كوظيفة؟

INPUT تمر بالشاشة كاملة بكل حقولها المرئية وقواعدها العرضية، بينما VERSION تركز على التحقق والحفظ وفق الحقول المحددة للإصدار. اختر بحسب قصدك: محاكاة إدخال موظف على شاشة، أم عملية خلفية موجّهة بلا واجهة.

هل أستطيع استدعاء OFS من داخل T24 نفسها؟

نعم، عبر مكتبة OFS.REQUEST من أي Subroutine. هذه طريقة شائعة لدفع معاملة من روتين آخر بحيث تمر بمنطق التحقق الكامل، بدل الكتابة المباشرة في الملفات التي تجاوز دورة الحياة والأثر.

الخلاصة

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

لتخصيص المعاملة بصيانة، راجع «تخصيص معاملة Temenos القابل للصيانة».

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

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

flowchart LR

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

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

    C["فحوص Temenos"]

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

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

    A --> B

    B --> C

    C --> D

    D --> E