T24 4 — VERSION, ENQUIRY & lập trình jBC

Có một câu hỏi thực tế mà mọi đội triển khai core banking đều phải trả lời: khi ngân hàng cần một màn hình mở tài khoản rút gọn cho teller, một báo cáo liệt kê tài khoản theo chi nhánh, hay một quy tắc kiểm tra riêng cho nghiệp vụ trong nước — có phải sửa mã nguồn của core không? Với Temenos T24 (nay là Temenos Transact), câu trả lời phần lớn là không. Bài này đi sâu vào ba công cụ tùy biến quan trọng nhất: VERSION để thiết kế màn hình nhập liệu, ENQUIRY để làm truy vấn/báo cáo, và ROUTINE viết bằng ngôn ngữ jBC khi cấu hình chưa đủ — cùng hai cấu phần bổ trợ là Local Reference Fields và Design Studio.

Các bài trước trong series đã trình bày mô hình dữ liệu của T24 (application, file, template, multi-value/sub-value), Arrangement Architecture (AA), và OFS — giao thức message để đưa giao dịch vào lõi. Bài này giả định người đọc đã nắm các khái niệm đó; ở đây ta tập trung vào lớp cấu hình và phát triển đặt phía trên chúng.

Triết lý: parameter-driven, hạn chế đụng lõi

T24 được thiết kế theo tư tưởng parameter-driven (hướng tham số). Phần lớn hành vi nghiệp vụ không nằm cứng trong mã nguồn mà được điều khiển bởi các bản ghi cấu hình — các parameter table — mà ngân hàng có thể chỉnh sửa qua chính giao diện nhập liệu của hệ thống. Muốn thay đổi cách hạch toán, quy tắc lãi, danh mục sản phẩm, quy tắc kiểm tra dữ liệu, bố cục màn hình... phần lớn là đổi bản ghi tham số, không phải viết lại chương trình.

Hệ quả của triết lý này rất quan trọng về mặt vận hành lâu dài. Temenos phát hành các R-release (ví dụ R21, R22...) định kỳ. Nếu ngân hàng nhét logic tùy biến trực tiếp vào mã lõi, mỗi lần nâng cấp sẽ là một cuộc "trộn code" đau đớn và rủi ro. Ngược lại, khi tùy biến nằm ở tầng cấu hình (VERSION, ENQUIRY, parameter table) và ở các routine gắn vào các điểm mở rộng (hook) được định nghĩa sẵn, thì việc nâng cấp R-release an toàn hơn nhiều: lõi được thay mới, còn lớp cấu hình và các routine đã đăng ký tiếp tục được "cắm" vào.

Nói cách khác, có một quang phổ các mức tùy biến, và người triển khai được khuyến khích chọn mức thấp nhất khả dĩ:

1. Cấu hình thuần — chỉnh parameter table, tạo VERSION/ENQUIRY. Không viết dòng code nào.
2. Local Reference Fields — thêm trường tùy biến mà không đổi cấu trúc chuẩn.
3. Routine (jBC) — khi cấu hình không diễn đạt được logic, viết subroutine gắn vào các hook của vòng đời bản ghi.

Chỉ khi cả ba mức trên không đủ mới bàn tới sửa lõi — và điều đó bị xem là ngoại lệ, phải tránh.

VERSION: bản thiết kế màn hình nhập liệu

VERSION là một application chuẩn của T24 dùng để tạo ra các màn hình nhập liệu tùy biến cho một application khác. Bản thân application (ví dụ ACCOUNT, CUSTOMER, FUNDS.TRANSFER) đã có một cấu trúc trường chuẩn và một màn hình mặc định; nhưng màn hình mặc định thường hiển thị tất cả các trường, không tối ưu cho từng nghiệp vụ. VERSION cho phép "gói" lại một trải nghiệm nhập liệu cụ thể.

Tên của một VERSION theo dạng APPLICATION,NAME, ví dụ ACCOUNT,INPUT, CUSTOMER,RETAIL, FUNDS.TRANSFER,TELLER. Phần trước dấu phẩy chỉ application mục tiêu, phần sau là tên phân biệt của phiên bản màn hình. Một application có thể có nhiều VERSION phục vụ các nghiệp vụ khác nhau: một VERSION mở tài khoản đầy đủ cho cán bộ tín dụng, một VERSION rút gọn cho teller, một VERSION chỉ để sửa hạn mức...

Trong một VERSION, người cấu hình có thể khai báo:

• Chọn trường và thứ tự hiển thị — chỉ đưa ra các trường cần thiết, sắp xếp lại theo luồng nghiệp vụ, gom nhóm bằng tab/screen.
• Giá trị mặc định (default) — điền sẵn giá trị cho một trường khi mở màn hình.
• Validation — quy tắc kiểm tra ở mức trường (bắt buộc, khoảng giá trị, danh sách hợp lệ).
• Enrichment — hiển thị thông tin diễn giải bên cạnh mã (ví dụ nhập mã tiền tệ USD thì hiện "US Dollar").
• Gắn routine — cắm subroutine jBC vào các điểm trong vòng đời (xem phần ROUTINE bên dưới).
• Phân quyền và maker-checker — kiểm soát ai được dùng VERSION nào, và giao dịch qua VERSION đó có cần phê duyệt hay không.

Về mặt vòng đời, một bản ghi nhập qua VERSION đi qua các giai đoạn: người dùng (maker) nhập → hệ thống chạy validation ở mức trường và mức bản ghi → giao dịch được lưu ở trạng thái unauthorised (chưa duyệt) → một người khác (checker) authorise → hệ thống chạy các authorisation routine rồi commit bản ghi vào file LIVE. Mô hình maker-checker này là mặc định cho hầu hết application quan trọng và là nền tảng kiểm soát nội bộ của T24.

Ví dụ một định nghĩa VERSION (rút gọn)

VERSION.NAME.......  ACCOUNT,TELLER.OPEN
APPLICATION........  ACCOUNT
FUNCTION...........  I           ; I = Input
NO.OF.AUTH.........  1           ; cần 1 checker duyệt (maker-checker)

; --- Danh sách trường hiển thị, đúng thứ tự ---
FIELD.NO  1   CUSTOMER          ; bắt buộc
FIELD.NO  2   CATEGORY          DEFAULT = 6001   ; mặc định "current account"
FIELD.NO  3   CURRENCY          DEFAULT = VND
FIELD.NO  4   ACCOUNT.TITLE
FIELD.NO  5   LOCAL.REF:L.BRANCH.CODE    ; một Local Reference Field

; --- Enrichment: hiện tên khách khi nhập mã CUSTOMER ---
ENRICHMENT  CUSTOMER > @CUSTOMER.NAME

; --- Routine gắn theo vòng đời ---
VALIDATION.RTN......  V.CHECK.BRANCH.LIMIT   ; kiểm tra khi input
AUTH.RTN............  A.NOTIFY.BRANCH        ; chạy khi authorise

(minh hoạ, không chạy trong sandbox — cú pháp thực tế phụ thuộc phiên bản T24 và có thể khai báo qua Design Studio)

Điểm cần nhớ: VERSION không sao chép hay đổi cấu trúc của ACCOUNT; nó chỉ là một lăng kính nhìn vào application đó. Cùng một file ACCOUNT có thể được nhập qua hàng chục VERSION khác nhau.

ENQUIRY: truy vấn và báo cáo khai báo

ENQUIRY là công cụ báo cáo/truy vấn khai báo (declarative) của T24. Thay vì viết chương trình đọc file và định dạng kết quả, người cấu hình khai báo muốn gì và T24 lo phần làm thế nào. Một định nghĩa ENQUIRY bao gồm:

• File nguồn — application/file để đọc dữ liệu (ví dụ ACCOUNT, CUSTOMER, một concat file, hoặc một file lịch sử).
• Field hiển thị — các trường đưa ra cột kết quả, kèm nhãn, độ rộng, định dạng.
• Selection criteria — điều kiện lọc bản ghi (ví dụ CO.CODE = 'BR001'), có thể để người dùng nhập tại thời điểm chạy.
• Sort — thứ tự sắp xếp kết quả.
• Conversion / build routine — khi cần tính toán một cột không có sẵn trong bản ghi, ENQUIRY có thể gọi một subroutine jBC để dựng dữ liệu (build routine) hoặc chuyển đổi hiển thị (conversion routine).

Kết quả ENQUIRY xem trực tiếp trên Browser (giao diện web của T24), có thể drill-down (bấm vào một dòng để mở bản ghi chi tiết hoặc một enquiry khác), và có thể export ra file. Có các dạng enquiry khác nhau tùy nguồn dữ liệu: enquiry trên file LIVE (dữ liệu hiện hành), enquiry trên history (dữ liệu lịch sử của bản ghi), và các enquiry lồng nhau để drill-down.

Một điểm rất quan trọng với đội tích hợp và đội dữ liệu: enquiry có thể chạy không cần giao diện người dùng thông qua động từ ENQUIRY.SELECT gửi qua OFS. Nghĩa là một hệ thống bên ngoài (hoặc một job) có thể "gọi" một enquiry đã định nghĩa sẵn, truyền tham số lọc, và nhận về kết quả — đây là cách phổ biến để lấy dữ liệu ra khỏi T24 một cách có kiểm soát mà không cần đọc thẳng file lõi. (Cơ chế OFS đã được trình bày ở bài OFS trong series này.)

ROUTINE / API: lập trình jBC gắn vào vòng đời

Khi cấu hình khai báo không diễn đạt được logic (ví dụ: tính một hạn mức động, gọi hệ thống ngoài, áp dụng quy tắc nghiệp vụ phức tạp), ta viết routine bằng jBC — ngôn ngữ BASIC của Temenos (một biến thể MultiValue/Pick BASIC, kế thừa dòng jBASE). Routine là các subroutine được biên dịch và cắm vào các điểm mở rộng đã định nghĩa sẵn trong vòng đời bản ghi:

• Record routine — chạy khi bản ghi được nạp/khởi tạo, dùng để tính giá trị mặc định động, điền sẵn trường.
• Validation routine — chạy khi input, để kiểm tra dữ liệu maker nhập và trả lỗi nếu không hợp lệ.
• Authorisation routine — chạy tại bước checker authorise, dùng cho hành động phụ khi duyệt (thông báo, cập nhật liên đới).
• Input routine — chạy ở giai đoạn input, thường để biến đổi/bổ sung dữ liệu trước khi lưu.
• Build / conversion routine cho ENQUIRY — dựng cột dữ liệu tính toán hoặc chuyển đổi hiển thị cho kết quả truy vấn.

Ngoài các routine gắn vào application, jBC còn dùng để viết các job batch (COB — Close Of Business), các dịch vụ nền, và các API dùng lại.

Chuẩn lập trình jBC

Có một bộ quy ước tối thiểu mà mọi routine T24 phải theo:

• Chương trình là file BASIC (thường đuôi .b), được biên dịch (compile) và cataloguer, rồi đăng ký một bản ghi trong PGM.FILE (và EB.API với các API dùng chung) để T24 biết và gọi được.
• Mọi routine phải chèn $INSERT I_COMMON và $INSERT I_EQUATE ở đầu chương trình. I_COMMON khai báo khối biến toàn cục dùng chung cho toàn hệ thống (thông tin phiên làm việc, ngày hệ thống, người dùng...), còn I_EQUATE định nghĩa các hằng số/token chuẩn.
• Truy cập dữ liệu qua các API lõi thay vì thao tác file trực tiếp: F.READ/F.WRITE để đọc/ghi bản ghi, CACHE.READ để đọc các bản ghi tham số ít thay đổi (được cache để tối ưu), cùng nhóm hàm EB.* cho các tác vụ chung. Việc mở file (OPF) cũng theo quy ước của T24.
• Không hardcode giá trị nghiệp vụ trong code. Ngưỡng, danh mục, mã sản phẩm... phải đọc từ bảng tham số để giữ đúng tinh thần parameter-driven — thay đổi nghiệp vụ chỉ cần sửa bản ghi tham số, không phải sửa và biên dịch lại code.

Ví dụ một subroutine jBC (rút gọn)

    SUBROUTINE V.CHECK.BRANCH.LIMIT
*-----------------------------------------------------------------
* Validation routine gắn vào VERSION ACCOUNT,TELLER.OPEN.
* Kiểm tra: teller chỉ được mở tài khoản trong hạn mức của chi nhánh.
* Ngưỡng KHÔNG hardcode -> đọc từ bảng tham số.
*-----------------------------------------------------------------
    $INSERT I_COMMON            ;* khối biến toàn cục (COMI, R.NEW, ...)
    $INSERT I_EQUATE            ;* hằng số/token chuẩn

    GOSUB READ.PARAM
    GOSUB VALIDATE
    RETURN

READ.PARAM:
    Y.BRANCH = R.NEW(AC.CO.CODE)                 ;* chi nhánh trên bản ghi
    CALL CACHE.READ('F.BRANCH.LIMIT', Y.BRANCH, R.LIMIT, ERR)
    Y.MAX = R.LIMIT<1>                            ;* hạn mức từ tham số
    RETURN

VALIDATE:
    IF R.NEW(AC.OPENING.BAL) > Y.MAX THEN
        AF = AC.OPENING.BAL                      ;* trường bị lỗi
        ETEXT = 'Vuot han muc chi nhanh'         ;* T24 hiển thị lỗi
        CALL STORE.END.ERROR                     ;* chặn commit
    END
    RETURN

END

(minh hoạ, không chạy trong sandbox — tên trường/hằng số phụ thuộc template và phiên bản T24)

Khi maker bấm commit trên VERSION, T24 tự gọi V.CHECK.BRANCH.LIMIT; nếu routine đặt ETEXT và gọi STORE.END.ERROR, giao dịch bị chặn và maker thấy lỗi ngay tại trường. Không có dòng SQL, không đụng lõi — chỉ một routine đăng ký trong PGM.FILE và một dòng khai báo trong VERSION.

Local Reference Fields (LRF)

Cấu trúc trường chuẩn của mỗi application do Temenos định nghĩa và không nên đổi (vì sẽ vỡ khi nâng cấp). Nhưng ngân hàng luôn có nhu cầu lưu thêm dữ liệu địa phương — ví dụ mã ngành nghề theo quy định trong nước, số CIF cũ khi di trú hệ thống, cờ nghiệp vụ nội bộ. Local Reference Fields giải quyết đúng việc này: thêm trường tùy biến vào một application mà không thay đổi cấu trúc chuẩn của nó.

Cơ chế: các trường tùy biến được khai báo trong LOCAL.TABLE (định nghĩa loại, độ dài, quy tắc kiểm tra của từng LRF) rồi gắn vào application mục tiêu thông qua PGM.FILE. Dữ liệu LRF được lưu trong một trường "local reference" chung của bản ghi (dạng đa giá trị), nên cấu trúc chuẩn giữ nguyên. Trong VERSION, ta tham chiếu LRF bằng cú pháp LOCAL.REF:tên.trường để đưa nó lên màn hình như một trường bình thường. Routine cũng đọc/ghi được LRF qua các API lõi. Đây là công cụ chủ lực cho các yêu cầu "thêm một trường" mà không cần can thiệp sâu.

Design Studio: IDE phát triển hiện đại

Cách phát triển "classic" là thao tác trực tiếp trên các bản ghi cấu hình qua giao diện T24 và biên dịch code từ dòng lệnh. Temenos Design Studio là một IDE trên nền Eclipse thay thế/bổ sung cách làm đó: nó cung cấp trình soạn thảo trực quan cho VERSION, ENQUIRY, và các thành phần khác; hỗ trợ viết, biên dịch và gỡ lỗi jBC với gợi ý cú pháp; và quản lý việc đóng gói triển khai (package deployment) để đưa một tập hợp thay đổi (VERSION + ENQUIRY + routine + tham số) từ môi trường phát triển sang môi trường khác một cách nhất quán. Điều này giúp chuẩn hóa quy trình, giảm sai sót thủ công và quản lý phiên bản cấu hình tốt hơn.

Vòng đời một giao dịch qua VERSION

Sơ đồ nhấn mạnh: routine không phải là "code chạy tự do" mà được gọi tại các điểm xác định trong vòng đời (validation khi input, authorisation khi duyệt), và maker-checker là hàng rào mặc định giữa "nhập" và "hiệu lực".

Use case thực tế

1. ENQUIRY liệt kê tài khoản theo chi nhánh. Đội nghiệp vụ cần một báo cáo: tất cả tài khoản đang mở tại một chi nhánh, kèm tên khách, số dư, loại tài khoản. Không cần lập trình: tạo một ENQUIRY với file nguồn là ACCOUNT, selection criteria CO.CODE (để người dùng nhập chi nhánh khi chạy), các cột CUSTOMER, ACCOUNT.TITLE, WORKING.BALANCE, CATEGORY, sort theo CATEGORY. Muốn cột "Tên khách" đầy đủ thì thêm một conversion routine nhỏ đọc CUSTOMER để lấy tên. Người dùng chạy trên Browser và export; hệ thống ngoài có thể chạy cùng enquiry đó qua ENQUIRY.SELECT trên OFS để lấy dữ liệu định kỳ.

2. VERSION mở tài khoản rút gọn cho teller. Màn hình ACCOUNT mặc định có hàng chục trường mà teller không cần và dễ nhập sai. Ta tạo VERSION ACCOUNT,TELLER.OPEN chỉ hiển thị 5-6 trường thiết yếu, mặc định CATEGORY = current account và CURRENCY = VND, enrichment tên khách khi nhập mã, gắn validation routine kiểm tra hạn mức chi nhánh (như ví dụ jBC ở trên), và đặt NO.OF.AUTH = 1 để bắt buộc một checker duyệt. Teller mở tài khoản nhanh, ít lỗi, vẫn nằm trong kiểm soát nội bộ — tất cả bằng cấu hình cộng một routine ngắn.

Trải nghiệm dev thực tế

• Maker-checker cho cả tham số. Không chỉ giao dịch nghiệp vụ, mà việc đổi bản ghi cấu hình/tham số cũng đi qua maker-checker: một người sửa, một người duyệt. Điều này biến "đổi cấu hình" thành một thay đổi có kiểm soát và có dấu vết.
• Test trong môi trường tách biệt. Thay đổi được thử ở môi trường mô hình (Model Bank / MB) và UAT trước khi lên production. Một package deployment thường đi qua chuỗi các môi trường này.
• Versioning cấu hình. Vì tùy biến nằm ở tầng cấu hình + routine đăng ký, ta có thể quản lý phiên bản chúng (qua Design Studio package hoặc công cụ SCM), giúp tái tạo và roll-back một tập thay đổi thay vì sửa lẻ tẻ trên production.

Ghi nhớ

• T24 parameter-driven: ưu tiên cấu hình trước, code sau; chọn mức tùy biến thấp nhất khả dĩ để nâng cấp R-release an toàn.
• VERSION = bản thiết kế màn hình nhập liệu cho một application (dạng APP,NAME): chọn/sắp trường, default, validation, enrichment, gắn routine, phân quyền. Nhiều VERSION cho cùng một application.
• ENQUIRY = truy vấn/báo cáo khai báo: file nguồn + field + selection + sort + (build/conversion routine). Xem trên Browser, drill-down, export; chạy được qua ENQUIRY.SELECT trên OFS; có enquiry trên LIVE và history.
• ROUTINE (jBC) khi cấu hình không đủ: record / validation / authorisation / input / build-conversion. Chuẩn: $INSERT I_COMMON, $INSERT I_EQUATE, dùng F.READ/CACHE.READ/nhóm EB.*, đăng ký PGM.FILE/EB.API, không hardcode — đọc bảng tham số.
• Local Reference Fields (LOCAL.TABLE + PGM.FILE): thêm trường địa phương mà không đổi cấu trúc chuẩn.
• Design Studio (Eclipse): IDE hiện đại để phát triển và đóng gói triển khai (package deployment).
• Mọi thay đổi đi qua maker-checker, test ở MB/UAT, và quản lý versioning cấu hình.

Liên kết trong series

• OFS — gọi VERSION và ENQUIRY từ bên ngoài (message OFS, ENQUIRY.SELECT).
• Mô hình dữ liệu T24 — application, file, template, multi-value/sub-value; nền của VERSION và LRF.
• Arrangement Architecture (AA) — mô hình sản phẩm hiện đại; VERSION/ENQUIRY/routine áp dụng cả cho các application của AA.

Nguồn tham khảo kỹ thuật:

• TEMENOS T24 Programming Standards
• TEMENOS T24 Subroutine Guide
• VERSION Routines (Temenos T24)
• jBC — Temenos và What is T24
• jBC Programmer's Reference Guide