Mở đầu — vì sao bài này quan trọng
Có một sự thật mà nhiều bạn BA trẻ hay bỏ qua: thế giới công nghệ không "thay thế" công nghệ cũ, nó chỉ "chồng lớp" lên thôi. Bạn đọc về JSON, về REST API hiện đại, và nghĩ rằng XML đã chết. Nhưng rồi đến ngày bạn ngồi họp với một ngân hàng, một công ty bảo hiểm, hay một cơ quan nhà nước ở Việt Nam, và đối tác đưa cho bạn một tài liệu tích hợp dày 80 trang — toàn bộ payload là XML. Lúc đó nếu bạn ú ớ, uy tín của bạn trước mặt đội kỹ thuật và khách hàng sẽ rớt thê thảm.
XML (eXtensible Markup Language) là "tiền bối" của JSON. Nó ra đời cuối những năm 1990 và thống trị thế giới trao đổi dữ liệu suốt gần hai thập kỷ. Những hệ thống được xây trong giai đoạn đó — core banking, hệ thống thuế, hải quan, bảo hiểm xã hội, các chuẩn thanh toán liên ngân hàng — phần lớn vẫn đang chạy và vẫn nói "ngôn ngữ XML". Người ta gọi chúng là legacy systems (hệ thống cũ/kế thừa), không phải vì chúng kém, mà vì chúng quá quan trọng và quá rủi ro để viết lại.
Là một BA, bạn không cần biết viết code parse XML. Nhưng bạn bắt buộc phải đọc hiểu được một tài liệu XML, hiểu cấu trúc của nó, biết nó khác JSON ở chỗ nào, và đặc biệt là biết đặt câu hỏi đúng khi làm việc với các hệ thống tích hợp kiểu cũ. Bài này sẽ trang bị cho bạn đúng những thứ đó — không hơn, không kém.
Khái niệm cốt lõi
XML là gì?
XML là một định dạng đánh dấu (markup) dùng để mô tả dữ liệu có cấu trúc bằng các thẻ (tag) do chính người dùng tự đặt tên. Chữ "eXtensible" (có thể mở rộng) chính là tinh thần của nó: không có bộ thẻ cố định như HTML, bạn tự định nghĩa thẻ phù hợp với nghiệp vụ của mình.
Hãy nhìn một ví dụ đơn giản — thông tin một khách hàng:
<KhachHang>
<MaKH>KH00125</MaKH>
<HoTen>Nguyễn Văn An</HoTen>
<SoDienThoai>0901234567</SoDienThoai>
<DiaChi>
<SoNha>27</SoNha>
<Duong>Lê Lợi</Duong>
<Quan>Quận 1</Quan>
<ThanhPho>TP. Hồ Chí Minh</ThanhPho>
</DiaChi>
</KhachHang>
Cùng dữ liệu đó, nếu viết bằng JSON sẽ là:
{
"MaKH": "KH00125",
"HoTen": "Nguyễn Văn An",
"SoDienThoai": "0901234567",
"DiaChi": {
"SoNha": "27",
"Duong": "Lê Lợi",
"Quan": "Quận 1",
"ThanhPho": "TP. Hồ Chí Minh"
}
}
Bạn thấy ngay: XML "nặng" hơn vì mỗi giá trị phải mở và đóng bằng một cặp thẻ. Nhưng đổi lại, XML diễn đạt rất rõ ràng và có khả năng mô tả nghiệp vụ phức tạp tốt hơn nhiều.
Các thành phần cấu trúc của XML
Để đọc được XML, bạn cần nắm bốn khái niệm này:
1. Element (phần tử): Là cặp thẻ mở <HoTen> và thẻ đóng </HoTen>, cùng nội dung bên trong. Element có thể lồng nhau (nested) thành cây phân cấp. Một tài liệu XML luôn có đúng một element gốc (root element) bao trùm tất cả.
2. Attribute (thuộc tính): Thông tin bổ sung viết ngay trong thẻ mở, dưới dạng tên="giá trị". Ví dụ:
<GiaoDich loai="ChuyenKhoan" trangThai="ThanhCong">
<SoTien donViTienTe="VND">5000000</SoTien>
</GiaoDich>
Ở đây loai và trangThai là attribute của GiaoDich; còn donViTienTe là attribute của SoTien. Đây là điểm khác biệt lớn với JSON — JSON không có khái niệm attribute, mọi thứ đều là cặp key-value. Khi đọc spec, bạn phải để ý dữ liệu nằm trong element hay attribute, vì cách lấy ra khác nhau.
3. Namespace (không gian tên): Khi nhiều hệ thống ghép dữ liệu lại, có thể trùng tên thẻ. Namespace dùng tiền tố (prefix) như xmlns:ns1="..." để phân biệt. Bạn sẽ thấy rất nhiều trong các chuẩn ngân hàng, ví dụ <ns2:Document>. Không cần hiểu sâu, chỉ cần biết phần ns2: là tiền tố namespace, không phải tên thẻ thật.
4. Prolog (khai báo đầu file): Dòng đầu tiên thường là <?xml version="1.0" encoding="UTF-8"?>. Phần encoding="UTF-8" rất quan trọng với tiếng Việt — nếu encoding sai, dấu tiếng Việt sẽ biến thành ký tự lỗi.
XML Schema (XSD) — bản hợp đồng dữ liệu
Đây là khái niệm mà BA cần đặc biệt quan tâm. XSD (XML Schema Definition) là một file định nghĩa quy tắc: tài liệu XML phải có những thẻ nào, kiểu dữ liệu là gì, thẻ nào bắt buộc, thẻ nào lặp lại bao nhiêu lần, độ dài tối đa ra sao.
Hãy hình dung XSD giống như biểu mẫu có ô bắt buộc ở quầy ngân hàng: "Số CMND phải đúng 12 số", "Số tiền không được âm", "Mục người thụ hưởng bắt buộc điền". Hệ thống nhận XML sẽ validate (kiểm tra hợp lệ) tài liệu dựa trên XSD trước khi xử lý. Nếu sai một quy tắc, toàn bộ giao dịch bị từ chối.
Với JSON, khái niệm tương đương là JSON Schema (bạn sẽ học ở bài khác). Nhưng trong thế giới legacy, XSD mạnh và phổ biến hơn nhiều, và nó chính là thứ định nghĩa "hợp đồng" giữa hai hệ thống. Khi bạn viết tài liệu nghiệp vụ cho một tích hợp dùng XML, rất có thể bạn sẽ phải đọc và đối chiếu với XSD do đối tác cung cấp.
Một chút về SOAP — người bạn đồng hành của XML
Trong các hệ thống cũ, XML thường đi cùng SOAP (Simple Object Access Protocol) — một giao thức gọi dịch vụ dựa hoàn toàn trên XML. Khác với REST (linh hoạt, nhẹ), SOAP đóng gói mọi thứ trong một "phong bì" XML gọi là <soap:Envelope>, có phần <soap:Header> và <soap:Body>. Bạn không cần học sâu SOAP trong bài này, chỉ cần nhận diện được: khi thấy Envelope, Header, Body và một file mô tả gọi là WSDL, đó là một dịch vụ SOAP kiểu cũ.
Tình huống thực tế
Ví dụ 1: Tích hợp thanh toán liên ngân hàng qua NAPAS
Một fintech ở TP.HCM (gọi là VíPay) muốn cho phép người dùng chuyển tiền nhanh 24/7 sang tài khoản ngân hàng khác. Họ tích hợp qua NAPAS — đơn vị vận hành chuyển mạch tài chính quốc gia. Đội BA của VíPay nhận được bộ tài liệu kỹ thuật, và message mẫu trông như thế này:
<?xml version="1.0" encoding="UTF-8"?>
<FundTransfer xmlns:ns="urn:napas:fasttransfer">
<TransactionID>VPAY20260627000182</TransactionID>
<DebitAccount>
<AccountNo>9704220012345678</AccountNo>
<BankCode>970432</BankCode>
</DebitAccount>
<CreditAccount>
<AccountNo>1903123456789</AccountNo>
<BankCode>970422</BankCode>
</CreditAccount>
<Amount currency="VND">2500000</Amount>
<Content>Thanh toan don hang DH8821</Content>
</FundTransfer>
Diễn giải: BA của VíPay phát hiện vài điểm nghiệp vụ quan trọng. Thứ nhất, trường Content (nội dung chuyển khoản) trong tài liệu NAPAS giới hạn 210 ký tự và không dấu — nếu app của VíPay cho người dùng gõ tiếng Việt có dấu, message sẽ bị NAPAS từ chối. Thứ hai, Amount để số tiền là số nguyên đồng (không có phần thập phân), với attribute currency. Thứ ba, BankCode phải khớp đúng mã ngân hàng theo bảng mã của NAPAS.
Bài học rút ra: Cái BA cần nắm không phải là cú pháp XML, mà là những ràng buộc nghiệp vụ ẩn trong cấu trúc XML: độ dài tối đa, có dấu hay không, định dạng số, mã tham chiếu. Chính BA là người phải dịch các ràng buộc này thành business rule và acceptance criteria cho đội dev và QA, để app không cho người dùng nhập sai ngay từ đầu.
Ví dụ 2: Nộp hóa đơn điện tử cho Tổng cục Thuế
Một công ty SaaS làm phần mềm kế toán (tạm gọi là KếToánViệt) muốn tích hợp hóa đơn điện tử với hệ thống của Tổng cục Thuế. Chuẩn hóa đơn điện tử Việt Nam (theo Thông tư 78 và Nghị định 123) định nghĩa toàn bộ định dạng hóa đơn bằng XML, kèm chữ ký số (digital signature) cũng được nhúng trong XML.
Đội BA phải đối chiếu với XSD do cơ quan thuế ban hành. Một đoạn rút gọn:
<HDon>
<DLHDon>
<TTChung>
<KHHDon>C26TYY</KHHDon>
<SHDon>00000182</SHDon>
<NLap>2026-06-27</NLap>
</TTChung>
<NDHDon>
<NMua>
<Ten>Công ty TNHH Hoa Sen</Ten>
<MST>0312345678</MST>
</NMua>
<TToan>
<TgTCThue>10000000</TgTCThue>
<TgTThue>1000000</TgTThue>
<TgTTTBSo>11000000</TgTTTBSo>
</TToan>
</NDHDon>
</DLHDon>
</HDon>
Diễn giải: Các thẻ viết tắt khó hiểu (TgTCThue = Tổng tiền chưa thuế, TgTThue = Tổng tiền thuế, TgTTTBSo = Tổng tiền thanh toán bằng số). BA phải lập một bảng ánh xạ (mapping) giữa thẻ XML của cơ quan thuế và trường dữ liệu trong phần mềm KếToánViệt. Họ cũng phát hiện một business rule sống còn: TgTTTBSo phải bằng TgTCThue + TgTThue, nếu lệch một đồng do làm tròn thì hóa đơn bị từ chối cấp mã.
Bài học rút ra: Trong các tích hợp với nhà nước, XML không chỉ là định dạng — nó là chuẩn pháp lý. BA phải đọc kèm văn bản pháp luật và XSD, lập mapping table cẩn thận, và xác định các quy tắc kiểm tra chéo (cross-field validation). Đây là phần việc thuần BA mà không lập trình viên nào làm thay được.
Ví dụ 3: Một dịch vụ SOAP cũ của đối tác bảo hiểm
Một sàn thương mại điện tử muốn bán kèm gói bảo hiểm du lịch của một hãng bảo hiểm lớn ở Đông Nam Á. Hãng này cung cấp API kiểu SOAP với một file WSDL. Khi đội kỹ thuật gửi thử yêu cầu báo giá, response trả về như sau:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<GetQuoteResponse>
<QuoteID>Q-2026-558210</QuoteID>
<Premium currency="USD">12.50</Premium>
<CoverageDays>7</CoverageDays>
</GetQuoteResponse>
</soap:Body>
</soap:Envelope>
Diễn giải: BA nhận ra dữ liệu hữu ích (QuoteID, Premium, CoverageDays) nằm sâu bên trong soap:Body, phải "bóc" qua lớp phong bì SOAP mới tới được. Phía sàn TMĐT lại dùng REST/JSON hiện đại, nên cần một lớp trung gian chuyển đổi giữa hai thế giới. BA ghi nhận yêu cầu phi chức năng: cần một adapter để dịch SOAP/XML của đối tác sang JSON nội bộ.
Bài học rút ra: Khi một bên dùng XML/SOAP cũ và một bên dùng JSON/REST mới, gần như luôn cần một lớp chuyển đổi (transformation). BA cần nhận diện sớm nhu cầu này để đưa vào phạm vi dự án, tránh việc đội dev "vỡ kế hoạch" vào phút chót khi phát hiện hai hệ thống không nói chung ngôn ngữ.
Hướng dẫn từng bước
Khi bạn được giao một tài liệu tích hợp dùng XML, hãy làm theo trình tự sau:
Bước 1 — Xác định đây là XML đơn thuần hay SOAP. Nhìn dòng đầu và element gốc. Nếu thấy <soap:Envelope>, Header, Body và có file WSDL, đó là dịch vụ SOAP. Nếu chỉ là cây thẻ dữ liệu thông thường, đó là XML payload đơn thuần (thường đi cùng REST hoặc trao đổi file).
Bước 2 — Tìm root element và vẽ cây cấu trúc. Bắt đầu từ thẻ ngoài cùng, liệt kê các thẻ con theo cấp. Một sơ đồ cây đơn giản trên giấy giúp bạn hiểu quan hệ cha–con nhanh hơn đọc raw text.
Bước 3 — Phân biệt element và attribute. Với mỗi mẩu dữ liệu, ghi rõ nó là element hay attribute. Điều này ảnh hưởng đến cách dev lấy dữ liệu và cách bạn viết mapping.
Bước 4 — Xin và đọc file XSD. Đây là bước nhiều BA bỏ qua và phải trả giá. XSD cho bạn biết: thẻ nào bắt buộc (minOccurs), thẻ nào lặp lại (maxOccurs), kiểu dữ liệu, độ dài, giá trị cho phép. Hãy đối chiếu từng trường với dữ liệu hệ thống của bạn.
Bước 5 — Lập bảng mapping. Tạo một bảng ba cột: Thẻ XML của đối tác — Trường dữ liệu hệ thống mình — Ghi chú/ràng buộc. Đây là sản phẩm BA quan trọng nhất của giai đoạn này.
Bước 6 — Trích xuất business rule. Từ XSD và tài liệu, viết ra các quy tắc: ràng buộc độ dài, định dạng, kiểm tra chéo giữa các trường, mã tham chiếu. Đưa vào acceptance criteria.
Bước 7 — Xác minh bằng mẫu thật. Yêu cầu đối tác cung cấp file XML mẫu hợp lệ và file lỗi. So sánh hai file giúp bạn hiểu hệ thống chấp nhận và từ chối cái gì.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhầm element với attribute. BA hay đọc lướt và bỏ qua attribute. Trong khi <Amount currency="VND">2500000</Amount> có hai mẩu dữ liệu: số tiền (element) và đơn vị tiền (attribute). Bỏ sót attribute là bỏ sót nghiệp vụ.
Lỗi 2 — Bỏ qua encoding và dấu tiếng Việt. Nếu prolog khai báo sai encoding hoặc đối tác chỉ nhận ASCII, tiếng Việt có dấu sẽ thành ký tự rác. Luôn hỏi rõ: "Trường này có nhận tiếng Việt có dấu không?".
Lỗi 3 — Quên rằng XML phân biệt chữ hoa chữ thường (case-sensitive). <HoTen> khác <hoten>. Nhiều lỗi tích hợp đến từ việc dev gõ sai một chữ hoa.
Lỗi 4 — Thẻ phải đóng đúng và lồng đúng. Khác HTML "dễ tính", XML rất nghiêm: mọi thẻ mở phải có thẻ đóng, và phải lồng đúng thứ tự. Một thẻ thiếu đóng làm cả file "không hợp lệ" (not well-formed) và bị từ chối hoàn toàn.
Lỗi 5 — Không xin XSD. Đây là sai lầm tốn kém nhất. Không có XSD, bạn chỉ đoán cấu trúc qua vài mẫu, và sẽ bỏ sót các trường bắt buộc hoặc ràng buộc ẩn.
Mẹo: Khi cần kiểm tra nhanh một file XML có hợp lệ về cú pháp không, bạn có thể mở bằng trình duyệt web — trình duyệt sẽ báo lỗi ngay nếu file "not well-formed". Đây là cách kiểm tra nhanh không cần công cụ chuyên dụng.
Mẹo: Khi viết tài liệu, hãy đính kèm một file XML mẫu hợp lệ làm phụ lục. Một ví dụ cụ thể giúp đội dev và QA hiểu nhanh hơn mười trang mô tả.
Bài tập thực hành
- Đọc cây cấu trúc: Lấy đoạn XML hóa đơn thuế ở Ví dụ 2, vẽ ra sơ đồ cây phân cấp đầy đủ các element. Đánh dấu element nào chứa giá trị, element nào chỉ chứa element con.
- Tìm attribute: Trong cả ba ví dụ ở bài này, liệt kê tất cả attribute và giải thích ý nghĩa nghiệp vụ của từng cái.
- Lập mapping table: Giả sử hệ thống của bạn có các trường
customer_name,tax_code,amount_before_tax,tax_amount,total_amount. Hãy lập bảng mapping ánh xạ sang các thẻ XML tương ứng trong Ví dụ 2 (Ten,MST,TgTCThue,TgTThue,TgTTTBSo).
- Viết business rule: Từ Ví dụ 1 (NAPAS), viết ít nhất ba business rule cho trường
ContentvàAmountđể app validate trước khi gửi đi.
- So sánh: Viết lại đoạn XML KhachHang ở đầu bài sang JSON, rồi liệt kê ba khác biệt thực tế giữa hai định dạng mà một BA cần lưu ý khi tư vấn chọn định dạng cho dự án mới.
Tóm tắt
XML chưa chết, và sẽ còn sống rất lâu trong các hệ thống legacy mà BA Việt Nam gặp hằng ngày: ngân hàng và NAPAS, hóa đơn điện tử của Tổng cục Thuế, hải quan, bảo hiểm, và các dịch vụ SOAP cũ của đối tác. Bạn không cần biết lập trình XML, nhưng bạn phải đọc hiểu cấu trúc — element, attribute, namespace, prolog — và đặc biệt phải biết khai thác XSD như một bản hợp đồng dữ liệu để trích xuất ràng buộc nghiệp vụ.
Giá trị thực sự của BA không nằm ở việc thuộc cú pháp, mà ở chỗ biến cấu trúc XML thành mapping table, business rule và acceptance criteria rõ ràng; nhận diện sớm nhu cầu chuyển đổi giữa thế giới XML cũ và JSON mới; và đặt đúng câu hỏi về độ dài, định dạng, encoding tiếng Việt, mã tham chiếu. Nắm vững những điều này, bạn sẽ tự tin ngồi vào bàn họp với bất kỳ đối tác legacy nào — và đó chính là khác biệt giữa một BA non kinh nghiệm và một BA được tin tưởng.