Với các dịch vụ có được, tác giả xây dựng mô hình tích hợp dịch vụ nhằm giải quyết bài toán quản lý nhà thuốc hiệu quả đồng thời kiểm soát được lượng thuốc mua vào bán ra thông qua việc
BỐI CẢNH, MỤC TIÊU VÀ NỀN TẢNG LÝ THUYẾT
Tổng quan
1.1.1 Bối cảnh tình hình phân phối dược phẩm hiện nay
Kinh doanh dược (bán buôn, bán lẻ) thuộc danh mục ngành nghề đầu tư kinh doanh có điều kiện thuộc lĩnh vực quản lý của Cục Quản Lý Dược - Bộ Y
Tế Các cơ sở kinh doanh dược được phân thành nhiều loại, trong đó có các cơ sở bán buôn thuốc, nguyên liệu làm thuốc và các cơ sở bán lẻ thuốc (bao gồm nhà thuốc, quầy thuốc, tủ thuốc của trạm y tế hoặc cơ sở chuyên bán thuốc đông y, thuốc dược liệu, thuốc cổ truyền) Mạng lưới các cơ sở bán lẻ thuốc tại Việt Nam rất rộng lớn, chia làm 3 nhóm: nhà sản xuất có thực hiện phân phối thuốc, chuỗi nhà thuốc và các nhà thuốc lẻ tư nhân
Mô hình màng lưới phân phối thuốc ở Việt Nam [1]:
Hình 1.1 Hệ thống phân phối dược tại Việt Nam
Qua Hình 1.1 ta có thể nhận thấy hệ thống phân phối dược tại Việt Nam thể hiện qua 3 yếu tố:
1 Doanh nghiệp sản xuất dược phẩm
Tại Việt Nam, các doanh nghiệp sản xuất dược phẩm bao gồm tân dược và đông dược sản xuất chủ yếu là các dạng bào chế đơn giản, nguồn gốc nhập khẩu dược liệu chủ yếu là từ 2 nước Trung Quốc và Ấn Độ Thuốc không đến tay trực tiếp người bệnh mà sử dụng các kênh OTC (Over The Counter), ETC( Ethical drug) cùng một số kênh phân phối khác
Tình hình sản xuất dược phẩm trong nước vẫn còn nhiều hạn chế và mới chỉ đáp ứng được khoảng 52,5 % nhu cầu sử dụng dược phẩm, số còn lại được đáp ứng thông qua việc nhập khẩu từ nước ngoài Về số lượng doanh nghiệp, theo thống kê chưa đầy đủ thì Việt Nam có khoảng 180 doanh nghiệp sản xuất dược phẩm cả nội địa và FDI Số liệu này không bao gồm các trường hợp bào chế dược liệu theo phương pháp cổ truyền, bởi các phòng khám, cơ sở khám chữa bệnh đông y (được suy đoán là rất lớn)
Sản xuất trong nước chủ yếu là các dạng bào chế đơn giản, sản xuất các loại thuốc generic (Thuốc đã hết bản quyền được phép sản xuất đại trà , đa số là
9 các thuốc thông dụng và có thành phần không quá phức tạp ) Trung bình mỗi năm tiêu thụ khoảng 60.000 tấn nguyên liệu dược phẩm các loại trong đó 80%- 90% nguyên liệu dược phải nhập khẩu (hơn 50% đến từ Trung Quốc)
Ngoài ra còn bao gồm sản xuất trực tiếp (cho các doanh nghiệp) và gia công (cho các hãng dược phẩm nước ngoài)
Một số doanh nghiệp sản xuất có hệ thống phân phối thuốc có thể trực tiếp đưa thuốc đến quầy thuốc, phòng khám Điểm mạnh của ngành dược Việt Nam đến từ hệ thống phân phối thuốc rộng khắp , đầu ra cho sản phẩm thuận lợi Đầu ra cho các sản phẩm thuốc đã có 194 nhà máy đạt chuẩn GMP – WHO đối với một hoặc một số loại thuốc,
2 Các công ty dược phẩm vừa sản xuất phân phối:
Một số doanh nghiệp có thể kể đến như: Traphaco, Sao Thái Dương Dược Hậu Giang, Domesco…
Tại đây, thuốc có thể qua các kênh OTC, ETC đến với quầy thuốc, phòng khám
3 Doanh nghiệp phân phối dược phẩm chuyên nghiệp:
Các doanh nghiệp phân phối dược phẩm nhà nước: Dược phẩm TW1 (CPC 1 ), Dược phẩm TW2 ( Codupha), Dược phẩm Đông Á Trong đó Công ty TNHH MTV Dược phẩm Trung ương 1 và Dược phẩm TW2 đều trực thuộc Tổng Công ty Dược Việt Nam Cả hai doanh nghiệp đêì hoạt động chính trong lĩnh vực kinh doanh dược phẩm không bao gồm sản xuất Trong khi, Dược phẩm TW1 có trụ sở tại Hà Nội, thì Dược phẩm TW lại thực hiện xuất nhập khẩu - thông quan và có trụ sở tại TP HCM
Doanh nghiệp phân phối dược phẩm tư nhân: Dược phẩm Đô Thành, dược phẩm Đông Đô Ba nhà phân phối sỉ dược phẩn trong nước tính đến năm 2015 là Zeullig Pharma, Diethelm Viet Nam và Mega Product chiếm 40% thị phần, ngoài ra, còn có hơn 304 nhà phân phối nước ngoài khác đang hiện diện tại Việt Nam cùng 897 nhà phân phối trong nước chiếm thị phần còn lại.4 Hệ thống chợ sỉ:
Trên thực tế, thành phần kiểm soát việc phân phối thuốc lớn nhất tại Việt Nam là hệ thống chợ sỉ tại Tp Hồ Chí Minh và Hà Nội (chợ Hapu và chợ Láng
10 Hạ) Đây là mô hình tổ chức độc đáo nhất trên thế giới và chỉ có thể tìm thấy tại Việt Nam Ví dụ như tại chợ thuốc Hapu, gần 200 quầy, hơn 300 nhà cung cấp Các tập đoàn dược phẩm đa quốc gia của Mỹ, Anh, Pháp, Đức, Hàn Quốc… và cả nhà phân phối trong nước đều tập trung ở đây Bình quân mỗi ngày có hơn
5000 lượt giao dịch, cung cấp thuốc cho các nhà thuốc, bệnh viện, phòng mạch…
Ngay bên cạnh chợ thuốc Hapu là bến xe khách, vận tải với hệ thống đi hầu hết các tỉnh phía Bắc, bưu điện Việt Nam VNPT số 51 Vụ Trọng Phụng nằm cách chỉ vài bước chân Nhờ hệ thống vận chuyển tiện lợi, quy mô lớn mà thuốc từ chợ Hapu có thể dễ dàng đến tay người tiêu dùng nhanh chóng
Cuối cùng, thuốc sẽ đến tay người bệnh thông qua các nhà thuốc, phòng khám tại các hệ thống bệnh viện công lập, bệnh viện tư nhận, qua các nhà thuốc hoặc phòng mạch
Có thể nhận thấy rằng, có rất nhiều con đường để đưa dược phẩm đến được với tay người tiêu dùng được mô tả qua mô hình phân phối thuốc như sau [2]:
Hình 1.2 Mô hình phân phối dược phẩm tại Việt Nam
11 Qua Hình 1.2 có thể tóm tắt lại các con đường như sau:
- Thuốc nhập khẩu chính ngạch:
Các nhà phân phối trong và ngoài nước thực hiện việc nhập khẩu và phân phối đến các bệnh viện, nhà thuốc, phòng mạch và chợ sỉ Bệnh nhân không nhận thuốc qua các con đường từ nhà phân phối hay chợ sỉ mà thông qua việc kê đơn của bác sĩ từ bệnh viện, phòng khám (ETC) hoặc mua thuốc không qua kê đơn tại các nhà thuốc (OTC)
- Thuốc sản xuất tại Việt Nam:
Mục tiêu và giải pháp
1.2.1 Mục tiêu của đề tài
Trong việc ứng dụng công nghệ thông tin vào bài toán quản lý nhà thuốc ta có thể thấy bất cập cần giải quyết ở đây xoay quanh vấn đề đồng bộ hóa đơn , phiếu nhập để biết được lượng thuốc nhập vào và bán ra, tránh tình trạng thuốc giả hoặc thuốc kém chất lượng Tác giả lựa chọn việc áp dụng SOA ( Kiến trúc hướng dịch vụ ) vào vấn đề quản lý nhà thuốc nhằm xây dựng các dịch vụ một cách đúng quy trình mang lại tính chính xác, tự động và đơn giản hóa các nghiệp vụ của nhà quản lý , cụ thể là :
- Dịch vụ đăng nhập lấy phiên làm việc
- Dịch vụ quản lý phiếu nhập kết nối với phần mềm của dược quốc gia
- Dịch vụ tích hợp hóa đơn bán thuốc kết nối với phần mềm của dược quốc gia
- Dịch vụ thống kê thuốc
- Dịch vụ báo cáo kết quả kinh doanh
Từ việc xây dựng các dịch vụ sẽ đem lại những lợi ích qua việc tái sử dụng phần mềm Nếu gói mã mà tạo thành một dịch vụ có quy mô và kích thước phù hợp sau đó nó có thể được tái sử dụng cho lần kế tiếp.Tính linh hoạt khi mở rộng, kết nối và tích hợp Giả sử rằng các dịch vụ sẽ được tái sử dụng, thì ta có thể đưa ra nhiều giá trị nếu ta làm cho hệ thống CNTT chỉnh sửa dễ dàng hơn Đối tượng sử dụng sẽ có cái nhìn toàn cảnh các quy trình kinh doanh được xây dựng theo quan điểm của công nghệ Khi các dự án CNTT được đặt theo quan điểm của các hoạt động và các quy trình kinh doanh hơn là các ứng dụng phần mềm phức tạp, những người làm kinh doanh có thể đánh giá và ủng hộ các dự án CNTT tốt hơn
Cơ chế này cần đạt được các kết quả sau :
- Giảm thao tác của con người thay vào đó các xử lý của máy tính
- Giảm thời gia xử lý yêu cầu
- Cập nhật thông tin theo từng bước và đúng quy trình
Mục tiêu của mô hình: hệ thống thực hiện giúp các nhà thuốc liên thông các đơn thuốc các phiếu nhập trả với hệ thống Dược Quốc gia, đồng thời quản lý
20 các nhà thuốc, quản lý kho, quản lý công tác bán thuốc, đưa ra được những thống kê báo cáo theo thời gian tùy chọn
Tầm quan trọng và lý do sử dụng hệ thống: Việc truy cập và khai thác thông tin được bảo mật tùy theo vai trò, nhiệm vụ của từng nhà thuốc, đảm bảo phục vụ công cộng nhưng vẫn an toàn về các thông tin cần bảo mật
Với nhóm dịch vụ đã nêu có thể giải quyết các vấn đề cơ bản trong việc quản lý nhà thuốc và đưa ra các định hướng kinh doanh thông qua các dịch vụ về báo cáo thông kê
Tác giả lựa chọn phạm vi nghiên cứu của tác giả xoay quanh thị trường bán kẻ thuốc tân dược tại Việt Nam Mô hình chuỗi bán lẻ thuốc tân dược đã xuất hiện trên thế giới hàng chục năm về trước Thậm chí, ở nhiều nước châu Á có nền kinh tế, qui mô dân số tương đồng Việt Nam như Thái Lan, Philippines… chuỗi nhà thuốc đã ra đời từ những năm 1940 Tại nhiều quốc gia trên thế giới, thị trường bán lẻ dược phẩm khá tập trung với chỉ trên dưới 10 chuỗi nhà thuốc chia nhau thị phần áp đảo tại mỗi quốc gia Số lượng nhà thuốc tư nhân nhỏ lẻ là không đáng kể
Tại Việt Nam, mô hình chuỗi nhà thuốc chỉ mới xuất hiện 10 năm trở lại đây Năm 2007, Phano Pharmacy là đơn vị tiên phong xây dựng mô hình chuỗi bán lẻ dược phẩm hiện đại tại Việt Nam Sau đó, thị trường mới xuất hiện thêm một vài cái tên khác như Phúc An Khang, Pharmacity, Vistar… Suốt 4-5 năm sau đó, các chuỗi nhà thuốc phát triển khá chậm về quy mô số lượng cửa hàng Một trong những lý do chủ đạo là bởi người tiêu dùng trong nước vẫn chưa thực sự quen với mô hình bán lẻ thuốc tân dược Mãi đến 1-2 năm trở lại đây, thị trường bán lẻ thuốc tân dược theo mô hình chuỗi nhà thuốc mới thực sự gây được tiếng vang và khiến người tiêu dùng cũng như nhiều nhà đầu tư bắt đầu để ý
1.2.2.2 Đối tượng nghiên cứu Đối tượng nghiên cứu hướng tới là các chủ nhà thuốc , chủ chuỗi nhà thuốc hoặc nhà sản xuất có phân phối thuốc Những đối tượng đang hoặc chưa sử dụng phần mềm quản lý nhà thuốc đạt chuẩn
Luận văn này nhằm đề xuất mô hình tích hợp dịch vụ SOA trong việc tiếp nhập và xử lý yêu cầu tích hợp dữ liệu dược quốc gia, xử lý tự động yêu cầu về đăng nhập, xử lý đồng bộ dữ liệu đơn thuốc của các cơ sở bán lẻ thuốc tân dược, đăng ký các dịch vụ lên nhà trung gian dịch vụ Các công việc cần thực hiện cụ thể như sau:
- Tìm hiểu lý thuyết liên quan :
+ Lý thuyết về SOA và Webservice
+ Xây dựng mô hình ánh xạ giải pháp theo kiến trúc SOA
+ Xây dựng ứng dụng theo kiến trúc hướng dịch vụ
+ Thử nghiệm việc đăng ký dịch vụ.
Cơ sở lý thuyết và công nghệ
1.3.1 Kiến trúc hướng dịch vụ (SOA)
Có nhiều cách định nghĩa SOA Có định nghĩa mang tính kỹ thuật, thường liên quan đến một số thuật ngữ như WSDL, SOAP, XSD, XML, SCA… Cũng có định nghĩa mang tính nghiệp vụ thể hiện tính liên kết giữa các khả năng công nghệ thông tin (CNTT) với mô hình nghiệp vụ trong doanh nghiệp Xét cho cùng, dịch vụ là những gì mà doanh nghiệp nghĩ rằng họ đang cung cấp cho khách hàng
Do đó, SOA chính là nền tảng CNTT để cung cấp những dịch vụ đó Oracle bắt đầu nhận thấy SOA tái thiết vai trò của CNTT đối với việc đổi mới kinh doanh và đây chính là con đường dẫn tới sự đổi mới nhanh nhất cho khách hàng SOA không phải là một phần mềm riêng lẻ, đó là cơ chế kiến trúc lại hệ thống nhằm nâng cao khả năng chia sẻ thông tin và ứng dụng SOA giúp các tổ chức hai việc:
- Đơn giản hóa và nâng cao hiệu quả cho môi trường CNTT phức tạp Tạo ra kiến trúc tích hợp các ứng dụng, cho phép các doanh nghiệp có thể đáp ứng nhanh chóng các yêu cầu mới của khách hàng trong môi trường cạnh tranh và không ngừng thay đổi Ở phương diện nào đó, SOA là một giải pháp cho tính phức tạp của CNTT Bằng việc đơn giản hóa các khả năng của CNTT thành các dịch vụ nghiệp vụ cụ thể được sắp xếp và quản lý, giám sát và đánh giá, các khả năng CNTT (hay nói cách khác là danh mục dịch vụ nghiệp vụ
- Để có cái nhìn tổng quát về SOA, chúng ta cùng tìm hiểu kiến trúc tổng thể của SOA Kiến trúc SOA là một kiểu kiến trúc phân tầng, được thể hiện qua hình vẽ sau [3]:
Hình 1.3 Kiến trúc phân tầng của SOA
Ta có thể thấy kiến trúc SOA trong Hình 1.3 bao gồm các thành phần như sau: Tầng dưới cùng là tầng chứa các ứng dụng con trong hệ thống CNTT của doanh nghiệp
Tầng phía trên nó là tầng chứa service thực thi
Tầng tiếp theo là tầng Orchestration (kết hợp) là sự kết hợp các service thực thi theo một quy trình
Tầng trên của tầng Orchestration là tầng chứa các service nghiệp vụ
Tầng trên của tầng các service nghiệp vụ thể hiện toàn bộ quy trình hay luồng công việc của hệ thống doanh nghiệp
23 Tầng trên cùng trong kiến trúc SOA là tầng các ứng dụng front-end
Web service, đơn giản là 1 phương thức kết nối giữa 2 ứng dụng hoặc thiệt bị điện tử thông qua WorldWideWeb (www) Web service gồm 2 loại: SOAP và REST Ở thời kì hậu PC, để đồng bộ giữa các thiết bị và kết nối giữa những website và dịch vụ, người ta dùng webservice Ngoài Web API service gửi và nhận dữ liệu bằng JSON thì web service ASMX và WCF cũng đã được các lập trình viên NET sử dụng rất nhiều để xây dựng các dịch vụ Ở bài viết này mình sẽ nêu rõ sự khác biệt của chúng, những ưu nhược điểm cũng như cách sử dụng chúng được hiệu quả
Simple Object Access Protocol (SOAP) và Representational State Transfer (REST) là 2 đáp án cho 1 câu hỏi: làm sao để truy cập Web services Sự lựa chọn ban đầu có thể dễ dàng, nhưng nhiều lúc cũng rất khó khăn với những dự án phức tạp
SOAP là chuẩn protocol để access các Webservice chuẩn, được phát triển bởi Microsoft, nó được sử dụng rộng rãi một thời gian khá lâu trước và có những lợi ích nhất định
SOAP định nghĩa 1 phương thức (set of rules) chuẩn để kết nối dựa trên XML để trao đổi thông tin SOAP sử dụng nhiều phương thức kết nối như HTTP và SMTP
REST là người đến sau, nó sữa chữa những vấn đề của SOAP và đưa ra cách đơn giản hơn để truy cập Web service Tuy nhiên, đôi lúc thì SOAP cũng dễ sử dụng hơn, đôi lúc REST cũng có những vấn đề Cả 2 công nghệ này đều cần cân nhắc trước khi quyết định sử dụng
REST mô tả 1 tập các công thức mà ở đó dữ liệu có thể được trao đổi thông qua 1 chuẩn interface (ví dụ HTTP) REST không chưa tầng message layer để định nghĩa các hàm và ràng buộc dữ liệu, vì vậy mà truyền dữ liệu bằng REST
24 cũng ít tốn băng thông hơn, thường nhận và gửi bằng JSON Client có thể access tài nguyên dựa trên URI và nhận được response cùng với state.
ASMX web service và WCF service là những loại webservice xây dựng theo chuẩn SOAP
1.3.4 Vấn đề xác thực REST API với JWT (JSON Web Token)
Như chúng ta đã biết trong API thì Client giao tiếp và gửi request (yêu cầu) đến Server thông qua URL trên giao thức HTTP , ví dụ ta có 2 yêu cầu
@RequestMapping(value = "/users/{userid}", method =
RequestMethod.GET) public User findUserByUserId(@PathVariable("userid") long userId) { return userRepository.findOne(userId);
@RequestMapping(value = "/users/{userid}", method =
RequestMethod.DELETE) public String deleteUserByUserId(@PathVariable("userid") long userId) { userRepository.delete(userId); return "Successful";
@RequestMapping: dùng để cấu hình URL của request method: ở đây mình sử dụng 2 phương thức đó là GET và DELETE
@PathVariable: đây là tham số truyền vào đi kèm với request, ở đây mình truyền trực tiếp trên đường dẫn nên mình sử dụng PathVariable
Ví dụ ta yêu cầu Server lấy User có Id là 01 như sau [GET] localhost:8080/users/01hoặc xóa [DELETE] localhost:8080/users/01 Ở đây nếu chúng ta không sử dụng bất kì phương thức nào để bảo mật API thì tất cả các User khác điều có thể gọi tới các Request này để lấy thông tin hoặc xoá User 01 và Server sẽ thực hiện yêu cầu mà không cần biết yêu cầu này có phải là của User 01 hay không Điều này rất nguy hiểm, các hacker có thể xóa hết dữ liệu hoặc đánh cắp thông tin người dùng bằng cách truy cập vào các URL này, cho nên ta cần một phương pháp nào đó để Server xác định được yêu cầu đó là của User01 thì Server mới thực hiện, vì vậy ta sẽ sử dụng JWT
Cách thức hoạt động của JWT [4]
Hình 1.4 Mô hình hoạt động của JWT
Giải thích theo Hình 1.4 thì :
Bước 1: Người dùng yêu cầu đăng nhập với Username, Password
Bước 2 + 3: Server nhận được yêu cầu và kiểm tra Username, Password nếu đúng sẽ gửi cho người dùng một chuỗi JWT
Bước 4: Người dùng sẽ dùng JWT này kèm theo các yêu cầu kế tiếp
Bước 5 + 6: Server sẽ nhận yêu cầu và kiểm tra chuổi JWT, nếu chuỗi hợp lệ thì sẽ thực hiện yêu cầu
Sử dụng phần mềm PostMan để request Server
26 Chúng ta sẽ yêu cầu đăng nhập với username = user, password = user (Tài khoản này có Id = 88)
Hình 1.5 Hình ảnh postman trả về chuỗi dữ liệu Khi đăng nhập thành công thì Server sẽ trả về một chuỗi access_token: // access_token eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJhdWQiOlsidGVzdGp3dHJlc291c mNlaWQiXSwidXNlcl9uYW1lIjoidXNlciIsInNjb3BlIjpbInJlYWQiLCJ3cml0Z SJdLCJleHAiOjE1MTM4MzE3ODcsImF1dGhvcml0aWVzIjpbIlNUQU5EQVJ EX1VTRVIiXSwianRpIjoiYzBiNjE0NDgtZWQyMi00OTMxLThkZGQtZDkyZ TI1ZWE1OTU1IiwiY2xpZW50X2lkIjoiY2xpZW50aWQifQ.2IraSC0vG7iT98N qdtJ4YMAOh7wXnHcLq2hCstTYxN8
Sau khi nhận được Token rồi chúng ta sẽ gửi yêu cầu Server lấy thông tin của User này kèm theo Token được đóng gói ở Header, đây là kết quả
Hình 1.6 Kết quả dữ liệu trả về từ postman
Hình 1.6 là tất cả thông tin của UserId = 88 vừa đăng nhập, sử dụng tiếp Token này yêu cầu Server lấy thông tin của UserId = 87
Kết Chương
Trong chương này tác giả đã trình bày các vấn đề lý thuyết cơ bản, những lý thuyết đã trình bày là cơ sở để xây dựng mô hình tích hợp dịch vụ tiếp nhập và xử lý yêu cầu tích hợp dữ liệu Phần hai của chương này trình bày về cơ sở lý thuyết của luận văn bao gồm: Tổng thể giải pháp SOA , Xây dựng và mô tả dịch vụ của cơ sở GPP
Các dịch vụ sẽ được xây dựng thông qua việc chuyển đổi từ các hệ thống tác nghiệp nội bộ và được mô tả bằng các thuộc tính liên quan
XÂY DỰNG MÔ HÌNH TÍCH HỢP DỊCH VỤ QUẢN LÝ NHÀ THUỐC
Mô hình tích hợp dịch vụ ánh xạ theo SOA
Dựa trên cơ sở nền tảng lý thuyết kiến trúc hướng dịch vụ SOA và mô hình Web API, tác giả đề xuất mô hình tích hợp dịch vụ tiếp nhập và xử lý yêu cầu tích hợp dữ liệu dược quốc gia Từ đó xây dựng xây dựng dịch vụ tiếp nhập các yêu cầu về đăng nhập, xử lý đồng bộ dữ liệu đơn thuốc của các cơ sở bán lẻ thuốc tân dược
Hình 2.1 Mô hình ánh xạ giải pháp theo kiến trúc SOA
29 Tầng dưới cùng là tầng cơ sở dữ liệu : lưu trữ cơ sở dữ liệu nội tại của hệ thống, cung cấp dữ liệu cho tầng dịch vụ xử lý.
Tầng dịch vụ tích hợp : Là tầng chứa các dịch vụ đăng nhập , dịch vụ tích hợp hóa đơn và dịch vụ tích hợp phiếu nhập tương ứng với tầng Implementation Services
Tầng dịch vụ kinh doanh : Là tầng chứa các dịch vụ thống kê và dịch vụ báo cáo tương ứng với tương ứng với tầng Business Services
Tầng giao diện hiển thị : gồm giao diện website hiển thị cho chủ nhà thuốc và website hiển thị của cục quản lý dược tương ứng với tầng Front-end
Việc xây dựng dịch vụ ánh xạ theo kiến trúc SOA giúp cho việc xác định được miền vấn đề của quy trình nghiệp vụ quản lý nhà thuốc trở nên rõ ràng Từ đó việc lựa chọn công nghệ trở nên phù hợp hơn, cung cấp cơ sở xây dựng tầm nhìn của việc phát triển phần mềm.
Dịch vụ kết nối với cơ sở dữ liệu dược quốc gia
Để chủ nhà thuốc có thể kết nối với cơ sở dữ liệu dược quốc gia việc đầu tiên là các chủ nhà thuốc phải có mã liên thông Mã liên thông này tùy vào từng sở y tế sẽ thực hiện việc cấp cho nhà thuốc với cách thức khác nhau Ví dụ : Sở
Y tế tỉnh Bình Định sẽ yêu cầu các nhà thuốc làm đơn theo mẫu và gửi qua email Căn cứ vào các giấy tờ liên quan như : Giấy phép kinh doanh, Giấy chứng nhận đủ điều kiện kinh doanh dược, giấy chứng chỉ hành nghề dược cùng với đơn đăng ký và các giấy tờ liên quan khác, Sở Y Tế tỉnh Bình Định sẽ trực tiếp gửi tài khoản liên thông đó cho nhà thuốc sau từ 1 đến 2 ngày với 3 nội dung chính mà các chủ nhà thuốc phải lưu ý là : Mã cơ sở, Tên tài khoản kết nối dữ liệu, Mật khẩu tài khoản
Chủ nhà thuốc sau khi nhận được nội dung tài khoản có thể tiến hành truy cập vào địa chỉ trang web của cục quản lý dược : duocquocgia.com.vn để kiểm tra lại tài khoản và thay đổi lại mật khẩu
Hình 2.2 Giao diện đăng nhập website của cục quản lý dược
Hình 2.3 Giao diện người dùng website của cục quản lý dược
Hình 2.2 và Hình 2.3 là hình ảnh giao diện của phần mềm do bên dược quốc gia quản lý Sau khi hoàn thành việc này chủ nhà thuốc có quyền tự do lựa chọn bất kỳ cơ sở cung cấp phần mềm bất kỳ trên địa bàn theo nguyên tắc cơ sở trên phải đáp ứng các quy định tại quyết định số 540/QĐ-QLD và quyết định số 777/QĐ-QLD về chuẩn dữ liệu đầu ra và chuẩn dữ liệu phần mềm theo điều 1 khoản a công văn hướng dẫn việc triển khai kết nối liên thông dữ liệu với hệ thống “Cơ sở dữ liệu Dược Quốc gia”(CV 10045).
Xây dựng dịch vụ dựa trên dịch vụ kết nối với cơ sở dữ liệu dược quốc
Dựa theo mô tả về dịch vụ kết nối cơ sở dữ liệu dược quốc gia đươc mô tả ở phần trước đó có thể thấy rằng chủ nhà thuốc là consumer sử dụng dịch vụ của 2 provider là cục quản lý dược và phần mềm quản lý nhà thuốc để thực hiện việc báo cáo hóa đơn và phiếu nhập trong hoạt động kinh doanh Phần mềm quản lý thuốc là consumer sử dụng dịch vụ CSDL thuốc từ provider là Cục quản lý dược
Từ đây , tác giả tiến hành xây dựng các dịch vụ quản lý nhà thuốc dựa trên dịch vụ liên thông dữ liệu dược quốc gia Phần mềm quản lý nhà thuốc có cô hình truyền dữ liệu như sau:
Hình 2.4 Mô hình truyền dữ liệu cần xây dựng Phần mềm quản lý nhà thuốc 24x7 thuộc nhóm các phần mềm bên thứ 3 , cung cấp các dịch vụ phục vụ việc quản lý nhá thuốc , đáp ứng các quy định tại quyết định số 540/QĐ-QLD và quyết định số 777/QĐ-QLD về chuẩn dữ liệu đầu ra và chuẩn dữ liệu phần mềm Ngoài ra phần mềm đã thực hiện việc kết nối CSDL với hệ thống “ Cơ sở dữ liệu dược quốc gia” theo hướng dẫn từ khoản 2 phụ lục đính kèm công văn số 24026 /QLD – Ttra ngày 28 tháng 2 năm 2018
Hình 2.5 Mô hình cài đặt
Hình 2.5 mô tả hệ thống xây dựng chức năng dưới dạng các API với mục đích cung cấp cho việc tái sử dụng Vấn đề về hiệu năng và cơ chế đảm bảo an toàn được đảm bảo an toàn do hệ thống dữ liệu khách hàng được lưu trữ trên đám mây
Phần xây dựng webservice hệ thống sử dụng chuẩn kết nối RESTful APIs đây một tiêu chuẩn dùng trong việc thết kế các thiết kế API cho các ứng dụng web để quản lý các resource RESTful là một trong những kiểu thiết kế API được sử dụng phổ biến nhất ngày nay Mỗi dịch vụ được xây dựng gồm các thành phần :request url; các request method như : GET, PUT, POST, DELETE Trong đó:
GET để truy vấn object
POST để tạo object mới
PUT để sửa đổi hoặc thay thế một object
DELETE để loại bỏ một object
33 Khi nhận được yêu cầu từ một máy khách, webserive sẽ trả về tài nguyên được yêu cầu Tài nguyên này là định dạng dữ liệu Json
Phần thiết kế cơ sở dữ liệu: Phần mềm quanlythuoc24x7 xử dụng Database: MySQL với chuẩn dữ liệu phần mềm và chuẩn dữ liệu đầu ra đã được đăng ký với cục Quản lý dược
Mô hình chức năng tổng quan
Dựa trên phân tích chức năng của từng dịch vụ ta có mô hình chức năng tổng của toàn hệ thống được mô tả theo hình dưới đây :
Hình 2.7 Mô hình tổng quan chức năng
Tiếp theo đó là xây dựng lược đồ tuần tự của dịch vụ :
Hình 2.8 Lược đồ tuần tự của dịch vụ
35 Phiên khách được lưu trữ trên máy khách Máy chủ không trạng thái có nghĩa là mọi máy chủ có thể phục vụ bất kỳ máy khách nào vào bất kỳ lúc nào, không có mối quan hệ với phiên làm việc Thông tin về phiên làm việc có liên quan được lưu trữ trên máy khách và được chuyển đến máy chủ khi cần Khách hàng sau khi tiên hành đăng ký tài khoản và đăng nhập vào hệ thống sẽ tự động duyệt thông qua các yêu cầu Các yêu cầu từ khách hàng bao gồm việc quản lý hóa đơn , phiếu nhập tương ứng hệ thống sẽ tự động cập nhật và xử lý việc kết nối dữ liệu và trả về các thông điệp cũng như báo cáo thống kê tương ứng.
Dịch vụ đăng nhập lấy phiên làm việc
Chủ nhà thuốc tiến hành đăng ký tài khoản và đăng nhập vào ứng dụng Sau khi đăng nhập thành công hệ thống sẽ tự động gửi yêu cầu cấp phiên làm việc lên hệ thống Dược quốc gia Hệ thống sẽ trả về Token tương ứng với phiên làm việc
Tên đăng nhập hoặc mật khẩu không đúng
- Trường hợp thành công: Hệ thống trả về:
Content-Type application/json;charset=UTF-8
Json data Trả về là một object bao gồm các thuộc tính sau:
{ token : token được sử dụng cho phiên làm việc, token_type: "bearer",
- Mô tả hoạt động của dịch vụ :
Hình 2.9 Mô hình hoạt động của dịch vụ đăng nhập
- Giao diện đăng nhập: Giao diện đăng nhập được xây dựng trên Web frontend-Reactjs
Dịch vụ quản lý phiếu nhập từ cơ sở GPP
Dịch vụ quản lý phiếu nhập là dịch vụ phục vụ cho nghiệp vụ nhập thuốc, sau khi đăng nhập tài khoản thành công chủ nhà thuốc cần tiến hành đồng bộ hóa tài khoản liên thông với phần mềm:
Hình 2.11 Mô tả quá trình đồng bộ hóa tài khoản liên thông
37 Sau khi hệ thống thông báo thành công , chủ nhà thuốc có thể tiến hành tìm kiếm thông tin thuốc và tạo hóa đơn bán hành thông qua việc lựa chọn các thông số về: Số lượng , quy cách đóng gói , đơn vị tính , giá nhập , giá bán , số lô, Trong đó:
* Số lượng: Tính theo (đơn vị nhập) Ví dụ: nhập 1 thùng có 5 hộp(đơn vị bán là hộp) => Số lượng = 1
* Quy cách: Là cách đóng gói của sản phẩm tính theo (đơn vị bán) Ví dụ: nhập 1 thùng có 5 hộp (đơn vị bán là hộp) => Quy cách = 5, nhập 1 hộp có 2 vỉ * 10 viên (đơn vị bán là viên) => Quy cách = 2*10
* Giá nhập(sỉ): Là giá nhập trên 01 (đơn vị nhập) Ví dụ: nhập 1 thùng có 5 hộp có giá 500.000 đ => Giá nhâp(sỉ) của 1 thùng = 500.000 đ
* Giá nhập(lẻ): Là giá nhập trên 01 (đơn vị bán) Ví dụ: nhập 1 thùng có 5 hộp có giá 500.000 đ => Giá nhâp(lẻ) của 1 hộp = 100.000 đ
* Giá bán(lẻ): Là giá bán trên 01 (đơn vị bán) Ví dụ: nhập 1 thùng có 5 hộp có giá 500.000 đ => Giá bán(lẻ) của 1 hộp = 150.000 đ
Tiếp sau đó phiếu nhập này sẽ được hệ thống tự động liên thông với phần mềm của Cục Quản Lý Dược Chủ nhà thuốc có thể đăng nhập tài khoản tại website :quanlyduoc.com.vn để xem lại tình hình liên thông phiếu nhập
Dịch vụ quản lý phiếu nhập có các chức năng chính sau :
- Tạo phiếu nhập: Đầu vào: Request URL, Request Method, Request Header Đầu ra: Hệ thống trả về
- Trường hợp lỗi: Chưa xác thực tài khoản Đầu vào chưa hợp lệ -Trường hợp thành công: Thành công
- Cập nhật phiếu nhập: Đầu vào: Request URL, Request Method, Request Header Đầu ra: Hệ thống trả về
- Trường hợp lỗi: Chưa xác thực tài khoản Đầu vào chưa hợp lệ
38 Không tồn tại hóa đơn
-Trường hợp thành công: Thành công
- Xóa phiếu nhập: Đầu vào: Request URL, Request Method, Request Header Đầu ra: Hệ thống trả về
- Trường hợp lỗi: Chưa xác thực tài khoản
Không tồn tại đơn thuốc -Trường hợp thành công: Xóa thông tin thành công
- Mô tả hoạt động của dịch vụ:
Hình 2.12 Mô tả hoạt động dịch vụ quản lý phiếu nhập
- Giao diện dịch vụ quản lý phiếu nhập: xây dựng trên Web frontend-Reactjs
Hình 2.13 Giao diện dịch vụ quản lý phiếu nhập
39 Sau khi phiếu nhập được lưu lại thành công hệ thống sẽ tự động kết nối với phần mềm của dược quốc gia và cập nhật phiếu nhập lên giao diện người dùng:
Hình 2.14 Giao diện chi tiết phiếu nhập trên phần mềm của dược quốc gia
Dịch vụ tích hợp hóa đơn bán thuốc của cơ sở GPP
Dịch vụ tích hợp hóa đơn bán thuốc là dịch vụ phục vụ cho nghiệp vụ bán thuốc của mỗi nhà thuốc Sau khi tiến hành đăng nhập, đồng bộ hóa tài khoản liên thông và thực hiện tạo phiếu nhập thuốc chủ nhà thuốc có thể tiến hành tạo hóa đơn bán thuốc qua việc tìm kiếm theo:Tên thuốc, Mã thuốc hoặc Mã(barcode) Hệ thống sẽ tự động trả về thông tin thuốc có trong kho nhập Các thông tin liên quan đến hóa đơn bán thuốc bao gồm : Tên thuốc , Số lượng, Đơn vị tính , Giá bán , Thành tiền
Tiếp sau đó hóa đơn này sẽ được hệ thống tự động liên thông với phần mềm của Cục Quản Lý Dược Chủ nhà thuốc có thể đăng nhập tài khoản tại website :quanlyduoc.com.vn để xem lại tình hình liên thông hóa đơn
Dịch vụ tích hợp hóa đơn bán thuốc có các chức năng chính sau:
- Tạo hóa đơn bán thuốc: Đầu vào: Request URL, Request Method, Request Header Đầu ra: Hệ thống trả về
- Trường hợp lỗi: Chưa xác thực tài khoản
40 Đầu vào chưa hợp lệ
- Trường hợp thành công: Tạo đơn thuốc thành công
- Cập nhật hóa đơn bán thuốc: Đầu vào: Request URL, Request Method, Request Header Đầu ra: Hệ thống trả về
- Trường hợp lỗi: Chưa xác thực tài khoản
- Trường hợp thành công: Cập nhật đơn thuốc thành công
- Xóa hóa đơn bán thuốc: Đầu vào: Request URL, Request Method, Request Header Đầu ra: Hệ thống trả về
- Trường hợp lỗi: Chưa xác thực tài khoản -Trường hợp thành công: Xóa thành công
- Mô tả hoạt động của dịch vụ:
Hình 2.15 Mô tả hoạt động của dịch vụ tích hợp hóa đơn bán thuốc
- Giao diện dịch vụ tích hợp hóa đơn: xây dựng trên Web frontend-Reactjs
41 Hình 2.16 Giao diện dịch vụ tích hợp hóa đơn
Sau khi hóa đơn được lưu lại thành công hệ thống sẽ tự động kết nối với phần mềm của dược quốc gia và cập nhật phiếu nhập lên giao diện người dùng:
Hình 2.17 Giao diện chi tiết hóa đơn trên phần mềm của dược quốc gia
Dịch vụ thống kê thuốc
Dịch vụ thống kê thuốc có các chức năng chính sau :
- Thống kê thuốc trong kho:
Căn cứ vào lịch sử nhập, lịch sử bán, hệ thống tự động tính toán lượng thuốc còn lại trong kho và tạo thành danh sách hiển thị trên giao diện người dùng Chủ nhà thuốc có thể tải về thống kế thuốc dưới dạng file excel
42 Đầu vào: Request URL, Request Method, Request Header Đầu ra: Hệ thống trả về
- Trường hợp lỗi: Chưa xác thực tài khoản
- Trường hợp thành công: Danh sách thuốc có trong kho
- Thống kê thuốc săp hết hạn:
Căn cứ vào hạn dùng thuốc , hệ thống sẽ tự động liệt mặt hàng thuốc có hạn sử dụng dưới 6 tháng vào danh sách thuốc sắp hết hạn hiển thị trên giao diện người dùng Chủ nhà thuốc có thể tải về thống kê thuốc dưới dạng file excel Đầu vào: Request URL, Request Method, Request Header Đầu ra: Hệ thống trả về:
- Trường hợp lỗi: Chưa xác thực tài khoản
- Trường hợp thành công: Danh sách thuốc sắp hết hạn
- Mô tả hoạt động của dịch vụ:
Hình 2.18 Mô tả hoạt động dịch vụ thống kê thuốc
- Giao diện dịch vụ thống kê: xây dựng trên Web frontend-Reactjs
Hình 2.19 Giao diện dịch vụ thống kê thuốc
Dịch vụ báo cáo
Dịch vụ báo cáo có những chức năng chính như sau:
- Báo cáo lãi chi tiết:
Căn cứ vào số liệu tiền vốn , tiền bán ra hệ thống tiến hành đưa ra chênh lệch trên mỗi thuốc đã bán và tự động tạo báo cáo lãi chi tiết theo thời gian hiển thị trên giao diện người dùng Đầu vào: Request URL, Request Method, Request Header Đầu ra: Hệ thống trả về:
- Trường hợp lỗi: Chưa xác thực tài khoản
- Trường hợp thành công: Báo cáo lãi chi tiết
Dựa vào số lượng và tổng tiền bán ra trên mỗi thuốc đã bán , hệ thống tự động tạo báo cáo thuốc bán chạy nhất dựa trên thời gian hiển thị trên giao diện người dùng,sắp xếp theo thứ tự giảm dần của tổng tiền bán Chủ nhà thuốc dựa vào đây để đưa ra quyết định về số lượng nhập hàng Đầu vào: Request URL, Request Method, Request Header Đầu ra: Hệ thống trả về:
- Trường hợp lỗi: Chưa xác thực tài khoản
- Trường hợp thành công: Báo cáo thuốc bán chạy
Căn cứ vào số lượng, tổng tiền bán, tổng tiền nhập, tổng tiền lãi, hệ thống tự động tạo báo cáo thuốc lãi nhất dựa trên thời gian hiển thị trên giao diện người dùng,sắp xếp theo thứ tự giảm dần của tổng tiền lãi Chủ nhà thuốc dựa vào đây để đưa ra quyết định về thuốc cần nhập cũng như số lượng nhập về Đầu vào: Request URL, Request Method, Request Header Đầu ra: Hệ thống trả về:
- Trường hợp lỗi: Chưa xác thực tài khoản
- Trường hợp thành công: Báo cáo thuốc lãi nhất
Căn cứ vào số tiền bán được trên hóa đơn , phần mềm tự động tạo ra báo cáo doanh số bán hàng theo ngày , cập nhật mỗi khi có hóa đơn tạo mới và tạo ra báo cáo theo cột với trục “x” tương ứng với thời gian , trục “y” tương ứng với lượng tiền Chủ nhà thuốc dựa vào đây để có cái nhìn tổng quát về tình hình bán hàng Đầu vào: Request URL, Request Method, Request Header Đầu ra: Hệ thống trả về:
- Trường hợp lỗi: Chưa xác thực tài khoản
- Trường hợp thành công: Báo cáo doanh số ngày
45 Tương tự với báo cáo doanh số ngày , báo cáo danh số nhân viên cũng cập nhật mỗi khi có hóa đơn mới được tạo ra từ nhân viên và tạo báo cáo dạng cột với trục “x” là tên nhân viên , trục “y: là lượng tiền Chủ nhà thuốc dựa vào báo cáo này để xác định khả năng của nhân viên cũng như ca kíp có lượng khách hàng đến mua nhiều Đầu vào: Request URL, Request Method, Request Header Đầu ra: Hệ thống trả về:
- Trường hợp lỗi: Chưa xác thực tài khoản
- Trường hợp thành công: Báo cáo doanh số nhân viên
- Doanh số chi nhánh: Đối với mỗi chi nhánh khác nhau lại có tình hình kinh doanh thuốc khác nhau chức năng báo cáo doanh số trên mỗi chi nhánh là cần thiết để chủ nhà thuốc có cái nhìn tổng quan và so sánh các chi nhánh với nhau Phần mềm tự động dựa vào thông tin hóa đơn trên mỗi chi nhánh để xây dựng báo cáo dạng cột với trục “x” là tên chi nhánh, trục “y ” là lượng tiền Đầu vào: Request URL, Request Method, Request Header Đầu ra: Hệ thống trả về:
- Trường hợp lỗi: Chưa xác thực tài khoản
- Trường hợp thành công: Báo cáo doanh số chi nhánh
- Mô tả hoạt động của dịch vụ:
Hình 2.20 Mô tả dịch vụ báo cáo
- Giao diện dịch vụ báo cáo: xây dựng trên Web frontend-Reactjs
Hình 2.21 Giao diện dịch vụ báo cáo
Hình 2.22 Giao diện chức năng báo cáo doanh số bán hàng theo ngày
Hình 2.23 Giao diện chức năng báo cáo doanh số bán hàng theo nhân viên
Kết chương
Kiến trúc hướng Dịch vụ là một cách tiếp cận tốt với kiến trúc của hệ thống thông tin, bằng cách sử dụng các cơ chế làm cho chúng kết nối tốt với nhau, cả ở trong và ngoài doanh nghiệp
Thực tế là doanh nghiệp thực sự cần một kiến trúc bên trong doanh nghiệp, như là Kiến trúc hướng Dịch vụ, để thiết lập hầu hết các tính toán đám mây Trong chương này đã trình bày chi tiết về mô hình triển khai, mô hình tích hợp dịch vụ SOA và trình bày chi tiết về các dịch vụ tích hợp thông tin dược quốc gia từ các phần mềm quản lý nhà thuốc ở các cơ sở kinh doanh dược phẩm.
THỬ NGHIỆM TRÊN NỀN TẢNG KIẾN TRÚC HƯỚNG DỊCH VỤ (SOA)
Mô hình triển khai
Sau khi đóng gói các chức năng của phần mềm dưới dạng dịch vụ Tác giả tiến hành đăng ký dịch vụ với trung gian dịch vụ Các dịch vụ đăng ký thuốc nhóm Business service phục vụ cho việc báo cáo thống kê của chủ nhà thuốc Các nhà thuốc sử dụng phần mềm khác trên cùng 1 nền tảng có thể tái sử dụng dịch vụ
Mô hình triển khai như sau:
Hình 3.1 Mô hình triển khai đăng ký dịch vụ
Nhà cung cấp dịch vụ ở đây đóng vai trò là thành phần duy trì dịch vụ và đăng ký với thành phần cho phép đăng ký dịch vụ Trao đổi thông tin liên quan về các dịch vụ được cung cấp như tính sẵn có, bảo mật, những gì cần tính phí
49 Nhà môi giới dịch vụ tác giả lựa chọn là Eureka sever với vai trò cung cấp thông tin liên quan đến dịch vụ cho những người yêu cầu dịch vụ Phạm vi của broker được tác giả xác định thông qua việc triển khai và cấu hình máy chủ
Người yêu cầu dịch vụ ở đây là các đối tượng quan tâm đến dịch vụ thuộc nhóm business services đối tượng khách hàng này tìm kiếm các dịch vụ từ trung gian dịch vụ và sau đó liên kết với nhà cung cấp dịch vụ.
Cài đặt và thử nghiệm
Ngoài ứng dụng thử nghiệm mô hình tích hợp dịch vụ được xây dựng tác giả cài đặt hệ thống thử nghiệm bao gồm các bước thành phần sau:
1 Cài đặt Spring Boot lên Eclipse
2 Xây dựng một máy chủ Eureka
Ngôn ngữ sử dụng : Java
Eclipse IDE for Rust Developers Version: 2019-12 (4.14.0)
3.2.2 Kịch bản thử nghiệm Tác giả xây dựng kịch bản thử nghiệm như sau:
1 App quanluthuoc24x7 đóng vai trò là nhà cung cấp dịch vụ tiến hành tạo một Eureka sever với vai trò trung gian dịch vụ
2 Nhà cung cấp tiến hành đăng ký dịch vụ lên Eureka
3 Máy chủ Eureka tự động cập nhật trạng thái dịch vụ được đăng ký
4 Eureka sever trả về một URL và mô tả cho dịch vụ được yêu cầu
5 Chủ nhà thuốc sử dụng các ứng dụng quản lý nhà thuốc khác cùng nền nhận được thông điệp phản hồi là định dạng dữ liệu dễ hiểu bởi ứng dụng
Bước 1 : Truy cập https://start.spring.io/ và khởi động Spring với 2 phụ thuộc là Eureka sever và Actutor cho dự án Maven
Hình 3.2 Trang chủ của Spring.io Giải nén file đã tải về và nhập dự án vào Eclipse dưới dạng 1 dự án maven Trong bước này, tất cả các phụ thuộc cần thiết sẽ được tải xuống từ kho lưu trữ của maven.Cấu trúc dự án hoàn chỉnh có dạng:
Hình 3.3 Cấu trúc dự án Maven
51 Bước 2 : Cấu hình cho Eureka sever
Tiền hành sửa đổi file application.properties nằm trong EurekaServer/src/main/ resources/ để thêm port và vô hiệu hóa đăng ký
Hình 3.4 Cấu hình servier.port trong file appclication.properties
Mở EurekaServer/src/main/java/com/example/EurekaServiceApplication.java và thêm @EnableEurekaServer ở trên @SpringBootApplication import org.springframework.cloud.netflix.eureka.server.EnableEurekaServer;
Việc này sẽ cấu hình một sổ đăng ký cho phép các ứng dụng khác giao tiếp
Bước 3 : Khởi động Eureka sever:
Nhấp chuột phải vào Project Run As Spring boot app
Hình 3.5 Khởi động Eureka sever
Kết quả : Sau quá trình khởi chạy , ta sẽ có thể mở http://localhost:8761 và trạng thái hiện giờ không có dịch vụ nào đang chạy
53 Hình 3.6 Giao diện Spring Eureka
Ghi chú : Ngoài việc triển khai Eureka sever dưới dạng project của maven ta còn có thể triển khai từ Spring project với Type maven hoặc dưới dạng Gradle
2 Tiến hành đăng ký dịch vụ lên Eureka sever
Bắt đầu với dịch vụ báo cáo (Report service ) tác giả tiến hành khởi tạo Spring starter project với các nội dung : spring-eureka-client-report-service
Tiến hành lựa chọn 4 phụ thuộc gồm:
Hình 3.7 Khởi tạo dưới dạng dự án của Spring
`Cấu trúc dự án có dạng:
Hình 3.8 Cấu trúc tệp của dịch vụ
Tác giả tiến hành thêm @EnableEurekaClient chú thích vào lớp ứng dụng có trong thư mục src Qua đó project này sẽ hoạt động như một máy khách và sẽ tự đăng ký trong máy chủ Eureka gắn liền với dịch vụ: package com.example.howtodoinjava.springeurekaclientreportservice; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication;
55 import org.springframework.cloud.netflix.eureka.EnableEurekaClient;
@EnableEurekaClient public class SpringEurekaClientReportServiceApplication { public static void main(String[] args) {
SpringApplication.run(SpringEurekaClientReportServiceApplication.class , args);
Tác giả tiến hành cấu hình Client bằng cách tạo một tệp application.yml nằm trong src\main\resources với nội dung như sau : server: port: 8098 eureka: instance: leaseRenewalIntervalInSeconds: 1 leaseExpirationDurationInSeconds: 2 client: serviceUrl: defaultZone: http://127.0.0.1:8761/eureka/ healthcheck: enabled: true lease: duration: 5
56 spring: application: name: report-service logging: level: com.example.howtodoinjava: DEBUG
Tiếp theo tác giả tiến hành viết Configuring info endpoint chứa nội dung muốn gửi đến người dùng cuối khám phá dịch vụ : info.service.name=Report service info.service.description=This is the Report service, which is again dicovery server aware!!! info.service.RequestURL: https://api.quanlythuoc247.com/api/v1/report/get_lai_chi_tiet info.service.Header-Content-Type=application/json;charset=UTF-8 info.service.Response-Header: info.service.access-control-allow-methods:GET, POST, PUT, OPTIONS info.service.access-control-allow-origin: * info.service.access-control-max-age: 1728000 info.service.cache-control: max-age=0, private, must-revalidate info.service.cf-cache-status: DYNAMIC info.service.cf-ray: 563c08b33df9c755-HAN info.service.content-encoding: br info.service.content-type: application/json; charset=utf-8 info.service.date: Wed, 12 Feb 2020 05:06:34 GMT info.service.etag: W/"c728c515014dd80daf283c42001f0804" info.service.expect-ct: max-age`4800, report-uri="https://report- uri.cloudflare.com/cdn-cgi/beacon/expect-ct" sinfo.service.erver: cloudflare
cfduid4fc0e50ed052e29577d3e5df78b1f81581483994; expires=Fri, 13- Mar-20 05:06:34 GMT; path=/; domain=.quanlythuoc247.com; HttpOnly; SameSite=Lax; Secure info.service.status: 200 OK info.service.vary: Accept-Encoding info.service.x-powered-by: Phusion Passenger 6.0.0 info.service.x-request-id: 74a418e1-6eb7-4038-ae4a-f15e62bf6ad4 info.service.x-runtime: 0.007774
Nội dung này chứa các thành phần về tên dịch vụ , mô tả Response header , domain của dịch vụ Tiếp sau đó là tiến hành giới thiệu Response body publish qua : http://localhost:8098/getLoginDetailsForSchool/loginschool : package com.example.howtodoinjava.springeurekaclientloginservice.util; import java.util.Collections; import org.springframework.boot.actuate.info.Info; import org.springframework.boot.actuate.info.InfoContributor; import org.springframework.stereotype.Component;
@Component public class SpringEurekaClientLoginServiceInfoContributor implements InfoContributor {
@Override public void contribute(Info.Builder builder) { builder.withDetail("body", Collections.singletonMap("Response Body", "This is the Login service, which is discovery from http://localhost:8098/getLoginDetailsForSchool/loginschool "));
3 Tiến hành chạy đăng ký dịch vụ
58 Chuột phải vào project login service Run As Spring boot app ta nhận được kết quả về dự án qua việc máy chủ Eureka tự động cập nhật trạng thái dịch vụ được đăng ký:
Hình 3.9 Kết quả đăng ký dịch vụ trên giao diện hiển thị
4 Eureka sever trả về một URL và mô tả cho dịch vụ được yêu cầu
Khám phá dịch vụ, truy cập vào URL sẽ nhận được thông tin về dịch vụ bào gồm các thành phần sau:
Truy cập vào: http://localhost:8098/getReportDetailsForSchool/loginschool sẽ nhận định dạng dữ liệu phản hồi :
{"code":"200","message":"Đăng nhập thành công"}, {"code":"401","message":"Chưa xác thực tài khoản"}
59 3.2.1 Đánh giá kết quả thử nghiệm
Quá trình xây dựng và thử nghiệm mô hình tích hợp dịch vụ dựa trên nền tảng SOA đã đạt được những kết quả sau: Ở đây chúng ta so sánh với hệ thống khi chưa áp dụng mô hình SOA và mô hình đã áp dụng mô hình SOA
Tiêu chí Hệ thống cũ Hệ thống mới
Khả năng đăng ký , khám phá dịch vụ
Linh hoạt trong kết nối phần mềm
Khả năng quản lý dịch vụ
Khó quản lý được dịch vụ Quản lý được dịch vụ một cách dễ dàng
Bảng 3.1 So sánh kết quả thử nghiệm
Kết quả thử nghiệm đã chứng minh được mô hình tích hợp dịch vụ dựa trên SOA cho thấy những lợi ích:
1 Khả năng đang ký và khám phá dịch vụ được tích hợp từ mô hình giúp hỗ trợ cho việc phát triển và tái sử dụng phần mềm
2 Tính linh hoạt trong kết nối phần mềm là một lợi thế khi sử dụng kiến trúc SOA Thời gian được tiết kiệm thông qua việc phát triển, kiểm thử và tích hợp đó với chức năng phần mềm nhỏ bé tương tự đó có thể thêm vào.Năng suất gia tăng Nếu các lập trình viên tái sử dụng các dịch vụ điều đó có nghĩa là các dự án phần mềm có thể tiến xa hơn và đội phát triển tương tự có thể tiếp tục nhiều dự án hơn
3 Với việc sử dụng broker nắm vai trò là trung gian dịch vụ giúp cho việc quản lý dịch vụ một cách dễ dàng hơn
4 Các dịch vụ có thể được mở rộng và phát triển thông qua việc tối ưu hiệu suất và nâng cấp hệ thống, các dịch vụ có thể được thay thế cho phù hợp với tính chất công việc
5 Tận dụng hệ thống qua việc phân loại dịch vụ và sử dụng cách gọi dịch vụ thông qua một cơ chế chung Đây là lợi ích chính của việc tích hợp các dịch vụ
60 Những điểm còn hạn chế:
Tuy nhiên, vẫn tồn tại các điểm hạn chế bởi tính chất nghiệp vụ của các nhóm dịch vụ dẫn dến việc tiếp cận trong thực thế trở nên khó khăn Ứng dụng được xây dựng mới chỉ triển khai thử nghiệm trong phạm vi nhỏ nên chưa đánh giá được tính hiệu quả của thành phần trung gian dịch vụ trong thực tế
Hướng phát triển tiếp theo của đề tài bao gồm việc nghiên cứu áp dụng mô hình SOA để giải quyết các vấn đề khác còn tồn tại trong việc quản lý nhà thuốc Ngoài ra tập trung vào việc xây dựng các thành phần xử lý lỗi Nghiên cứu việc thử nghiệm khả năng kết nối và sử dụng trên các phần mềm khác cùng nền tảng
Tìm hiểu thêm về các công nghệ tính toán lưới, điện toán đám mây, công nghệ WCF, mối quan hệ giữa chúng với SOA để nâng cao hiệu suất các ứng dụng triển khai theo SOA.2.