LUẬN VĂN:ỨNG DỤNG KIẾN TRÚC HƯỚNG DỊCH VỤ TRONG BÀI TOÁN THANH TOÁN TẬP TRUNG

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN ĐỨC NGỌC

ỨNG DỤNG KIẾN TRÚC HƯỚNG DỊCH VỤ

TRONG BÀI TOÁN THANH TOÁN TẬP TRUNG

LUẬN VĂN THẠC SĨ

Hà Nội - 2010

ĐẠI HỌC QUỐC GIA HÀ NỘI

TRƯỜNG ĐẠI HỌC CÔNG NGHỆ

NGUYỄN ĐỨC NGỌC

ỨNG DỤNG KIẾN TRÚC HƯỚNG DỊCH VỤ

TRONG BÀI TOÁN THANH TOÁN TẬP TRUNG

Ngành : Công nghệ Thông tin

Chuyên ngành : Hệ thống thông tin

Mã số : 604805

LUẬN VĂN THẠC SĨ

NGƯỜI HƯỚNG DẪN KHOA HỌC: TS. NGUYỄN NGỌC HÓA

Hà Nội - 2010

LỜI CAM ĐOAN

Tôi xin cam đoan kết quả đạt được trong luận văn là sản phẩm của riêng cá nhân tôi. Trong toàn bộ nội dung của luận văn, những điều được trình bầy hoặc là của cá nhân hoặc là được tổng hợp từ nhiều nguồn tài liệu. Tất cả các tài liệu tham khảo đều có xuất xứ rõ ràng và được trích dẫn hợp pháp.

Tôi xin hoàn toàn chịu trách nhiệm và chịu mọi hình thức kỷ luật theo quy

định cho lời cam đoan của mình.

Hà Nội, ngày 30 tháng 5 năm 2010

Người cam đoan

Nguyễn Đức Ngọc

LỜI CẢM ƠN

Trong quá trình học tập và hoàn thành luận văn tốt nghiệp, tôi đã nhận được rẩt nhiều sự giúp đỡ, động viên từ thầy cô, gia đình và bạn bè. Tôi muốn bày tỏ sự cảm ơn sâu sắc của mình tới tất cả mọi người.

Tôi xin bày tỏ sự cám ơn đặc biệt tới TS Nguyễn Ngọc Hóa, người đã định hướng cho tôi trong lựa chọn đề tài, đưa ra những nhận xét quý giá và trực tiếp hướng dẫn tôi trong suốt quá trình nghiên cứu và hoàn thành luận văn tốt nghiệp.

Tôi xin cảm ơn các thầy cô trong khoa CNTT - Trường Đại học Công nghệ - ĐHQG Hà Nội đã dạy bảo tận tình cho tôi trong suốt khoảng thời gian học tập tại trường.

Tôi xin cảm ơn toàn thể bạn bè đồng nghiệp tại Trung tâm Công nghệ Thông tin Ngân hàng Đầu tư và Phát triển Việt Nam, đơn vị mà tôi đang công tác, đã chia sẻ, giúp đỡ tạo điều kiện cho tôi tham gia khoá học và hoàn thành khoá luận này. Xin cảm ơn tất cả những bạn bè đã giúp đỡ tôi trong suốt quá trình học tập và công tác.

Cuối cùng, tôi xin gửi lời cảm ơn sâu sắc nhất tới gia đình của mình, nguồn động viên và cổ vũ lớn lao và là động lực giúp tôi thành công trong công việc và trong cuộc sống. Hà Nội, ngày 30 tháng 5 năm 2010

Nguyễn Đức Ngọc

MỤC LỤC

LỜI CAM ĐOAN

LỜI CẢM ƠN

MỤC LỤC

DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ

DANH MỤC BẢNG BIỂU

DANH MỤC HÌNH VẼ

MỞ ĐẦU ....................................................................................................................1

Chương 1 - TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ..............................5

1.1 Mở đầu ........................................................................................................5

1.2 Kiến trúc hướng dịch vụ ...............................................................................7

1.2.1 Khái niệm về SOA ...........................................................................7

1.2.2 Kiến trúc SOA.................................................................................9

1.2.2.1 Tầng tầng thao tác hệ thống .................................................9

1.2.2.2 Tầng thành phần tác nghiệp ..................................................9

1.2.2.3 Tầng dịch vụ.......................................................................10

1.2.2.4 Tầng xử lý nghiệp vụ ..........................................................10

1.2.2.5 Tầng biểu diễn ....................................................................10

1.2.2.6 Tầng tích hợp......................................................................11

1.2.2.7 Tầng QoS(Tầng chất lượng dịch vụ) ...................................11

1.3 Các tính chất của một hệ thống SOA .........................................................11

1.4 Kết luận .....................................................................................................12

Chương 2 - CÁC BƯỚC TRIỂN KHAI MỘT ỨNG DỤNG THEO MÔ HÌNH SOA ..........................................................................................................................13

2.1 Các phương pháp tiếp cận trong triển khai SOA ........................................13

2.2 Quy trình phát triển ứng dụng theo mô hình SOA......................................14

2.2.1 Phân rã domain..................................................................................14

2.2.2 Xây dựng Goal-service ....................................................................16

2.2.3 Phân tích hệ thống con ....................................................................17

2.2.4 Đưa ra các dịch vụ...........................................................................17

2.2.5 Đặc tả thành phần............................................................................17

2.2.6 Cấu trúc thành phần và dịch vụ........................................................18

2.2.7 Lựa chọn giải pháp thực thi .............................................................18

2.3 SOA và Web Service...............................................................................18

2.3.1 Kiến trúc Web services....................................................................18

2.3.2 Simple Object Access Protocol – SOAP ..........................................20

2.3.3 Web Service Description Language (WSDL) ..................................21

2.3.4 UDDI ..............................................................................................22

2.4 Kết luận.......................................................................................................22

Chương 3 - ỨNG DỤNG SOA TRONG TÍCH HỢP HỆ THỐNG THANH TOÁN HÓA ĐƠN CỦA BIDV............................................................................................23

3.1 Phát biểu bài toán .......................................................................................23

3.2 Đề xuất mô hình SOA trong hệ thống thanh toán hoá đơn của BIDV ........23

3.3 Quy trình hoạt động....................................................................................25

3.4 Cơ sở dữ liệu .............................................................................................30

3.5 Thiết kế Web service dùng trong hệ thống .................................................30

3.6 Kết luận .....................................................................................................32

Chương 4 - THỰC NGHIỆM VÀ ĐÁNH GIÁ ......................................................33

4.1 Môi trường tích hợp...................................................................................33

4.2 Tích hợp thử nghiệm..................................................................................34

4.3 Kết quả thực nghiệm..................................................................................39

Chương 5 - KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN ...........................................59

TÀI LIỆU THAM KHẢO .......................................................................................60

PHỤ LỤC - CÁC USE CASE CỦA HỆ THỐNG THANH TOÁN HÓA ĐƠN....61

DANH MỤC CÁC TỪ VIẾT TẮT VÀ THUẬT NGỮ

BIDV

Bank for Investment and Development of Vietnam Ngân hàng Đầu tư và Phát triển Việt Nam

Corebanking Service Consumer

Service provider Service provider

là một hệ thể

Hệ thống ngân hàng cốt lõi Người sử dụng dịch vụ ở đây có thể là một ứng dụng, một dịch vụ hoặc là các module phần mềm khác yêu cầu sử dụng dịch vụ. Đây là thực thể thực thi quá trình định vị dịch vụ thông qua service registry, liên kết với dịch vụ và thực thi các chức năng của dịch vụ. Người sử dụng dịch vụ thực thi chức năng dịch vụ bằng cách một gửi yêu cầu theo đúng dịnh dạng được mô tả trong hợp đồng. Nhà cung cấp dịch vụ ở đây là một dịch vụ chấp nhận và xử lý những yêu cầu từ người sử dụng dịch vụ. thống Nó có mainframe, một thành phần hoặc các dạng phần mềm khác xử lý yêu cầu dịch vụ. Nhà cung cấp gửi hợp đồng lên service registry để những người sử dụng dịch vụ có thể truy cập đến nó.

Service Registry Service Registry

Service registry là chứa tất cả các dịch vụ đăng ký. Service registry chấp nhận và lưu trữ các hợp đồng gửi đến từ nhà cung cấp dịch vụ và cung cấp các hợp đồng tùy theo yêu cầu của người sử dụng dịch vụ.

Service contract Service contract

tích hợp SIBS SIBS Một hợp đồng (contract) là một đặc tả về cách thức bên sử dụng dịch vụ trao đổi liên lạc với bên cung cấp dịch vụ. Nó chỉ rõ ra định dạng và yêu cầu và đáp trả của dịch vụ Hệ thống ngân hàng Siverlake

Kiến trúc hướng dịch vụ SOA Service Oriented Architect

DANH MỤC BẢNG BIỂU

Bảng 1- Các yêu cầu triển khai thử nghiệm................................................................35

Bảng 2- Bảng kịch bản test dịch vụ vnmart................................................................47

Bảng 3 - Kết quả triển khai thực tế.............................................................................55

Bảng 4 - Các dịch vụ và kênh thanh toán dự kiến triển khai trong tương lai ...............56

Bảng 5 - Danh sách các use case hệ thống .................................................................62

DANH MỤC HÌNH VẼ

Hình 1- Các kênh giao dịch của ngân hàng khi cùng thực hiện thao tác chuyển khoản.5

Hình 2 - Kiến trúc EJB ................................................................................................6

Hình 3 - Mô hình CORBA...........................................................................................6

Hình 4 - Mô hình DCOM.............................................................................................7

Hình 5 - Các đối tượng trong SOA...............................................................................8

Hình 6 - Kiến trúc phân tầng của hệ thống SOA ..........................................................9

Hình 7 - Một khung nhìn chi tiết về một dịch vụ........................................................10

Hình 8 - Các dịch vụ khác nhau được cung cấp trên một website...............................10

Hình 9 - Các bước cần thực hiện khi triển khai một hệ thống SOA. ...........................13

Hình 10 - Phân rã domain hệ thống thanh toán hóa đơn ............................................14

Hình 11 – Danh sách use case khi triển khai theo mô hình SOA ................................15

Hình 12 – Các domain và use case sử dụng................................................................16

Hình 13 – Đưa các dịch vụ vào các thành phần..........................................................17

Hình 14 - Các tầng của Web service ..........................................................................19

Hình 15 - Tương tác giửa các tác nhân trong Web service .........................................19

Hình 16 - Truyền thông điệp sử dụng SOAP..............................................................20

Hình 17 - Cấu trúc SOAP message ............................................................................20

Hình 18 – WSDL.......................................................................................................21

Hình 19 - Mô hình tổng quát hệ thống thanh toán hoá đơn của BIDV ........................24

Hình 20- Web service dùng trong hệ thống thanh toán hoá đơn .................................32

Hình 21 - Môi trường RAD cuả IBM .........................................................................33

Hình 22 - Môi trường Message Queue của IBM.........................................................34

Hình 23 - Sơ đồ bảo mật của hệ thống thanh toán hoá đơn BIDV ..............................35

Hình 24 - Sơ đồ backup Database ..............................................................................36

Hình 25 - Màn hình đăng nhập hệ thống ....................................................................48

Hình 26 - Màn hình quản lý người sử dụng................................................................48

Hình 27 - Màn hình quản lý chi nhánh.......................................................................49

Hình 28 - Màn hình quản lý nhà cung cấp..................................................................49

Hình 29 - Màn hình quản lý dịch vụ...........................................................................50

Hình 30 - Màn hình đăng ký khách hàng....................................................................50

Hình 31 - Màn hình vấn tin hóa đơn ..........................................................................51

Hình 32 - Màn hình thanh toán hóa đơn.....................................................................51

Hình 33 - Các màn hình giao dịch tại ATM ...............................................................54

Hình 34- Màn hình Gateway xử lý từ các kênh thanh toán.........................................54

Hình 35 - Use case quản lý chi nhánh ........................................................................62

Hình 36 - Use case quản lý người sử dụng .................................................................66

Hình 37 - Use case quản lý nhà cung cấp ..................................................................71

Hình 38 - Use case quản lý dịch vụ............................................................................76

Hình 39 - Use case quản lý khách hàng......................................................................81

Hình 40 - Use case xử lý thanh toán hoá đơn .............................................................86

Hình 41 - Use case đăng nhập....................................................................................92

MỞ ĐẦU

Trong thời kỳ phát triển và hội nhập kinh tế thế giới của Việt Nam những năm gần đây các doanh nghiệp Việt Nam gặp rất nhiều khó khăn khi phải cạnh tranh với các doanh nghiệp nước ngoài không những mạnh về quản trị nhân lực, mạnh về vốn và cả công nghệ…

Việc áp dụng khoa học công nghệ vào lĩnh vực kinh tế, trong đó có ngành Ngân hàng, một trong những ngành kinh tế đặc biệt tác động trực tiếp đến hệ thống tài chính của quốc gia, trở nên cấp thiết hơn bao giờ hết.

Trong quá trình điều hành và vận hành hệ thống Ngân hàng, điều mà các lãnh đạo quan tâm nhất là làm sao nắm bắt được tình hình hoạt động của hệ thống mình một cách nhanh nhất, chính xác và kịp thời nhất, để đưa ra các quyết định đúng đắn, giảm tối thiểu rủi ro, đảm bảo lợi ích của Ngân hàng mình. Hơn nữa, các ngân hàng thương mại còn phải hướng đến việc nâng cao chất lượng dịch vụ để phục vụ khách hàng. Với việc Việt Nam chính thứ gia nhập tổ chức thương mại thế giới WTO thì các ngân hàng đang phải đối mặt với sự cạnh tranh của các ngân hàng ngoại vốn mạnh về tài chính và công nghệ và còn phải cạnh tranh khốc liệt với khối ngân hàng nội đang từng bước lớn mạnh.

Để cạnh tranh được thì vấn đề cốt lõi của các ngân hàng là phải hiện đại hóa về hệ thống CNTT mà nền tảng là đa dạng hóa dịch vụ. Một trong những dịch vụ quan trong cần phải đặc biệt chú trong dó chính là dịch vụ thanh toán tập trung tại ngân hàng.

Bài toán thực tế

Trước khi đi vào mục tiêu chính của luận văn, chúng ta sẽ phân tích bài toán

thực tế tại ngân hàng Đầu tư và phát triển Việt Nam BIDV như sau:

(i) Tập đoàn điện lực Việt Nam EVN từ trước đến nay đều thu tiền điện qua mạng lưới cộng tác viên đến thu tiền trực tiếp tại nhà dân hay tại các điểm thu tiền của EVN. Điều này dẫn tới mạng lưới đội ngũ cộng tác viên này rất lớn phức tạp trong quản lý. Hơn nữa số tiền mà các cộng tác viên này thu được phải mất vài ngày đến hàng tuần mới đến nộp được cho sở điện lực. Nếu số tiền này mà được gửi ngay tại ngân hàng thì EVN vừa dễ quản lý và theo dõi lại được phát sinh một số tiền lãi rất lớn. Ngoài ra cũng tránh được nhiều nguy cơ rủi ro như tiền giả, cộng tác viên dùng sai mục đích…

Các yêu cầu về thanh toán cước viễn thông trả sau với Tổng công ty viễn thông quân đội Viettel, với tập đoàn bưu chính viễn thông Việt Nam VNPT, với công ty viễn thông điện lực EVN Telecom, thu hộ tiền nước…

(ii) Dịch vụ nạp tiền cho thuê bao trả trước với nhà cung cấp dịch vụ VNPAY : Thay vì phải đến các điểm bán thẻ trả trước để cào lấy mã số thẻ rồi nạp tiền thì khách

hàng có thêm một kênh là nạp tiền cho điện thoại di động qua tin nhắn hay mua thẻ tại ATM thông qua mở tài khoản tại ngân hàng.

(iii) Dịch vụ nạp tiền ví điện tử vnmart: Đây là dịch vụ phối hợp với với công ty VNPAY. Dịch vụ thanh toán trực tuyến mới phát triển trong vài năm gần đây tại Việt Nam. Đây là dịch vụ giúp chủ thẻ tại BIDV có thể nạp rút tiền vào tài khoản ảo qua đó dùng ví điện tử này kết hợp với các website bán hàng trực tuyến để thanh toán trực tuyến. Khi dùng dịch vụ ví điện tử này sẽ đảm bảo an toàn hơn khi thanh toán trực tuyến thay vì thanh toán trực tuyến bằng tài khoản ngân hàng. Sự phát triển của dịch vụ gắn liền với sự quảng bá dịch vụ với các website bán hàng trực tuyến.

(iv) Dịch vụ nạp tiền tài khoản Vietpay: Đây là dịch vụ phối hợp với với công ty VietPay dùng để nạp tiền game cho các ại lý.

(v) Dịch vụ thanh toán vé máy bay Jetstart: Đây là dịch vụ phối hợp với với công ty Onepay triển khai qua hai kênh ATM và quầy giao dịch : Khách hàng sau khi vào website của jetstart pacific để đặt chỗ rồi sẽ qua ATM hay quầy giao dịch của BIDV để thanh toán bằng cách nhập vào mã đặt chỗ. Đây là dịch vụ sẽ rất hữu ích tại những nơi không có đại lý bán vé máy bay của Jetstart đặc biệt tại các tỉnh và các huyện xa.

(vi) Dịch vụ mua bảo hiểm xe máy, ô tô qua ATM với công ty bảo hiểm BIDV (BIDV Insurance Company BIC) : Thay vì ra các đại lý bảo hiểm thì khách hàng là chủ thẻ của BIDV có thể ra ATM để đặt mua bảo hiểm ô tô, xe máy. Phương thức này giúp khách hàng có thể tiết kiệm được thời gian đồng thời có tỉ lệ chiết khấu cao hơn khi ra đại lý mua vì công ty bảo hiểm sẽ không phải trích trả cho đại lý. Đây cũng là hình thức quảng bá sự đa dạng dịch vụ cho BIDV. Dịch vụ này mới triển khai.

(vii) Dịch vụ thanh toán phí bảo hiểm qua ATM với công ty bảo hiểm Prudential: Phí đóng bảo hiểm hàng tháng sẽ được công ty gửi cho khách hàng qua bưu điện, email, điện thoại…Khách hàng chỉ cần ra ATM nhập mã hợp đồng và số tiền phải đóng vào là có thể thanh toán được phí bảo hiểm với Prudential. Đây cũng là một dịch vụ rất mới giúp cho công ty bảo hiểm giảm bớt số lượng cộng tác viên đồng thời giúp quản lý dòng tiền thu được từ khách hàng một cách nhanh chóng chính xác tránh nhiều rủi ro khi cần đội ngũ cộng tác viên đi thu như mất tiền, tiền không hợp lệ…

Nắm bắt được các yêu cầu của các doanh nghiệp trong nghiệp vụ thanh toán hóa đơn cũng như phát triển thêm thanh toán không dùng tiền mặt đồng thời đẩy mạnh phát triển dịch vụ tại BIDV. BIDV đã tiến hành khảo sát và ký kết với các đơn vị trên để phát triển một cổng thanh toán đáp ứng được các nghiệp vụ thanh toán hóa đơn. Vấn đề là cổng thanh toán đó phải tích hợp được nhiều kênh thanh toán như ATM, quầy, SMS… đồng thời phải mở rộng được các nhà cung cấp dịch vụ mới.

Kiến trúc hướng dịch vụ SOA (Service Oriented Architecture) ra đời như là giải pháp tối ưu để tích hợp các dịch vụ giữa BIDV và các nhà cung cấp để giải quyết bài toán thanh toán trên.

SOA là một trong những hướng thời sự hiện nay của ngành công nghệ thông tin. Nó cho phép cung cấp những dịch vụ có tính đầy đủ nhất đối với nhu cầu của người sử dụng. Vấn đề tích hợp được đặt ra để cho phép các ứng dụng, cơ sở dữ liệu riêng lẻ có thể tích hợp với nhau trong các quy trình nghiệp vụ và không chỉ giới hạn trong nội bộ doanh nghiệp mà còn có khả năng tích hợp với các quy trình của khách hàng và đối tác bên ngoài. Tuy nhiên, trong đa số trường hợp, việc tích hợp chỉ mới dừng lại ở mức tích hợp doanh nghiệp và trong một số ít trường hợp ở mức tích hợp logic nghiệp vụ, sử dụng các phương cách tích hợp truyền thống như tích hợp điểm-nối-điểm (hai ứng dụng cần trao đổi thông tin sẽ kết nối trực tiếp với nhau), tích hợp tĩnh (ví dụ như viết các mã tích hợp đan xen với mã ứng dụng nên khó thay đổi trong tương lai). Theo thời gian, phương cách tích hợp truyền thống sẽ tạo ra một hệ thống kết nối chồng chéo, phụ thuộc lẫn nhau một cách chặt chẽ, rất khó chỉnh sửa khi yêu cầu nghiệp vụ thay đổi, dẫn đến chi phí tích hợp ngày càng gia tăng đáng kể.

Một số tổ chức, doanh nghiệp Việt Nam đang bước đầu tiếp cận kiến trúc tích hợp linh hoạt của SOA và thường bắt đầu theo hai hướng: tích hợp con người nhằm nâng cao năng suất làm việc và mở rộng thêm các kênh truy cập vào hệ thống ứng dụng bằng cách xây dựng cổng làm việc điện tử, cổng giao dịch điện tử... Ngoài hai hướng này, các hướng tiếp cận khác của SOA bao gồm tích hợp và tự động hóa quy trình nghiệp vụ, tích hợp thông tin và xây dựng kho tài nguyên dịch vụ có khả năng sử dụng lại trong các ứng dụng mới. SOA là một mô hình kiến trúc tích hợp hiện đại dựa trên khái niệm dịch vụ. Các chức năng nghiệp vụ và cơ sở hạ tầng được cung cấp như là các dịch vụ, các dịch vụ này riêng lẻ hoặc kết hợp với nhau sẽ cung cấp các chức năng ứng dụng cho các ứng dụng đầu cuối hoặc cho các dịch vụ khác. Các dịch vụ được kết nối với nhau thông qua trục tích hợp doanh nghiệp, xây dựng theo kiến trúc bus thay cho kiến trúc điểm-nối-điểm. Nhờ kiến trúc tích hợp linh hoạt của SOA, doanh nghiệp có thể xây dựng các hệ thống linh hoạt cho phép thay đổi các quy trình nghiệp vụ nhanh chóng và có thể tái sử dụng các cấu thành hệ thống.

Dịch vụ là yếu tố then chốt trong SOA. Có thể hiểu dịch vụ như là hàm chức năng (mô-đun phần mềm) thực hiện qui trình nghiệp vụ nào đó. Một cách cơ bản, SOA là tập hợp các dịch vụ kết nối 'mềm dẻo' với nhau (nghĩa là một ứng dụng có thể 'nói chuyện' với một ứng dụng khác mà không cần biết các chi tiết kỹ thuật bên trong), có giao tiếp (dùng để gọi hàm dịch vụ) được định nghĩa rõ ràng và độc lập với nền tảng hệ thống, và có thể tái sử dụng. SOA là cấp độ cao hơn của phát triển ứng dụng, chú trọng đến qui trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự phức tạp kỹ thuật bên dưới.

Thiết kế SOA tách riêng phần thực hiện dịch vụ (phần mềm) với giao tiếp gọi dịch vụ. Điều này tạo nên một giao tiếp nhất quán cho ứng dụng khách (client) sử dụng dịch vụ bất kể công nghệ thực hiện dịch vụ. Thay vì xây dựng các ứng dụng đơn lẻ và đồ sộ, nhà phát triển sẽ xây dựng các dịch vụ tinh gọn có thể triển khai và tái sử dụng trong toàn bộ quy trình nghiệp vụ. Điều này cho phép tái sử dụng phần mềm tốt

hơn, cũng như tăng sự linh hoạt vì nhà phát triển có thể cải tiến dịch vụ mà không làm ảnh hưởng đến ứng dụng client sử dụng dịch vụ.

Ưu điểm quan trọng nhất của SOA là khả năng kết nối "mềm dẻo" (nhờ sự

chuẩn hóa giao tiếp) và tái sử dụng. Các dịch vụ được đóng gói có thể được gọi bởi ngôn ngữ bất kỳ.

Với ngữ cảnh đó, luận văn hướng đến mục tiêu tập trung nghiên cứu, tìm hiểu sâu về mô hình kiến trúc hướng dịch vụ, từ đó ứng dụng trong bài toán thanh toán tập trung tại ngân hàng BIDV.

Nội dung chính của luận văn được tổng hợp, trình bày trong 5 chương chính sau:

- Chương 1: Giới thiệu khái niệm về kiến trúc hướng dịch vụ SOA, các tính chất của hệ thống SOA. Chương này cũng trình bày về kiến trúc phân tầng của hệ thống SOA.

- Chương 2: Chương thứ hai của luận văn đề cập đến xây dựng một bài toán

dựa theo mô hình SOA, giới thiệu về Web Service… - Chương 3: Chương này đưa ra ứng dụng SOA trong bài toán thanh toán hoá đơn của BIDV bao gồm phát biểu bài toán, mô hình tích hợp đề xuất và nêu quy trình hoạt động của bài toán, thiết kế chi tiết bài toán. - Chương 4: Giới thiệu môi trường phát triển và triển khai hệ thống thanh toán hoá đơn, chính sách bảo mật của hệ thống, kết quả thực nghiệm sau khi triển khai. - Chương 5: Kết luận và hướng phát triển của đề tài.

Chương 1 - TỔNG QUAN VỀ KIẾN TRÚC HƯỚNG DỊCH VỤ

1.1 Mở đầu

Trong những năm qua có rất nhiều kiến trúc phần mềm đã và đang được xây dựng và triển khai nhằm giải quyết các vấn đề như giảm chi phí phát triển phần mềm, giảm chi phí bảo trì vận hành phần mềm...

Rất nhiều hãng phần mềm khác nhau trên thế giới đã nghiên cứu, tìm tòi nhiều công nghệ mới, nhiều kiến trúc phần mềm khác nhau nhưng lại dựa trên các chuẩn khác nhau dẫn đến môi trường không đồng nhất. Nhiều hệ thống cũ thay vì được sử dụng lại thì lại được xây dựng lại từ đầu dẫn đến quá tốn kém về thời gian và tiền bạc. Hơn nữa giữa các hệ thống khác nhau, các môi trường khác nhau sẽ không thể giao tiếp được với nhau một khi chưa thống nhất được chuẩn để giao tiếp với nhau. Đó là khó khăn rất lớn trong quá trình tích hợp các hệ thống với nhau.

Một nguyên nhân cũng gây rất nhiều khó khăn cho các đơn vị tích hợp hệ thống là vấn đề lập trình dư thừa và không tái sử dụng được. Ví dụ như Ngân hàng A phát triển một dịch vụ như chuyển khoản qua các kênh ATM, quầy giao dịch và internet của Ngân hàng A. Các dịch vụ này đều có mục đích là truy nhập vào CoreBanking để thực hiện giao dịch cộng tiền vào tài khoản đích và trừ tiền vào tài khoản nguồn. Nếu không được tái sử dụng thì ở mỗi kênh trên ta đều gặp phải bài toán là viết một đoạn chương trình thực hiện ghi có tài khoản đích và ghi nợ tài khoản nguồn. Hơn nữa với tưng kênh giao dịch lại sử dụng môt ngôn ngữ lập trình khác nhau dẫn tới tốn rất nhiều thời gian và công sức thể thực hiện bài toán cho các kênh đó.

Hình 11- Các kênh giao dịch của ngân hàng khi cùng thực hiện thao tác chuyển khoản

Cứ khi triển khai thêm một kênh mới như SMS, Mobile… thì công việc chuyển khoản lại phải xây dựng gây sự nhàm chán, tốn chi phí thời gian và tiền bạc với người lập trinh viên. Như Hình 1 thì lập trình viên phải viết lại đoạn chương trình thực hiện chuyển khoản trên các ngôn ngữ khác nhau.

Về mô hình kiến trúc phần mềm truyền thống, đã có rất nhiều cách tiếp cận

khác nhau đối với việc xây dựng, phát triển các ứng dụng phân tán chẳng hạn:

 EJB (Enterprise Java Beans)

Hình 2 2- Kiến trúc EJB

 Common Object Request Broker Architecture (CORBA ) :

Hình 3 3- Mô hình CORBA

 DCOM – Distributed Component Object Model:

Hình 44 - Mô hình DCOM

Các kiến trúc trên đều yêu cầu kiến trúc triển khai cài đặt bên phía nhà cung cấp dịch vụ và phía sử dụng dịch vụ phải giống nhau. Mỗi khi có một sự thay đổi thì thì yêu cầu đều phải thay đổi cả bên cung cấp dịch vụ và bên triệu gọi sử dụng dịch vụ. Các kiến trúc trên đa phần là chuẩn đóng rất khó để giao tiếp với các chuẩn khác…

Chính vì những nhược điểm của các mô hình đã có yêu cầu tìm ra một kiến trúc mới có thể tương thích được các chuẩn, các môi trường và sử dụng lại được các hệ thống cũ. Kiến trúc hướng dịch vụ (Service-Oriented Architecture - SOA) ra đời giúp giải quyết các nhược điểm của các mô hình phân tán đã có.

1.2 Kiến trúc hướng dịch vụ

1.2.1 Khái niệm về SOA

Trước khi ta hiểu khái niệm kiến trúc hướng dịch ta ta tìm hiểu khái niệm về

dịch vụ là gì?

Dịch vụ là là các thành phần logic dùng để thực hiện một thao tác nghiệp vụ

được truy nhập qua internet sử dụng các chuẩn mở.

Kiến trúc hướng dịch vụ là một tập hợp các dịch vụ được chuẩn hoá trên mạng trao đổi với nhau trong ngữ cảnh một tiến trình nghiệp vụ. Dịch vụ là yếu tố then chốt trong SOA. SOA là tập hợp các dịch vụ kết nối ‘mềm dẻo’ với nhau (nghĩa là một ứng dụng có thể ‘nói chuyện’ với một ứng dụng khác mà không cần biết các chi tiết kỹ thuật bên trong), có giao tiếp (dùng để gọi hàm dịch vụ) được định nghĩa rõ ràng và độc lập với nền tảng hệ thống, và có thể tái sử dụng. SOA là cấp độ cao hơn của phát triển ứng dụng, chú trọng đến qui trình nghiệp vụ và dùng giao tiếp chuẩn để giúp che đi sự phức tạp kỹ thuật bên dưới.

Thiết kế SOA tách riêng phần thực hiện dịch vụ (phần mềm) với giao tiếp gọi dịch vụ. Điều này tạo nên một giao tiếp nhất quán cho ứng dụng khách (client) sử dụng dịch vụ bất chấp công nghệ thực hiện dịch vụ. Thay vì xây dựng các ứng dụng

đơn lẻ và đồ sộ, nhà phát triển sẽ xây dựng các dịch vụ tinh gọn có thể triển khai và tái sử dụng trong toàn bộ quy trình nghiệp vụ. Điều này cho phép tái sử dụng phần mềm tốt hơn, cũng như tăng sự linh hoạt vì nhà phát triển có thể cải tiến dịch vụ mà không làm ảnh hưởng đến ứng dụng client sử dụng dịch vụ.

SOA Trong SOA[5]-[8]-[11] có ba đối tượng chính là nhà cung cấp dịch vụ (service provider), người sử dụng dịch vụ (service consumer) và nơi lưa trữ dịch vụ (service registry) như minh họa trong Hình 5

Nơi đăng ký dịch vụ (Service Registry)

Tìm dịch vụ() Xuất bản dịch vụ ()

Gọi dịch vụ()

Nhà cung cấp dịch vụ (Service Provider) Người sử dụng dịch vụ (Service Consumer)

Hình 55 - Các đối tượng trong SOA

Nhà cung cấp dịch vụ (service provider) : Cung cấp thông tin về dịch vụ cho

một nơi lưu trữ thông tin dịch vụ (service registry).

Người sử dụng dịch vụ (service consumer) : Thông qua service registry để tìm kiếm thông tin mô tả về dịch vụ cần tìm và sau đó là xây dựng kênh giao tiếp với phía nhà cung cấp.

Nơi lưu trữ thông tin dịch vụ (service registry) : Là nơi lưu trữ các dịch vụ khi một dịch vụ của nhà cung cấp dịch vụ được đưa ra. Đây chính là nơi người sử dụng dịch vụ có thể tìm và triệu gọi các dịch vụ được cung cấp.

SOA cung cấp giải pháp để giải quyết các vấn đề tồn tại của các hệ thống hiện nay như: phức tạp, không linh hoạt và không ổn định. Một hệ thống triển khai theo mô hình SOA có khả năng dễ mở rộng, liên kết tốt. Đây chính là cơ sở và nền tảng cho việc tích hợp, tái sử dụng lại những tài nguyên hiện có.

Tư tưởng của SOA không hoàn toàn mới, DCOM và CORBA cũng có kiến trúc tương tự. Tuy nhiên, các kiến trúc cũ ràng buộc các thành phần với nhau quá chặt, ví dụ như các ứng dụng phân tán muốn làm việc với nhau phải đạt được thỏa thuận về chi tiết tập hàm API, một thay đổi mã lệnh trong thành phần COM sẽ yêu cầu những thay đổi tương ứng đối với mã lệnh truy cập thành phần COM này.

Ưu điểm quan trọng nhất của SOA là khả năng kết nối mềm và tái sử dụng. Các dịch vụ có thể được sử dụng với trình client chạy trên nền tảng bất kỳ và được viết với ngôn ngữ bất kỳ. Ví dụ như ứng dụng Java có thể liên kết với dịch vụ web .NET và ngược lại.

SOA dựa trên 2 nguyên tắc thiết kế quan trọng:

 Mô-đun hoá: Tách vấn đề lớn thành nhiều vấn đề nhỏ.

 Đóng gói: Che đi dữ liệu và lô-gic trong từng mô-dun đối với truy cập từ

ngoài.

Sau đây sẽ trình bày về kiến trúc phân tầng của SOA.

1.2.2 Kiến trúc SOA

Sau đây là kiến trúc phân tầng của SOA[7] -[8] gồm 7 tầng chính là : Tầng Operational Systems (tầng tích hợp các hệ thống cũ đang hoạt động), tầng Enterprise components ( tầng thành phần tác nghiệp), tầng dịch vụ, tầng xử lý nghiệp vụ, tầng biểu diễn, tầng tích hợp và tầng theo dõi, quản lý chất lượng dịchvụ.

Hình 6 - Kiến trúc phân tầng của hệ thống SOA

1.2.2.1 Tầng tầng thao tác hệ thống

Mục đích tầng này là gọi đến các ứng dụng cũ đã xây dựng trước đó như các ứng dụng xây dựng bằng các ngôn ngữ lập trình hướng đối tượng cũ, các ứng dụng thực hiện các thao tác nghiệp vụ thông minh, các gói ứng dụng CRM, ERP..

Để tích hợp các hệ thống đã tồn tại này thì dùng kỹ thuật tích hợp hướng dịch

vụ.

1.2.2.2 Tầng thành phần tác nghiệp

Tầng này có nhiệm vụ thực hiện các chức năng và vận hành các dịch vụ đưa ra.

Tầng này quản lý các tài nguyên mức đơn vị nghiệp vụ.

1.2.2.3 Tầng dịch vụ

Tầng dịch vụ đưa ra các đặc tả dịch vụ, đặc tả các đơn vị thành phần nghiệp vụ.

1.2.2.4 Tầng xử lý nghiệp vụ

Các dịch vụ được đưa vào thành 1 luồng để xử lý như một ứng dụng đơn lẻ. Tầng này hỗ trợ đặc tả các use case và thực hiện các quy trình nghiệp vụ.

1.2.2.5 Tầng biểu diễn

Hình 7 - Một khung nhìn chi tiết về một dịch vụ

Hình 8 - Các dịch vụ khác nhau được cung cấp trên một website

Tầng biểu diễn cung cấp các ứng dụng cho người dùng cuối dưới dạng các dịch vụ được xây dựng từ các tầng trên. Người dùng cuối sẽ không quan tâm đến xử lý trong bản thân các dịch vụ mà chỉ quan tâm đến đầu vào và đầu ra của dịch vụ.

1.2.2.6 Tầng tích hợp

Tầng này cho phép tích hợp các dịch vụ trước đó như đưa ra tập các khả năng tin cậy như định tuyến thông minh, các giao thức điều chỉnh hoặc các cơ chế chuyển đổi khác thường được miêu tả là ESB.

1.2.2.7 Tầng QoS(Tầng chất lượng dịch vụ)

Tầng này cung cấp các khả năng để quản lý, theo dõi,vận hành chất lượng các

dịch vụ như an ninh, hiệu năng xử dụng của hệ thống và độ sẵn sàng của hệ thống. Đây là bước xử lý phía sau và cần cài đặt các công cụ để theo dõi vận hành ứng dụng SOA.

1.3 Các tính chất của một hệ thống SOA

SOA gồm các tính chất cơ bản sau [8]-[9]

 Sử dụng lại dịch vụ

Trong SOA tính chất sử dụng lại dịch vụ cho phép các một dịch vụ mới có thể tái sử dụng các dịch vụ đã. Tái sử dụng lại các dịch vụ còn giúp loại bỏ những thành phần dư thừa giúp giảm thời gian và chi phí cho việc phát triển và quản trị phần mềm.

 Tính đóng gói dịch vụ

Tính đóng gói dịch vụ trong SOA nghĩa là các thành phần sử dụng thuộc phạm vi bên ngoài của mỗi dịch vụ sẽ không được biết đến cài đặt của dịch vụ đó. Các đối tượng sử dụng dịch vụ sẽ chỉ cần quan tâm đến đặc tả của dịch vụ. Các chức năng chỉ được cung cấp thông qua các giao diện mà dịch vụ đó cung cấp. Tính đóng gói dịch vụ kế thừa từ kiến trúc hướng đối tượng đã có trước đó.

 Sử dụng dịch vụ bất đồng bộ

SOA hỗ trợ triệu gọi bất đồng bộ : Bên gọi gửi thông điệp sang bên nhận xử lý mà không cần chờ bên nhận xử lý xong thông điệp. Do bên gọi không phải chờ cho đến khi yêu cầu được xử lý xong và trả về nên không bị ảnh hưởng bởi việc xử lý trễ và lỗi khi thực thi các dịch vụ bất đồng bộ. Trên lý thuyết một hệ thống SOA có thể hỗ trợ gửi và nhận cả thông điệp đồng bộ và bất đồng bộ.

 Khả năng cộng tác

Khả năng cộng tác (Interoperability) là khả năng mà các hệ thống có thể giao

tiếp với nhau trên nhiều nền tảng và ngôn ngữ khác nhau.  Dò tìm dịch vụ (service discovery)

Dò tìm dịch vụ (service discovery): Trong SOA hỗ trợ dò tìm dịch vụ. Đối tượng sử dụng dịch vụ sẽ tìm các dịch vụ lưu trữ trong service registry nhờ SOA hỗ trợ dò tìm dịch vụ.

 Loose coupling

Trong SOA các thành phần giao tiếp với nhau sẽ có sự ràng buộc vơi nhau. Sự ràng buộc mang tính loose coupling có nghĩa là ràng buộc được mô tả rõ ràng. Hầu như mọi kiến trúc phần mềm đều hướng đến tính loose coupling giữa các module. Mức độ kết dính của mỗi hệ thống ảnh hưởng trực tiếp đến khả năng chỉnh sửa hệ thống của chính nó. Kết dính càng chặt bao nhiêu thì càng có nhiều thay đổi liên quan cần chỉnh sửa ở phía sử dụng dịch

1.4 Kết luận

Chương 1 trình bày về một số khó khăn của ngành công nghệ phần mềm hiện nay. Từ đó giới thiệu, phân tích các ưu khuyết điểm của một số mô hình kiến trúc phân tán được xây dựng để giải quyết các khó khăn trên như là EJB,CORBA, DCOM… Chương này cũng giới thiệu khái niệm về kiến trúc hướng dịch vụ SOA, các tính chất của hệ thống SOA, giới thiệu về kiến trúc phân tầng của hệ thống SOA…

Chương 2 - CÁC BƯỚC TRIỂN KHAI MỘT ỨNG DỤNG THEO MÔ HÌNH SOA

2.1 Các phương pháp tiếp cận trong triển khai SOA

Phần này sẽ giới thiệu các phương pháp để xác định các dịch vụ hai phương pháp cơ bản là phương pháp top-down (xuất phát từ các yêu cầu nghiệp vụ) và bottom-up (xuất phát từ thực trạng của hệ thống hiện có).

• Top-down : trong xây dựng một hệ thống SOA, thì phương pháp top-down là phương pháp mà điểm xuất phát của nó sẽ là từ các yêu cầu nghiệp vụ để xác định các yêu cầu chức năng, các tiến trình và tiến trình con, các trường hợp sử dụng (use cases) để tiến tới việc xác định các thành phần hệ thống (components), các dịch vụ…

• Bottom-up : phương pháp này sẽ dựa trên việc phân tích tình trạng, các tài nguyên của hệ thống hiện có và sẽ tái sử dụng lại những thành phần này trong việc xây dựng các dịch vụ mới. Phương pháp này bao gồm 7 bước chính được thể hiện ở Hình 9[5].

Hình 9 - Các bước cần thực hiện khi triển khai một hệ thống SOA.

Trong Hình 9 ta sẽ tiếp cận mô hình theo phương pháp top-down đi từ trên xuống.Với các bước mà song song nhau thì trong thực tế có thể tiến hành cùng một lúc. Các bước chính để xây dựng hệ thống dựa trên SOA đó là :

1. Phân rã domain 2. Xây dựng mô hình Goal-service 3. Phân tích hệ thống con 4. Đưa ra các dịch vụ 5. Đặc tả thành phần 6. Cấu trúc thành phần và dịch vụ 7. Lựa chọn công nghệ thực hiện.

Sau đây ta sẽ xét chi tiết các bước phát triển theo mô hình SOA trên.

2.2 Quy trình phát triển ứng dụng theo mô hình SOA

Ta xét tới bài toán thanh toán hóa đơn của Ngân hàng Đầu tư và Phát triển Việt Nam(BIDV) : Khách hàng có thể ra ATM hoặc quầy giao dịch của BIDV để thanh toán các loại hóa đơn tiền điện, nước…

2.2.1 Phân rã domain

Trong quy trình phát triển ứng dụng theo mô hình SOA.Bước này dùng để phân rã toàn bộ qui trình nghiệp vụ thành các quy trình nghiệp vụ con, tiến trình con[3]- [5]. Hình 10 cho biết quá trình phân rã domain áp dụng cho bài toán thanh toán hóa đơn trên sẽ gồm 4 hệ thống con là ATM, Web Server, CoreBanking, Nhà cung cấp dịch vụ.

ATM

Web Server

CoreBanking

Nhà cung cấp dịch vụ

Hình 10 - Phân rã domain hệ thống thanh toán hóa đơn

Sau khi phân rã domain thành một dãy các vùng chức năng liên quan, ta tiếp tục phân tích từng vùng chức năng để xác định các sơ đồ use case .

Hình 11 – Danh sách use case khi triển khai theo mô hình SOA

Hình 11 cho ta biết danh sách các use case của hệ thanh toán hóa đơn:

• Use case Vấn tin nhà cung cấp : Trên ATM khi lựa chọn giá trị gia tăng sẽ hiển thị ra danh sách các nhà cung cấp dịch vụ để khách hàng có thể lựa chọn.

• Use case Vấn tin dịch vụ : Sau khi đã hiển thị danh sách nhà cung cấp thì khác hàng lựa chọn nhà cung cấp để lấy ra danh sách các dịch vụ được cung cấp.

• Use case Vấn tin hóa đơn : Đây là use case sẽ xử dụng hai use case con. - Use case vấn tin tài khoản SIBS : Đây là use case dùng để lấy thông tin của một tài khoản trên CoreBanking SIBS như họ tên tài khoản, số dư, số dư khả dụng, số cif… - Use case vấn tin hóa đơn bên nhà cung cấp : Dùng để lấy thông tin khách hàng bên nhà cung cấp như họ tên khách hàng, địa chỉ khách hàng, kì hóa đơn, số tiền trong kỳ, chi tiết hóa đơn… • Use case Gạch nợ : Use case này cũng xử dụng hai Use con.

- Use case Hạch toán tài khoản trong CoreBanking : Có chức năng trừ tiền khách hàng bằng với số tiền trên hóa

đơn mà khách hàng nợ bên nhà cung cấp, cộng tiền vào tài khoản nhà cung cấp số tiền tương ứng.

- Use case gạch nợ hóa đơn bên nhà cung cấp : Sau khi đã trừ tiền khách hàng trong CoreBanking của ngân hàng sẽ gửi sang bên nhà cung cấp để yêu cầu nhà cung cấp xóa nợ cho khách hàng.

• Use case Hủy gạch nợ : Use case này cũng xử dụng hai Use con.

- Use case hủy hạch toán tài khoản trong CoreBanking : Khi phát sinh một lỗi như timeout hay gạch nợ hóa đơn bên nhà cung cấp không thành công thì sẽ yêu cầu hoàn tiền cho khách hàng. Use case này sẽ làm nhiệm vụ hủy giao dịch hạch toán trong CoreBanking trước đó để hoàn lại tiền cho khách hàng.

- Use case hủy gạch nợ bên nhà cung cấp : Một khi đã hoàn tiền cho khách hàng trong tài khoản CoreBanking ngân hàng thì sẽ yêu cầu bên nhà cung cấp hủy giao dịch xóa nợ trước đó để khách hàng vẫn nợ hóa đơn trước đó. Các thành phần hệ thống con với các use case tạo thành các miền nghiệp vụ sau :

ATM Web Server

Use case : 1.Vấn tin dịch vụ 2.Thanh toán hóa đơn, 3.Hủy thanh toán

Use case : 1.Vấn tin nhà cung cấp 2.Vấn tin hóa đơn 3.Vấn tin dịch vụ 4.Thanh toán hóa đơn, 5.Hủy thanh toán

Nhà cung cấp dịch vụ CoreBanking

khoản tin tài

tài khoản Use case : 1.Vấn tin hóa đơn 2.Gạch nợ hóa đơn 3.Hủy gạch nợ hóa đơn.

Use case : 1.Vấn CoreBanking toán 2.Hạch CoreBanking 3.Hủy hạch toán tài khoản CoreBanking

Hình 12 – Các domain và use case sử dụng

2.2.2 Xây dựng Goal-service

Mục đích của xây dựng goal-service[5] này là kiểm tra “các ứng cử viên” trong các mục tiêu trên có thật sự là tốt không? Ta sẽ xuất phát từ mục tiêu chính (goal) và từng bước phân tích để xác định các công việc cần làm để đạt được mục tiêu

chính đó là gì (sub-goal). Quá trình phân rã như thế (goal thành các sub-goal) sẽ được thực hiện cho tới khi nào ta thấy rằng “mục tiêu này có thể được thực hiện bởi một dịch vụ nào đó Trong quá trình xây dựng mô hình goal-service này, ta sẽ xác định thêm các dịch vụ cần thiết.

2.2.3 Phân tích hệ thống con

Trong giai đoạn này các use case nghiệp vụ sẽ là dùng để thiết kế các use case hệ thống. Hệ thống con bao gồm các thành phần nghiệp vụ.

Trong bài toán thanh toán hóa đơn, có các hệ thống con được phân rã trong bước phân rã domain là ATM, Web Server, CoreBanking và Nhà cung cấp dịch vụ. Mỗi hệ thống con cung cấp một tập các service nghiệp vụ . Một use case nghiệp vụ có thể bao gồm 1 hoặc nhiều use case hệ thống. Như trong nghiệp vụ vấn tin hóa đơn sẽ có hai use case hệ thống là use case vấn tin thông tin tài khoản trong CoreBanking và use case vấn tin hóa đơn bên Nhà cung cấp dịch vụ.

2.2.4 Đưa ra các dịch vụ

Các dịch vụ đã được xác định qua hai giai đoạn là phân rã domain và xây dựng mô hình goal-service[5]. Trong giai đoạn này, chúng ta sẽ thực hiện đưa các dịch vụ này vào các thành phần. Bước này sẽ xác định xem thành phần nào sẽ cung cấp phần thực thi và quản lý cho mỗi dịch vụ. Phân bổ dịch vụ sẽ thể hiện tính năng truy vết giữa các dịch vụ và các thành phần chịu trách nhiệm thực thi và quản lý chúng.

Hình 13 – Đưa các dịch vụ vào các thành phần

2.2.5 Đặc tả thành phần

Bước này là đặc tả lại các thành phần sau khi đã thực hiện các bước trên như đặc tả đầu vào đầu ra web service…

2.2.6 Cấu trúc thành phần và dịch vụ

Trong giai đoạn này ta sẽ thực hiện đưa các dịch vụ và các thành phần vào các trong các tầng của SOA. Đây là bước quan trọng vì sẽ ảnh hưởng đến kiến trúc hệ thống, ảnh hưởng đến công tác xây dựng và triển khai hệ thống.

2.2.7 Lựa chọn giải pháp thực thi

Đây là bước quan trọng để quyết định giải pháp kỹ thuật ảnh hưởng đến tiến độ và chi phí của dự án như quyết định có sử dụng lại hệ thống cũ với các chức năng đã được thiết kế theo hướng dịch vụ hay là xây dựng một hệ thống hoàn toàn mới …

2.3 SOA và Web Service

SOA là một kiến trúc phần mềm, bao gồm một tập các nguyên tắc thiết kế độc lập với kỹ thuật và công nghệ nhằm liên kết các dịch vụ. SOA bắt đầu với việc định nghĩa thành phần giao tiếp (interface) và sau đó, xây dựng kiến trúc hệ thống như là sự liên kết của các thành phần interface, phần thực thi của các interface và cách thức tương tác giữa các interface. Trong khi đó, Web services lại là một tập hợp các kỹ thuật và công nghệ (SOAP, WSDL, UDDI, HTTP...) được dùng để hiện thực hóa các nguyên tắc thiết kế của SOA. Trong thực tế, khái niệm SOA không phải là một khái niệm hoàn toàn mới, mà đã xuất hiện cách đây khá lâu. Và trong quá khứ đã có rất nhiều kỹ thuật khác được dùng để triển khai một hệ thống SOA như : • Distributed object : như CORBA, J2EE, COM/DCOM • Message-oriented middleware (MOM) : WebSphere MQ

Phần dưới đây sẽ giới thiệu rõ hơn về Web service, khái niệm, kiến trúc và các

thành phần trong Web service

2.3.1 Kiến trúc Web services

Web service [4]-[6]-[10] là một tập các chuẩn đặc tả mở rộng khả năng của các chuẩn có sẵn như XML, URL và HTTP nhằm cung cấp chuẩn truyền thông giữa các hệ thống với nhau. Web services là những thành phần thực thi một số xử lý nghiệp vụ thông qua những dịch vụ và cung cấp những dịch vụ qua mạng, những dịch vụ này có thể được triệu gọi bởi các dịch vụ client bằng cách sử dụng giao thức SOAP trên HTTP. Web services độc lập về ngôn ngữ và độc lập về nền tảng bởi vì nó tách biệt đặc tả ra khỏi cài đặt; nó còn hỗ trợ tích hợp loose coupling giữa các ứng dụng với nhau qua trao đổi các thông điệp đồng bộ và bất đồng bộ thông. Web services dựa trên kiến trúc phân tán trong đó không có bất kì dịch vụ xử lý trung tâm nào và tất cả dạng truyền thông đều sử dụng các giao thức chuẩn. Các giao thức không được có bất kì ý nghĩa ngầm định nào bên trong mà phải được mô tả rõ ràng.

Trong Web services thì giữa thành phần triệu gọi web service(client) và Web services đều không cần biết cài đặt của nhau. Web services sử dụng XML, một ngôn ngữ độc lập trong việc biểu diễn dữ liệu, làm ngôn ngữ trao đổi thông tin.

Mô hình web services dạng đơn giản định nghĩa cách thức tương tác giữa Service Requester, Service Provider, và Service Directory như sau : Bên sử dụng dịch vụ tìm kiếm các dịch vụ trong một UDDI Service Directory. Chúng sẽ lấy thông tin

mô tả WSDL của các Web services cung cấp bởi Service Providers từ trước thông qua Service Directory. Sau khi lấy được mô tả WSDL, bên yêu cầu dịch vụ kết nối đến nhà cung cấp dịch vụ bằng cách triệu gọi các dịch vụ thông qua giao thức SOAP. Web services cơ bản bao gồm các khái niệm SOAP, WSDL, và UDDI. Chúng ta sẽ lần lượt phân tích trong các phần sau. Cần lưu ý là các chuẩn trên có thể được kết hợp với nhau hoặc dùng độc lập tùy trường hợp cụ thể.

Hình 14 - Các tầng của Web service

Hình 14 mô tả các tầng hình thành nên Web service. Hình 15 mô tả các tác

nhân trong Web service tương ứng với các tầng này.

Có 3 thành phần tác nhân chính tham gia vào Web service. 1. Service Provider: Dùng Web Services Description Language (WSDL) để mô tả dịch vụ mà mình có thể cung cấp cho Service Broker (tương tự với Service Registry trong SOA).

2. Service Broker: Lưu trữ thông tin về các service được cung cấp bởi các Service Provider. Cung cấp chức năng tìm kiếm hỗ trợ Service Requester (Service Consumer trong SOA) trong việc xác định Service Provider phù hợp. Thành phần chính của Service Broker là Universal Discovery, Description, and Integration (UDDI) repositories.

3. Service Requester: Dùng WSDL để đặc tả nhu cầu sử dụng và gởi cho service Broker.

Môi giới dịch vụ(Service Broker)

WSDL WSDL SOAP Nhà cung cấp dịch vụ (Service Provider)

Yêu cầu dịchvụ (Serice Requester)

Hình 15 - Tương tác giửa các tác nhân trong Web service

2.3.2 Simple Object Access Protocol – SOAP

SOAP là một protocol giao tiếp dùng trong Web service được xây dựng dựa trên XML. SOAP được sử dụng để đặc tả và trao đổi thông tin về các cấu trúc dữ liệu cũng như các kiểu dữ liệu giữa các thành phần trong hệ thống.

Hình 16[4] mô tả giao tiếp của một ứng dụng với một web service được thực hiện qua thông điệp SOAP sử dụng giao thức HTTP. Ứng dụng sẽ đặc tả yêu cầu trong SOAP message và thông qua giao thức mạng gởi đến cho web service. Web service sẽ nhận và phân tích yêu cầu sau đó trả về kết quả thích hợp.

Hình 16 - Truyền thông điệp sử dụng SOAP

Hình 17 - Cấu trúc SOAP message

Hình 17 mô tả cấu trúc một thông điệp SOAP. Một thông điệp SOAP bao gồm

các thành phần sau:

 Protocol Header: Chứa thông tin về các chuẩn giao thức được sử dụng.  SOAP Envelop: Bao gồm 2 thành phần là SOAP header và SOAP body. Trong SOAP header chứa các header của message còn trong SOAP body chứa thông tin về name và data được đặc tả dưới dạng XML và trường lỗi được dùng để đưa ra các lỗi khi gọi web service.

2.3.3 Web Service Description Language (WSDL)

Trong WSDL sẽ miêu tả các dịch vụ thực hiện một quy trình nghiệp vụ gồm đầu

vào và đầu ra, cổng kết nối web service,…

Hình 18[4] mô tả các thành phần cơ bản của một file WSDL dùng để đặc tả

một web service.

Hình 18 – WSDL

 Port Types: định nghĩa một web service, các tác vụ mà service cung cấp và

định dạng các thông điệp được sử dụng để khởi động các tác vụ này.  Services: Chứa các method có thể được sử dụng thông qua các giao thức.  Ports: Địa chỉ dùng để kết nối đến web service.  Operations: Mỗi operation có thể được xem như một method hay một lời gọi hàm trong các ngôn ngữ lập trình cổ điển.

 Binding: chỉ định port type, các operation, SOAP binding stype (RPC/Document), SOAP protocol được dùng.

 Message: Mỗi message tương ứng với một operation và chứa các thông tin cần thiết để thực thi operation đó. Mỗi message có một name duy nhất và một hay nhiều logical part. Các logical part được phân biệt với nhau qua name và có thể lưu trữ các tham số cần cho operation.

 Element: Được định nghĩa trong Types. Mỗi element có một name duy nhất và kiểu dữ liệu. Element được dùng để đặc tả dữ liệu dùng trong message. Element có thể đặc tả các dữ liệu đơn giản (string, integer) hay phức tạp hơn như array, struct, ...

 XSD file: Các element thường được định nghĩa trong các XML Schema Definition (XSD) file. XSD file có thể ở trong cùng file WSDL hoặc ở file riêng biệt.

2.3.4 UDDI

UDDI (Universal Description, Discovery, and Intergration) là chuẩn phục vụ các tổ chức đăng ký và tìm kiếm các Web Service. UDDI hỗ trợ tìm kiếm, định vị thông tin về một nhà cung cấp dịch vụ bao gồm địa chỉ, thông tin liên lạc và các định danh.

2.4 Kết luận

Chương này trình bày các vấn đề liên quan đến việc xây dựng và triển khai hệ thống SOA trong thực tế một cách hiệu quả, xem xét quy trình phát triển ứng dụng theo mô hình SOA.

Trong chương cũng nêu các vấn đề liên quan đến Web services như kiến trúc Web service, các thành phần của Web service, các khai niệm về niệm SOAP, WSDL, và UDDI trong Web service. Chương sau sẽ đề cập tới bài toán thanh toán hóa đơn tại BIDV sử dụng mô

hình SOA dùng Web Service.

Chương 3 - ỨNG DỤNG SOA TRONG TÍCH HỢP HỆ THỐNG THANH TOÁN HÓA ĐƠN CỦA BIDV

3.1 Phát biểu bài toán

Trong những năm qua BIDV không ngừng nâng cao chất lượng dịch vụ để phục vụ khách hàng. Với việc Việt Nam chính thức gia nhập tổ chức thương mại thế giới WTO thì BIDV đang phải đối mặt với sự cạnh tranh của các ngân hàng ngoại vốn mạnh về tài chính và công nghệ và còn phải cạnh tranh khốc liệt với khối ngân hàng nội đang từng bước lớn mạnh. Để cạnh tranh được thì cốt lõi phải hiện đại hóa về hệ thống CNTT mà nền tảng là đa dạng hóa dịch vụ.

Tập đoàn điện lực Việt Nam EVN từ trước đến nay đều thu tiền điện qua mạng lưới cộng tác viên đến thu tiền trực tiếp tại nhà dân hay tại các điểm thu tiền của EVN. Điều này dẫn tới mạng lưới đội ngũ cộng tác viên này rất lớn phức tạp trong quản lý. Hơn nữa số tiền mà các cộng tác viên này thu được phải mất vài ngày đến hàng tuần mới đến nộp được cho sở điện lực. Nếu số tiền này mà được gửi ngay tại ngân hàng thì EVN vừa dễ quản lý và theo dõi lại được phát sinh một số tiền lãi rất lớn. Ngoài ra cũng tránh được nhiều nguy cơ rủi ro như tiền giả, cộng tác viên dùng sai mục đích…

Dịch vụ nạp tiền cho thuê bao trả trước với nhà cung cấp dịch vụ VNPAY : Thay vì phải đến các điểm bán thẻ trả trước để cào lấy mã số thẻ rồi nạp tiền thì khách hàng có thêm một kênh là nạp tiền cho điện thoại di động qua tin nhắn hay mua thẻ tại ATM thông qua mở tài khoản tại ngân hàng.

Nắm bắt được các yêu cầu của các doanh nghiệp trong nghiệp vụ thanh toán hóa đơn cũng như phát triển thêm thanh toán không dùng tiền mặt đồng thời đẩy mạnh phát triển dịch vụ tại BIDV. BIDV đã tiến hành khảo sát và ký kết với các đơn vị trên để phát triển một cổng thanh toán đáp ứng được các nghiệp vụ thanh toán hóa đơn[4]. Vấn đề là cổng thanh toán đó phải tích hợp được nhiều kênh thanh toán như ATM, quầy, SMS… đồng thời phải mở rộng được các nhà cung cấp dịch vụ mới.

Kiến trúc hướng dịch vụ SOA (Service Oriented Architecture ) ra đời như là giải pháp tối ưu để tích hợp các dịch vụ giữa BIDV và các nhà cung cấp để giải quyết bài toán thanh toán trên.

3.2 Đề xuất mô hình SOA trong hệ thống thanh toán hoá đơn của BIDV

Thành phần sử lý trung tâm hệ thống thanh toán hoá đơn Bill Payment Gateway sẽ định nghĩa ra các hàm web service để các kênh thanh toán như quầy giao dịch

BIDV

ATM

M ba s e M es s a g e

LAN

SWITCH

EVN

SIBS

d Lin

a s e

o 8

e g a s s e M e s a b M

v i c

Leased Line

b S e r

W e

Viettel

Web Se r vi ce

SMS

d Lin

S M S

W e b S ervic e

8049

Bill Payment Gateway

Web Server

Mobil Phone

S P T T H

H TT P S

VNPAY

Chi nhánh 1

Chi nhánh 2

Chi nhánh 3

BIDV Branch, Internet hay Mobile sẽ gọi và trao đổi thông điệp. Sau khi Bill Payment Gateway xử lý sẽ truyền thông điệp sang nhà cung cấp dịch vụ cũng sử dụng web service để trao đổi dữ liệu. Các thông điệp trao đổi là đồng bộ và Bill Payment Gateway có thể xử lý song song nhiều thông điệp. Mô hình cũng đề xuất sử dụng Message Queue của IBM để tăng khả năng xử lý tránh trường hợp quá tải với Bill Payment Gateway.

Hình 19 - Mô hình tổng quát hệ thống thanh toán hoá đơn của BIDV

Bill Payment Gateway: Trung tâm của hệ thống Thanh toán hóa đơn là hệ thống Bill Payment Gateway đóng vai trò là cổng kết nối giao diện giữa hệ thống CoreBanking /SIBS, quầy giao dịch tại các chi nhánh của Ngân hàng Đầu tư và Phát triển Việt nam, hệ thống ATM/SWITCH với các nhà cung cấp dịch vụ . Bill Payment Gateway được thiết kế và xây dựng để thực hiện các nhiệm vụ sau:

• Tiếp nhận các yêu cầu thanh toán hóa đơn từ 02 kênh thanh toán: ATM và quầy giao dịch của tất cả các chi nhánh trên phạm vi toàn hệ thống Ngân hàng Đầu tư và phát triển Việt nam.

• Thực hiện gửi các yêu cầu hạch toán online vào hệ thống SIBS đối với các

giao dịch thanh toán hóa đơn xuất phát từ quầy giao dịch.

• Switching giao dịch đến đúng nhà cung cấp dịch vụ theo yêu cầu thanh toán

được gửi đến từ kênh thanh toán ATM hoặc quầy giao dịch.

SWITCH: Máy chủ Switch được thiết kế và xây dựng để thực hiện các nhiệm

vụ sau:

• Tiếp nhận các yêu cầu thanh toán hóa đơn từ các ATM Terminal và switching

các yêu cầu đó sang hệ thống Bill Payment Gateway.

• Thực hiện gửi các yêu cầu hạch toán online 24/7 vào hệ thống SIBS đối với

các giao dịch xuất phát từ ATM Terminal.

ATM Terminal: Các ATM Terminal đóng vai trò cung cấp dịch vụ thanh toán hóa đơn cho khách hàng qua máy giao dịch tự động ATM. ATM Terminal được cài đặt một phần mềm thích hợp để có thể gửi yêu cầu thanh toán hóa đơn tới SWITCH.

Chi nhánh BIDV: Là danh sách các chi nhánh, hoặc điểm giao dịch của Ngân hàng Đầu tư và phát triển Việt nam được chọn lựa để phục vụ yêu cầu thanh toán hóa đơn của khách hàng. Tại các điểm này, một phần mềm thích hợp được trang bị để có thể gửi yêu cầu thanh toán hóa đơn tới Bill Payment Gateway.

CoreBanking – SIBS: tiếp nhận và xử lý các yêu cầu hạch toán vào tài khoản các nhà cung cấp mở tại Ngân hàng Đầu tư và phát triển Việt nam từ Bill Payment Gateway và ATM/SWITCH

Các nhà cung cấp như EVN, Mobile Phone…: Giao tiếp với Bill Payment

Gateway thông qua Web service

Các thuê bao di động sử dụng kênh SMS : giao tiếp thông qua tổng đài 8049,

máy chủ tổng sẽ giao tiếp với Bill Payment Gateway thông qua Web service.

3.3 Quy trình hoạt động

Hiện tại BIDV mới triển khai hệ thống thanh toán hoá đơn qua các kênh chi nhánh BIDV, ATM và dịch vụ nạp tiền điện thoại cho thuê bao trả trước thêm kênh SMS. Trong tương lai gần sẽ triển khai thêm kênh internet, kênh mobile cho tất cả các dịch vụ. Ở đây ta sẽ chỉ đề cập chính đến hệ thống thanh toán hoá đơn cho hai kênh đã triển khai rộng là ATM và quầy giao dịch của BIDV

Luồng giao dịch giữa các cấu thành của hệ thống

Luồng giao dịch của kênh thanh toán tại quầy

Giao dịch vấn tin hóa đơn

Khách hàng ra quầy thanh toán sẽ nhập mã hóa đơn khách hàng rồi gửi lên Gateway. Gateway sẽ xử lý và gửi sang bên nhà cung cấp rồi gửi trả lại web server để hiển thị lên màn hình cho biết chi tiết hóa đơn của khách hàng hay lỗi.

BII

NCC

Bill Gateway

Web Server

BIR

BII: Inquiry Items

BIR: Inquiry Items Response

Giao dịch thanh toán hóa đơn

Sau khi vấn tin về thông tin hóa đơn xong nếu đồng ý thanh toán sẽ gửi lên Gateway để Gateway gửi message vào Corebanking để trừ tiền khách hàng sau đó Gateway gửi sang bên nhà cung cấp để xóa nợ. Mỗi một trong các bước trên gặp lỗi thì tiến trình sẽ dừng lại.

BPM

NCC

Web Server

Bill Gateway

BPR

TFT TFR

SIBS

BPM: Bill Payment

TFT: Fund Transfer

TFR: Fund Transfer Response

BPR: Bill Payment Response

Giao dịch hủy gạch nợ

Khi giao dịch muốn hủy thì từ Web Server sẽ gửi lên Gateway để Gateway gửi vào Corebanking để hủy giao dịch đã hạch toán trước đó đồng thời gửi sang bên nhà cung cấp để hủy giao dịch xóa nợ trước đó.

BPC

NCC

Web Server

Bill Gateway

BCR

TTC TCR

SIBS

BPC: Bill Payment Correction

TTC: Fund Transfer Correction

TCR: Fund Transfer Correction Response

BCR: Bill Payment Correction Response

Luồng giao dịch của kênh thanh toán qua ATM

Giao dịch vấn tin nhà cung cấp và dịch vụ

Khách hàng ra ATM của BIDV khi chọn dịch vụ giá trị gia tăng thì từ ATM yêu cầu sẽ gửi lên hệ thống Switch và hệ thống Switch sẽ gửi lên Gateway và Gateway sẽ gửi trả danh sách các nhà cung cấp đã triển khai dịch vụ thanh toán hóa đơn tại BIDV.

BIP

ATM

SWITCH

Bill Gateway

BPR

BIP: Inquiry Providers and Services

BPR: Inquiry Providers and Services Response

Giao dịch vấn tin hóa đơn

Tương tự như giao dịch tại quầy sau khi nhập thông tin khách hàng sẽ gửi lên Swtich sau đó sẽ gửi lên Gateway rồi gửi sang nhà cung cấp để lấy chi tiết hóa đơn khách hàng để hiển thị lên ATM.

BII

ATM

SWITCH

NCC

Bill Gateway

BIR

BII: Inquiry Items

BIR: Inquiry Items Response

Giao dịch thanh toán hóa đơn

Sau khi khách hàng chọn thanh toán sẽ gửi lên Switch để gửi hạch toán vào CoreBanking, nếu thành công thì sẽ gửi lên Bill Gateway để gửi sang nhà cung cấp dịch vụ để gạch nợ.

BPM

ATM

SWITCH

NCC

Bill Gateway

BPR

TFT TFR

SIBS

BPM: Bill Payment

TFT: Fund Transfer

TFR: Fund Transfer Response

BPR: Bill Payment Response

Giao dịch hủy gạch nợ

Khi giao dịch bị lỗi khi gạch nợ hóa đơn bên nhà cung cấp hay timeout bên nhà cung cấp sẽ xuất hiện giao dịch đảo để Switch gửi vào CoreBanking để hủy giao dịch hạch toán tiền trước đó đồng thời Gateway gửi sang bên nhà cung cấp để hủy giao dịch gạch nợ(nếu giao dịch đã thành công trước đó nhưng bị timeout bên nhà cung cấp)

BPC

ATM

SWITCH

NCC

Bill Gateway

BCR

TTC TCR

SIBS

BPC: Bill Payment Correction

TTC: Fund Transfer Correction

TCR: Fund Transfer Correction Response

BCR: Bill Payment Correction Response

Các tình huống phát sinh giao dịch nghịch đảo của hệ thống

Timeout tại Switch

BPC

ATM

SWITCH

NCC

Bill Gateway

BCR

TTC TCR

SIBS

Trong trường hợp xảy ra timeout tại Switch, ATM tự động gửi yêu cầu hủy giao dịch tới Switch. Switch sẽ gửi tiếp yêu cầu hủy giao dịch tới SIBS và Bill Payment Gateway. Cơ chế gửi yêu cầu hủy giao dịch là cơ chế store and forward.

Timeout tại SIBS

SWITCH

TTC TTR

SIBS

Trong trường hợp xảy ra timeout tại SIBS, Switch sẽ gửi yêu cầu hủy giao dịch

hạch toán tới SIBS mà không gửi yêu cầu gạch nợ sang Bil Payment Gateway.

Timeout tại nhà cung cấp dịch vụ

BPC

SWITCH

NCC

Bill Gateway

BCR

TTC TTR

SIBS

Trong trường hợp xảy ra timeout tại nhà cung cấp, Bill Payment Gateway sẽ gửi yêu cầu hủy gạch nợ tới NCC và gửi kết quả không thành công về cho Switch. Switch sẽ gửi tiếp yêu cầu gạch nợ tới SIBS và trả lời cho ATM là giao dịch không thành công.

Giao dịch gạch nợ tại nhà cung cấp dịch vụ không thành công

SWITCH

Bill Gateway

TTC TTR

SIBS

Trong trường hợp giao dịch gạch nợ tại NCC là không thành công, Bill Payment Gateway trả kết quả không thành công về cho Switch. Switch gửi yêu cầu hủy hạch toán tới SIBS và gửi trả kết quả không thành công về cho máy ATM.

Tình toán thời gian thực hiện của một giao dịch

Theo thiết kế mạng của NH ĐT&PT-VN, các giao dịch từ quầy giao dịch và máy ATM của chi nhánh phải qua hai tầng firewall mới đến được máy chủ Bill Payment Gateway. Các giao dịch vì thế cũng sẽ bị trễ tuy nhiên thời gian trễ phụ thuộc vào tốc độ xử lý của firewall. Hiện tại đỗ trễ của giao dịch khi đi qua firewall là không

thể xác định được trong quá trình thiết kế ứng dụng mà chỉ có thể xác định trong thời gian chạy thật. Vì thế khi thiết kế hệ thống Bill Payment Gateway chúng tôi tham số hóa các giá trị timeout của các cấu thành tham gia hệ thống, cụ thể là:

- Tham số timeout tại ứng dụng trên máy ATM, dùng để xác định khoảng thời

gian đợi message trả lời từ Switch. - Tham số timeout tại ứng dụng trên Web Server dùng để xác định khoảng thời gian đợi message trả lời từ Bill Payment Gateway.

- Switch có 02 tham số timeout, một dùng để xác định khoảng thời gian đợi message trả lời từ Bill Payment Gateway, và một dùng để xác định khoảng thời gian đợi message trả lời từ SIBS..

- Bill Payment Gateway có 1 tham số timeout dùng để xác định khoảng thời gian đợi message trả lời từ SIBS, và một tham số timeout để xác định khoảng thời gian đợi message trả lời từ các nhà cung cấp. Trong quá trình kiểm thử hệ thống và vận hành hệ thống, quản trị viên có thể

thay đổi các giá trị timeout này để hệ thống vận hành thông suốt.

Hạn mức thanh toán của hệ thống

Tham số về hạn mức thanh toán sẽ được đặt tại Bill Payment Gatway. Có hai tham số về hạn mức thanh toán, 01 xác định hạn mức thanh toán tại quầy và 02 là hạn mức thanh toán tại ATM. Khi xử lý yêu cầu thanh toán từ Switch hoặc Web Server, Bill Payment Gateway sẽ kiểm tra 02 giá trị này. Trong trường hợp khách hàng thanh toán vượt quá hạn mức, Bill Payment Gateway sẽ thông báo lỗi cho Web Server và Switch.

Hệ thống thanh toán hoá đơn được xây dựng trên mô hình phân tích thiết kế hệ

thống UML[1]-[2]

Danh sách các usecase và mô tả chi tiết xin tham khảo trong phụ lục 1 : Các

use case của hệ thống thanh toán hóa đơn.

3.4 Cơ sở dữ liệu

Hệ thống thanh toán hóa đơn sử dụng hệ quản trị cơ sở dữ liệu Oracle 10 G. Chi tiết cơ sở dữ liệu có thể tham khảo phụ lục 2 : Mô tả các bảng của hệ thống thanh toán hóa đơn.

3.5 Thiết kế Web service dùng trong hệ thống

Hệ thống có xây dựng các web service như lấy thông tin hóa đơn, gạch nợ hóa đơn, lấy thông tin về số khách hàng trong CoreBanking, chuyển khoản trong CoreBanking…

Hình 20- Web service dùng trong hệ thống thanh toán hoá đơn

3.6 Kết luận

Trong chương đã đề cập đến bài toán thanh toán hoá đơn của BIDV với các nhà cung cấp dịch vụ, sự cần thiết phải triển khai bài toán thanh toán hoá đơn. Đề xuất sử dụng mô hình SOA áp dụng cho bài toán.

Chương cũng đề cập đến thiết kế chi tiết hệ thống như sơ đồ các use case, kịch bản, thiết kế chi tiết cơ sở dữ liệu…Các thành phần và quy trình hoạt động của mô hình triển khai thanh toán hoá đơn.

Chương 4 - THỰC NGHIỆM VÀ ĐÁNH GIÁ

4.1 Môi trường tích hợp

Chương trình thanh toán hóa đơn tại quầy sử dụng Visual studio . Net 2005

Cơ sở dữ liệu của chương trình dùng Oracle 10 G Release 2

Chương trình tại Gateway sử dụng bộ framework của IBM như IBM Message

Queue, IBM Ratinal Application Developer(RAD).

IBM Ratinal Application Developer(RAD) :

Hình 21 - Môi trường RAD cuả IBM

Đây là phần mềm cho phép phát triển phần Server backend để xử lý và gửi các giao dịch sang bên nhà cung cấp. Đây là frameword để tạo các web service để trao đổi dữ liệu với nhà cung cấp.

IBM Message Queue: Đây là công cụ hoạt động theo cơ chế vào trước ra ra trước(first in first out) dùng để hứng các message từ các kênh giao dịch như quầy, mobile,… đến Server. Nhờ message queue sẽ tránh được quá tải cho server. Các message đến chưa được xử lý sẽ nàm chờ trong Queue, message nào đến trước sẽ

được xử lý trước, message nào đến sau sẽ được xử lý sau. Trong Message Queue cũng cho phép đặt thời gian tối đa cho message khi ghi vào queue cho đến khi xử lý xong.

Hình 22 - Môi trường Message Queue của IBM

4.2 Tích hợp thử nghiệm

Tên Yêu cầu kỹ thuật Ghi chú TT

Phần cứng I

Máy chủ Gateway IBM server, 4 GBRAM, 160GB Tối thiểu 1

ổ cứng, core 2 dual >=2 GHz

Máy chủ Database IBM server, 3 GBRAM, 160GB Tối thiểu

ổ cứng, 2 GHz

Máy chủ Web và Web IBM server, 1GBRAM, 40GB ổ Tối thiểu

service cứng, 1GHz

Máy trạm tại chi nhánh IBM Pentium III, HP Compad Tối thiểu 2

PHẦN MỀM II

Hệ điều hành máy chủ Window Server 2003 Tối thiểu 1

Hệ quản trị CSDL Oracle 10 G Release 2 Tối thiểu 2

Tên Yêu cầu kỹ thuật Ghi chú TT

Hệ điều hành máy trạm Microsoft Windows 2000 Tối thiểu 3

Professional, XP

Web server IIS của Microsoft Tối thiểu 4

Trình duyệt Web Internet Explorer 6.0 trở lên Tối thiểu 5

Bảng 1- Các yêu cầu triển khai thử nghiệm

Cơ chế bảo mật của hệ thống Thanh toán hóa đơn tập trung

Cơ chế bảo mật của hệ thống Thanh toán hóa đơn bao gồm các cơ chế bảo mật

- Bảo mật mạng của NH ĐT&PT-VN với các nhà cung cấp - Bảo mật về mặt chương trình

Bảo mật mạng của Ngân hàng Đầu tư và phát triển Việt nam với các nhà

cung cấp dịch vụ

Vùng bảo mật tại Trung tâm CNTT

SWITCH

EVN

d Lin

a s e

SIBS

LAN TTCN TT

Leased Line

Viettel

d Lin

Web Server

Database Oracle 10 G

Other Partner server

Mobil Phone

Bill Payment Gateway

S P T T H

HTTPS

Other Partner server

Chi nhánh 1

Chi nhánh 2

Chi nhánh 3

Hệ thống mạng tại Trung tâm CNTT đã thiết lập sẵn một VLAN bảo mật cho các kết nối ra bên ngoài. Máy chủ Bill Payment Gateway, máy chủ Bill Payment Gateway Backup và máy chủ Web Server sẽ được đặt trong phân vùng mạng bảo mật cho các kết nối bên ngoài.

Hình 23 - Sơ đồ bảo mật của hệ thống thanh toán hoá đơn BIDV

Bảo mật về mặt chương trình

• Giao tiếp giữa máy trạm của giao dịch viên tại chi nhánh với Web Server:

dùng giao thức bảo mật SSL (HTTPS).

• Giao tiếp giữa Bill Payment Gateway với hệ thống của nhà cung cấp: Ngoài cơ chế bảo mật bằng firewall, hệ thống còn hỗ trợ cơ chế bảo mật bằng chương trình theo phương thức xác thực do từng nhà cung cấp qui định.

• Giao tiếp giữa SWITCH với SIBS, Bill Payment Gateway với SIBS: Sử

dụng cơ chế xác thực và các mã giao dịch riêng do hệ thống SIBS qui định.

• Cơ chế truy cập cơ sở dữ liệu Oracle: Bill Payment Gateway và Web Server truy cập cơ sở dữ liệu sử dụng cơ chế xác thực username/password. Username và password được mã hóa theo chuẩn DES. Khi Bill Payment Gateway và Web Server khởi động, username và password sẽ được giải mã và được sử dụng để truy cập cơ sở dữ liệu.

• Cơ chế bảo mật giữa Switch với Bill Payment Gateway:

Bill Payment Gateway sử dụng cơ chế xác thực địa chỉ IP của máy chủ Switch. Bill Payment Gateway chỉ chấp nhận các giao dịch được gửi đến từ một địa chỉ IP cụ thể được xác định tại thời điểm cài đặt hệ thống.

Cơ chế sao lưu phục hồi cơ sở dữ liệu

Mô hình kiến trúc

Hệ thống được cài đặt theo chế độ Cluster Active/Standby nên hai máy chủ dữ liệu sẽ kết nối tới dữ liệu nằm trên tủ đĩa tập trung. Như vậy, trong trường hợp có sự cố với một máy chủ thì máy chủ còn lại sẽ đảm nhận vai trò xử lý dữ liệu và không ảnh hưởng tới dữ liệu trên tủ đĩa tập trung. Do đó việc sao lưu dữ liệu được thực hiện theo phương pháp dự phòng thảm hoạ và được lưu ra băng từ hàng ngày.

Hình 24 - Sơ đồ backup Database

Cơ chế sao lưu dữ liệu hàng ngày của quản trị viên hệ thống

Bill Payment Gateway cung cấp chức năng kiết xuất dữ liệu cho phép quản trị viên hệ thống thực hiện backup dữ liệu của toàn hệ thống. Ngoài ra Bill Payment Gateway còn hỗ trợ chức năng dọn dẹp dữ liệu. Thời gian để dọn dẹp dữ liệu sẽ được tham số hóa trong hệ thống.

Các bước thực hiện khi xảy ra sự cố về cơ sở dữ liệu

Khi xảy ra sự cố, quản trị viên phải thực hiện các thao tác sau:

- Chuyển tham số kết nối cơ sở dữ liệu sang máy chủ dự phòng - Thực hiện việc khôi phục dữ liệu từ các file dữ liệu đã được back up hàng

ngày nếu máy chủ backup dữ liệu không có đủ dữ liệu. Phương pháp dự phòng chương trình ứng dụng

Mô hình kiến trúc

Để dự phòng chương trình ứng dụng, Web Server và Bill Payment Gateway sẽ được cài đặt dự phòng lên máy chủ dự phòng có cấu hình giống hệt với cấu hình của 02 máy chủ chạy thật. Khi xảy ra sự cố cho một trong các máy chủ hoặc Web Server hoặc Bill Payment Gateway, máy chủ dự phòng sẽ được sử dụng để giảm thiểu thời gian ngừng cung cấp dịch vụ thanh toán hóa đơn của toàn hệ thống.

Các bước thực hiện khi xảy ra sự cố về chương trình ứng dụng

Khi xảy ra sự cố về chương trình ứng dụng (Web Server hoặc Bill Payment

Gateway), quản trị viên thực hiện các thao tác sau:

- Khởi tạo máy chủ dự phòng - Đổi địa chỉ IP của máy chủ dự phòng sang địa chỉ IP của máy chủ chạy thật tương ứng

- Khởi tạo các tiến trình của Bill Payment Gateway hoặc - Khởi tạo tiến trình của Web Server.

Các rủi do của hệ thống

Rủi ro liên quan đến tài chính

Hạch toán tại SIBS nhưng không gạch nợ tại nhà cung cấp

Các trường hợp phát sinh rủi ro

(1) Switch thực hiện hạch toán tại SIBS nhưng không gửi yêu cầu gạch nợ tới

Bill Payment Gateway.

(2) Bill Payment Gateway nhận yêu cầu thanh toán hóa đơn từ Web Server, hạch toán thành công tại SIBS nhưng bị down khi xử lý gửi yêu cầu gạch nợ sang nhà cung cấp

Cách khắc phục

• Với trường hợp (1), cán bộ nghiệp vụ phải xử lý hủy hạch toán bằng tay cho

khách hàng.

• Với trường hợp (2), Quản trị hệ thống

Kiểm tra bảng dữ liệu OUTGOING_MESSAGE_QUEUE, nếu:

- Bảng OUTGOING_MESSAGE_QUEUE có chứa message định gửi sang nhà cung cấp, quản trị viên xóa dữ liệu và yêu cầu cán bộ nghiệp vụ hủy hạch toán tại SIBS bằng tay.

- Bảng OUTGOING_MESSAGE_QUEUE không chứa message định gửi sang nhà cung cấp, quản trị viên yêu cầu cán bộ nghiệp vụ hủy hạch toán tại SIBS bằng tay Xóa dữ liệu ở bảng INCOMING_MESSAGE_QUEUE

Khởi tạo lại các tiến trình của Bill Payment Gateway.

Hủy hạch toán tại SIBS nhưng không hủy gạch nợ tại nhà cung cấp

Các trường hợp phát sinh rủi ro

(1) Bill Payment Gateway bị down nên không thể nhận yêu cầu hủy giao dịch

từ Switch trong khi Switch đã thực hiện hủy hạch toán tại SIBS.

(2) Bill Payment Gateway nhận yêu cầu hủy thanh toán hóa đơn từ Web Server, thực hiện hủy hạch toán tại SIBS thành công nhưng bị down khi xử lý hủy gạch nợ sang nhà cung cấp.

(3) Đường truyền kết nối với nhà cung cấp bị đứt nên Bill Payment Gateway không thể gửi yêu cầu hủy giao dịch sang nhà cung cấp trong khi đã hủy hạch toán tại SIBS thành công.

Cách khắc phục

Với trường hợp (1), quản trị hệ thống khởi tạo lại các tiến trình của Bill Payment Gateway. Hệ thống sẽ tự động nhận được yêu cầu hủy gạch nợ từ Switch và thực hiện hủy gạch nợ ở nhà cung cấp.

Với trường hợp (2) và (3), quản trị hệ thống cũng chỉ phải khởi tạo lại tiến trình của Bill Payment Gateway mà không phải làm gì cả. Chức năng hủy giao dịch của Bill Payment Gateway hoạt động theo cơ chế store/forward. Bảng dữ liệu REVERSAL_MESSAGE chứa các giao dịch cần được hủy. Bill Payment Gateway sẽ liên tục gửi yêu cầu hủy giao dịch sang nhà cung cấp cho đến khi nhận được phản hồi thành công từ nhà cung cấp. Lúc này Bill Payment Gateway mới xóa yêu cầu hủy giao dịch ở trong bảng REVERSAL_MESSAGE.

Rủi ro về mặt kỹ thuật

Rủi ro của máy chủ cơ sở dữ liệu

Trong quá trình vận hành có thể gặp những rủi rõ cho máy chủ chứa cơ sở dữ

liệu. Nếu quá trình này xảy ra, quản trị viên hệ thống phải:

- Chuyển máy chủ dữ liệu sang máy chủ dự phòng - Thực hiện phục hồi dữ liệu từ file dữ liệu hàng ngày (nếu cần thiết) - Thiết lập địa chỉ IP cho máy chủ dự phòng với địa chỉ IP là địa chỉ IP của máy

chủ chạy chính.

Rủi ro về đường truyền với các hệ thống SIBS, SWITCH, và các hệ thống

của nhà cung cấp

Khi gặp sự cố về đường truyền với các hệ thống khác, quản trị viên hệ thống phải phối hợp với các cán bộ phụ trách mạng truyền thông của Trung tâm CNTT tìm cách khắc phục. Phối hợp với cán bộ nghiệp vụ thông báo tạm dừng giao dịch thanh toán hóa đơn.

4.3 Kết quả thực nghiệm

Một số kịch bản test

KỊCH BẢN TEST NẠP TIỀN CHO VÍ VNMART BẰNG ATM, SMS và Quầy GD

Thông tin đầu vào

Kết quả dự kiến

STT Quy trình test

Các bước chi tiết

Kết quả thực tế

NẠP TIỀN CHO VÍ ĐIỆN TỬ BẰNG QUẦY GIAO DỊCH

Số tài khoản đúng

Số điện thoại chưa đăng ký

Trên màn hình Web hiển thị “Số điện thoại chưa đăng ký ví điện tử vnmart”

Chọn màn hình vấn tin hóa đơn. Chọn chuyển khoản

Đáp ứng yêu cầu đặt ra

Nhập số điện thoại chưa đăng tại ký www.vnm art.vn

Số tài khoản sai

Số điện thoại đúng

Chọn màn hình vấn tin hóa đơn. Chọn chuyển khoản

Số tài khoản không đúng

Đáp ứng yêu cầu đặt ra

Nhập số điện thoại đã đăng ký tại www.vn mart.vn

Số điện thoại đúng

Chọn màn hình vấn tin hóa đơn. Chọn tiền mặt

Hiển thị thông tin chi tiết về khách hàng

Đáp ứng yêu cầu đặt ra

Nhập số điện thoại đã đăng ký tại www.vn mart.vn

Số tài khoản

Chọn

Số điện thoại đúng

Đáp ứng yêu cầu đặt ra

màn hình vấn tin hóa đơn. Chọn chuyển khoản

- Hiển thị thông tin chi tiết về khách hàng đăng ký bên vnmart - Hiển thị tên chủ tài khoản và số dư khả dụng

Nhập số điện thoại đăng đã ký tại www.vnm art.vn

Số tài khoả

Chọn

Số điện thoại đúng

- Hiển thị số dư khả dụng nhỏ hơn số tiền cần thanh toán

Đáp ứng yêu cầu đặt ra

Nhập số điện thoại đã đăng ký tại www.vn mart.vn

màn hình vấn tin hóa đơn. Chọn chuyển khoản. Chọn mệnh giá tiền rồi đẩy lên KSV nhưng số dư khả dụng lại nhỏ hơn mệnh giá tiền

Số tài khoản

- Hiển thị đã đẩy điện

lên KSV

Số điện thoại đúng

Đáp ứng yêu cầu đặt ra

Nhập số điện thoại đã đăng ký tại www.vn mart.vn

Chọn màn hình tin hóa vấn Chọn đơn. chuyển khoản. Chọn mệnh giá tiền rồi đẩy lên KSV, số dư khả dụng lớn hơn mệnh giá tiền

Chọn dịch vụ Vnmart Chọn ngày

KSV đăng nhập và chọn màn hình duyệt.

Thông báo duyệt điện thành công hoặc báo lỗi

Đáp ứng yêu cầu đặt ra

NẠP TIỀN CHO VÍ ĐIỆN TỬ BẰNG ATM

Trên màn hình ATM hiển thị:

Số điện thoại chưa đăng ký, số tiền nạp

Đáp ứng yêu cầu đặt ra

toán

“Số điện thoại/ Mã khách hàng chưa đăng ký”

số Nhập điện thoại chưa đăng ký tại www.vnm art.vn

Chọn dịch vụ chọn GTGT, thanh trả trước, chọn ví điện tử vnmart, chọn mệnh giá

Hiển thị thông tin về khách hàng bên vnpay trả về

Số điện thoại đã đăng ký, số tiền nạp

Đáp ứng yêu cầu đặt ra

- Chọn dịch vụ GTGT, chọn thanh toán trả trước, chọn ví điện tử vnmart, chọn mệnh giá

N hập số điện thoại đăng đã ký tại www.vnm art.vn

Số điện thoại đã đăng ký, số tiền nạp

Hiển thị thông báo thành công, rồi in hóa đơn giao dịch

Đáp ứng yêu cầu đặt ra

toán

Nhập số điện thoại đăng đã ký tại www.vnm art.vn

Chọn dịch vụ chọn GTGT, trả thanh trước, chọn ví điện tử vnmart,chọn mệnh giá sau khi hiển thị thông tin xác nhận thanh toán

Hiển thị giao dịch

không thành công

Số điện thoại đã đăng ký, số tiền nạp

Đáp ứng yêu cầu đặt ra

toán

Nhập số điện thoại đăng đã ký tại www.vnm art.vn

Chọn dịch vụ chọn GTGT, thanh trả trước, chọn ví điện tử vnmart,chọn mệnh giá sau khi hiển thị thông tin xác nhận thanh toán sau đó rút mạng

ĐĂNG KÝ VÍ ĐIỆN TỬ

Soạn tin nhắn theo cú

Đăng ký qua SMS

Thuê bao nhận được 3 tin nhắn:

pháp:

Soạn tin nhắn đúng cú pháp gửi 8149

DK VM => gửi tới 8149

Đáp ứng yêu cầu đặt ra

thanh Truy

MT1: Quy khach da dang ky vi dien tu VnMart thanh cong: So vi VnMart la: 101000000425, toan: Mat khau cap 925108. www.vnmart.vn de kich hoat Web User.

MT2: De doi mat khau thanh toan quy khach soan tin nhan VMKT MatKhauCu MatKhauMoi gui 8149. Mat khau thanh toan hop le co do dai tu 6- 12 ky tu. HT: 1900555577.

Soan

MT3:

tin nhan VNMT DK gui 8149 de dang ky su dung cac dich vu SMS cua vi dien tu VnMart: Kiem tra so du, tien su gd, nap Lich VnTopup, Bien dong so du.

Soạn tin nhắn theo cú

Thuê bao nhận được tin nhắn:

pháp:

Soạn tin nhắn đúng cú pháp gửi 8149

DK VM => gửi tới 8149

Đáp ứng yêu cầu đặt ra

Đăng ký qua SMS, sử dụng số điện thoại đã đăng ký Ví

Dang ky khong thanh cong do so di dong dang ky vi dien tu VnMart da bi trung. Xin quy khach vui long kiem tra lai hoac lien he 1900 555577 de duoc ho tro.

Màn hình hiển thị:

* Thông tin đăng ký:

- Số di động

- Mật khẩu

Truy cập website www.vnmart.vn và điền các thông tin theo mẫu

Đáp ứng yêu cầu đặt ra

- E-mail

Đăng ký qua website www.vn mart.vn

- Họ tên

- Số CMT

- Quốc gia

- Thành phố

Ví điện tử của bạn chưa được kích hoạt, xin vui lòng nhập mã kích hoạt (được gửi về số di động của quý khách) để có thể đăng nhập. Mọi thắc mắc xin liên hệ số DT 1900555577 để được trợ giúp.

- Mã an ninh

- Thuê bao nhận

* Nhập mã kích hoạt gửi

được tin nhắn:

về điện thoại sau khi đăng ký

Cam

quy khach da dang ky dich vu VnMart. Ma kich hoat cua quy khach la: 6551. So DT ho tro 1900555577.

- Sau khi nhập mã kích hoạt có thể đăng nhập tài khoản Ví tại website www.vnmart.vn

NẠP TIỀN CHO VÍ ĐIỆN TỬ BẰNG SMS

Soạn tin nhắn (SMS) với

cú pháp :

Thuê bao nhận được tin nhắn từ số 8049 với nội dung:

NAP VM10 0912750910

Đáp ứng yêu cầu đặt ra

Gửi tin nhắn nạp tiền cho Ví VnMart đúng từ khoá tới số 8049

123

=> gửi tới 8049

“Nap tien khong thanh cong do quy khach chua dang ky dich vu nap tien VnTopup. Xin vui long lien he so dien thoai 1900555577 de duoc ho tro”

Gửi tin nhắn nạp cho tiền Ví VnMart khi thuê bao chưa đăng ký sử dụng dịch vụ VnTopup

Khách hàng điền thông tin

ký tại

đăng ký theo mẫu

Đăng VnTopup ngân hàng

Đăng ký VnTopup thành công

tại

Đáp ứng yêu cầu đặt ra

Thuê bao đăng ký dịch vụ VnTopu p ngân hàng

Soạn tin nhắn (SMS) với

Thuê bao nhận được tin nhắn:

cú pháp:

Đáp ứng yêu cầu đặt ra

Gửi tin nhắn kích hoạt vụ dịch VnTopup

OK 12345 => gửi tới

8049

Thuê bao kích hoạt dịch vụ VnTopu p, đặt mật khẩu là 12345

Kich hoat VnTopup thanh cong. De Nap tien soan: "NAP MenhGia SoDT MatKhau" gui 8049. Menh gia: VN10,VN20,VN30,VN50,V N100,VN200,VN300,VN500 . HT: 1900555577

Soạn tin nhắn (SMS) với

cú pháp:

Đáp ứng yêu cầu đặt ra

Thuê bao nhận được tin nhắn từ số 8049 với nội dung:

NAP VM10 0912750910

tin nhắn Soạn nạp tiền gửi tới 8049

12345

=> gửi 8049

trong

tai

Thuê bao tiền nạp cho Ví VnMart 09127509 10 với mệnh giá tiền 10.000 VND

“Ban da nap tien thanh cong cho tai khoan 101500000023. So tien bi tru khoan 10000VND. Ma so giao dich la xxxxxx. So DT ho tro 1900555577”

Soạn tin nhắn (SMS) với

cú pháp:

Thuê bao nhận được tin nhắn với nội dung:

Đáp ứng yêu cầu đặt ra

Soạn tin nhắn nạp tiền

VM100

trong

tai

NAP 0912750910 12345 => Gửi 8049

“Ban da nap tien thanh cong cho tai khoan 101500000023. So tien bi khoan tru 100000VND. Ma so giao dich la xxxxxx. So DT ho tro 1900555577”

Thuê bao tiền nạp cho Ví VnMart 0912750 910 với mệnh giá tiền 100.000 VND

tin nhắn

Soạn tin nhắn (SMS) với

Soạn nạp tiền

cú pháp

Thuê bao nhận được thông báo trả về có nội dung:

NAP VM10 0912750910

Đáp ứng yêu cầu đặt ra

12347

=> Gửi 8049

“Nap tien khong thanh cong do Quy khach nhap sai mat khau. Xin vui long thu lai voi mat khau tro dung. So DT ho 1900555577”

Thuê bao nạp 10,000 VND cho Ví VnMart 09127509 và 10 nhập sai mật khẩu

Soạn tin nhắn (SMS) với

Thuê bao nhận được thông báo trả về có nội dung:

Soạn tin nhắn nạp tiền:

Đáp ứng yêu cầu đặt ra

cú pháp: NAT VM10 0912750910 12345

=>Gửi 8049

“Tin nhan sai tu khoa. DT Ho tro: 1900 55 55 77. VnTopup, dich vu nap tien dien thoai va nap tien cho vi VnMart qua SMS.”

Thuê bao tiền nạp cho Ví VnMart 0912750 910 với mệnh giá 10.000 VND. Nạp sai từ khoá

Soạn tin nhắn (SMS) với

Soạn tin nhắn nạp tiền:

huê bao nhận được thông báo trả về có nội dung:

Đáp ứng yêu cầu đặt ra

cú pháp:

NAP VM15 0912750910 12345 => Gửi 8049

Thuê bao nạp tiền cho Ví VnMart và nhập sai mã sản phẩm (mệnh giá).

“Giao dich chua duoc thuc hien do sai menh gia nap tien. Menh gia dung: VM10, VM20, VM30, VM50, VM100, VM200, VM300, VM500. So DT ho tro: 1900 55 55 77.”

Soạn tin nhắn (SMS) với

Thuê bao nhận được thông báo trả về có nội dung:

Soạn tin nhắn nạp tiền:

cú pháp:

Đáp ứng yêu cầu đặt ra

NAP VM100 091275091 12345 => Gửi 8049

Thuê bao tiền nạp cho Ví VnMart và nhập sai Số di động.

“Giao dich chua duoc thuc hien do thong tin vi dien tu VnMart duoc nap khong hop le. Xin lien he so 1900 55 55 77 de duoc ho tro.”

Soạn tin nhắn (SMS) với

Soạn tin nhắn đổi mật khẩu.

cú pháp:

Thuê bao nhận được thông báo trả về có nội dung:

Đáp ứng yêu cầu đặt ra

“Thay

MK [abcde] [54321] => Gửi 8049

doi mat khau khong thanh cong do mat khau khong dung. So DT Ho tro: 1900 55 55 77.”

Thuê bao thực hiện đổi mật khẩu không thành công do nhập sai mật khẩu cũ.

Soạn tin nhắn (SMS) với

Nhận được câu thông báo trả về có nội dung:

Soạn tin nhắn bỏ mật khẩu.

cú pháp:

Đáp ứng yêu cầu đặt ra

“Quy

MK <12345> => Gửi 8049

Thuê bao bỏ mật khẩu thành công

khach da thay doi mat khau thanh cong. Cam on da su dung dich vu VnTopup. So DT ho tro 1900 55 5577”

Soạn tin nhắn (SMS) với

cú pháp:

Đáp ứng yêu cầu đặt ra

Thuê bao nhận được tin nhắn từ số 8049 với nội dung:

NAP VM30 0912750910

Soạn tin nhắn nạp tiền gửi tới 8049

12345

=> gửi 8049

trong

tai

Thuê bao nạp tiền cho Ví VnMart 09127509 10 với mệnh giá tiền 30.000 VND

“Ban da nap tien thanh cong cho tai khoan 101500000023. So tien bi khoan tru 30000VND. Ma so giao dich la xxxxxx. So DT ho tro 1900555577”

tin nhắn

Soạn tin nhắn (SMS) với

Nhận được câu thông báo trả về có nội dung:

Soạn nạp tiền

cú pháp:

Đáp ứng yêu cầu đặt ra

NAP VM500 0912750910 => Gửi 8049

So DT

“Giao dich chua duoc thuc hien do so du trong tai khoan ngan hang khong du. Vui long thu lai voi menh gia nap tien nho tro hon. 1900555577”

Thuê bao nạp tiền với mệnh giá 500,000 VND. Số dư tài khoản ngân hàng không đủ.

RÚT TIỀN TỪ VÍ ĐIỆN TỬ CHUYỂN SANG TÀI KHOẢN BIDV BẰNG SMS

Soạn tin nhắn (SMS) với cú

Thuê bao nhận được tin nhắn từ số 8049 với nội dung:

pháp :

tin rút cho

RUT VM10 0912750910

Đáp ứng yêu cầu đặt ra

123

Gửi tin nhắn nạp tiền cho Ví VnMart đúng từ khoá tới số 8049

=> gửi tới 8049

“Rut tien khong thanh cong do quy khach chua dang ky dich vu nap tien VnTopup. Xin vui long lien he so dien thoai 1900555577 de duoc ho tro”

Gửi nhắn tiền Ví VnMart khi thuê bao chưa đăng ký sử dụng dịch vụ VnTopup

Khách hàng điền thông tin

đăng ký theo mẫu

Đăng ký VnTopup tại ngân hàng

Đăng ký VnTopup thành công

Đáp ứng yêu cầu đặt ra

Thuê bao đăng ký dịch vụ VnTopup tại ngân hàng

Thuê bao nhận được tin nhắn:

Soạn tin nhắn (SMS) với cú

pháp:

Đáp ứng yêu cầu đặt ra

OK 12345 => gửi tới 8049

Gửi tin nhắn hoạt kích dịch vụ VnTopup

Thuê bao kích hoạt dịch vụ VnTopup , đặt mật khẩu là 12345

Kich hoat VnTopup thanh cong. De Nap tien soan: "NAP SoDT MenhGia MatKhau" gui 8049. Menh gia: VN10,VN20,VN30,VN50,VN100, VN200,VN300,VN500. HT: 1900555577

Soạn tin nhắn (SMS) với cú

Thuê bao nhận được tin nhắn từ số 8049 với nội dung:

pháp:

Đáp ứng yêu cầu đặt ra

“Ban rút nap

RUT VM10 0912750910

Soạn tin nhắn nạp tiền gửi tới 8049

12345

=> gửi 8049

tien tai khoan thanh cong cho 101500000023. So tien bi tru trong tai khoan 10000VND. Ma so giao dich la xxxxxx. So DT ho tro 1900555577”

Thuê bao tiền rút cho Ví VnMart 09127509 10 với mệnh giá tiền 10.000 VND

Soạn tin nhắn (SMS) với cú

pháp:

Thuê bao nhận được tin nhắn với nội dung:

Đáp ứng yêu cầu đặt ra

tin nạp

RUT VM100 0912750910

Soạn nhắn tiền

12345

cho

=> Gửi 8049

“Ban rút nap tien thanh cong khoan tai 101500000023. So tien bi tru trong tai khoan 100.000VND. Ma so giao dich la xxxxxx. So DT ho tro 1900555577”

Thuê bao rút tiền cho Ví VnMart 09127509 10 với mệnh giá tiền 100.000 VND

Soạn tin nhắn (SMS) với cú pháp

Soạn tin nhắn nạp tiền

RUT

VM10 0912750910

Thuê bao nhận được thông báo trả về có nội dung:

Đáp ứng yêu cầu đặt ra

12347

=> Gửi 8049

“Nap tien khong thanh cong do Quy khach nhap sai mat khau. Xin vui long thu lai voi mat khau dung. So DT ho tro 1900555577”

Thuê bao rút 10,000 VND cho Ví VnMart 09127509 10 và nhập sai mật khẩu

Soạn tin nhắn (SMS) với cú

Thuê bao nhận được thông báo trả về có nội dung:

tin nạp

Soạn nhắn tiền:

Đáp ứng yêu cầu đặt ra

pháp: NAT RUT 0912750910 12345

=>Gửi 8049

“Tin nhan sai tu khoa. DT Ho tro: 1900 55 55 77. VnTopup, dich vu nap tien dien thoai va nap tien cho vi VnMart qua SMS.”

sai

T huê bao rút tiền cho Ví VnMart 09127509 10 với mệnh giá 10.000 VND. Nạp từ khoá

Soạn tin nhắn (SMS) với cú

tin nạp

Thuê bao nhận được thông báo trả về có nội dung:

Soạn nhắn tiền:

pháp:

Đáp ứng yêu cầu đặt ra

RUT VM15 0912750910 12345 => Gửi 8049

“Giao dich chua duoc thuc hien do sai menh gia nap tien. Menh gia dung: VM10, VM20, VM30, VM50, VM100, VM200, VM300, VM500. So DT ho tro: 1900 55 55 77.”

Thuê bao rút tiền cho Ví VnMart và nhập sai mã sản phẩm (mệnh giá).

Soạn tin nhắn (SMS) với cú

Thuê bao nhận được thông báo trả về có nội dung:

tin nạp

Đáp ứng yêu cầu đặt ra

Soạn nhắn tiền:

pháp: RUT VM100 091275091 12345 => Gửi 8049

Thuê bao rút tiền Ví cho VnMart và sai nhập Số di động.

“Giao dich chua duoc thuc hien do thong tin vi dien tu VnMart duoc nap khong hop le. Xin lien he so 1900 55 55 77 de duoc ho tro.”

Soạn tin nhắn (SMS) với cú

pháp:

tin đổi

Thuê bao nhận được thông báo trả về có nội dung:

Đáp ứng yêu cầu đặt ra

Soạn nhắn mật khẩu.

MK [abcde] [54321] => Gửi 8049

“Thay doi mat khau khong thanh cong do mat khau khong dung. So DT Ho tro: 1900 55 55 77.”

Thuê bao thực hiện đổi mật khẩu không thành do công nhập sai mật khẩu cũ.

Soạn tin nhắn (SMS) với cú

pháp:

tin bỏ

Soạn nhắn mật khẩu.

Nhận được câu thông báo trả về có nội dung:

MK <12345> => Gửi 8049

Thuê bao mật bỏ khẩu thành công

Đáp ứng yêu cầu đặt ra

“Quy khach da thay doi mat khau thanh cong. Cam on da su dung dich vu VnTopup. So DT ho tro 1900 55 5577”

Soạn tin nhắn (SMS) với cú

Thuê bao nhận được tin nhắn từ số 8049 với nội dung:

pháp:

Đáp ứng yêu cầu đặt ra

Soạn tin nhắn rút tiền gửi tới 8049

RUT VM30 0912750910

12345

=> gửi 8049

“Ban da rút tien thanh cong khoan tai cho 101500000023. So tien bi tru trong tai khoan 30000VND. Ma so giao dich la xxxxxx. So DT ho tro 1900555577”

Thuê bao tiền rút Ví cho VnMart 09127509 với 10 mệnh giá tiền 30.000 VND

Soạn tin nhắn (SMS) với cú

Soạn tin nhắn rút tiền

Nhận được câu thông báo trả về có nội dung:

pháp:

Đáp ứng yêu cầu đặt ra

RUT VM500 0912750910 => Gửi 8049

“Giao dich chua duoc thuc hien do so du trong tai khoan vnmart. Vui long thu lai voi menh gia nap tien nho hon. So DT ho tro 1900555577”

Thuê bao rút tiền với mệnh giá 500,000 VND. Số dư tài khoản vnmart không đủ

Bảng 2- Bảng kịch bản test dịch vụ vnmart

Hiện tại hệ thống đã triển khai thực tế được các nhà cung cấp dịch vụ như thanh toán tiền điện, viễn thông trả sau, nạp tiền điện thoại trả trước, mua vé máy bay, ví điện tử, bảo hiểm… với doanh số giao dịch hàng chục tỷ đồng. Đã triển khai qua các kênh ATM, quầy giao dịch và SMS nạp tiền điện thoại. Tốc độ giao dịch đạt yêu cầu đặt ra như 1 giao dịch qua ATM sẽ nhỏ hơn 1 phút, giao dịch tại quầy <30 giây.

Tuy nhiên trong khi thực hiện giao dịch vẫn còn bị timeout bên nhà cung cấp, giao dịch thực hiện đồng thời quá nhiều dẫn tới Bill Payment Gateway không kịp xử lý dẫn tới timeout, lỗi đường truyền, lỗi ATM, lỗi mạng… Sau đây là các màn hình giao dịch thực tế của hệ thống và kết quả thanh

toán với các nhà cung cấp sau một thời gian triển khai :

Màn hình đăng nhập hệ thống :

Hình 25 - Màn hình đăng nhập hệ thống

Màn hình quản lý người sử dụng :

Hình 26 - Màn hình quản lý người sử dụng

Màn hình quản lý chi nhánh :

Hình 27 - Màn hình quản lý chi nhánh

Màn hình quản lý nhà cung cấp :

Hình 28 - Màn hình quản lý nhà cung cấp

Màn hình quản lý dịch vụ :

Hình 29 - Màn hình quản lý dịch vụ

Màn hình đăng ký khách hàng :

Hình 30 - Màn hình đăng ký khách hàng

Màn hình vấn tin về hóa đơn :

Hình 31 - Màn hình vấn tin hóa đơn

Màn hình thanh toán hóa đơn :

Hình 32 - Màn hình thanh toán hóa đơn

Các màn hình thanh toán tại ATM của BIDV :

12010000228842

TNDS Xe may

Nguyen Duc Ngoc

0912000403/29K56868

Mua bao hiem dan su xe may

66000 VND

Hình 33 - Các màn hình giao dịch tại ATM

Màn hình Bill Payment Gateway đón nhận và xử lý message từ các kênh giao

dịch :

Hình 34- Màn hình Gateway xử lý từ các kênh thanh toán

Kết quả sau khi triển khai hệ thống thanh toán hoá đơn thực tế :

Nhà cung cấp ATM Quầy SMS lượng

Số giao dịch

10000 GD 90000 GD EVN

100000 GD/ tháng

150000 750000 NẠP

900000 GD/ tháng

TIỀN ĐIỆN THOẠI TRẢ TRƯỚC(VNTOPUP)

1000 5000

6000 GD/tháng

THANH TOÁN TRỰC TUYẾN VÍ ĐIỆN TỬ VNMART

200 TIỀN

200 GD /tháng NẠP VIETPAY

200 JETSTART

200 GD / tháng

2000 BIC

2000 GD / tháng

1000 AIA

1000 GD / tháng

Bảng 3 - Kết quả triển khai thực tế

Các dịch vụ và kênh thanh toán dự kiến tích hợp và triển khai trong tương lai

Nhà cung cấp ATM

Kênh internet

Kênh Mobile Banking Quầy giao dịch

Số lượng giao dịch mong đợi

EVN

Đang tích hợp Đang tích hợp Đã triển khai

Đã triển khai 1000000 GD/ tháng

tích NẠP

Đang hợp Đang tích hợp Đã triển khai

Đã triển khai 200000 GD/ tháng TIỀN ĐIỆN THOẠI TRẢ TRƯỚC(VNTOPUP)

tích triển

Đang hợp Đã khai Đã triển khai

Đã triển khai 100000 GD/ tháng THANH TOÁN TRỰC TUYẾN VÍ ĐIỆN TỬ VNMART

tích TIỀN

Đang hợp Đang tích hợp NẠP VIETPAY

Đã triển khai 50000 GD/ tháng

tích JETSTART

Đang hợp Đang tích hợp Đã triển khai 30000 gd/ tháng

Đã triển khai

tích BIC

Đang hợp Đang tích hợp Đã triển khai 20000 gd/ tháng

tích AIA

Đang hợp Đang tích hợp Đã triển khai 10000 gd/ tháng

tích 100000 Thanh toán trả

Đang hợp Đang tích hợp Đang tích hợp sau Viettel

Đang tích hợp

Đang bàn về kỹ thuật Thanh toán trả

sau Mobile

Bảng 4 - Các dịch vụ và kênh thanh toán dự kiến triển khai trong tương lai

Đánh giá hiệu quả các dịch vụ đã triển khai:

Dịch vụ tiền điện EVN : Đây là dịch vụ triển khai đầu tiên của hệ thống thanh toán hóa đơn. Khách hàng có thể nộp tiền mặt, dùng tài khoản BIDV, hoặc có thể ủy quyền cho Ngân hàng tự động vào trích nợ hàng tháng tương ứng số tiền phát sinh bên điện lực. Do tâm lý của người Việt Nam vẫn thích dùng tiền mặt và có thói quen là các cộng tác viên của điện lực đến thu tiền tại nhà cộng với số lượng cộng tác viên của điện lực rất nhiều nên không thể chấm dứt hợp đồng lao động một sớm một chiều ngay được nên hiện nay mới triển khai được trên 20 đơn vị điện lực trên phạm vi toàn hệ thống BIDV bao gồm hơn 1000 ATM, 140 chi nhánh trên 64 tỉnh thành của cả nước. Tuy nhiên do phát sinh cước của điện lực thường là trong 1 khoảng thời gian ngắn( thường là ngày 5-15 hàng tháng) dẫn đến lưu lượng băng thông hệ thống không đều. Trong các ngày phát sinh cước thì lượng giao dịch vấn tin, thanh toán rất nhiều nhưng trong các ngày khác thì giao dịch tiền điện hầu như không có. Điều này dẫn tới khi có quá nhiều chi nhánh cùng tham gia vấn tin hay thanh toán thì hệ thống thanh toán hóa đơn cũng như hệ thống bên điện lực có thể xảy ra timeout. Hiện tại hệ thống bên BIDV đã được nâng cấp sử dụng Message Queue của IBM giúp phân tải rất tốt có thể đặt thời gian timeout tối đa cho 1 giao dịch, có thể mở đồng thời nhiều tiến trình xử lý song song nên lượng giao dịch timeout đã giảm đáng kể.

Dịch vụ tiền nạp tiền trả trước vntopup: Đây là dịch vụ rất tiện ích cho khách hàng có thể nạp tiền cho thuê bao di động trả trước cho tất cả các mạng di động

cho mình hoặc cho người thân qua hai kênh thanh toán chính là ATM và SMS. Hiện nay dịch vụ này có thể sử dụng trên toàn bộ các tỉnh thành của cả nước với thời gian 24/24. Đây là dịch vụ phối hợp với công ty VNPAY là công ty chuyên về giải pháp thanh toán. Dịch vụ triển khai được đánh giá là khá thành công trong việc quảng bá hình ảnh của BIDV giúp gia tăng các tiện ích của chủ thẻ. Hiện nay lượng giao dịch qua kênh SMS rất nhiều nhất là trong các đợt khuyến mại của các nhà cung cấp viễn thông. Trong tương lai khi triển khai thêm kênh internet chắc chắn dịch vụ sẽ càng được biết đến nhiều hơn.

Dịch vụ nạp tiền ví điện tử vnmart: Đây là dịch vụ phối hợp với với công ty VNPAY. Dịch vụ thanh toán trực tuyến mới phát triển trong vài năm gần đây tại Việt Nam. Đây là dịch vụ giúp chủ thẻ tại BIDV có thể nạp rút tiền vào tài khoản ảo qua đó dùng ví điện tử này kết hợp với các website bán hàng trực tuyến để thanh toán trực tuyến. Khi dùng dịch vụ ví điện tử này sẽ đảm bảo an toàn hơn khi thanh toán trực tuyến thay vì thanh toán trực tuyến bằng tài khoản ngân hàng. Sự phát triển của dịch vụ gắn liền với sự quảng bá dịch vụ với các website bán hàng trực tuyến. Dịch vụ ví điện tử mới triển khai cho nên lượng giao dịch chưa nhiều. Trong tương lai khi tích hợp thêm các kênh internet sẽ gia tăng tiện ích hơn cho khách hàng.

Dịch vụ nạp tiền tài khoản Vietpay: Đây là dịch vụ phối hợp với với công ty VietPay dùng để nạp tiền game cho các đại lý. Dịch vụ này mới triển khai hiện tại qua kênh quầy giao dịch. Trong tương lai khi tích hợp thêm các kênh internet, kênh mobile thì lượng giao dịch mới có thể nhiều hơn.

Dịch vụ thanh toán vé máy bay Jetstart: Đây là dịch vụ phối hợp với với công ty Onepay triển khai qua hai kênh ATM và quầy giao dịch : Khách hàng sau khi vào website của jetstart pacific để đặt chỗ rồi sẽ qua ATM hay quầy giao dịch của BIDV để thanh toán bằng cách nhập vào mã đặt chỗ. Đây là dịch vụ sẽ rất hữu ích tại những nơi không có đại lý bán vé máy bay của Jetstart đặc biệt tại các tỉnh và các huyện xa. Tuy nhiên lượng giao dịch vẫn chưa đạt được kỳ vọng. Trong tương lai khi tích hợp thêm các kênh internet, kênh mobile sẽ rất hữu ích cho khách hàng trong thanh toán trực tuyến. Như vậy chắc chắn lượng giao dịch sẽ nhiều hơn.

Dịch vụ mua bảo hiểm xe máy, ô tô qua ATM với công ty bảo hiểm BIDV(BIDV Insurance Company BIC) : Thay vì ra các đại lý bảo hiểm thì khách hàng là chủ thẻ của BIDV có thể ra ATM để đặt mua bảo hiểm ô tô, xe máy. Phương thức này giúp khách hàng có thể tiết kiệm được thời gian đồng thời có tỉ lệ chiết khấu cao hơn khi ra đại lý mua vì công ty bảo hiểm sẽ không phải trích trả cho đại lý. Đây cũng là hình thức quảng bá sự đa dạng dịch vụ cho BIDV. Dịch vụ này mới triển khai.

Dịch vụ thanh toán phí bảo hiểm qua ATM với công ty bảo hiểm Prudential: Phí đóng bảo hiểm hàng tháng sẽ được công ty gửi cho khách hàng qua bưu điện, email, điện thoại…Khách hàng chỉ cần ra ATM nhập mã hợp đồng và số tiền phải đóng vào là có thể thanh toán được phí bảo hiểm với Prudential. Đây cũng là một dịch

vụ rất mới giúp cho công ty bảo hiểm giảm bớt số lượng cộng tác viên đồng thời giúp quản lý dòng tiền thu được từ khách hàng một cách nhanh chóng chính xác tránh nhiều rủi ro khi cần đội ngũ cộng tác viên đi thu như mất tiền, tiền không hợp lệ…

Chương 5 - KẾT LUẬN VÀ HƯỚNG PHÁT TRIỂN

Luận văn tập trung nghiên cứu, tìm hiểu về mô hình kiến trúc hướng dịch vụ (SOA), ưu và nhược điểm so với các hệ thống trước đây như CORBA, DCOM…các tính chất của hệ thống SOA. Phân tích một số lợi ích đạt được và khảo sát một số mô hình của kiến trúc hướng dịch vụ cách thức triển khai xây dựng một SOA trong thực tế, các tính chất của SOA. Luận văn cũng đề cập đến việc sử dụng Web Services với các chuẩn SOAP, UDDI, WSDL…, để xây dựng, phát triển, cũng như triển khai các dịch vụ theo các tiếp cận SOA.

Những kết quả lý thuyết trên đã được vận dụng vào bài toán thực tế tại ngân hàng BIDV: xây dựng một hệ thống thanh toán tập trung các hoá đơn của các nhà cung cấp dịch vụ qua nhiều kênh giao dịch như ATM và quầy giao dịch. Mô hình SOA giải quyết bài toán này đã được đưa ra và tiến hành thực nghiệm. Hệ thống thanh toán hóa đơn đã xây dựng là hệ thống mở, dễ dàng tích hợp

thêm các dịch vụ tương lai như thanh toán tiền nước, đóng học phí, đóng viện phí, thu

hộ phí tàu xe, truyền hình cáp… cũng như có thể mở rộng các kênh thanh toán trong

tương lai như Internet, mobile… Hệ thống cũng đảm bảo tính an toàn/an ninh cao:

giữa BIDV và các nhà cung cấp dịch vụ đều có hệ thống tường lửa firewall để chặn

các truy nhập không hợp lệ, hệ thống chặn IP chỉ cho phép một số IP có thể truy nhập

vào hệ thống. Trong CSDL đều ghi vết các giao dịch chạy qua, thao tác, thời gian…

Việc quản trị và vận hành hệ thống không phức tạp, không mất nhiều thời gian

và công sức: Hiện tại các công việc của hệ thống đều được lập lịch và thực hiện tự

động, không cần có sự can thiệp của con người.

Những kết quả thu được này bước đầu khẳng định được tính đúng đắn, tính khả

thi của việc sử dụng SOA trong bài toán mang tính thực tiễn đặt ra.

Trong tương lai, hệ thống sẽ tích hợp thêm các kênh thanh toán khác như

Mobile Banking sử dụng các chuẩn Web Services đã thiết kế chung cho kênh thanh

toán tại quầy giao dịch.

TÀI LIỆU THAM KHẢO

Tiếng Việt

1. Dương Kiều Hoa. Tôn Thất Hòa An (2006), Giáo trình Phân Tích Hệ Thống

Hướng Đối Tượng Với UML, Nhà xuất bản Đại học Quốc gia TPHCM.

2. Đoàn Văn Ban (2001), Giáo trình UML.

3. Nhóm nghiệp vụ Ngân hàng Đầu tư và Phát triển Việt Nam (2008), Tài liệu yêu

cầu người sử dụng hệ thống thanh toán hóa đơn.

4. Phạm Hùng Tiến, Đặng Hoài Đức, “Báo cáo seminar: SOA, Web Service in

Grid computing”.

Tiếng Anh

5. IBM Red Book Team (2004), Pattern: Service-Oriented Architecture and Web

Services.

6. Hartwig Gunzer (2002), Introduction to Web Services

7. Stefan Link, Christof Momm , Sebastian Abeck, “The SOA’s Layer”.

8. http://www.ibm.com.

9. http://www.soaprinciples.com.

10. http://www.w3.org.

11. Xiaoying Bai (2007), Introduct to Service – Orientation, Department of

Computer Science and Technology Tsinghua Univeristy.

PHỤ LỤC - CÁC USE CASE CỦA HỆ THỐNG THANH TOÁN HÓA ĐƠN

Danh sách các usecase và các tác nhân của hệ thống

Các tác nhân của hệ thống

Các tác nhân của Web Server, và Bill Payment Gateway bao gồm:

Giao dịch viên, kiểm soát viên, người quản trị hệ thống Hệ thống SWITCH, SIBS, hệ thống quản lý của nhà cung cấp

- - Mô tả usecase

STT Phân loại Tên usecase Mã usecase

Thêm mới một chi nhánh WS-QT-0001

1 Quản lý chi nhánh

WS-QT-0002 2

Thay đổi thông tin một chi nhánh

Xóa một chi nhánh WS-QT-0003 3

Thêm mới người sử dụng WS-QT-0004

lý sử

4 Quản người dụng

WS-QT-0005 5

Thay đổi thông tin người sử dụng

Xóa người sử dụng WS-QT-0006 6

Thêm mới nhà cung cấp WS-QT-0007

7 Quản lý nhà cung cấp

WS-QT-0008 8

Thay đổi thông tin nhà cung cấp

Xóa nhà cung cấp WS-QT-0009 9

10 Quản lý dịch WS-QT-0010

vụ Thêm mới dịch vụ của nhà cung cấp

11 Thay đổi thông tin dịch vụ WS-QT-0011

của nhà cung cấp

WS-QT-0012 12

Xóa dịch vụ của nhà cung cấp

13 Quản lý Thêm mới khách hàng WS-CU-0001

khách hàng

WS-CU-0002 14

Thay đổi thông tin khách hàng

Xóa thông tin khách hàng WS-CU-0003 15

16 Đăng nhập Đăng nhập hệ thống WS-US-0001

17 Đổi mật khẩu WS-US-0002

18 Đăng xuất WS-US-0003

Bảng 5 - Danh sách các use case hệ thống

Nhóm usecase Quản lý chi nhánh

Hình 35 - Use case quản lý chi nhánh

Đặc tả của nhóm usecase Quản lý chi nhánh

Tạo mới chi nhánh

Tạo mới chi nhánh WS-QT-0001 Tên usercase

Usecase được khởi tạo bởi Quản trị viên của hệ thống nhân

Các tác tham gia usecase

1. Người quản trị chọn chức năng “Thêm mới chi Luồng xử lý

nhánh”.

2. Web Server hiển thị màn hình “Thêm mới chi nhánh”. Màn hình “Thêm mới chi nhánh” có hai trường thông tin gồm “Mã chi nhánh”, “Tên chi nhánh” và hai nút chức năng gồm “Thêm mới” và “Thoát”.

3. Nếu người quản trị nhập các thông tin về mã chi

nhánh, tên chi nhánh và nhấn nút “Thêm mới”.

5. Web Server kiểm tra tuần tự khuôn dạng của mã chi nhánh, tên chi nhánh đã được nhập hay chưa, và sự tồn tại của chi nhánh mới nhập trong cơ sở dữ liệu.

Nếu các bước kiểm tra đều đạt, nhập chi nhánh mới

vào cơ sở dữ liệu.

Nếu có một bước kiểm tra không đạt, gửi thông báo

lỗi tới người quản trị.

6. Nếu người quản trị nhấn nút “Thoát”.

7. Web Server thoát khỏi chức năng mà không thực

hiện gì cả.

Người quản trị phải đăng nhập vào hệ thống trước khi

khởi tạo usecase này. Điều kiện để khởi tạo usecase

- Khách hàng nhấn nút “Thoát” ở màn hình “Thêm

mới chi nhánh” hoặc Điều kiện kết thúc usecase

- Thông tin chi nhánh được nhập vào cơ sở dữ liệu

hoặc

- Một thông báo lỗi khi hệ thống phát hiện lỗi khi

kiểm tra thông tin đầu vào hoặc

- Một thông báo lỗi phát sinh (lỗi cơ sở dữ liệu, lỗi đường truyền …) để giải thích tại sao thông tin chi nhánh không thể nhập vào cơ sở dữ liệu.

Các thông báo lỗi mà Web Server có thể kiểm soát

được phải được hiển thị bằng tiếng Việt. Yêu cầu về chất lượng

Các thông báo lỗi khác dùng diễn giải lỗi bằng tiếng Anh của hệ thống (ví dụ thông báo lỗi của cơ sở dữ liệu, …).

Sửa thông tin chi nhánh

Thay đổi thông tin chi nhánh WS-QT-0002 Tên usercase

Usecase được khởi tạo bởi Quản trị viên của hệ thống nhân

tác Các tham gia usecase

1. Người quản trị chọn chức năng “Thay đổi thông tin Luồng xử lý

chi nhánh”.

2. Web Server hiển thị màn hình “Thay đổi thông tin chi nhánh chi nhánh”. Màn hình “Thay đổi thông tin chi nhánh” có có một combo box liệt kê danh sách các chi nhánh có trong hệ thống, một trường dữ liệu để hiện thị tên chi nhánh và ba nút chức năng gồm “Chọn chi nhánh”, “Lưu thông tin” và “Thoát”.

3. Nếu người quản trị nhấn nút “Thoát”.

4. Web Server thoát khỏi chức năng mà không thực

hiện gì cả.

5. Nếu người quản trị chọn một chi nhánh và nhấn nút

“Chọn chi nhánh”.

6. Web Server hiển thị tên chi nhánh trên trường dữ

liệu để quản trị viên thay đổi thông tin.

7. Người quản trị thay đổi thông tin về tên chi nhánh

và nhấn nút “Lưu thông tin”.

8. Web Server kiểm tra tên chi nhánh đã được nhập

hay chưa

Nếu đã nhập, lưu thôn tin sửa đổi vào cơ sở dữ liệu.

Nếu trường dữ liệu rỗng gửi thông báo lỗi tới người

quản trị.

Người quản trị phải đăng nhập vào hệ thống trước khi

khởi tạo usecase này. Điều kiện để khởi tạo usecase

- Khách hàng nhấn nút “Thoát” ở màn hình “Thay đổi

thông tin chi nhánh” hoặc Điều kiện kết thúc usecase

- Thông tin chi nhánh được nhập vào cơ sở dữ liệu

hoặc

- Một thông báo lỗi khi hệ thống phát hiện lỗi khi

kiểm tra thông tin đầu vào hoặc

- Một thông báo lỗi phát sinh (lỗi cơ sở dữ liệu, lỗi đường truyền …) để giải thích tại sao thông tin chi nhánh không thể nhập vào cơ sở dữ liệu.

Các thông báo lỗi mà Web Server có thể kiểm soát

được phải được hiển thị bằng tiếng Việt. Yêu cầu về chất lượng

Các thông báo lỗi khác dùng diễn giải lỗi bằng tiếng Anh của hệ thống (ví dụ thông báo lỗi của cơ sở dữ liệu, …).

Xóa chi nhánh

Xóa chi nhánh WS-QT-0003 Tên usercase

Usecase được khởi tạo bởi Quản trị viên của hệ thống nhân

Các tác tham gia usecase

1. Người quản trị chọn chức năng “Xóa chi nhánh”. Luồng xử lý

2. Web Server hiển thị màn hình “Xóa chi nhánh”. Màn hình “Xóa chi nhánh” có có một combo box liệt kê danh sách các chi nhánh có trong hệ thống, một trường dữ liệu để hiện thị tên chi nhánh và ba nút chức năng gồm “Chọn chi nhánh”, “Xóa chi nhánh” và “Thoát”.

3. Nếu người quản trị nhấn nút “Thoát”.

4. Web Server thoát khỏi chức năng mà không thực

hiện gì cả.

5. Nếu người quản trị chọn một chi nhánh và nhấn nút

“Chọn chi nhánh”.

6. Web Server hiển thị tên chi nhánh trên trường dữ

liệu.

7. Người quản trị nhấn nút “Xóa chi nhánh”.

8. Web Server hiển thị màn hình xác nhận thao tác

xóa chi nhánh.

Nếu người quản trị xác nhận, xóa chi nhánh ra khỏi

hệ thống.

Người quản trị phải đăng nhập vào hệ thống trước khi

khởi tạo usecase này. Điều kiện để khởi tạo usecase

- Khách hàng nhấn nút “Thoát” ở màn hình “Xóa chi

nhánh” hoặc Điều kiện kết thúc usecase

- Thông tin chi nhánh được xóa khỏi cơ sở dữ liệu

hoặc

- Một thông báo lỗi khi hệ thống phát hiện lỗi khi

kiểm tra thông tin đầu vào hoặc

- Một thông báo lỗi phát sinh (lỗi cơ sở dữ liệu, lỗi đường truyền …) để giải thích tại sao thông tin chi nhánh không thể nhập vào cơ sở dữ liệu.

Trường dữ liệu chứa thông tin chi nhánh đặt chế độ để

người quản trị không sửa được dữ liệu. Yêu cầu về chất lượng

Các thông báo lỗi mà Web Server có thể kiểm soát

được phải được hiển thị bằng tiếng Việt.

Các thông báo lỗi khác dùng diễn giải lỗi bằng tiếng Anh của hệ thống (ví dụ thông báo lỗi của cơ sở dữ liệu, …).

Nhóm usecase Quản lý người sử dụng

Hình 36 - Use case quản lý người sử dụng

Đặc tả nhóm usecase Quản lý người sử dụng

Thêm mới người sử dụng

Tạo mới NSD WS-QT-0004 Tên usercase

Usecase được khởi tạo bởi Quản trị viên của hệ thống nhân

Các tác tham gia usecase

1. Người quản trị chọn chức năng “Quản lý NSD”. Luồng xử lý

2. Web Server hiển thị màn hình “Thêm mới NSD”.

Màn hình “Thêm mới NSD” có năm trường thông tin gồm “Tên đăng nhập”, “Tên đầy đủ”, “Chi nhánh”, “Nhóm”, “Mật khẩu” và hai nút chức năng “Thêm mới”, “Thoát”.

3. Người quản trị tiến hành nhập các thông tin về Tên đăng nhập, Tên đầy đủ, Chi nhánh, lựa chọn nhóm cho người sử dụng mới từ danh sách Nhóm người sử dụng, đánh mật khẩu cho user mới tạo.

4. Kích nút “Thêm mới”

5. Web Server kiểm tra khuôn dạng của Tên đăng nhập, Mật khẩu đã nhập đủ hay còn trống, và sự tồn tại của chi nhánh, nhóm người sử dụng sau đó mới cập nhập trong cơ sở dữ liệu.

Nếu các bước kiểm tra đều đạt, người sử dụng mới sẽ

được tạo trong cơ sở dữ liệu.

Nếu có một bước kiểm tra không đạt, gửi thông báo

lỗi tới người quản trị.

6. Nếu người quản trị nhấn nút “Thoát”.

7. Web Server thoát khỏi chức năng mà không thực

hiện gì cả.

Người quản trị phải đăng nhập vào hệ thống trước khi

khởi tạo usecase này. Điều kiện để khởi tạo usecase

- Khách hàng nhấn nút “Thoát” ở màn hình “Thêm

mới người sử dụng” hoặc Điều kiện kết thúc usecase

- Thông tin người sử dụng được nhập vào cơ sở dữ

liệu hoặc

- Một thông báo lỗi khi hệ thống phát hiện lỗi khi

kiểm tra thông tin đầu vào hoặc

- Một thông báo lỗi phát sinh (lỗi cơ sở dữ liệu, lỗi đường truyền …) để giải thích tại sao thông tin về người sử dụng không thể nhập vào cơ sở dữ liệu.

Các thông báo lỗi mà Web Server có thể kiểm soát Yêu cầu về chất

được phải được hiển thị bằng tiếng Việt. lượng

Không cho phép tạo 2 người sử dụng có cùng user

Không cho phép tạo người sử dụng có user chứa ký tự

đặc biệt

Mật khẩu cần phải lớn hơn hoặc bằng 6 k ý tự để đảm bảo tính an toàn bảo mật, mật khẩu không được chứa k ý tự đặc biệt và chỉ bao gồm các k ý tự từ a-z, A-Z, 0-9

Các thông báo lỗi khác dùng diễn giải lỗi bằng tiếng Anh của hệ thống (ví dụ thông báo lỗi của cơ sở dữ liệu, …).

Thay đổi thông tin người sử dụng

Thay đổi thông tin NSD WS-QT-0005 Tên usecase

Usecase được khởi tạo bởi Quản trị viên của hệ thống nhân

tác Các tham gia usecase

1. Người quản trị chọn chức năng “Thay đổi thông tin Luồng xử lý

người sử dụng “

2. Web Server hiển thị màn hình “Thay đổi thông tin người sử dụng”. Màn hình “Thay đổi thông tin người sử dụng” gồm có một combo chứa danh sách các chi nhánh, một datagrid chứa danh sách các người sử dụng ứng với chi nhánh đã được đăng ký, các trường tên đăng nhâp, tên đầy đủ, mật khẩu, nhóm sử dụng các nút chức năng “Tìm”, “Lưu thông tin” và “Thoát” .

3. Người quản trị tiến hành lựa chọn nhà chi nhánh rồi bấm nút “Tìm”. Danh sách các người sử dụng của chi nhánh sẽ được hiển thị ở datagrid. Người quản trị chọn một trong các người sử dụng trong danh sách này.

4. Web Server hiển thị thông tin chi tiết về người sử dụng gồm tên đăng nhâp, tên đầy đủ, mật khẩu, nhóm sử dụng vào các trường tương ứng. Riêng trường tên đăng nhập không được phép sửa.

5. Người quản trị thay đổi các thông tin cần sửa rồi ấn

nút “Lưu thông tin”.

6. Web Server sẽ kiểm tra khuôn dạng các trường nhập vào xem có đúng không như mật khẩu không chứa ký

tự đặc biệt và phải dài hơn 6 ký tự…

Nếu các bước kiểm tra đều đạt, các thông tin thay

đổi sẽ được lưu vào cơ sở dữ liệu.

Nếu có một bước kiểm tra không đạt, gửi thông

báo lỗi tới người quản trị.

7. Nếu người quản trị nhấn nút “Thoát”.

8. Web Server thoát khỏi chức năng mà không thực

hiện gì cả.

Người quản trị phải đăng nhập vào hệ thống trước khi

khởi tạo usecase này. Điều kiện để khởi tạo usecase

- Người quản trị nhấn nút “Thoát” ở màn hình “Thay

đổi thông tin người sử dụng” hoặc Điều kiện kết thúc usecase

- Thông tin người sử dụng được nhập vào cơ sở dữ

liệu hoặc

- Một thông báo lỗi khi hệ thống phát hiện lỗi khi

kiểm tra thông tin đầu vào hoặc

Các thông báo lỗi mà Web Server có thể kiểm soát

được phải được hiển thị bằng tiếng Việt. Yêu cầu về chất lượng

Các thông báo lỗi khác dùng diễn giải lỗi bằng tiếng Anh của hệ thống (ví dụ thông báo lỗi của cơ sở dữ liệu, …).

Xóa người sử dụng

Xóa NSD WS-QT-0006 Tên usercase

Usecase được khởi tạo bởi Quản trị viên của hệ thống nhân

tác Các tham gia usecase

1. Người quản trị chọn chức năng “Xóa thông tin Luồng xử lý

người sử dụng “

2. Web Server hiển thị màn hình “Xóa thông tin người sử dụng”. Màn hình “Xóa thông tin người sử dụng” gồm có một combo chứa danh sách các chi nhánh, một

datagrid chứa danh sách các người sử dụng ứng với chi nhánh đã được đăng ký, các trường tên đăng nhâp, tên đầy đủ, mật khẩu, nhóm sử dụng các nút chức năng “Tìm”, “Xóa người sử dụng” và “Thoát” .

4. Web Server hiển thị thông tin chi tiết về người sử dụng gồm tên đăng nhâp, tên đầy đủ, mật khẩu, nhóm sử dụng vào các trường tương ứng.

5. Người quản trị ấn nút “Xóa người sử dụng”.

6. Web Server sẽ yêu cầu quản trị viên khẳng định lại xem có chắc chắn xóa không. Nếu chắc chắn thì sẽ xóa thông tin người sử dụng ra khỏi cơ sở dữ liệu.

7. Nếu người quản trị nhấn nút “Thoát”.

8. Web Server thoát khỏi chức năng mà không thực

hiện gì cả

Người quản trị phải đăng nhập vào hệ thống trước khi

khởi tạo usecase này. Điều kiện để khởi tạo usecase

- Người quản trị nhấn nút “Thoát” ở màn hình “Xóa

thông tin người sử dụng” hoặc Điều kiện kết thúc usecase

- Thông tin người sử dụng được xóa khỏi cơ sở dữ

liệu

- Một thông báo lỗi phát sinh (lỗi cơ sở dữ liệu, lỗi đường truyền …) để giải thích tại sao thông tin về người sử dụng không thể xóa khỏi cơ sở dữ liệu.

Các thông báo lỗi mà Web Server có thể kiểm soát

được phải được hiển thị bằng tiếng Việt. Yêu cầu về chất lượng

Các thông báo lỗi khác dùng diễn giải lỗi bằng tiếng Anh của hệ thống (ví dụ thông báo lỗi của cơ sở dữ liệu, …).

Nhóm usecase Quản lý nhà cung cấp

WEB SERVER

Thêm mới nhà cung cấp

Thay đổi thông tin nhà cung cấp

Quản trị hệ thống

Xóa nhà cung cấp

Hình 37 - Use case quản lý nhà cung cấp

Đặc tả nhóm usecase Quản lý nhà cung cấp

Thêm mới nhà cung cấp

Thêm mới nhà cung cấp WS-QT-0007 Tên usercase

Usecase được khởi tạo bởi Quản trị viên của hệ thống nhân

tác Các tham gia usecase

1. Người quản trị chọn chức năng “Thêm mới nhà Luồng xử lý

cung cấp”.

2. Web Server hiển thị màn hình “Thêm mới nhà cung cấp”. Màn hình “Thêm mới nhà cung cấp” có hai trường thông tin gồm “Mã nhà cung cấp”, “Tên nhà cung cấp” và hai nút chức năng “Thêm mới”, “Thoát”.

3. Người quản trị tiến hành nhập các thông tin về Mã

nhà cung cấp, Tên nhà cung cấp và kích nút “Thêm mới”

4. Web Server kiểm tra khuôn dạng của Tên nhà cung cấp, Mã nhà cung cấp đã nhập đủ hay còn trống, và sự hợp l ý sau đó mới cập nhập trong cơ sở dữ liệu.

Nếu các bước kiểm tra đều đạt, nhà cung cấp mới sẽ

được tạo trong cơ sở dữ liệu.

Nếu có một bước kiểm tra không đạt, gửi thông báo

lỗi tới người quản trị.

5. Nếu người quản trị nhấn nút “Thoát”.

6. Web Server thoát khỏi chức năng mà không thực

hiện gì cả.

Người quản trị phải đăng nhập vào hệ thống trước khi

khởi tạo usecase này. Điều kiện để khởi tạo usecase

- Khách hàng nhấn nút “Thoát” ở màn hình hoặc

Điều kiện kết thúc usecase - Thông tin nhà cung cấp được nhập vào cơ sở dữ liệu

hoặc

- Một thông báo lỗi khi hệ thống phát hiện lỗi khi

kiểm tra thông tin đầu vào hoặc

- Một thông báo lỗi phát sinh (lỗi cơ sở dữ liệu, lỗi đường truyền …) để giải thích tại sao thông tin về người nhà cung cấp không thể nhập vào cơ sở dữ liệu.

Các thông báo lỗi mà Web Server có thể kiểm soát

được phải được hiển thị bằng tiếng Việt. Yêu cầu về chất lượng

Không cho phép tạo 2 người nhà cung cấp có cùng mã

Không cho phép tạo nhà cung cấp có mã chứa k ý tự

đặc biệt

Nếu tên nhà cung cấp đã có trong CSDL yêu cầu Hệ thống đưa ra cảnh báo cho NSD, nếu NSD vẫn chấp nhận tên trung với tên đã có thì vẫn cho tạo bình thường

Các thông báo lỗi khác dùng diễn giải lỗi bằng tiếng Anh của hệ thống (ví dụ thông báo lỗi của cơ sở dữ liệu, …).

Thay đổi thông tin nhà cung cấp

Thay đổi thông tin nhà cung cấp WS-QT-0008 Tên usercase

Usecase được khởi tạo bởi Quản trị viên của hệ thống nhân

tác Các tham gia usecase

1. Người quản trị chọn chức năng “Thay đổi thông tin Luồng xử lý

nhà cung cấp“

2. Web Server hiển thị màn hình “Thay đổi thông

tin nhà cung cấp”. Màn hình “Thay đổi thông tin nhà cung cấp” gồm có một combo box liệt kê danh sách các nhà cung cấp có trong hệ thống, một trường dữ liệu để hiện thị tên nhà cung cấp và ba nút chức năng gồm “Chọn nhà cung cấp”, “Lưu thông tin” và “Thoát”.

3. Nếu người quản trị nhấn nút “Thoát”.

4. Web Server thoát khỏi chức năng mà không thực

hiện gì cả.

5. Nếu người quản trị chọn một nhà cung cấp và nhấn

nút “Chọn nhà cung cấp”.

6. Web Server hiển thị tên nhà cung cấp trên trường

dữ liệu để quản trị viên thay đổi thông tin

7. Người quản trị thay đổi các thông tin về tên nhà

cung cấp rồi ấn nút “Lưu thông tin”.

8. Web Server kiểm tra tên nhà cung cấp đã được

nhập hay chưa

Nếu đã nhập lưu thôn tin sửa đổi vào cơ sở dữ liệu.

Nếu trường dữ liệu rỗng gửi thông báo lỗi tới người

quản trị.

Người quản trị phải đăng nhập vào hệ thống trước khi

khởi tạo usecase này. Điều kiện để khởi tạo usecase

- Người quản trị nhấn nút “Thoát” ở màn hình “Sửa

thông tin nhà cung cấp" hoặc Điều kiện kết thúc usecase

- Thông tin nhà cung cấp được nhập vào cơ sở dữ liệu

hoặc

- Một thông báo lỗi khi hệ thống phát hiện lỗi khi

kiểm tra thông tin đầu vào hoặc

- Một thông báo lỗi phát sinh (lỗi cơ sở dữ liệu, lỗi đường truyền …) để giải thích tại sao thông tin về nhà cung cấp không thể nhập vào cơ sở dữ liệu.

Các thông báo lỗi mà Web Server có thể kiểm soát

được phải được hiển thị bằng tiếng Việt. Yêu cầu về chất lượng

Các thông báo lỗi khác dùng diễn giải lỗi bằng tiếng

Anh của hệ thống (ví dụ thông báo lỗi của cơ sở dữ liệu, …).

Xóa nhà cung cấp

Xóa nhà cung cấp WS-QT-0009 Tên usercase

Usecase được khởi tạo bởi Quản trị viên của hệ thống nhân

Các tác tham gia usecase

1. Người quản trị chọn chức năng “Xóa nhà cung cấp Luồng xử lý

“

2. Web Server hiển thị màn hình “Thay đổi thông tin chi nhánh chi nhánh”. Màn hình “Thay đổi thông tin chi nhánh” có có một combo box liệt kê danh sách các nhà cung cấp có trong hệ thống, một trường dữ liệu để hiện thị tên chi nhánh và ba nút chức năng gồm “Chọn nhà cung cấp”, “Xóa nhà cung cấp” và “Thoát”.

3. Nếu người quản trị nhấn nút “Thoát”.

4. Web Server thoát khỏi chức năng mà không thực

hiện gì cả.

5. Nếu người quản trị chọn một nhà cung cấp và nhấn

nút “Chọn nhà cung cấp”.

6. Web Server hiển thị tên nhà cung cấp trên trường

dữ liệu nhưng không cho phép thay đổi

7. Người quản trị ấn nút “Xóa nhà cung cấp”.

8. Hệ thống đưa ra màn hình yêu cầu xác nhận lại

thông tin muốn xóa

9. Nếu người quản trị xác nhận việc Xóa nhà cung

cấp.

10. Hệ thống sẽ xóa bỏ nhà cung cấp đó trong

CSDL.

Người quản trị phải đăng nhập vào hệ thống trước khi

khởi tạo usecase này. Điều kiện để khởi tạo usecase

- Người quản trị nhấn nút “Thoát” trên màn hình “Xóa

nhà cung cấp” hoặc Điều kiện kết thúc usecase

- Thông tin nhà cung cấp bị xóa khỏi cơ sở dữ liệu

hoặc

- Một thông báo lỗi phát sinh (lỗi cơ sở dữ liệu, lỗi đường truyền…) để giải thích tại sao thông tin về nhà cung cấp không thể xóa khỏi cơ sở dữ liệu.

Các thông báo lỗi mà Web Server có thể kiểm soát

được phải được hiển thị bằng tiếng Việt. Yêu cầu về chất lượng

Các thông báo lỗi khác dùng diễn giải lỗi bằng tiếng Anh của hệ thống (ví dụ thông báo lỗi của cơ sở dữ liệu, …).

Xóa nhà cung cấp WS-QT-0009 Tên usercase

Usecase được khởi tạo bởi Quản trị viên của hệ thống nhân

tác Các tham gia usecase

1. Người quản trị chọn chức năng “Xóa nhà cung cấp Luồng xử lý

“

3. Nếu người quản trị nhấn nút “Thoát”.

4. Web Server thoát khỏi chức năng mà không thực

hiện gì cả.

5. Nếu người quản trị chọn một nhà cung cấp và nhấn

nút “Chọn nhà cung cấp”.

6. Web Server hiển thị tên nhà cung cấp trên trường

dữ liệu nhưng không cho phép thay đổi

7. Người quản trị ấn nút “Xóa nhà cung cấp”.

8. Hệ thống đưa ra màn hình yêu cầu xác nhận lại

thông tin muốn xóa

9. Nếu người quản trị xác nhận việc Xóa nhà cung

cấp.

10. Hệ thống sẽ xóa bỏ nhà cung cấp đó trong

CSDL.

Người quản trị phải đăng nhập vào hệ thống trước khi

khởi tạo usecase này. Điều kiện để khởi tạo usecase

- Người quản trị nhấn nút “Thoát” trên màn hình “Xóa

nhà cung cấp” hoặc Điều kiện kết thúc usecase

- Thông tin nhà cung cấp bị xóa khỏi cơ sở dữ liệu

hoặc

Các thông báo lỗi mà Web Server có thể kiểm soát

được phải được hiển thị bằng tiếng Việt. Yêu cầu về chất lượng

Các thông báo lỗi khác dùng diễn giải lỗi bằng tiếng Anh của hệ thống (ví dụ thông báo lỗi của cơ sở dữ liệu, …).

Nhóm usecase Quản ký dịch vụ

Hình 38 - Use case quản lý dịch vụ

Đặc tả nhóm usecase Quản lý dịch vụ

Thêm mới dịch vụ

Tên usecase Thêm mới dịch vụ WS-QT-0010

Usecase được khởi tạo bởi Quản trị viên của hệ thống

Các tác nhân tham gia usecase

Luồng xử lý 1. Người quản trị chọn chức năng “Thêm mới dịch

vụ”

2. Web Server hiển thị màn hình “Thêm mới dịch

vụ”

Màn hình “Thêm mới dịch vụ” có các trường thông tin gồm “Mã dịch vụ”, “Tên dịch vụ”, “Số tài khoản”, “Tên tài khoản”, combo để chọn nhà cung cấp và nút chức năng “Thêm mới”,”Thoát”

3. Người quản trị tiến hành nhập các thông tin về Mã dịch vụ, Tên dịch vụ, Số tài khoản, Tên tài khoản, chọn chi nhánh, chọn nhà cung cấp và kích nút “Thêm mới”

4. Web Server kiểm tra khuôn dạng của Tên dịch vụ, Mã dịch vụ, Số tài khoản, Tên tài khoản đã nhập đủ hay còn trống, và sự hợp l ý sau đó mới cập nhập trong cơ sở dữ liệu.

Nếu các bước kiểm tra đều đạt, dịch vụ mới sẽ được

tạo trong cơ sở dữ liệu bằng cách tạo một bản ghi Services.

Nếu có một bước kiểm tra không đạt, gửi thông báo

lỗi tới người quản trị.

5. Nếu người quản trị nhấn nút “Thoát”.

6. Web Server thoát khỏi chức năng mà không thực

hiện gì cả.

Người quản trị phải đăng nhập vào hệ thống trước khi

khởi tạo usecase này. Điều kiện để khởi tạo usecase

- Khách hàng nhấn nút “Thoát” ở màn hình hoặc

Điều kiện kết thúc usecase - Thông tin dịch vụ được nhập vào cơ sở dữ liệu hoặc

- Một thông báo lỗi khi hệ thống phát hiện lỗi khi

kiểm tra thông tin đầu vào hoặc

- Một thông báo lỗi phát sinh (lỗi cơ sở dữ liệu, lỗi đường truyền …) để giải thích tại sao thông tin về dịch vụ không thể nhập vào cơ sở dữ liệu.

Các thông báo lỗi mà Web Server có thể kiểm soát

Yêu cầu về chất lượng được phải được hiển thị bằng tiếng Việt.

Không cho phép tạo 2 dịch vụ có cùng Mã

Không cho phép tạo dịch vụ có Mã chứa k ý tự đặc

biệt

Nếu tên dịch vụ đã có trong CSDL yêu cầu Hệ thống đưa ra cảnh báo cho NSD, nếu NSD vẫn chấp nhận tên trùng với tên đã có thì vẫn cho tạo bình thường

Các thông báo lỗi khác dùng diễn giải lỗi bằng tiếng Anh của hệ thống (ví dụ thông báo lỗi của cơ sở dữ liệu, …).

Thay đổi thông tin dịch vụ

Tên usecase Thay đổi thông tin dịch vụ WS-QT-0011

Usecase được khởi tạo bởi Quản trị viên của hệ thống

Các tác nhân tham gia usecase

Luồng xử lý 1. Người quản trị chọn chức năng “Thay đổi thông tin

dịch vụ “

2. Web Server hiển thị màn hình “Thay đổi thông tin dịch vụ”. Màn hình “Thay đổi thông tin dịch vụ” gồm có một combo chứa danh sách các nhà cung cấp, một datagrid chứa danh sách các dịch vụ ứng với nhà cung cấp đã được đăng ký, các trường mã dịch vụ, tên dịch vụ, mã nhà cung cấp, số tài khoản, tên tài khoản, số hóa đơn và các nút chức năng “Tìm”, “Lưu thông tin” và “Thoát” .

3. Nếu người quản trị nhấn nút “Thoát”.

4. Web Server thoát khỏi chức năng mà không thực

hiện gì cả.

5. Người quản trị tiến hành lựa chọn nhà cung cấp rồi bấm nút “Tìm”. Danh sách các dịch vụ của nhà cung cấp sẽ được hiển thị ở datagrid. Người quản trị chọn một trong các dịch vụ trong danh sách này.

6. Web Server hiển thị thông tin chi tiết về dịch vụ

gồm tên nhà cung cấp, mã dịch vụ, tên dịch vụ, số tài khoản, tên tài khoản, số hợp đồng vào các trường tương ứng. Riêng trường mã dịch vụ không được phép sửa.

7. Người quản trị thay đổi các thông tin cần sửa rồi ấn

nút “Sửa”.

8. Web Server sẽ kiểm tra khuôn dạng các trường nhập vào xem có đúng không như số tài khoản đúng 14 số không chứa ký tự, tên tài khoản không có dấu và không chứa ký tự đặc biệt…

Nếu các bước kiểm tra đều đạt, các thông tin thay

đổi sẽ được lưu vào cơ sở dữ liệu.

Nếu có một bước kiểm tra không đạt, gửi thông

báo lỗi tới người quản trị.

Người quản trị phải đăng nhập vào hệ thống trước khi

Điều kiện để khởi tạo usecase khởi tạo usecase này.

- Người quản trị nhấn nút “Thoát” ở màn hình “Thay

Điều kiện kết thúc usecase đổi thông tin dịch vụ”

- Thông tin về dịch vụ được nhập vào cơ sở dữ liệu

hoặc

- Một thông báo lỗi khi hệ thống phát hiện lỗi khi

kiểm tra thông tin đầu vào hoặc

Các thông báo lỗi mà Web Server có thể kiểm soát

Yêu cầu về chất lượng được phải được hiển thị bằng tiếng Việt.

Các thông báo lỗi khác dùng diễn giải lỗi bằng tiếng Anh của hệ thống (ví dụ thông báo lỗi của cơ sở dữ liệu, …).

Xóa dịch vụ

Tên usecase Xóa dịch vụ WS-QT-0012

Usecase được khởi tạo bởi Quản trị viên của hệ thống

Các tác nhân tham gia usecase

Luồng xử lý 1. Người quản trị chọn “Xóa dịch vụ”

2. Web Server hiển thị màn hình “Xóa dịch vụ”. Màn hình “Xóa dịch vụ” gồm một combo chứa danh sách các nhà cung cấp dịch vụ, một datagrid chứa danh sách các dịch vụ ứng với một nhà cung cấp và các nút chức năng “Tìm”,”Xóa dịch vụ”,”Thoát”.

3. Nếu người quản trị kích nút “Thoát”

4. Web Server thoát khỏi chức năng mà không thực

hiện gì cả.

5. Người quản trị chọn nhà cung cấp rồi bấm nút “Tìm”. Danh sách các dịch vụ ứng với nhà cung cấp này sẽ hiển thị trong datagrid. Người quản trị chọn dịch vụ cần xóa trong daragrid rồi kích nút “Xóa dịch vụ” nếu muốn bỏ dịch vụ đó khỏi CSDL

6. Hệ thống đưa ra màn hình yêu cầu xác nhận lại

thông tin muốn xóa

7. Nếu người quản trị xác nhận việc Xóa dịch vụ.

7. Hệ thống sẽ xóa bỏ dịch vụ đó trong CSDL.

Người quản trị phải đăng nhập vào hệ thống trước khi

Điều kiện để khởi tạo usecase khởi tạo usecase này.

- Người quản trị nhấn nút “Thoát” trên màn hình “Xóa

Điều kiện kết thúc usecase dịch vụ” hoặc

- Thông tin về dịch vụ được xóa khỏi cơ sở dữ liệu

- Một thông báo lỗi phát sinh (lỗi cơ sở dữ liệu, lỗi đường truyền …) để giải thích tại sao thông tin về dịch vụ không thể xóa khỏi cơ sở dữ liệu.

Các thông báo lỗi mà Web Server có thể kiểm soát

Yêu cầu về chất lượng được phải được hiển thị bằng tiếng Việt.

Các thông báo lỗi khác dùng diễn giải lỗi bằng tiếng Anh của hệ thống (ví dụ thông báo lỗi của cơ sở dữ liệu, …).

Quản lý khách hàng

Hình 39 - Use case quản lý khách hàng

Thêm mới khách hàng

Tên usecase Thêm mới khách hàng WS-CU-0001

Usecase được khởi tạo bởi giao dịch viên

Các tác nhân tham gia usecase

Luồng xử lý 1. Giao dich viên chọn chức năng “Thêm mới khách

hàng”

2. Web Server hiển thị màn hình “Thêm mới khách hàng”. Màn hình “Thêm mới khách hàng” gồm các trường thông tin gồm mã khách hàng, họ tên, địa chỉ, số chứng minh thư, điện thoại, email, fax và các nút chức năng “Thêm mới” và “Thoát”.

3. Nếu giao dịch viên nhập các thông tin về khách

hàng rồi nhấn nút “Thêm mới”

4. Web Server sẽ kiểm tra khuôn dạng các trường nhập vào. Nếu kiểm tra đạt thì Web Server sẽ kiểm tra trong cơ sở dữ liệu xem có mã khách hàng này chưa, nếu chưa thì sẽ ghi vào cơ sở dữ liệu còn nếu có lỗi thì sẽ gửi thông báo

lỗi tới người sử dụng hệ thống..

5. Nếu giao dịch viên nhấn nút “Thoát”.

6. Web Server thoát khỏi chức năng mà không thực

hiện gì cả.

Giao dịch viên phải đăng nhập vào hệ thống trước khi

Điều kiện để khởi tạo usecase khởi tạo usecase này.

- Giao dịch viên nhấn nút “Thoát” ở màn hình “Thêm

Điều kiện kết thúc usecase mới khách hàng” hoặc

- Thông tin của khách hàng đã được thêm mới vào

trong cơ sở dữ liệu.

- Một thông báo lỗi khi hệ thống phát hiện lỗi khi

kiểm tra thông tin đầu vào hoặc

- Một thông báo lỗi phát sinh (lỗi cơ sở dữ liệu, lỗi

đường truyền …).

Các thông báo lỗi mà Web Server có thể kiểm soát

Yêu cầu về chất lượng được phải được hiển thị bằng tiếng Việt.

Mã khách hàng, chứng minh thư không được chứa ký

tự đặc biệt. Chứng minh thư chỉ có thể là số 0..9

Các thông báo lỗi khác dùng diễn giải lỗi bằng tiếng Anh của hệ thống (ví dụ thông báo lỗi của cơ sở dữ liệu, …).

Sửa thông tin khách hàng

Tên usercase Thay đổi thông tin khách hàng WS-CU-0002

Usecase được khởi tạo bởi giao dịch viên của hệ

Các tác nhân tham gia usecase thống

Luồng xử lý 1. Giao dịch viên chọn chức năng “Thay đổi thông tin

khách hàng”.

2. Web Server hiển thị màn hình “Thay đổi thông tin chi nhánh khách hàng”. Màn hình “Thay đổi thông tin khách hàng” có một datagrid chứa danh sách các khách hàng, các trường mã khách hàng, tên khách hàng, số điện thoại, chứng minh thư, email, số fax và các nút chức năng gồm “Tìm”, “Lưu thông tin” và “Thoát”.

3. Nếu giao dịch viên nhấn nút “Thoát”.

4. Web Server thoát khỏi chức năng mà không thực

hiện gì cả.

5. Nếu giao dịch viên nhập tên khách hàng rồi bấm

nút “Tìm”.

6. Web Server hiển thị danh sách khách hàng ở

Datagrid

7. Người quản trị chọn một trong các khách hàng

trong danh sách này.

8. Web Server hiển thị trên các trường tương ứng như tên khách hàng, chứng minh thư, địa chỉ, điện thoại, email, số fax. Lúc này trường mã khách hàng sẽ không được phép thay đổi.

9. Giao dịch viên thay đổi thông tin về khách hàng rồi

nhấn nút “Lưu thông tin”.

10. Web Server kiểm tra tên khuôn dạng của các trường nhập vào. Nếu không có gì sai sót, lưu thông tin khách hàng vào cơ sở dữ liệu.

Nếu có sai sót, gửi thông báo lỗi tới người sử dụng.

Giao dịch viên phải đăng nhập vào hệ thống trước khi

khởi tạo usecase này. Điều kiện để khởi tạo usecase

- Khách hàng nhấn nút “Thoát” ở màn hình “Sửa kiện

thông tin khách hàng” hoặc Điều kết thúc usecase

- Thông tin khách hàng được cập nhật vào cơ sở dữ

liệu hoặc

- Một thông báo lỗi khi hệ thống phát hiện lỗi khi

kiểm tra thông tin đầu vào hoặc

- Một thông báo lỗi phát sinh (lỗi cơ sở dữ liệu, lỗi đường truyền …) để giải thích tại sao thông tin khách hàng không thể nhập vào cơ sở dữ liệu.

Yêu cầu về chất lượng

Cho phép tìm kiếm gần đúng ở tất cả các trường dữ liệu. Điều kiện lọc dữ liệu là “OR” đối với các trường tìm kiếm.

Các thông báo lỗi mà Web Server có thể kiểm soát

được phải được hiển thị bằng tiếng Việt.

Các thông báo lỗi khác dùng diễn giải lỗi bằng tiếng Anh của hệ thống (ví dụ thông báo lỗi của cơ sở dữ liệu, …).

Xóa khách hàng

Tên usecase Xóa khách hàng WS-CU-0003

Usecase được khởi tạo bởi giao dịch viên của hệ

Các tác nhân tham gia usecase thống

Luồng xử lý 1. Giao dịch viên chọn chức năng “Xóa khách hàng”.

3. Nếu giao dịch viên nhấn nút “Thoát”.

4. Web Server thoát khỏi chức năng mà không thực

hiện gì cả.

5. Nếu giao dịch viên nhập tên khách hàng vào rồi

bấm nút “Tìm”.

6. Web Server hiển thị danh sách khách hàng trên

datagrid.

7. Người quản trị chọn một trong các khách hàng

được hiển thị.

9. Giao dịch viên nhấn nút “Xóa”.

10. Web Server sẽ yêu cầu người sử dụng khẳng định lại xem có chắc chắn muốn xóa khách hàng này hay không. Nếu giao dịch viên khẳng định lại thì Web Server sẽ xóa khách hàng ra khỏi cơ sở dữ liệu..

Giao dịch viên phải đăng nhập vào hệ thống trước khi

Điều kiện để khởi tạo usecase khởi tạo usecase này.

- Khách hàng nhấn nút “Thoát” ở màn hình “Xóa

Điều kiện kết thúc usecase khách hàng” hoặc

- Thông tin khách hàng bị xóa khỏi cơ sở dữ liệu hoặc

- Một thông báo lỗi khi hệ thống phát hiện lỗi khi

kiểm tra thông tin đầu vào hoặc

- Một thông báo lỗi phát sinh (lỗi cơ sở dữ liệu, lỗi

đường truyền …).

Yêu cầu về chất lượng

Cho phép tìm kiếm gần đúng ở tất cả các trường dữ liệu. Điều kiện lọc dữ liệu là “OR” đối với các trường tìm kiếm.

Các thông báo lỗi mà Web Server có thể kiểm soát

được phải được hiển thị bằng tiếng Việt.

Các thông báo lỗi khác dùng diễn giải lỗi bằng tiếng Anh của hệ thống (ví dụ thông báo lỗi của cơ sở dữ liệu, …).

Nhóm usecase Xử lý yêu cầu từ các kênh thanh toán

Bill Payment Gateway

Vấn tin nhà cung cấp

Vấn tin dịch vụ

Vấn tin tài khoản SIBS

«uses»

Vấn tin hóa đơn

«uses»

SIBS

Switch

Vấn tin hóa đơn nhà cung cấp

«uses»

Hạch toán tài khoản SIBS

«uses»

Gạch nợ

Provider Systems

Gạch nợ hóa đơn nhà cung cấp

«uses»

Web Server

Hủy hạch toán tài khoản SIBS

«uses»

Hủy gạch nợ

«uses»

Hủy gạch nợ hóa đơn nhà cung cấp

Hình 40 - Use case xử lý thanh toán hoá đơn

Đặc tả nhóm usecase Xử lý yêu cầu từ các kênh thanh toán

Vấn tin nhà cung cấp

Tên usercase Vấn tin nhà cung cấp

Usecase được khởi tạo bởi Switch

Các tác nhân tham gia usecase

Luồng xử lý 1. Switch gửi yêu cầu vấn tin danh sách nhà cung cấp

tới Bill Payment Gateway.

2. Bill Payment Gateway tạo một bản ghi

ClientLogMsg ở cơ sở dữ liệu và kiểm tra yêu cầu

- Nếu là yêu cầu đầu tiên, gửi trả lại danh sách nhà

cung cấp với sáu bản ghi đầu tiên.

- Nếu là yêu cầu thứ 2, gửi trả lại danh sách nhà cung

cấp với sáu bản ghi thứ 2.

- …

- Nếu là yêu cầu thứ n, gửi trả lại danh sách nhà cung

cấp với sáu bản ghi thứ n.

Điều kiện để khởi tạo usecase

- Switch nhận được danh sách nhà cung cấp hoặc

Điều kiện kết thúc usecase

- Trong nhật ký giao dịch của Bill Payment Gateway phải thể hiện được đặc tả lỗi tại sao không xử lý được yêu cầu.

- Những giai đoạn quan trọng của quá trình xử lý phải

Yêu cầu về chất lượng được ghi vào nhật ký giao dịch.

- Switch nhận được danh sách nhà cung cấp trong

khoảng thời gian 05 giây.

Vấn tin dịch vụ

Tên usercase Vấn tin dịch vụ

Usecase được khởi tạo bởi SWITCH

Các tác nhân tham gia usecase

Luồng xử lý 1. Switch gửi yêu cầu vấn tin dịch vụ của một nhà

cung cấp tới Bill Payment Gateway.

2. Bill Payment Gateway tạo một bản ghi

ClientLogMsg ở cơ sở dữ liệu và kiểm tra yêu cầu

- Nếu là yêu cầu đầu tiên, gửi trả lại danh sách dịch

vụ của nhà cung cấp với sáu bản ghi đầu tiên.

- Nếu là yêu cầu thứ 2, gửi trả lại danh sách dịch vụ

của nhà cung cấp với sáu bản ghi thứ 2.

- …

- Nếu là yêu cầu thứ n, gửi trả lại danh sách dịch vụ

của nhà cung cấp với sáu bản ghi thứ n.

Điều kiện để khởi tạo usecase Trước đó Switch phải thực hiện thành công usecase “Vấn tin nhà cung cấp” và chọn một nhà cung cấp bất kỳ

trước khi gửi yêu cầu tới Bill Payment Gateway

- Switch nhận được danh sách dịch vụ của nhà cung

Điều kiện kết thúc usecase cấp hoặc

- Trong nhật ký giao dịch của Bill Payment Gateway phải thể hiện được đặc tả lỗi tại sao không xử lý được yêu cầu.

- Những giai đoạn quan trọng của quá trình xử lý phải

Yêu cầu về chất lượng được ghi vào nhật ký giao dịch.

- Switch nhận được danh sách dịch vụ của nhà cung

cấp trong khoảng thời gian 05 giây.

Vấn tin hóa đơn

Tên usercase Vấn tin hóa đơn

- Usecase được khởi tạo bởi Switch hoặc Web Server

Các tác nhân tham gia usecase - Usecase giao tiếp với SIBS và hệ thống của nhà

cung cấp dịch vụ

Luồng xử lý

1. Switch hoặc Web Server gửi yêu cầu vấn tin hóa đơn tới Bill Payment Gateway với các thông tin chính sau: Mã nhà cung cấp, mã dịch vụ, mã khách hàng tại nhà cung cấp, số tài khoản tại SIBS, …

2. Bill Payment Gateway tạo một bản ghi

ClientLogMsg ở cơ sở dữ liệu.

Bill Payment Gateway khởi tạo usecase “Vấn tin tài khoản SIBS” nếu yêu cầu được gửi đến từ Web Server và trong yêu cầu có thông tin tài khoản của khách hàng mở tại SIBS.

Bill Payment Gateway khởi tạo usecase “Vấn tin hóa

đơn nhà cung cấp”.

Bill Payment Gateway tổng hợp kết quả và gửi trả về

cho Switch hoặc Web Server

Điều kiện để khởi

Trước đó Switch phải thực hiện thành công usecase “Vấn tin dịch vụ” và chọn một dịch vụ bất kỳ trước khi gửi

tạo usecase yêu cầu tới Bill Payment Gateway

- Switch hoặc Web Server nhận được thông tin về hóa

Điều kiện kết thúc usecase đơn của khách hàng hoặc

- Thông báo lỗi giải thích tại sao yêu cầu không được

đáp ứng

- Những giai đoạn quan trọng của quá trình xử lý phải

Yêu cầu về chất lượng được ghi vào nhật ký giao dịch.

- Switch hoặc Web Server nhận được thông tin hóa

đơn trong khoảng thời gian 15 giây.

Gạch nợ

Tên usercase Gạch nợ

- Usecase được khởi tạo bởi Switch hoặc Web Server

Các tác nhân tham gia usecase - Usecase giao tiếp với SIBS và hệ thống của nhà

cung cấp dịch vụ

Luồng xử lý

1. Switch hoặc Web Server gửi yêu cầu gạch nợ tới Bill Payment Gateway với các thông tin chính sau: Mã nhà cung cấp, mã dịch vụ, mã khách hàng tại nhà cung cấp, số tài khoản tại SIBS, số tiền trên hóa đơn, …

2. Bill Payment Gateway tạo một bản ghi

ClientLogMsg ở cơ sở dữ liệu.

3. Bill Payment khởi tạo usecase “Hạch toán tài khoản SIBS” nếu yêu cầu gửi đến từ Web Server, tham số hệ thống “Hạch.toán tài khoản SIBS” được bật là “Y”, và trong yêu cầu có thông tin tài khoản khách hàng tại SIBS

4. Bill Payment Gateway thoát khỏi usecase này nếu kết quả trả về từ usecase “Hạch toán tài khoản SIBS” là không thành công, và gửi kết quả không thành công về cho Web Server.

5. Bill Payment Gateway khởi tạo usecase “Hủy hạch toán tài khoản SIBS” nếu kết quả trả về từ usecase “Hạch toán tài khoản SIBS” là timeout, và gửi kết quả không thành công về cho Web Server.

6. Bill Payment Gateway khởi tạo usecase “Gạch nợ

hóa đơn nhà cung cấp” nếu kết quả trả về từ usecase “Hạch toán tài khoản SIBS” là thành công hoặc nếu trong trường hợp không phải hạch toán tài khoản.

7. Bill Payment Gateway khởi tạo usecase “Hủy hạch toán tài khoản SIBS” nếu kết quả trả về từ usecase “Gạch nợ hóa đơn nhà cung cấp” là không thành công và trước đó Bill Payment Gateway có khởi tạo usecase “Hạch toán tài khoản SIBS”. Sau đó Bill Payment Gateway gửi kết quả không thành công về cho Switch hoặc Web Server.

8. Bill Payment Gateway khởi tạo usecase “Hủy hạch toán tài khoản SIBS” (nếu trước đó Bill Payment Gateway có khởi tạo usecase “Hạch toán tài khoản SIBS”) và usecase “Hủy gạch nợ hóa đơn nhà cung cấp” nếu kết quả trả về từ usecase “Gạch nợ hóa đơn nhà cung cấp” là timeout và gửi kết quả không thành công về cho Switch hoặc Web Server.

9. Gửi trả kết quả thành công về cho Switch hoặc Web Server nếu kết quả từ usecase “Gạch nợ hóa đơn nhà cung cấp” là thành công.

Trước đó Switch hoặc Web Server phải thực hiện

thành công usecase “Vấn tin hóa đơn” Điều kiện để khởi tạo usecase

- Switch hoặc Web Server nhận được xác nhận giao

dịch gạch nợ thành công hoặc Điều kiện kết thúc usecase

- Thông báo lỗi giải thích tại sao giao dịch gạch nợ

không thành công.

- Những giai đoạn quan trọng của quá trình xử lý phải

Yêu cầu về chất lượng được ghi vào nhật ký giao dịch.

- Switch hoặc Web Server nhận được thông tin hóa

đơn trong khoảng thời gian 15 giây.

Hủy gạch nợ

Tên usercase Hủy gạch nợ

- Usecase được khởi tạo bởi Switch hoặc Web Server

Các tác nhân tham gia usecase - Usecase giao tiếp với SIBS và hệ thống của nhà

cung cấp dịch vụ

Luồng xử lý

1. Switch hoặc Web Server gửi yêu cầu hủy gạch nợ tới Bill Payment Gateway với các thông tin chính sau: mã nhà cung cấp, mã dịch vụ, mã giao dịch gạch nợ thành công trước đó, …

2. Bill Payment Gateway tạo một bản ghi

ClientLogMsg ở cơ sở dữ liệu.

3. Bill Payment Gateway khởi tạo usecase “Hủy hạch toán tài khoản SIBS” nếu trong giao dịch gạch nợ trước đó có hạch toán tài khoản SIBS.

4. Bill Payment Gateway khởi tạo usecase “Hủy gạch

nợ hóa đơn nhà cung cấp”.

Bill Payment Gateway tổng hợp kết quả và gửi trả về

cho Switch

- Switch hoặc Web Server nhận được xác nhận giao

Điều kiện để khởi tạo usecase dịch hủy gạch nợ thành công hoặc

- Thông báo lỗi giải thích tại sao giao dịch gạch nợ

không thành công.

Trước đó Switch hoặc Web Server phải thực hiện

Điều kiện kết thúc usecase thành công usecase “Gạch nợ”

- Những giai đoạn quan trọng của quá trình

Yêu cầu về chất lượng xử lý phải được ghi vào nhật ký giao dịch.

- SWITCH hoặc Web Server nhận được thông tin hóa đơn trong khoảng thời gian 15 giây.

Nhóm usecase Đăng nhập

Hình 41 - Use case đăng nhập

Đặc tả nhóm usecase Đăng nhập

Đăng nhập hệ thống

Đăng nhập hệ thống WS-US-0001 Tên usercase

Usecase được khởi tạo bởi tất cả người sử dụng hệ nhân

thống Các tác tham gia usecase

1. Người dùng gõ địa chỉ máy chủ Web Server để Luồng xử lý

chạy chương trình đăng nhập

2. Web Server hiển thị màn hình “Đăng nhập hệ thống”. Màn hình “Đăng nhập hệ thống” có hai trường thông tin gồm “Tên người sử dụng”, “Mật khẩu” và hai nút chức năng gồm “Đăng nhập” và “Thoát”.

3. Nếu người sử dụng nhập các thông tin về tên người

sử dụng, mật khẩu và ấn nút “Đăng nhập”.

4. Web Server kiểm tra tuần tự khuôn dạng của tên người sử dụng, mật khẩu đã được nhập hay chưa. Nếu nhập rồi chương trình sẽ kiểm tra xem trong cơ sở dữ liệu có tồn tại người sử dụng này và có đúng mật khẩu hay chưa? Nếu đúng thì cho phép người sử dụng đăng nhập vào hệ thống.

Nếu có một bước kiểm tra không đạt, gửi thông báo

lỗi tới người quản trị.

5. Nếu người quản trị nhấn nút “Thoát”.

6. Web Server thoát khỏi chức năng mà không thực

hiện gì cả.

Usecase có thể được khởi tạo bởi Web Server khi

người sử dụng thực hiện usecase “Đăng xuất” Điều kiện để khởi tạo usecase

- Người sử dụng nhấn nút “Thoát” ở màn hình “Đăng

nhập hệ thống” hoặc Điều kiện kết thúc usecase

- Đăng nhập thành công vào hệ thống

- Một thông báo lỗi khi hệ thống phát hiện lỗi khi

kiểm tra thông tin đầu vào hoặc

- Một thông báo lỗi phát sinh (lỗi cơ sở dữ liệu, lỗi

đường truyền …).

Các thông báo lỗi mà Web Server có thể kiểm soát

được phải được hiển thị bằng tiếng Việt. Yêu cầu về chất lượng

Các thông báo lỗi khác dùng diễn giải lỗi bằng tiếng Anh của hệ thống (ví dụ thông báo lỗi của cơ sở dữ liệu, …).

Đổi mật khẩu

Đổi mật khẩu WS-US-0002 Tên usercase

Usecase được khởi tạo bởi tất cả người dùng hệ thống nhân

Các tác tham gia usecase

1. Người sử dụng chọn chức năng “Đổi mật khẩu”. Luồng xử lý

2. Web Server hiển thị màn hình “Đổi mật khẩu”. Màn hình “Đổi mật khẩu” có bốn trường thông tin gồm “Tên người sử dụng”, “Mật khẩu cũ”, “Mật khẩu mới”, “ Nhập lại mật khẩu mới” và hai nút chức năng gồm “Đổi mật khẩu” và “Thoát”.

3. Nếu người sử dụng nhập các thông tin về tên người sử dụng, mật khẩu cũ, mật khẩu mới, khẳng định lại mật khẩu mới và bấm nút “Đổi mật khẩu”

4. Web Server kiểm tra tuần tự khuôn dạng của tên người sử dụng, mật khẩu cũ, mật khẩu mới đã được nhập

hay chưa và sự tồn tại của người sử dụng trong cơ sở dữ liệu.

Nếu các bước kiểm tra đều đạt thì mật khẩu mới của

người sử dụng sẽ được cập nhật vào cơ sở dữ liệu.

Nếu có một bước kiểm tra không đạt, gửi thông báo

lỗi tới người sử dụng hệ thống.

5. Nếu người quản trị nhấn nút “Thoát”.

6. Web Server thoát khỏi chức năng mà không thực

hiện gì cả.

Người sử dụng phải đăng nhập vào hệ thống trước khi

khởi tạo usecase này. Điều kiện để khởi tạo usecase

- Giao dịch viên nhấn nút “Thoát” ở màn hình “Đổi

mật khẩu” hoặc Điều kiện kết thúc usecase

- Mật khẩu mới của người sử dụng được cập nhật vào

cơ sở dữ liệu hoặc

- Một thông báo lỗi khi hệ thống phát hiện lỗi khi

kiểm tra thông tin đầu vào hoặc

- Một thông báo lỗi phát sinh (lỗi cơ sở dữ liệu, lỗi đường truyền …) để giải thích tại sao thông tin mật khẩu về người sử dung không thể nhập vào cơ sở dữ liệu.

Các thông báo lỗi mà Web Server có thể kiểm soát

được phải được hiển thị bằng tiếng Việt. Yêu cầu về chất lượng

Mật khẩu phải dài ít nhất sáu ký tự và không được

chứa ký tự đặc biệt

Các thông báo lỗi khác dùng diễn giải lỗi bằng tiếng Anh của hệ thống (ví dụ thông báo lỗi của cơ sở dữ liệu, …).

Đăng xuất

Đăng xuất WS-US-0003 Tên usercase

Usecase được khởi tạo bởi tất cả người dùng hệ thống nhân

tác Các tham gia usecase

1. Người sử dụng chọn chức năng “Đăng xuất”. Luồng xử lý

2. Web Server thoát toàn bộ chức năng của hệ thống

và khởi tạo usecase “Đăng nhập hệ thống”

Người sử dụng phải đăng nhập vào hệ thống trước khi

khởi tạo usecase này. Điều kiện để khởi tạo usecase

Điều kiện kết thúc usecase

Yêu cầu về chất lượng