Mô tả khái quát

- Nghiệp vụ này phát sinh khi khách hàng có yêu cầu hủy lệnh đã đặt, hoặc khi phát hiện có sự sai lệch giữa phiếu lệnh gốc của khách hàng với lệnh nhập vào hệ thống. - Nhân viên môi giới có thế gọi điện thông báo cho đại diện sàn để hủy lệnh.

- Chi có thể thực hiện yêu cầu hủy lệnh đối với những lệnh chưa khớp hoặc phần chưa được khớp cùa lệnh đặt. 4.2.2 S ơ đồ nghiệp vụ Q u y trỉn h hủy lệnh Bát đầu Két thúc ị f

1. Phiéu lộnh huy ^ duyột chưa? Chưa duyệt ► 2 Hủy lộnh tại công ty Đã duyệt

3 Thông báo cho đại diộn sàn

ị

Lộnh đâ nhập n 4 2 Nhập lệnh hùy vào hệ thống vào sàn ? p nhận lệnh cúa TTGD

Hình 4.2: Sơ đồ quy trình hủy lệnh môi giới

4.2.3 Mô tả chi tiết các bước

Bưóc Mô tả Chi tiết

1 Khách hàng viêt

--- ,--- r———— Khách hàng có thê hủy lệnh qua điện thoại, đèn trực

4 1 Xác nhận lệnh hùy trong StockPro. đổng thời bỏ qua không

nhâp lệnh đỏ vào hé thổng của * Chư« nhàp

Bước Mô tả Chi tiết

phiêu lệnh hủy tiêp sàn giao dịch tại công ty CK đê viêt phiêu lệnh hoặc Fax lệnh

2 Hủy lệnh tại công ty

Kiêm tra xem lệnh cũ tương ứng đã được duyệt chưa? Nếu chưa, kiếm soát viên có thế hủy lệnh neay tại công ty. Lệnh hủy sẽ có trạng thái X và StockPro sẽ lưu lại thông tin của việc hủy lệnh.

3 Thông báo cho đại diện sàn

Trong trường hợp lệnh đã được duyệt và được truyên vào sàn, nhân viên môi giới phải gọi điện vào sàn đế thông báo cho đại diện sàn biết về yêu cầu huy lệnh của khách hàng.

4.2 Nhập lệnh hủy vào hệ thống của TTGD

Nêu lệnh đặt của khách hàng đã được nhập vào hệ thống của TT, đại diện sàn sẽ nhập lệnh hủy tương ứng vào hệ thống. Lệnh đặt của khách hàng sẽ được cập nhật về trạng thái c.

4.1 Bỏ qua, ko nhập lệnh đặt vào hệ thống

Nêu lệnh đặt của khách hàng chưa được nhập vào hệ thống của TTGD, đại diện sàn sẽ nhấn nút huy lệnh trong StockPro, và bỏ qua không nhập lệnh đặt đó vào hệ thống của TTGD nữa.

Lệnh đặt của khách hàng sẽ được cập nhật thành trạng thái D

Bảng 4.2: Mô tả chi tiêt các bước của quy trình hủy lệnh

4.3 Quy trình sửa lệnh

4.3.1 Mô tả khái quát

- Nghiệp vụ phát sinh khi khách hàng có yêu cầu sửa giá của lệnh đặt, hoặc khi nhân viên giao dịch phát hiện có sự sai lệch về giá của lệnh gốc với giá của lệnh nhập vào hệ thống.

- Chỉ có thể thực hiện việc sửa giá đối với những lệnh chưa khớp hoặc phần chưa được khớp của lệnh đặt

56 (adsbygoogle = window.adsbygoogle || []).push({});

4.3.2 S ơ đồ nghiệp vụ

Q u y trin h sửa lệnh

Bắt đầu

▼

1 Phiéu lệnh sửa giá - . . . . , o. . r,

3 3 Nhập lệnh mới vào StockPro Két thúc +

A A

▼

Lệnh của sàn HO/ urif>r - r r 77 . . . . . . HOSE ► 2 --- ị Quy trinh hũy lệnh

HNX

▼

4 Cập nhật giá đặt cho lệnh Lệnh đâ nhập n 5 1 Nhập lệnh sửa giá váo hẻ muốn sửa giá * vào sàn ? n ạp ► Ịhống nhân lệnh cua TTGD

Chưa 5.2 Hủy lệnh cũ trong StockPro. nhập lệnh mới vào hệ thòng của

TTGD

Hình 4.3: Sơ đồ nghiệp vụ quy trình sửa lệnh môi giới

4.3.3 Các bước thực hiện

lỉước Mô tả Chi tiết

1 Khách hàng viêt phiếu lệnh sửa giá

Khách hàng có thê sửa lệnh qua điện thoại, đên trực tiếp sàn giao dịch tại công ty CK để viết phiếu lệnh hoặc Fax lệnh

2 Hủy lệnh cũ Đôi với những lệnh đặt trên sàn HSX => Hủy lênh cũ => Ọuy trình hủy lệnh

3 Nhập lệnh mới Sau khi hủy lệnh cũ => Nhân viên môi giới nhập lệnh mới vào hệ thống StockPro

4 Sửa lệnh Đôi với những lệnh đặt trên sàn HNX => Cập nhật vào hệ thống StockPro giá đặt mới cho lệnh đặt tương ứng

5.1 Bỏ qua, không nhập lệnh đặt vào hệ thống

Bước Mô tả Chi tiêt

TTGD

5.2 Nhập lệnh sửa Nêu lệnh đặt của khách hàng đã được nhập vào hệ thống của TTGD, đại diện sàn sẽ nhập lệnh sưa giá tương ứng vào HT sàn

CHƯƠNG 5 - THIÉT KÉ VÀ CÀI ĐẶT HỆ THỐNG

>s. Chương này trình bày về những hạn chế của hệ thống phần mềm chứng khoản cũ. từ đó áp dụng kiến trúc SOA đê giải quyết những hạn chế đó. (adsbygoogle = window.adsbygoogle || []).push({});

5.1 Lý do lựa chọn SOA cho việc phát triển phần mềm chứng khoán

- Cơ sở hạ tầng thị trường chứng khoán ở Việt Nam đang ở trên đà phát trien do đó các yêu cầu về nghiệp vụ cũng như cơ sở hạ tầng về hệ thống phần mềm cua các sơ giao dịch có nhiều thay đối tùy theo từng giai đoạn phát trien. Ví dụ, phương thức truyền lệnh giao dịch ban đầu của các công ty chứng khoán với các sở giao dịch là phương thức thủ công, nghĩa là mỗi công ty chứng khoán sẽ cử một sổ cá nhân làm đại diện sàn cho công ty và ngồi ở các sở giao dịch đề nhập lệnh trực tiếp vào phần mềm cua sở, sau nhiều năm phát triển cũng như sự lớn mạnh của thị trường chúng khoán Việt Nam thì hiện tại đã có sự kết nối trực tiếp giữa hệ thống phần mềm của công ty chứng khoán và hệ thống phần mềm của sở giao dịch, do đó việc truyền lệnh hiện tại là hoàn toàn tự động, lệnh được đặt ở công ty chứng khoán sẽ được truyền thẳng vào sàn. - Một số quy trình về giao dịch và thanh toán bù trừ giao dịch đa phương của các so cũng có những thay đổi khác nhau cho phù hợp với các giai đoạn phát triển. Ví dụ, biên độ giao dịch giá trần, sàn của các chứng khoán ở mỗi sớ đều có những lúc cần thay đổi để phù hợp với thị trường từng thời điểm, hay sự bổ sung rất nhiều các nghiệp vụ mới như đặt lệnh thỏa thuận, sửa lệnh, hủy lệnh,...

Như vậy ta thấy rằng hệ thống phần mềm của sở giao dịch chứng khoán đều có những thay đồi như bổ sung, nâng cấp, thêm các nghiệp vụ mới,...điều đó làm cho các phần mềm cúa các công ty chứng khoán cũng phải sửa đổi, bổ sung cho tương thích với hệ thống của các sở giao dịch. Việc sửa đổi, bổ sung cần được lên kế hoạch và đánh giá lại chi phí sửa đổi hệ thống, do đó vấn đề đặt ra là phải xây dựng một hệ thống phần niềm có tính mở cao, hệ thống phần mềm này có khả năng dễ nâng cấp, báo trì, dễ dàng tái sử dụng lại được các thành phần dịch vụ để tiết kiệm chi phí đồng thời kết nối dễ dàng với những hệ thống khác. Như vậy việc phát triển phần mềm theo kiến trúc SOA là rất thích hợp với hệ thống phần mềm ở công ty chứng khoán.

5.2 Thực trạng của hệ thống phần mềm công ty chứng khoán StockMart ViệtNam Nam

Hình dưới đây là bức tranh tổng thể mô phỏng các thành phần phần mềm hiện tại của Công ty chứng khoán StockMart Việt Nam.

1 HOSE k HNX --- n s. P3 HSX G atew ay P1 Trading 0 I Application y P4. HNX G atew ay P2. Bank Service Core Stock DataBase CTCK Back Office System

BAP G atew ay

C o re Banking D a tab a s e

Banking System

Hình 5.1: Mô hình các thành phần của hệ thống phần mềm hiện tại

Trong đó:

Pl.Trading Application

Đây là thành phần giao tiếp với người dùng, người dùng ở đây là các nhân viên của công ty chứng khoán như bộ phận giao dịch, bộ phận tin học, bộ phận đầu tư..., thành phần này sẽ kết nối với các sở thông qua các dịch vụ như ở trên mô hình để thực hiện việc giao dịch đặt lệnh mua bán chứng khoán cho khách hàng và thực hiện vấn tin, xem báo cáo,...

P2.Bank Service

Đây là một Web Service được viết riêng để thực hiện việc kết nối với ngân hàng nó thực hiện việc kiểm tra tiền, phong tỏa tiền, giải tỏa tiền, gửi bảng kê hạch toán santí ngân hàng đế thực hiện các nghiệp vụ liến quan đến tiền.

P3.HSX Gateway

Là một Web Service thực hiện việc kết nối với hệ thống của HSX đê thực hiện việc truvền, nhận lệnh.

6 0

Là một Web Service thực hiện việc kết nối với hệ thống cua HNX đẻ thực hiện việc truyền, nhận lệnh.

Nhận xét về hệ thống phần mềm hiện tại

Nhìn vào mô hình các thành phần của hệ thống phần mềm công ty chứng khoán StockMart hiện tại ta thấy các thành phần giao tiếp với nhau như sau:

- Hệ thống phần mềm của công ty sẽ thực hiện việc kết nối với ngân hàng thông qua một web service là “ Bank Service” đế thực hiện lấy các thông tin về số dư tiền, thực biện phong tỏa tiền trong trường hợp khách hàng đặt lệnh và giái tởa tiền trong trường hợp lệnh bị hủy,...

- Phần mềm nhập lệnh của công ty CK sẽ kết nối với hai sở giao dịch chứng khoán là sở giao dịch chứng khoán Thành Phố Hồ Chí Minh (HSX) và sở giao dịch chứng khoán Hà Nội (HNX) để thực hiện việc truyền lệnh vào sàn và nhận lại thông tin kết quả khớp lệnh trả về của sàn thông qua các web service tương ứng là HSX Gateway và HNX Gateway

Ư’u điểm:

Đã service hóa một số modun trong hệ thống như service kết nối với ngân hàng và các service kết nối với các sở, việc sử dụng các webservice đế kết nối với các hệ thống này làm tăng tính mềm dẻo của hệ thống và tăng khả năng sử dụng lại dịch vụ trong các yêu cầu về nghiệp vụ mới trong tương lai.

N huọc điểm:

1: Hệ thống phần mềm giao diện người dùng PI.Trading Application kết nối trực tiếp tới cơ sở dữ liệu khách hàng, kết nối này có tính chất Tight Coupling nghĩa là chúng gắn chặt với nhau điều này gây nên khó khăn trong việc sửa đổi, nâng cấp hệ thống. Ví dụ, các chức năng xử lý đặt lệnh, vấn tin khách hàng, thanh toán bù trừ với các sớ giao dịch được viết ngay trong ứng dụng PI.Trading Application. Như vậy khi phát triên thêm một thành phần mới có một số chức năng tương tự với thành phần Pl.TradingApplication như hệ thống giao dịch trực tuyến qua Internet cua khách hàng hay hệ thống đặt lệnh qua điện thoại di động, thì một lần nữa ta phải viết lại những chức năng này và thực hiện một quy trình kiểm tra chất lượng với các modun này, điều này gây ra việc mất thời gian, nhân lực, và cũng không thể đám bảo ràng những gì viết lại ở các modun là không còn lỗi.

2: Khi công ty chứng khoán muốn tích hợp phần mềm của một hãng khác vào các ứng dụng hiện tại, ví dụ phần mềm giao dịch qua Internet “Internet Trading”, hãng này yêu cầu công ty chứng khoán cung cấp cho các API để kết nối tới hệ thống phần mềm cua công ty chứng khoán như các hàm đặt lệnh, hủy lệnh, sửa lệnh, vấn tin tài khoán,...thì hệ thống của công ty chứng khoán hiện tại không đáp ứng được. Vì các nghiệp vụ mà hãng kia yêu cầu đã được viết cứng trong phần mềm PI.Trading Application, do đó hai hệ thống không thế nói chuyện được với nhau.

5.3 Thiết kế hệ thống phần mềm mói theo kiến trúc SOA

Ta sẽ thực hiện xây dựng phần mềm tuân theo quy trình xây dựng một hệ thông SOA, đồng thời đám báo được rằng các nguyên tắc cua SOA được hỗ trợ troniỉ phần mềm (adsbygoogle = window.adsbygoogle || []).push({});

5.3.1 Phân tích dich vu• •

Vì hệ thống phần mềm hiện tại đã được kiếm thử và chạy khá ôn định nên xét về các yếu tổ như chi phí phát triển, tiến độ dự án và khả năng tái sứ dụng trong phần mềm thì ta sẽ lựa chọn chiến lược thiết kế “bottom-up“ để có thế tận dụng các tài nguyên cũ của hệ thống mà vẫn còn hoạt động tốt như các thành phần P2, P3, P4. Dựa trên các tài nguyên sẵn có và nhu cầu xây dựng một hệ thống theo kiến trúc SOA ta có thề xác định các tập hợp sơ bộ của các dịch vụ trong hệ thống như sau:

Xác định miền dịch vụ• • •

Theo như phần đánh giá hiện trạng phần mềm hiện tại của công ty chứng khoán StockMart Việt Nam thì với nhược điểm 1, thành phần P1 không hỗ trợ tính chất loose coupling của định hướng dịch vụ, để giải quyết vấn đề này ta thực hiện phân chia các chức năng gắn chặt vào P1 thành các dịch vụ dựa trên những nhận xét:

- T a phải có những chính sách khác nhau cho các chức năng nghiệp vụ đế đảm bao hiệu năng của hệ thống và đáp ứng tốt các nhu cầu của khách hàng. Các modun dành cho giao dịch như đặt lệnh, sửa lệnh, hủy lệnh, vấn tin lệnh là các modun có tần số làm việc cao vì trong mồi phiên giao dịch có rất nhiều các kết nối từ phía các khách hàng và các bộ phận môi giới tới các dịch vụ này do đó cần có một chính sách riêng cho các dịch vụ này như các chính sách về cân bằng tải “Load balancing”, và chuyến đối dự phòng “Failover”, bảo mật.

- Các chức năng về giao dịch phải được service hóa vì có nhiều các client khác cần kết nối tới trong tương lai như các thành phần giao dịch qua internet (internet trading), hệ thống đặt lệnh qua điện thoại di động.

Dựa vào những nhận xét trên thì nên phân chia các chức năng nghiệp vụ trong thành phần P1 thành 2 dịch vụ:

1. Dịch vụ khách hàng chứa các chức năng về giao dịch như đặt lệnh, sửa lệnh, húy lệnh, vấn tin lệnh, vấn tin tiền và chứng khoán.

2. Dịch vụ nghiệp vụ chứa tất cả các chức năng nghiệp vụ còn lại của hệ thống như mớ tài khoản, vấn tin khách hàng, báo cáo, quản lý người dùng.

- Để có thể đáp ứng các yêu cầu về load balancing và failover trong thành phần dịch vụ giao dịch khách hàng, ta phải thêm vào một tầng giữa đế mọi thông điệp từ người tiêu dùng gửi tới dịch vụ khách hàng phải thông qua tầng giữa này nhằm mục đích quản lý tập trung được các thông điệp và có chính sách phù hợp đê thực hiện load balancing và failover. Tầng giữa này được thiết kể thành một Enterprise service bus. Như vậy trong bước phân tích dịch vụ này ta có được bức tranh toàn cảnh về các thành phần của phần mềm như sau:

6 2 P1. Trading Application HOSE 1 HNX P4. HNX Gateway P3. HSX Gateway

P7. Enterprise Service Bus P6 Core Services

P5. Trading Services 0 P2. Bank Service Core Stock DataBase C T C K Back Office System

BAP Gateway

Core Banking D ataB ase

Hình 5.2: Các thành phần phần mềm được thiết kế theo kiến trúc SOA

Trong đó: Các thành phần P l, P5, P6, P7 trong hình vẽ là các thành phần cần thiết kế và xây dựng mới, các thành phần khác được tái sử dụng lại từ các thành phần cua hệ thống cũ.

P5. Trading Service

Dịch vụ này bao gồm các hàm chức năng để xử lý việc giao dịch lệnh của khách hàng, dịch vụ này kết nối với dịch vụ P2.Bank Service để kiếm tra tiền ở ngân hàng của tài khoản đồng thời kết nối với cơ sở dữ liệu để kiểm tra chứng khoán.

P6. Core Service

Dịch vụ này bao gồm tất cả các chức năng còn lại của hệ thống như quản lý cấu hình, quản lý tài khoản, kế toán giao dịch, báo cáo, quản lý người dùng.

Đây là thành phần lớp giữa (midleware) của dịch vụ giao dịch P5.Trading Services, các message được gửi tới P5.Trading Services sẽ được định tuyến thông qua thanh

Mục lục