Bài 42 — Legacy Integration — SOAP, EDI, Mainframe

Mở đầu — vì sao bài này quan trọng

Nếu bạn làm Technical BA ở Việt Nam đủ lâu, sớm hay muộn bạn cũng sẽ chạm vào một sự thật khó chịu: phần lớn các hệ thống quan trọng nhất — core banking, hệ thống thuế, bảo hiểm xã hội, ERP của doanh nghiệp lớn, hệ thống của hãng hàng không — đều được xây từ 15, 20, thậm chí 30 năm trước. Chúng không nói "ngôn ngữ" REST/JSON hiện đại mà bạn quen thuộc. Chúng nói SOAP, EDI, và đôi khi là những giao thức chỉ chạy được trên mainframe.

Trong dự án thực tế, BA hiện đại thường rất giỏi vẽ REST API, viết OpenAPI spec đẹp đẽ, nhưng đến khi cần tích hợp với một hệ thống legacy thì lúng túng vì không hiểu WSDL là gì, không biết EDI segment đọc thế nào, không hình dung được vì sao mainframe lại "khó tính" đến vậy. Kết quả là spec viết ra thiếu thực tế, dự án trượt tiến độ vì những chi tiết tích hợp tưởng nhỏ.

Bài này trang bị cho bạn ba nhóm công nghệ legacy phổ biến nhất mà một Technical BA Việt Nam sẽ gặp: SOAP, EDI, và Mainframe. Mục tiêu không phải biến bạn thành lập trình viên SOAP, mà giúp bạn hiểu đủ sâu để viết spec đúng, hỏi đúng câu khi làm việc với vendor, và lường trước được rủi ro tích hợp.

Khái niệm cốt lõi

SOAP — giao thức XML-based còn sống khỏe trong enterprise

SOAP (Simple Object Access Protocol) là một giao thức trao đổi thông điệp dựa trên XML, chạy chủ yếu trên HTTP (nhưng cũng có thể chạy trên SMTP, JMS). Bản chất nó là RPC — Remote Procedure Call: bạn gọi một "hàm" ở hệ thống bên kia như thể gọi hàm trong code của mình, truyền tham số vào và nhận kết quả trả về.

Một thông điệp SOAP luôn có cấu trúc cố định gồm Envelope bao ngoài, bên trong có Header (chứa metadata như thông tin bảo mật) và Body (chứa nội dung nghiệp vụ thực sự):

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
  <soap:Header>
    <wsse:Security>...token bảo mật...</wsse:Security>
  </soap:Header>
  <soap:Body>
    <getAccountBalance>
      <accountNumber>0123456789</accountNumber>
    </getAccountBalance>
  </soap:Body>
</soap:Envelope>

Điểm mấu chốt khiến SOAP khác biệt với REST là WSDL (Web Services Description Language). WSDL là một file XML mô tả hợp đồng (contract) của service: có những operation nào, mỗi operation nhận tham số gì, trả về gì, kiểu dữ liệu ra sao, gọi tới endpoint nào. WSDL chính là "tài liệu API" tự động của thế giới SOAP — và quan trọng là nó strict typing: kiểu dữ liệu được định nghĩa chặt chẽ bằng XML Schema (XSD), sai một kiểu là service từ chối ngay.

Đặc điểm của SOAP cần ghi nhớ:

Verbose (rườm rà): một request đơn giản cũng tốn vài chục dòng XML, nặng hơn JSON nhiều lần.
Strict typing: hợp đồng chặt chẽ, ít chỗ cho sự mơ hồ. Đây vừa là điểm mạnh (an toàn) vừa là điểm yếu (khó thay đổi).
WS-Security: bộ tiêu chuẩn bảo mật cấp enterprise — chữ ký số, mã hóa từng phần message, token bảo mật. Đây là lý do banking và chính phủ vẫn ưa SOAP: nó hỗ trợ message-level security, không chỉ transport-level như HTTPS.
Stateful & có WS-* standards: WS-ReliableMessaging (đảm bảo gửi đúng một lần), WS-AtomicTransaction (giao dịch phân tán)... những thứ REST không có sẵn.

Vì sao SOAP vẫn phổ biến dù bị coi là "cũ"? Vì trong banking, bảo hiểm, chính phủ, viễn thông — nơi tính đúng đắn và bảo mật quan trọng hơn tốc độ phát triển — hợp đồng chặt chẽ và bảo mật mức message của SOAP là tài sản, không phải gánh nặng. Ở Việt Nam, NAPAS, nhiều cổng thanh toán liên ngân hàng, và các hệ thống tích hợp với Tổng cục Thuế vẫn dùng SOAP.

EDI — ngôn ngữ trao đổi dữ liệu giữa các doanh nghiệp

EDI (Electronic Data Interchange) ra đời từ những năm 1970, trước cả internet hiện đại. Nó là chuẩn để các doanh nghiệp trao đổi chứng từ kinh doanh — đơn hàng (PO), hóa đơn (Invoice), thông báo giao hàng (ASN) — theo định dạng máy đọc được, không cần con người gõ lại.

Hai bộ chuẩn EDI lớn nhất:

ANSI X12: phổ biến ở Bắc Mỹ. Mỗi loại chứng từ có một mã số, ví dụ 850 là Purchase Order, 810 là Invoice, 856 là Advance Ship Notice.
EDIFACT (UN/EDIFACT): chuẩn quốc tế, phổ biến ở châu Âu và châu Á. Ví dụ ORDERS, INVOIC, DESADV.

Một file EDI nhìn rất "khó nuốt" với người mới. Nó được tổ chức thành các segment (phân đoạn), mỗi segment là một dòng bắt đầu bằng mã định danh và kết thúc bằng dấu phân tách:

ISA00          00          ZZSENDERID ZZRECEIVERID*...
ST8500001~
BEG00SAPO12345*20260627~
N1STCONG TY ABC92VN001~
PO11100EA5.50*VPITEM-001~
CTT*1~
SE60001~

Mỗi segment (ISA, ST, BEG, N1, PO1...) có ý nghĩa cố định: ISA là phong bì trao đổi, BEG là thông tin đầu đơn hàng, PO1 là một dòng hàng (line item). Công việc của BA khi gặp EDI là mapping: ánh xạ từng trường trong hệ thống nội bộ (ví dụ "mã sản phẩm", "số lượng") sang đúng vị trí trong segment EDI, và ngược lại.

EDI thường được truyền qua VAN (Value Added Network) — một mạng trung gian chuyên dụng — hoặc qua AS2 (giao thức truyền file an toàn qua HTTP). Ở Việt Nam, EDI xuất hiện nhiều trong logistics, bán lẻ (nhà cung cấp gửi PO/Invoice cho các chuỗi siêu thị), hải quan, và đặc biệt là khi doanh nghiệp Việt làm hàng xuất khẩu cho các đối tác lớn như Walmart, Amazon — họ bắt buộc nhà cung cấp tuân thủ EDI.

Mainframe — "trái tim" thầm lặng của các hệ thống lớn

Mainframe là những máy chủ cỡ lớn (thường là IBM Z series) chạy hệ điều hành như z/OS, xử lý khối lượng giao dịch khổng lồ với độ tin cậy gần như tuyệt đối. Nhiều core banking, hệ thống thẻ, hệ thống của hãng bảo hiểm và hàng không vẫn chạy trên mainframe, viết bằng COBOL hoặc PL/I, dữ liệu lưu trong VSAM hoặc DB2, giao dịch xử lý qua CICS hoặc IMS.

BA cần hiểu vài điểm cốt lõi về mainframe khi tích hợp:

Batch vs Online: mainframe thường chạy theo lô (batch) vào cuối ngày — ví dụ tính lãi, đối soát, kết sổ. Trong giờ batch (thường ban đêm), hệ thống có thể "đóng cửa" với các giao dịch online. Đây là ràng buộc cực lớn khi thiết kế tích hợp.
EBCDIC: mainframe IBM dùng bảng mã EBCDIC chứ không phải ASCII/UTF-8. Khi trao đổi file, phải có bước convert mã, nếu không dữ liệu sẽ thành ký tự rác.
Fixed-length records: dữ liệu mainframe thường ở dạng bản ghi cố định độ dài (mỗi trường chiếm số byte cố định, không có dấu phân tách), gọi là copybook trong COBOL. BA phải đọc được copybook để biết trường nào ở byte nào.
Cách tích hợp: hoặc qua file (FTP/SFTP file batch), hoặc qua middleware như IBM MQ (message queue), hoặc qua một lớp "wrapper" expose CICS transaction ra thành web service.

Tình huống thực tế

Tình huống 1 — Ngân hàng VN tích hợp cổng thanh toán qua SOAP

Một ngân hàng thương mại cổ phần tầm trung ở TP.HCM (tạm gọi là Bank X) cần kết nối hệ thống Internet Banking mới (xây bằng microservices, REST) với hệ thống thanh toán liên ngân hàng qua NAPAS. NAPAS cung cấp giao diện SOAP với WS-Security: mỗi message phải được ký số bằng chữ ký số của ngân hàng, đính kèm trong SOAP Header.

Bạn — Technical BA của Bank X — nhận spec WSDL từ NAPAS dày hơn 200 trang. Đội dev REST của bạn hoảng vì chưa từng làm SOAP. Bài học rút ra: bạn không thể bắt toàn bộ hệ thống mới nói SOAP. Giải pháp đúng là thiết kế một adapter/integration layer — một service trung gian nhận REST từ nội bộ, dịch sang SOAP có WS-Security để gọi NAPAS, rồi dịch ngược kết quả về JSON. Trong spec, bạn phải mô tả rõ: WSDL operation nào dùng cho query số dư, operation nào cho chuyển tiền, mã lỗi SOAP Fault ánh xạ sang mã lỗi nội bộ thế nào, và yêu cầu chứng thư số (certificate) ai cấp, hết hạn khi nào. Chính chi tiết "certificate hết hạn" mà nhiều dự án bỏ quên đã gây sự cố downtime giữa đêm khi chứng thư hết hạn không ai gia hạn.

Tình huống 2 — Nhà cung cấp Việt làm hàng cho chuỗi bán lẻ qua EDI

Công ty TNHH sản xuất đồ gỗ Phú Tài (giả định) ký được hợp đồng cung cấp cho một chuỗi siêu thị lớn ở Singapore. Điều kiện bắt buộc: mọi đơn hàng, xác nhận giao hàng và hóa đơn phải trao đổi qua EDIFACT (ORDERS, DESADV, INVOIC) truyền qua AS2. Hệ thống ERP của Phú Tài chỉ xuất được file Excel.

Là BA của dự án, bạn phải làm EDI mapping document: ví dụ trường "Mã sản phẩm nội bộ" của Phú Tài ánh xạ sang segment LIN của EDIFACT ORDERS, "Số lượng đặt" sang QTY+21, "Ngày giao yêu cầu" sang DTM+2. Một chi tiết tưởng nhỏ nhưng suýt làm hỏng dự án: đối tác Singapore dùng đơn vị đo "thùng" còn Phú Tài quản theo "cái", và trong EDI không có chỗ cho sự mơ hồ — phải thống nhất bảng quy đổi đơn vị ngay trong mapping. Bài học: với EDI, 80% công việc của BA là mapping và xử lý sai khác dữ liệu chủ (master data) giữa hai bên, không phải kỹ thuật truyền file. Ngoài ra, mỗi đối tác EDI có một "biến thể" (variant) riêng dù cùng chuẩn EDIFACT, nên đừng giả định "đã làm EDI một lần là làm được mọi nơi".

Tình huống 3 — Công ty bảo hiểm tích hợp với core mainframe COBOL

Một công ty bảo hiểm nhân thọ tại Hà Nội có hệ thống core hợp đồng chạy trên mainframe IBM, viết bằng COBOL, dữ liệu trong DB2, từ những năm 2000. Họ muốn xây app mobile cho khách hàng tra cứu hợp đồng real-time. Vấn đề: mainframe chạy batch kết sổ từ 23h đến 3h sáng, trong khung giờ này dữ liệu hợp đồng bị khóa.

Bạn là Technical BA. Khi khảo sát, bạn phát hiện đội mainframe cung cấp dữ liệu qua file fixed-length theo copybook, mã hóa EBCDIC. Bạn viết spec yêu cầu một quy trình: ban ngày, app gọi qua một CICS transaction được expose thành web service để tra cứu online; nhưng dữ liệu danh mục lớn (ví dụ bảng phí) thì lấy qua file batch ban đêm rồi convert EBCDIC sang UTF-8, parse theo copybook và nạp vào một read-replica để app đọc. Trong giờ batch 23h–3h, app hiển thị thông báo "đang đồng bộ, dữ liệu cập nhật đến cuối ngày hôm trước". Bài học: khi tích hợp mainframe, BA phải thiết kế xoay quanh lịch batch và đặc thù dữ liệu (EBCDIC, fixed-length), không thể giả định "real-time mọi lúc". Việc lường trước khung giờ batch giúp dự án tránh được kỳ vọng sai từ phía business.

Hướng dẫn từng bước

Khi bạn được giao một dự án tích hợp với hệ thống legacy, hãy đi theo trình tự sau:

Xác định loại legacy và giao thức. Hỏi vendor/đội vận hành: hệ thống expose interface gì? SOAP (có WSDL không?), EDI (chuẩn X12 hay EDIFACT, qua VAN hay AS2?), hay mainframe (file batch, MQ, hay CICS web service?). Đây là câu hỏi đầu tiên quyết định toàn bộ thiết kế.

Lấy và đọc hợp đồng (contract). Với SOAP, xin file WSDL và XSD. Với EDI, xin implementation guide của đối tác (mỗi đối tác có guide riêng). Với mainframe, xin copybook và lịch batch.

Lập bảng mapping dữ liệu. Ánh xạ từng trường nghiệp vụ nội bộ sang trường/segment/byte tương ứng của hệ thống legacy. Ghi rõ kiểu dữ liệu, độ dài, đơn vị, định dạng ngày tháng, và quy tắc quy đổi master data.

Thiết kế lớp trung gian (adapter/integration layer). Đừng ép hệ thống hiện đại nói trực tiếp ngôn ngữ legacy. Tách một lớp adapter chuyên dịch giao thức và xử lý bảo mật (WS-Security, certificate, mã hóa EBCDIC...).

Đặc tả xử lý lỗi và đối soát. SOAP Fault, EDI acknowledgment (997/CONTRL — báo nhận file), file batch thất bại... Mỗi cơ chế cần có quy trình retry, alert và đối soát rõ ràng trong spec.

Ràng buộc vận hành. Ghi rõ: khung giờ batch, hạn certificate, hạn token, SLA của VAN, ai chịu trách nhiệm gia hạn. Đây là phần BA hay quên nhất nhưng gây sự cố nhiều nhất.

Lỗi thường gặp & mẹo

Lỗi 1 — Coi SOAP như REST. Nhiều BA viết spec SOAP theo tư duy REST (resource, verb). Sai. SOAP là RPC theo operation định nghĩa trong WSDL — hãy mô tả theo "operation gọi gì, nhận gì, trả gì", không phải "GET/POST resource nào".

Lỗi 2 — Bỏ quên message-level security. HTTPS chỉ bảo vệ đường truyền. Banking thường yêu cầu thêm WS-Security (ký số, mã hóa từng phần). Nếu spec không nhắc đến certificate và chữ ký, vendor sẽ reject ở vòng đầu tiên.

Lỗi 3 — Giả định EDI "một cỡ vừa tất cả". Cùng là EDIFACT ORDERS nhưng mỗi đối tác có variant riêng. Luôn xin implementation guide cụ thể của chính đối tác đó, đừng dùng lại mapping của dự án trước.

Lỗi 4 — Quên EBCDIC và fixed-length với mainframe. Nhận file mainframe mà không convert mã hóa và không có copybook để parse → dữ liệu rác. Luôn hỏi: file mã hóa gì, có copybook không.

Lỗi 5 — Bỏ qua lịch batch. Hứa với business "real-time 24/7" trong khi mainframe đóng cửa ban đêm để kết sổ. Luôn khảo sát khung giờ batch trước khi cam kết SLA.

Mẹo: Với hệ thống legacy, hãy luôn dành một mục riêng trong spec tên là "Ràng buộc tích hợp & vận hành" (integration constraints) — nơi ghi certificate, batch window, ack mechanism, master data mapping. Mục này thường cứu dự án khỏi những sự cố "không ai ngờ tới".

Mẹo: Học đọc một file WSDL và một file EDI ở mức nhận diện cấu trúc (envelope, operation / segment) là đủ để bạn nói chuyện ngang hàng với dev và vendor — bạn không cần tự code chúng.

Bài tập thực hành

Đọc WSDL. Tìm một file WSDL công khai trên mạng (ví dụ các web service mẫu của W3C hoặc dịch vụ tỷ giá). Xác định: có bao nhiêu operation, mỗi operation nhận input gì, trả output gì, endpoint ở đâu. Viết lại bằng tiếng Việt như thể giải thích cho một dev REST chưa từng biết SOAP.

Mapping EDI. Giả định bạn là BA của một nhà cung cấp gửi Purchase Order (X12 850) cho siêu thị. Hệ thống nội bộ có các trường: Mã đơn hàng, Ngày đặt, Mã NCC, danh sách dòng hàng (Mã SP, Số lượng, Đơn giá). Hãy lập bảng mapping 3 cột: Trường nội bộ / Segment EDI / Ghi chú quy tắc. (Gợi ý: BEG cho đầu đơn, N1 cho bên gửi/nhận, PO1 cho dòng hàng.)

Thiết kế tích hợp mainframe. Cho tình huống: app mobile cần tra cứu số dư hợp đồng từ core mainframe chạy batch 23h–3h. Hãy viết một đoạn spec ngắn (khoảng 200 từ) mô tả: dữ liệu lấy online hay batch, xử lý EBCDIC/copybook ra sao, app hiển thị gì trong giờ batch, và 2 rủi ro vận hành cần ghi chú.

Tóm tắt

SOAP là giao thức XML-based RPC chạy trên HTTP, định nghĩa hợp đồng chặt chẽ bằng WSDL + XSD, hỗ trợ WS-Security cho bảo mật mức message. Vẫn phổ biến trong banking và chính phủ vì tính đúng đắn và bảo mật cao. BA mô tả theo operation, không theo tư duy REST.
EDI là chuẩn trao đổi chứng từ kinh doanh giữa doanh nghiệp (X12 ở Bắc Mỹ, EDIFACT quốc tế), tổ chức theo segment. Công việc chính của BA là mapping và xử lý sai khác master data; mỗi đối tác có variant riêng.
Mainframe là core của nhiều hệ thống lớn, viết COBOL, dữ liệu EBCDIC/fixed-length, chạy theo lịch batch. BA phải thiết kế xoay quanh batch window, mã hóa và copybook.
Nguyên tắc xuyên suốt: luôn tách một lớp adapter giữa hệ thống hiện đại và legacy, và luôn có mục "ràng buộc tích hợp & vận hành" (certificate, batch, ack, master data) trong spec — đó là nơi cứu dự án khỏi sự cố ngầm.