T24 2 — Kiến trúc kỹ thuật: TAFC/TAFJ, jBASE & tầng dịch vụ

Vì sao cần hiểu kiến trúc T24

Temenos T24 (nay thương mại hóa dưới tên Temenos Transact) không phải một khối phần mềm nguyên khối. Nó là hệ thống nhiều tầng (multi-tier), trong đó ngôn ngữ nghiệp vụ, engine thực thi, cơ sở dữ liệu và các tiến trình nền được tách bạch. Điều khiến T24 khác đa số ứng dụng doanh nghiệp hiện đại là gốc gác của nó: engine chạy ngôn ngữ dòng PICK/MultiValue và một cơ sở dữ liệu multivalue tên là jBASE. Hiểu lớp kiến trúc này là điều kiện tiên quyết để hiểu vì sao dữ liệu T24 trông "lạ" (một trường nhiều giá trị), vì sao trích dữ liệu ra kho phân tích cần xử lý riêng, và vì sao nhiều ngân hàng đang có cuộc dịch chuyển hạ tầng tốn kém từ nền C sang Java.

Bài này đi qua bốn khối: (1) kiến trúc logic nhiều tầng, (2) ngôn ngữ jBC và hai bộ khung TAFC/TAFJ, (3) CSDL jBASE và lựa chọn multivalue vs RDBMS, (4) các tiến trình runtime (tSA/tSM, phantom) cùng khả năng mở rộng và HA.

Kiến trúc logic nhiều tầng

Về mặt logic, T24 tuân theo mô hình ba tầng kinh điển, dù cách hiện thực khác biệt so với một ứng dụng web thông thường.

Tầng trình bày (Presentation). Ngày nay người dùng nghiệp vụ tương tác với T24 qua Temenos Browser — giao diện web chạy trên trình duyệt, sinh động HTML/JS từ định nghĩa màn hình bên trong T24. Trước kia (T24 "classic") có ứng dụng desktop và các dạng terminal cũ hơn. Điểm cần nhớ: tầng trình bày không chứa logic nghiệp vụ; nó chỉ dựng màn hình, thu thập dữ liệu người dùng nhập rồi gửi xuống tầng dưới dưới dạng bản ghi giao dịch có cấu trúc (thường thông qua OFS — xem bài OFS — Open Financial Service).

Tầng ứng dụng / logic nghiệp vụ (Application). Đây là trái tim của T24: một engine thực thi các chương trình viết bằng jBC (jBASE BASIC). Toàn bộ quy tắc nghiệp vụ — cách tính lãi, cách hạch toán, cách kiểm tra hạn mức, cách chạy quy trình phê duyệt — nằm ở đây dưới dạng hàng chục nghìn routine jBC cùng các bản ghi cấu hình (parameter tables). Engine này chính là nơi TAFC và TAFJ khác nhau (mục sau).

Tầng dữ liệu (Data). Nơi lưu trữ bản ghi. T24 lưu dữ liệu ở dạng multivalue (dòng PICK), có thể đặt trực tiếp trên các file jBASE hoặc chuyển xuống một RDBMS (Oracle, DB2, MS SQL) thông qua lớp trung gian jEDI. Chi tiết mô hình dữ liệu này được trình bày ở bài Mô hình dữ liệu multivalue của T24.

Điểm mấu chốt: dù bạn chọn lưu dữ liệu trên jBASE files hay trên Oracle, tầng ứng dụng gần như không đổi — nó luôn "nhìn thấy" dữ liệu dưới dạng multivalue nhờ lớp jEDI che giấu sự khác biệt. Đây là một trong những quyết định thiết kế thông minh nhất của jBASE và là lý do T24 có thể sống trên nhiều nền hạ tầng khác nhau.

jBC / INFO-BASIC: ngôn ngữ nghiệp vụ

jBC (jBASE BASIC) là ngôn ngữ mà toàn bộ nghiệp vụ T24 được viết. Nó là một biến thể của INFO-BASIC / PICK BASIC — dòng ngôn ngữ ra đời cùng hệ điều hành PICK từ những năm 1970, tối ưu cho việc xử lý bản ghi multivalue. Với người quen Java/Python, jBC trông vừa lạ vừa quen: có biến, vòng lặp, hàm, nhưng thao tác đặc trưng nhất là đọc/ghi bản ghi và tách/gộp các "field", "value", "subvalue" bằng các dấu phân tách hệ thống.

Một đoạn jBC minh họa (đọc một bản ghi khách hàng và lấy tên):

* (minh hoa) Doc ban ghi tu file va truy xuat truong multivalue
    OPEN "F.CUSTOMER" TO F.CUST ELSE STOP "Khong mo duoc file"
    CUST.ID = "100234"
    READ R.CUST FROM F.CUST, CUST.ID THEN
        SHORT.NAME = R.CUST<EB.CUS.SHORT.NAME>      ;* lay 1 field
        PHONE.1    = R.CUST<EB.CUS.PHONE.1, 1>       ;* value thu 1 cua field multivalue
        CRT "Ten: " : SHORT.NAME
    END ELSE
        CRT "Khong tim thay khach hang"
    END

Cú pháp R.CUST<field, value, subvalue> chính là dấu ấn multivalue: một bản ghi được xem như một cấu trúc phân cấp field → value → subvalue, thay vì các cột phẳng như trong SQL. Đây là điều làm nên sức mạnh (một khách hàng có nhiều số điện thoại lưu gọn trong một field) nhưng cũng là nguồn gốc mọi khó khăn khi trích xuất sang kho dữ liệu quan hệ.

Điều quan trọng: jBC không được thông dịch trực tiếp. Nó được biên dịch, và chính khâu biên dịch này tách ra hai bộ khung lớn.

TAFC vs TAFJ: hai bộ khung chạy cùng một jBC

Cùng một mã nguồn jBC có thể chạy trên hai nền hoàn toàn khác nhau về công nghệ, tùy bộ khung (framework) mà ngân hàng triển khai.

TAFC — Temenos Application Framework for C

TAFC biên dịch jBC sang C/native code rồi build thành các nhị phân chạy trực tiếp trên hệ điều hành (thường là Unix/Linux, AIX, Solaris trước đây). Tên "TAFC" được đặt để phân biệt phần runtime/công cụ với phần cơ sở dữ liệu jBASE — vốn trước kia hay bị gọi gộp làm một. Đây là nền "cổ điển" của T24: hiệu năng native rất tốt, nhưng gắn chặt với hệ điều hành và khó tích hợp với hệ sinh thái ứng dụng doanh nghiệp hiện đại (Java app server, container, cloud).

TAFJ — Temenos Application Framework for Java

TAFJ là hướng hiện đại. Nó là một runtime và compiler cho jBC/PICK BASIC viết hoàn toàn bằng Java. Cơ chế: mã jBC được parser của TAFJ phân tích, dịch thành các lớp Java tương đương, rồi biên dịch bằng javac thành Java bytecode chạy trên JVM. Nhờ đó T24 có thể chạy bên trong một Java application server (WebLogic, WebSphere, JBoss/WildFly, Tomcat...), tận dụng toàn bộ hạ tầng Java: clustering, connection pooling, giám sát JMX, đóng gói triển khai, và đặc biệt là dễ đưa lên cloud và container.

Về dữ liệu, TAFJ kết nối tới CSDL qua JDBC: nó hỗ trợ các RDBMS tuân JDBC như Oracle, Microsoft SQL Server, DB2, DB2-zOS và H2 (thường dùng cho môi trường phát triển/thử nghiệm). Ngoài ra Temenos còn có nền .NET (TAF.Net) nhưng ít phổ biến hơn hai nền C và Java.

Thực tế nhiều ngân hàng đang chạy TAFC và có lộ trình chuyển đổi TAFC → TAFJ để mở đường lên cloud và kéo dài vòng đời core. Đây là một dự án lớn, không chỉ là "đổi compiler": phải kiểm thử lại toàn bộ code tùy biến (local development), rà các đoạn jBC gọi trực tiếp API C/hệ điều hành, chuyển kho dữ liệu và điều chỉnh vận hành. Bù lại, sau khi lên TAFJ, đội hạ tầng làm việc với công cụ Java quen thuộc thay vì phải am hiểu jBASE ở tầng thấp.

jBASE: cơ sở dữ liệu multivalue và lựa chọn RDBMS

jBASE là CSDL dòng MultiValue/PICK đi kèm T24. Nó ra đời từ các kỹ sư gốc Microdata/McDonnell Douglas và ngay từ đầu đã hỗ trợ mô hình dữ liệu multivalue một cách tự nhiên: một "record" có thể chứa nhiều field, mỗi field nhiều value, mỗi value nhiều subvalue — tất cả trong cùng một bản ghi, phân tách bằng ký tự hệ thống thay vì trải ra nhiều bảng như quan hệ.

Đặc điểm thiết kế nổi bật nhất của jBASE là dữ liệu ứng dụng có thể nằm ở bất kỳ CSDL nào, không riêng jBASE files. Cầu nối là jEDI (jBASE External Database Interface) — một lớp phần mềm nằm giữa mọi thao tác đọc/ghi (I/O) của jBASE và nơi lưu trữ thật. Nhờ jEDI:

• Ngân hàng có thể chọn lưu ngay trên jBASE files (native, nhẹ, nhanh cho mô hình multivalue).
• Hoặc lưu trên RDBMS doanh nghiệp (Oracle, DB2, MS SQL). Khi đó dữ liệu và dictionary của jBASE được ánh xạ sang bảng RDBMS, nhưng tầng ứng dụng vẫn "thấy" chúng ở dạng multivalue một cách trong suốt.

Multivalue vs relational cho khối lượng ngân hàng

Không có lựa chọn "đúng tuyệt đối"; mỗi hướng có đánh đổi:

Ưu điểm mô hình multivalue (jBASE files):

• Đọc một thực thể nghiệp vụ (ví dụ toàn bộ thông tin một tài khoản) thường chỉ cần một lần đọc bản ghi, không phải JOIN nhiều bảng → độ trễ thấp, rất hợp với giao dịch online.
• Mô hình dữ liệu phản ánh sát nghiệp vụ tự nhiên (một khách hàng có nhiều điện thoại, nhiều địa chỉ) mà không cần bảng phụ.
• Nhẹ, gắn chặt engine, tối ưu cho pattern truy cập của T24.

Nhược điểm / điểm cần cân nhắc:

• Khó khai thác bằng công cụ SQL/BI phổ thông; muốn phân tích phải trích xuất và làm phẳng dữ liệu multivalue.
• Hệ sinh thái công cụ vận hành, sao lưu, giám sát nhỏ hơn nhiều so với RDBMS lớn.
• Nhân sự am hiểu PICK/MultiValue ngày càng hiếm.

Chọn RDBMS (Oracle/DB2/MSSQL) đổi lại:

• Tận dụng hạ tầng DBA sẵn có, công cụ sao lưu/HA/giám sát trưởng thành, kỹ năng phổ biến trên thị trường.
• Dễ tích hợp báo cáo, tuân thủ với hệ sinh thái doanh nghiệp.
• Đánh đổi: thêm một lớp ánh xạ (jEDI), có thể phát sinh overhead so với native jBASE, và chi phí bản quyền RDBMS.

Với đội dữ liệu, điều quan trọng cần nhớ: dù T24 dùng jBASE files hay Oracle làm store, dữ liệu vẫn mang bản chất multivalue. Việc dữ liệu "nằm trong Oracle" không có nghĩa là bạn có thể mở SQL ra query như một schema quan hệ chuẩn — các cột thường vẫn là chuỗi multivalue được đóng gói. Đây là lý do các dự án data warehouse cho core T24 luôn cần một bước giải mã/làm phẳng chuyên biệt (xem lại bài mô hình dữ liệu multivalue).

Các tiến trình runtime: tSM, tSA và phantom

T24 không chỉ phục vụ giao dịch online mà còn phải chạy khối lượng lớn công việc nền: dịch vụ định kỳ, hàng đợi, sinh báo cáo, và đặc biệt là xử lý cuối ngày. Kiến trúc dịch vụ đảm nhận việc này.

tSM — Temenos Service Manager. Là tiến trình "nhạc trưởng". Được khởi động từ shell jBASE bằng lệnh START.TSM, tSM chịu trách nhiệm quản lý toàn bộ việc thực thi dịch vụ: đọc cấu hình khối lượng (workload profile) và khởi chạy đúng số lượng tiến trình con để làm việc.

tSA — Temenos Service Agent. Là các "công nhân" do tSM sinh ra để thực sự chạy công việc theo kiến trúc đa luồng (multi-thread). Nhiều tSA chạy song song, mỗi agent nhặt một phần việc, cập nhật tiến độ và trạng thái vào các bản ghi hệ thống (như TSA.STATUS). Nhờ đa luồng, một khối lượng lớn (ví dụ hàng triệu tài khoản cần tính lãi) được chia nhỏ và xử lý đồng thời thay vì tuần tự. Một khuyến nghị vận hành kinh điển: không cấp quá 2 tSA cho mỗi CPU/processor, vì cấp quá nhiều sẽ khiến hệ thống tranh chấp tài nguyên và tụt hiệu năng thay vì nhanh hơn.

Cấu hình dịch vụ. Việc bật/tắt một dịch vụ được điều khiển qua bản ghi trong bảng TSA.SERVICE: đặt trường điều khiển (SERVICE.CONTROL) thành START hoặc AUTO. Đây là nơi vận hành viên khai báo dịch vụ nào chạy, chạy bao nhiêu agent, theo lịch nào.

Phantom. Trước khi có kiến trúc đa luồng (ra đời khoảng release R05), T24 dùng phantom — tiến trình nền đơn luồng, quản lý qua EB.PHANTOM, có thể chạy vòng lặp vô hạn cho tới khi bị dừng thủ công. Phantom vẫn còn tồn tại nhưng dịch vụ (tSA/tSM) là cách hiện đại, hiệu quả hơn để tận dụng nhiều CPU. Điểm khác biệt cốt lõi cần nhớ: phantom đơn luồng, service đa luồng.

jsh / jshell. Mọi thao tác quản trị ở tầng thấp — khởi động tSM, chạy lệnh biên dịch jBC, thao tác file jBASE — đều thực hiện trong phiên jsh (jBASE shell), giao diện dòng lệnh của môi trường jBASE. Đây là "cửa hậu" mà quản trị viên T24 sống trong đó.

Close of Business (COB)

Một trong những công việc nền quan trọng nhất là Close of Business (COB) — quy trình xử lý cuối ngày theo batch: đóng ngày làm việc, tính lãi, tạo bút toán tự động, chạy các kiểm tra và sinh báo cáo, rồi mở ngày làm việc kế tiếp. COB thường tận dụng chính kiến trúc đa luồng tSA/tSM để hoàn thành trong cửa sổ thời gian cho phép (thường về đêm). Vì tầm quan trọng và độ phức tạp của nó, COB được trình bày riêng ở bài Close of Business — xử lý cuối ngày; ở đây chỉ cần định vị nó như một khối tiêu thụ lớn của tầng dịch vụ.

Khả năng mở rộng và tính sẵn sàng cao (HA)

Vì là hệ thống lõi, T24 phải chạy gần như không gián đoạn và chịu tải tăng theo quy mô ngân hàng. Kiến trúc nhiều tầng cho phép mở rộng ngang:

• Nhiều application server: thêm các node chạy engine (đặc biệt thuận lợi trên TAFJ, khi engine chạy trong app server Java và có thể cluster). Một load balancer phân phối phiên/giao dịch của người dùng và kênh API đến nhiều node.
• Nhiều database server: tầng CSDL được đặt trên hạ tầng RDBMS có sẵn cơ chế HA của chính nó (cluster, replica), hoặc trên jBASE với các cơ chế nhân bản tương ứng.
• Mô hình sẵn sàng cao: thiết kế điển hình gồm các node dự phòng và một trung tâm dữ liệu dự phòng thảm họa (DR). Tùy hạ tầng, ngân hàng có thể vận hành theo hướng active-active (nhiều node cùng phục vụ) hoặc active-passive kết hợp DR. Ý tưởng chung: loại bỏ điểm chết đơn (single point of failure) ở mọi tầng.

Việc tách tầng trình bày, tầng logic và tầng dữ liệu chính là điều làm những mô hình mở rộng/HA này khả thi — mỗi tầng scale và phòng lỗi theo cách riêng của nó.

Kiến trúc bản mới: API-first và cloud

Định hướng hiện tại của Temenos (dưới thương hiệu Transact) dịch chuyển mạnh về API-first và đóng gói dịch vụ:

• Chức năng nghiệp vụ được phơi ra dưới dạng API (bên cạnh OFS truyền thống, có các lớp API/IRIS hiện đại) để hệ thống ngoài tích hợp qua giao thức chuẩn (REST/JSON), phục vụ open banking và hệ sinh thái fintech.
• Nền TAFJ làm bệ phóng để chạy trên cloud và trong container, tận dụng khả năng co giãn của hạ tầng đám mây.
• Xu hướng chia nhỏ dịch vụ, tách chức năng thành các gói triển khai độc lập hơn thay vì một khối monolith cấu hình cứng.

Đây là bức tranh dài hạn; nhiều ngân hàng vẫn đang ở giữa hành trình (còn TAFC, còn on-premise), nên trong thực tế bạn sẽ gặp đủ mọi trạng thái trung gian.

Use case thực tế

Tình huống 1 — Ngân hàng chọn jBASE files vs Oracle làm store. Một ngân hàng quy mô vừa mới triển khai T24 ưu tiên đơn giản và hiệu năng giao dịch online, chọn để dữ liệu trên jBASE files native: giao dịch nhanh, ít lớp trung gian, vận hành gọn. Nhưng khi đội phân tích muốn xây kho dữ liệu, họ vấp phải rào cản: không thể cắm công cụ BI vào jBASE, mọi thứ phải qua bước trích xuất và giải mã multivalue. Trong khi đó một ngân hàng lớn khác đặt dữ liệu trên Oracle qua jEDI: đội DBA dùng lại toàn bộ công cụ sao lưu, giám sát, HA sẵn có, và việc ETL sang warehouse thuận tiện hơn — đổi lại họ trả phí bản quyền Oracle và chấp nhận thêm một lớp ánh xạ. Cùng một T24, hai quyết định hạ tầng dẫn tới hai đời sống vận hành khác hẳn nhau.

Tình huống 2 — Lộ trình chuyển TAFC → TAFJ. Một ngân hàng chạy T24 trên TAFC hơn mười năm, gắn với máy chủ Unix cũ, muốn lên cloud. Họ khởi động dự án chuyển sang TAFJ: dịch lại code jBC sang nền Java, rà soát các đoạn local development có gọi API C/hệ điều hành (những chỗ dễ vỡ nhất), thiết lập T24 trong Java app server có cluster, chuyển kho dữ liệu sang RDBMS truy cập qua JDBC, và kiểm thử hồi quy toàn bộ nghiệp vụ. Kết quả sau khi ổn định: hệ thống co giãn trên cloud, đội hạ tầng làm việc bằng công cụ Java/JVM phổ biến thay vì phải nuôi kỹ năng jBASE tầng thấp đang ngày càng khan hiếm.

Ghi nhớ

• T24 là kiến trúc ba tầng logic: Presentation (Temenos Browser) — Application (engine chạy jBC) — Data (multivalue trên jBASE files hoặc RDBMS qua jEDI).
• jBC là INFO-BASIC/PICK BASIC; nó được biên dịch, không thông dịch. TAFC dịch sang C/native; TAFJ dịch sang lớp Java → bytecode chạy trên JVM/app server. TAFJ là hướng hiện đại (cloud, API-first).
• jEDI che giấu khác biệt store: cùng một tầng ứng dụng chạy được trên jBASE files hoặc Oracle/DB2/MSSQL. Nhưng dữ liệu luôn mang bản chất multivalue, kể cả khi nằm trong Oracle.
• Xử lý nền theo mô hình đa luồng: tSM điều phối, sinh nhiều tSA để chạy song song (khuyến nghị ≤ 2 tSA / CPU); cấu hình qua TSA.SERVICE. Phantom là tiến trình nền đơn luồng đời cũ. Quản trị qua jsh.
• COB là công việc batch cuối ngày lớn nhất, tiêu thụ tầng dịch vụ (chi tiết ở bài riêng).
• Mở rộng ngang bằng nhiều app server + database server, load balancer, mô hình active-active/DR để loại bỏ single point of failure.

Liên kết bài liên quan

• Mô hình dữ liệu multivalue của T24
• OFS — Open Financial Service
• Close of Business — xử lý cuối ngày

Nguồn tham khảo

• Temenos jBC — What is T24 / What is TAFC
• jBC / jBASE features (Temenos)
• jBC Programmer's Reference Guide (bản lưu trên GitHub)
• Temenos TAFC to TAFJ Conversion — Maveric Systems
• High Availability and Disaster Recovery for Temenos T24 (IBM Redpaper)