3.6 Thiết kế chức năng 54
3.6.1 Xử lý đặt lệnh báo giá 54
3.6.1.1 Một số thực thể liên quan
StockOrderDAL: Thực thể cung cấp các hàm xử lý đối tương StockOrder của tầng DataAccessLayer
Thuộc tính
Thực thể này không có thuộc tính.
Phương thức STT Tên cột Kiểu dữ liệu Length P/F Key Mô tả 1. MatchId uniqueidenti fier P Mã khớp lệnh 2. SClientID Varchar 30 Mã CTCK bán
3. BClientID Varchar 30 Mã CTCK mua
4. SOrderID Varchar 30 Mã hiệu lệnh bán
5. BOrderID Varchar 30 Mã hiệu lệnh mua
6. MatchVolume Int Khối lượng khớp
7. MatchPrice Decimal Giá khớp
8. MatchTime Datetime Thời gian khớp
Bảng 3. 12. Chi tiết khớp lệnh của hệ thống
Phƣơng thức Mô tả
GetOrderNo() Hàm sinh số hiệu lệnh
GetExecID() Hàm sinh số ID xử lý lệnh
StockExchangeApp: Thực thể FIX Service thuộc tầng BussinessService
Thuộc tính
Tên thuộc tính Mô tả
orderID Private Số hiệu lệnh do HNX sinh ra để quản lý execID Private Số hiệu xử lý lệnh do HNX sinh ra để quản lý
Phương thức
GetOrder(String OrderNo, String ClientId)
Lấy thông tin một lệnh trong database
GetListOrder() Lấy danh sách tất cả các lệnh báo giá
UpdateOrder(StockOrder order) Cập nhật thông tin lệnh báo giá EditOrder(StockOrder order, decimal
newPrice)
Sửa một lệnh báo giá
CancelOrder(StockOrder order) Hủy một lệnh báo giá
Bảng 3. 13. Các phương thức lớp StockOrderDAL
Phƣơng thức Mô tả ReceivedAdmin(Message message,
SessionID sessionID)
Nhận một thông điệp FIX của lớp Session (logon, logout, heartbeat, ...) từ CTCK
ReceivedMessage(NewOrderSingle message, SessionID sessionID)
Nhận một lệnh đặt báo giá NewOrderSingle
ReceivedMessage(OrderCancelRequest message, SessionID sessionID)
Nhận một yêu cầu hủy lệnh
ReceivedMessage(OrderCancelReplaceReq uest message, SessionID sessionID)
Nhận một yêu cầu hủy lệnh
ReceivedMessage(Advertisement message, SessionID sessionID)
Nhận một lệnh quảng cáo
3.6.1.2 Sơ đồ giải thuật
Hình 3.9 là mô tả chi tiết các bước xử lý một lệnh báo giá từ CTCK gửi lên: message, SessionID sessionID)
ReceivedMessage(
CrossOrderCancelRequest message, SessionID sessionID)
Nhận một yêu cầu hủy lệnh thỏa thuận
ReceivedMessage(
CrossOrderCancelReplaceRequest message, SessionID sessionID)
Nhận một yêu cầu sửa lệnh thỏa thuận
SetSessionData(Message message, SessionID sessionID)
Gắn các thông tin session vào một FIX Message
SendMessage(Message message, SessionID sessionID)
Gửi một FIX Message đến CTCK
SendTradingSessionStatus(SessionID sessionID)
Gửi một message thông tin thị trường đến CTCK
FIX Service Gửi NewOrderSingle Message hợp lệ Gửi Reject Request Queue Yes Có bị mất Message Lệnh có đúng phiên giao dịch? So sánh giá trị trường 34 và 36
Yêu cầu gửi Resend message
Có bị lặp Mesage
So sánh giá trị trường 34 và 36
Yêu cầu gửi Reset lại Sequense
No No Lệnh có hợp lệ Lấy message từ queue xử lý
Kiểm tra các thông tin của lệnh: - Mã chứng khoán - Mã khách hàng - Loại lệnh, ...
Response Queue Gửi xác nhận vào Core
Gửi reject + mã lỗi Khớp lệnh
Gửi ExecReport (Khớp) Hủy lệnh
(Tự hủy)
Gửi ExecReport (Hủy)
Có lệnh đối ứng chờ khớp Yes Có thể chờ khớp No No Cập nhật lệnh: - Update Sorder/Border - Insert HistOrder FIX Sender Gửi phản hồi cho CTCK
Lưu vào sổ lệnh (Bảng Sorder/Border) CTCK
Hình 3. 9. Sơ đồ khối xử lý đặt lệnh báo giá
3.6.2 Hủy lệnh báo giá
3.6.2.1 Một số thực thể liên quan
Chức năng hủy lệnh báo giá sử dụng các thực thể đã mô tả trong Bảng 3.13 và Bảng 3.14
3.6.2.2 Sơ đồ giải thuật
FIX Service Gửi OrderCancelRequest Message hợp lệ Gửi Reject Request Queue Yes Có bị mất Message Lệnh có đúng phiên giao dịch? So sánh giá trị trường 34 và 36
Yêu cầu gửi Resend message
Có bị lặp Mesage
So sánh giá trị trường 34 và 36
Yêu cầu gửi Reset lại Sequense
No No Lệnh có hợp lệ Lấy message từ queue xử lý
Kiểm tra các thông tin của lệnh: - Mã lệnh cần hủy có tồn tại - Trạng thái lệnh cần hủy có hợp lệ - Loại lệnh cần hủy có hợp lệ, ...
Response Queue Gửi reject + mã lỗi Hủy lệnh
(Trạng thái = C) Gửi ExecReport (Hủy)
Cập nhật lệnh về C - Update Sorder/Border - Insert HistOrder
FIX Sender Gửi phản hồi cho CTCK
CTCK
Hình 3. 10. Sơ đồ khối hủy lệnh báo giá
3.6.3 Sửa lệnh báo giá
Chức năng sửa lệnh báo giá sử dụng các thực thể đã mô tả trong Bảng 3.13 và Bảng 3.14
3.6.3.2 Sơ đồ giải thuật
Hình 3.11 là mô tả chi tiết các bước hủy một lệnh báo giá từ CTCK gửi lên:
FIX Service Gửi yêu cầu sửa lệnh
OrderCancelReplaceRequest) Message hợp lệ Gửi Reject Request Queue Yes Có bị mất Message Lệnh có đúng phiên giao dịch? So sánh giá trị trường 34 và 36
Yêu cầu gửi Resend message
Có bị lặp Mesage
So sánh giá trị trường 34 và 36
Yêu cầu gửi Reset lại Sequense
No No Lệnh có hợp lệ Lấy message từ queue xử lý
Kiểm tra các thông tin của lệnh: - Mã lệnh cần sửa có tồn tại - Trạng thái lệnh cần sửa có hợp lệ - Loại lệnh cần sửa có hợp lệ, ...
Response Queue Gửi reject + mã lỗi Cập nhật lệnh theo
giá mới Gửi ExecReport (Sửa)
Cập nhật giá chờ khớp - Update Sorder/Border
FIX Sender Gửi phản hồi cho CTCK
CTCK
Hình 3. 11. Sơ đồ khối sửa lệnh báo giá
4.1 Kết quả xây dựng phần mềm
Sau quá trình nghiên cứu giao thức FIX cùng với việc phân tích thiết kế các chức năng đến nay phần mềm đã hoàn thành và đáp ứng được các yêu cầu đề ra. Đây là một dạng phần mềm Server, vì vậy các chức năng hầu hết dưới dạng service và tự động nên không có giao diện. Để xây dựng phần mềm tác giả đã sử dụng thư viện QuickFix như một Fix engine cung cấp các API và hỗ trợ thiết lập các kênh truyền nhận các Fix Message. Dưới đây là một số giao diện các chức năng tương tác với người dùng:
4.1.1 Màn hình chính
Hình 4. 1. Màn hình giao diện chính Các chức năng trên màn hình chính bao gồm:
- Khởi động và tạm dừng hệ thống - Thay đổi thông tin thị trường
- Theo dõi log gửi nhận thông điệp FIX - Theo dõi sổ lệnh
4.1.2 Đặt lệnh báo giá
Màn hình này cho phép thực hiện đặt các lệnh báo giá như LO, ATO, ATC, MAK,...
Hình 4. 2. Màn hình đặt lệnh báo giá
Hình 4. 3. Màn hình khớp lệnh thủ công
Chức năng này cho phép thực hiện chủ động khớp lệnh một lệnh báo giá hợp lệ
4.1.4 Sửa lệnh
Chức năng này cho phép thực hiện sửa một lệnh báo giá
Hình 4. 4. Sửa lệnh báo giá
Đây là chức năng thực hiện gửi một lệnh quảng cáo đến các công ty chứng khoán để quảng cáo cho việc giao dịch thỏa thuận.
Hình 4. 5. Đặt lệnh quảng cáo
4.2 Kịch bản thử nghiệm
4.2.1 Mục tiêu thử nghiệm
Đây là phần mềm mô phỏng hệ thống khớp lệnh của HNX nên phải đạt được các tiêu chuẩn gần như phần mềm thực tế như xử lý dữ liệu, hiệu năng cao, đảm bảo tính toàn vẹn dữ liệu khi xử lý và luôn sẵn sàng. Có như vậy phần mềm mới có ý nghĩa thực tiễn là sử dụng để kiểm thử các phần mềm giao dịch chứng khoán. Mục tiêu thử nghiệm phần mềm cần:
Thử nghiệm khả năng quản lý kết nối của hệ thống
Thử nghiệm khả năng xử lý nghiệp vụ của hệ thống
Thử nghiệm khả năng xử lý toàn vẹn thông tin
Thử nghiệm tính hiệu năng của hệ thống
4.2.2 Kịch bản
Tương ứng với mục tiêu thử nghiệm chúng ta có các kịch bản thử nghiệm hệ thống như sau:
Kịch bản thử nghiệm quản lý kết nối:
CTCK gửi logon thực hiện kết nối tới HNX, với các tình huống:
Thành công
Thất bại do sai thông tin kết nối
CTCK gửi thông điệp HeartBeat duy trì kết nối (định kỳ 30s)
CTCK gửi logout xin đóng kết nối
HNX tự đóng kết nối do timeout (sau 60s không nhận được thông điệp từ CTCK)
Kịch bản thử nghiệm xử lý nghiệp vụ:
Kịch bản kiểm tra khả năng xử lý toàn vẹn thông tin
STT Tình huống Điều kiện Kết quả mong đợi
1 CTCK gửi đặt lệnh báo giá
Hệ thống sẵn sàng HNX gửi phản hồi lệnh vào Core
Lệnh được gửi không đúng phiên
HNX gửi lại reject (kèm mã lỗi)
Thông tin lệnh không hợp lệ (Sai mã CK, giá đặt cao hơn giá trần, ...)
HNX gửi lại reject (kèm mã lỗi) Có lệnh đối ứng HNX thực hiện khớp lệnh và gửi phản hồi lệnh khớp Lệnh ATO/ATC hết phiên không được khớp
HNX Gửi kết quả lệnh bị hủy
2 CTCK gửi yêu cầu hủy lệnh báo giá
Trong HNX chưa tồn tại mã lệnh cần hủy
HNX gửi lại reject (kèm mã lỗi)
Lệnh đã bị hủy hoặc đã khớp hết
HNX gửi lại reject (kèm mã lỗi)
Loại lệnh không được hủy
(ATO/ATC)
HNX gửi lại reject (kèm mã lỗi)
Lệnh có thể hủy HNX gửi phản hồi hủy lệnh thành công
3 CTCK gửi yêu cầu sửa lệnh
Lệnh thỏa mãn điều kiện có thể sửa
HNX gửi phản hồi sửa lệnh thành công.
4 CTCK gửi lệnh quảng cáo
Lệnh quảng cáo yêu cầu gửi đến toàn thị trường
HNX forward các lệnh quảng cáo đến tất cả các máy trạm kết nối tới
STT Tình huống Điều kiện Kết quả mong đợi 1 CTCK gửi 100 thông điệp đặt lệnh liên tục, số sequense tăng từ 1 đến 100 Khi CTCK gửi đến thông điệp cuối cùng thì thực hiện ngắt kết nối.
Khi kết nối lại CTCK thực hiện gửi thông điệp thứ 101. Ngắt kết nối nhưng HNX vẫn nhận đủ 100 thông điệp HNX nhận thông điệp thứ 101 bình thường HNX không nhận đủ 100 thông điệp (giả sử chỉ nhận 80)
HNX sẽ từ chối thông điệp thứ 101 và gửi lại CTCK thông điệp ResendRequest yêu cầu gửi lại các thông điệp từ 81-100 2 CTCK gửi 100 thông điệp đặt lệnh liên tục, số sequense tăng từ 1 đến 100 Trong lúc đang thực hiện gửi thì ngắt kết nối đến HNX. Lúc này CTCK chỉ nhận được phản hồi đã gửi thành công 80 thông điệp Khi kết nối lại CTCK thực hiện gửi thông điệp thứ 81.
Thời điểm ngắt kết nối HNX chỉ nhận được 80 thông điệp
HNX nhận thông điệp thứ 81 bình thường
Thời điểm ngắt kết nối HNX nhận được nhiều hơn 80 thông điệp (giả sử 85) nhưng khi gửi lại phản hồi xác nhận với CTCK thì do ngắt đường truyền nên chỉ gửi xác nhận được 80 thông điệp
HNX sẽ không nhận thông điệp thứ 81 đồng gửi gửi lại thông điệp ResetMessage yêu cầu CTCK reset lại số sequense (trường 34) về 85.
Kịch bản thử nghiệm hiệu năng của hệ thống
4.3 Đánh giá kết quả
Kết quả đạt được:
Bằng việc thử nghiệm các kịch bản như đã nêu ở phần trên, kết quả thu được như sau:
- Phần thử nghiệm khả năng quả lý kết nối: Kết quả đạt như mong đợi, phần mềm có khả năng quản lý và duy trì kết nối như môi trường thực tế.
- Phẩn thử nghiệm xử lý nghiệp vụ: Phần mềm mô phỏng đáp ứng chính xác như kết quả mong muốn, các kết quả xử lý đúng với nghiệp vụ chứng khoán hiện hành.
- Thử nghiệm khả năng xử lý toàn vẹn thông tin: Kết quả đạt được như kết quả mong muốn của kịch bản
STT Tình huống Điều kiện Kết quả mong đợi
1
Bắt đầu từ 1 máy trạm và tăng dần số máy trạm (CTCK) gửi lệnh vào HNX, mỗi máy trạm gửi 1000 lệnh báo giá (gồm cả lệnh bán và mua) liên tục đến HNX Thị trường ở phiên giao dịch liên tục và sẵn sàng nhận lệnh - Tốc độ nhận lệnh 100 lệnh/giây trở lên
- Thời gian gửi và thời gian nhận (được ghi lại ở file log máy trạm và máy chủ) không quá 10ms.
- Thời gian Server nhận được thông điệp (ghi nhận ở log file) và thời gian đưa thông điệp vào Core (lấy từ RequestQueue ra xử lý) không vượt quá 30ms.
2
Sử dụng 3 máy trạm (CTCK), mỗi máy trạm gửi 800 lệnh báo giá (gồm cả lệnh bán và mua) và gửi 200 yêu cầu hủy các lệnh trên. Mã lệnh hủy được chọn ngẫu nhiên trong 800 lệnh.
- Thị trường ở phiên giao dịch liên tục và sẵn sàng nhận lệnh - Khi một lệnh được gửi vào hệ thống sẽ xử lý ngẫu nhiên 1 trong 2 cách là hủy lệnh hoặc khớp hết
- Không xảy ra trường hợp hủy một lệnh đã khớp.
- CTCK không được gửi một yêu cầu hủy tới một lệnh đã bị hủy hoặc đã khớp hết
- Thử nghiệm hiệu năng hệ thống:
Với kịch bản 1: Hệ thống đáp ứng đúng kết quả mong đợi với số máy trạm <=3.
Khi lên 4 máy trạm gửi liên tục trong điều kiện đường truyền tốt thì thời gian chênh lệch giữa lúc nhận được thông điệp và phản hồi vào Core lớn hơn 50ms.
Với kịch bản 2: Có 5 lệnh hủy không đúng yêu cầu, lệnh đã khớp mà CTCK vẫn
gửi lệnh hủy. Nguyên nhân vì khi đó Server đã thực hiện khớp lệnh thành công, kết quả đã được đưa vào ResponseQueue nhưng chưa kịp gửi về máy trạm thì máy trạm thực hiện gửi lệnh hủy. Trong thực tế cũng không tránh được tình huống này.
Hạn chế:
Do bị hạn chế về thời gian nên phần mềm tuy đã đạt được các yêu cầu về nghiệp vụ nhưng chưa hoàn thiện về hiệu năng. Phần mềm chưa mới thực hiện kết nối tới 4 máy trạm và chưa có điều kiện mở rộng số máy trạm kết nối đến.
Do chỉ dừng ở ứng dụng mô phỏng nên phần mềm được xây dựng trên các công nghệ tương đối cơ bản (.Net 2010 và SQL server 2008), các cấu trúc dữ liệu như Message Queue được thiết kế dưới dạng Memory Queue và Database Queue nên chưa phát huy được hiệu năng như thực tế sử dụng các Message Queue hiện đại như IBM MQ, Active MQ, ...
Phần mềm mới tập trung xây dựng các chức năng liên quan đến giao dịch như khớp lệnh, hủy sửa lệnh, ... Chưa xây dựng được các chức năng tính toán các chỉ số thị trường, còn nhiều hạn chế về giải thuật khớp lệnh định kỳ.
KẾT LUẬN
Với sự phát triển mạnh mẽ về công nghệ đang tạo ra sự đa dạng hóa về chất lượng phong phú về hình thức các hệ thống phần mềm tài chính. Trong thời đại hội nhập ngày nay nhu cầu trao đổi dữ liệu giữa các hệ thống nói chung và hệ thống tài chính nói riêng đang trở nên phổ biến và phát triển mạnh mẽ. Các phần mềm tin học không còn hoạt động với dữ liệu thông tin nội bộ một doanh nghiệp quốc gia nào mà luôn là một thành phần của mạng lưới rộng lớn. Sự cần thiết nhu cầu giao tiếp dữ liệu giữa các hệ thống tin học tài chính đang đặt ra yêu cầu cần thiết phải có những chuẩn giao thức chung để đơn giản hóa vấn đề tích hợp này. FIX ra đời để giải quyết vấn đề trao đổi dữ liệu giữa các hệ thống sàn giao dịch chứng khoán cũng là tiên phong trong lĩnh vực tích hợp giữa các hệ thống tài chính bằng chuẩn giao thức chung.
Với đề tài “Nghiên cứu chuẩn giao thức FIX và ứng dụng xây dựng phần mềm
mô phỏng hệ thống khớp lệnh chứng khoán của Sở giao dịch chứng khoán Hà Nội” tác
giả đã giới thiệu được nội dung chi tiết về chuẩn giao thức FIX đang được áp dụng rộng rãi tại các sàn giao dịch chứng khoán trên thế giới. Cùng với việc đi sâu nghiên cứu về chuẩn giao thức FIX tác giả cũng nghiên cứu framework mã nguồn mở QuickFix như là một thư việc hỗ trợ xây dựng các ứng dụng dựa trên FIX và áp dụng vào xây dụng một phần mềm mô phỏng tuân thủ đúng các nghiệp vụ tại sàn giao dịch chứng khoán Hà Nội. Phần mềm là sự áp dụng các kết quả nghiên cứu lý thuyết về FIX và nghiệp vụ chứng khoán Việt Nam nhằm cung cấp một công cụ hữu hiệu để kiểm thử các phần mềm giao dịch chứng khoán tại thị trường Việt Nam. Sự ra đời của ứng dụng mô phòng này sẽ giúp tiết kiệm rất nhiều chi phí kiểm thử của phần mềm giao dịch chứng khoán, bằng việc kết nối với ứng dụng này để thực hiện kiểm thử trước các giao dịch chứng khoán sẽ giúp khẳng định được chất lượng hoạt động khi các CTCK kết nối thực sự vào