4.2.3.1 Xây dựng các tiến trình và các tham số
Dựa vào Bảng 4.4 có thể xây dựng chi tiết các tiến trình và liệt kê các tham số sử dụng cho cấu hình, đầu vào và đầu ra của hệ thống
STT Tên tham số Mô tả ý nghĩa
Tham số cấu hình
1 id id của tiến trình, là tham số có tính duy nhất, để phân biệt giữa các tiến trình
2 from id của tiến trình trước đó
3 to id của tiến trình tiếp theo (đối với các tiến trình hành động) 4 toY id của tiến trình tiếp theo nếu điều kiện kiểm tra đúng (đối
với các tiến trình điều kiện)
5 toN id của tiến trình tiếp theo nếu điều kiện kiểm tra sai (đối với các tiến trình điều kiện)
Start)
7 amount Số tiền trừ vào tài khoản thuê bao trong tiến trình Debit 8 mtTemplate Cấu hình định dạng tin nhắn gửi tới thuê bao trong tiến trình
SMSOut và SendContent
9 contentId id của nội dung cụ thể cần lấy trong tiến trình SendContent 10 sortType Cách lấy nội dung trong tiến trình SendContent (1: theo id, 2:
theo độ ưu tiên, 3: lấy ngẫu nhiên)
11 point Điểm cộng thêm trong tiến trình AddPoint
12 format Định dạng mã dự thưởng trong tiến trình GenerateTicket, có dạng XXXXXX
13 ticketNum Số mã dự thưởng tạo ra trong tiến trình GenerateTicket 14 template Mẫu để so sánh trong tiến trình CheckMO và CountMO 15 syntax Cú pháp cần lấy ra từ MO để kiểm tra đáp án của nội dung
sau này
16 type Loại so sánh trong tiến trình CountMO (1: so sánh bằng, 2: so sánh nhỏ hơn, 3: so sánh lớn hơn, 4: so sánh nhỏ hơn hoặc bằng, 5: so sánh lớn hơn hoặc bằng). So sánh ở đây là so sánh số lượng MO (tin nhắn thuê bao gửi tới) với một tham số cấu hình (là tham số count)
17 count Số lượng cần so sánh trong tiến trình CountMO
18 isFinished Có cho phép kết thúc bài chơi trong phiên đó hay không (trong trường hợp đã dự đoán đúng, hoặc đã chơi một số lượng câu hỏi cho phép), sử dụng trong tiến trình CheckAnswer, CountContent
Tham số đầu vào/đầu ra 1 periodId id của phiên chơi hiện tại 2 msisdn Số điện thoại người chơi
3 moContent Nội dung tin nhắn người chơi gửi tới hệ thống 4 moId Id của tin nhắn gửi tới, do hệ thống lưu lại
5 moSyntax Cú pháp đã lọc từ MO để kiểm tra đáp án của nội dung sau này (ví dụ DD My Tam thì chỉ cần lấy thông tin My Tam để kiểm tra đáp án)
6 ticket Mã dự thưởng lần cuối cùng được lưu 7 totalTicket Tổng số mã dự thưởng hiện tại
8 periodPoint Số điểm trong phiên hiện tại 9 totalPoint Tổng số điểm của toàn dịch vụ 10 chargeResult Kết quả tính tiền
11 contentId Id của nội dung cuối cùng gửi cho người chơi 12 content Nội dung text cuối cùng gửi cho người chơi
13 isFinished Bài chơi đã dừng hay chưa 14 startTime Thời gian bắt đầu phiên hiện tại 15 endTime Thời gian kết thúc phiên hiện tại
Bảng 4.5 Các tham số cấu hình, đầu vào và đầu ra
Các tiến trình được định nghĩa dưới dạng XML (Extensible Markup Language), trong đó chứa các tham số được liệt kê trong Bảng 4.5
Các tiến trình được kết nối với nhau thông qua các tham số from, to, toY và toN. Dựa trên các kịch bản dịch vụ và các luồng xử lý đã phân tích Hình 4.1, Hình 4.2, Hình 4.3 có thể xây dựng được các cấu hình kịch bản dịch vụ bằng cách sử dụng ngôn ngữ XML
Công việc tiếp theo của phần thiết kế là thiết kế cơ sở dữ liệu chứa các thông tin phục vụ các kịch bản SMS. Chi tiết thiết kế của cơ sở dữ liệu được trình bày trong mục 4.2.3.2
4.2.3.2 Thiết kế cơ sở dữ liệu
Thông tin cần lưu của các kịch bản bao gồm:
- Thông tin về nội dung: các câu hỏi, các gợi ý, đáp án phục vụ người chơi. Thông tin này được cấu hình trên module Quản lý nội dung của SDP, để phục vụ cho mô phỏng, cơ sở dữ liệu tái hiện lại các nội dung này một cách đơn giản thông qua hai bảng “CONTENT” và “CONTENT_RESULT”
- Thông tin về dịch vụ: cấu hình dịch vụ, phiên chơi. Thông tin này cũng được lưu trên module Quản lý dịch vụ của SDP, để phục vụ cho mô phỏng, cơ sở dữ liệu tái hiện lại các thông tin này một cách đơn giản thông qua hai bảng “SERVICE” và “SERVICE_PERIOD”
- Thông tin về các tin nhắn người chơi gửi tới chương trình - Thông tin về các tin nhắn chương trình gửi tới người chơi - Thông tin về giao dịch điểm của người chơi
- Thông tin về giao dịch mã dự thưởng của người chơi - Thông tin về giao dịch gửi nội dung cho người chơi
- Trạng thái hiện tại của người chơi dịch vụ: số điểm trong phiên, số mã dự thưởng, tổng số điểm…
Hình 4.4 mô tả chi tiết thiết kế cơ sở dữ liệu bao gồm các bảng và mối quan hệ giữa các bảng
Hình 4.4 Thiết kế cơ sở dữ liệu
Bảng SERVICE: Bảng lưu thông tin dịch vụ
Tên trường Kiểu dữ liệu Mô tả Bắt buộc
id int(10) Id của dịch vụ, là khóa chính của bảng Có
name varchar(255) Tên của dịch vụ Có
description varchar(1024) Mô tả dịch vụ Không
Bảng 4.6 Bảng SERVICE
Bảng SERVICE_PERIOD: Bảng lưu thông tin phiên của dịch vụ
Tên trường Kiểu dữ liệu Mô tả Bắt buộc
id int(10) Id của phiên Có
service_id int(10) Id của dịch vụ chứa phiên Có
start_time datetime Thời điểm bắt đầu phiên Có
end_time datetime Thời điểm kết thúc phiên Có
Bảng 4.7 Bảng SERVICE_PERIOD
Bảng CONTENT: Bảng lưu thông tin nội dung (câu hỏi, gợi ý)
Tên trường Kiểu dữ liệu Mô tả Bắt buộc
id int(10) Id của nội dung Có
content varchar(4000) Nội dung text (không dấu) Có
priority int(10) Độ ưu tiên Không
service_id int(10) Id của dịch vụ Có
Bảng 4.8 Bảng CONTENT
Tên trường Kiểu dữ liệu Mô tả Bắt buộc
id int(10) Id của kết quả Có
content_id int(10) Id của nội dung gắn với kết quả Có
content varchar(4000) Kết quả Không
content_corect varchar(4000) Kết quả đúng Không
content_wrong varchar(4000) Kết quả sai Không
syntax_correct varchar(4000) Cú pháp đúng Có
syntax_wrong varchar(4000) Cú pháp sai Không
Bảng 4.9 Bảng CONTENT_RESULT
Bảng USER_SERVICE: Bảng lưu thông tin sử dụng dịch vụ của người chơi
Tên trường Kiểu dữ liệu Mô tả Bắt buộc
id int(10) Id của bảng Có
service_id int(10) Id của dịch vụ Có
total_point int(10) Tổng số điểm của người chơi Không period_point int(10) Tổng số điểm của người chơi trong
phiên hiện tại
Không total_ticket int(10) Tổng số mã dự thưởng của người
chơi
Không current_period_id int(10) Id của phiên hiện tại Không msisdn varchar(20) Số điện thoại của người chơi Có ticket varchar(255) Mã dự thưởng đã được cấp gần đây
nhất
Không is_period_finished tinyint(1) Đã kết thúc bài chơi trong phiên hay
chưa
0: chưa kết thúc, có thể tiếp tục chơi 1: đã kết thúc, sang phiên tiếp theo mới được chơi tiếp
Có
Bảng 4.10 Bảng USER_SERVICE
Bảng USER_CONTENT_LOG: Bảng lưu các nội dung hệ thống gửi cho người chơi
Tên trường Kiểu dữ liệu Mô tả Bắt buộc
id int(10) Id của bảng Có
msisdn varchar(20) Số điện thoại người chơi Có
content_id int(10) Id của nội dung gửi cho người chơi Có mt_id int(10) Id của tin nhắn MT gửi tới người chơi có
chứa nội dung gửi
Không
sent_time datetime Thời gian hệ thống gửi tin Không
Bảng 4.11 Bảng USER_CONTENT_LOG
Bảng POINT_TRANSACTION: Bảng lưu các giao dịch điểm của người chơi
Tên trường Kiểu dữ liệu Mô tả Bắt buộc
id int(10) Id của bảng Có
msisdn varchar(20) Số điện thoại người chơi Có
period_id int(10) Id của phiên chơi Có
point int(10) Điểm cộng thêm cho người chơi Có
create_date datetime Thời gian hệ thống cộng điểm Có mo_id int(10) Id của tin nhắn MO người chơi gửi tới
chương trình có liên quan đến việc cộng điểm
Có
Bảng 4.12 Bảng POINT_TRANSACTION
Bảng TICKET_TRANSACTION: Bảng lưu các giao dịch mã dự thưởng của người chơi
Tên trường Kiểu dữ liệu Mô tả Bắt buộc
id int(10) Id của bảng Có
msisdn varchar(20) Số điện thoại người chơi Có
period_id int(10) Id của phiên chơi Có
ticket varchar(20) Mã dự thưởng cấp cho người chơi Có create_date datetime Thời gian hệ thống cấp mã dự thưởng Có mo_id int(10) Id của tin nhắn MO người chơi gửi tới
chương trình có liên quan tới việc cấp mã dự thưởng
Có
Bảng 4.13 Bảng TICKET_TRANSACTION
Bảng MO_TRANSACTION: Bảng lưu các tin nhắn người chơi gửi tới chương trình
Tên trường Kiểu dữ liệu Mô tả Bắt buộc
id int(10) Id của tin nhắn MO Có
msisdn varchar(20) Số điện thoại người chơi Có
mo varchar(4000) Nội dung tin nhắn MO Có
receive_time datetime Thời gian hệ thống nhận được tin nhắn Có
period_id int(10) Id của phiên chơi Có
Bảng 4.14 Bảng MO_TRANSACTION
Bảng MT_TRANSACTION: Bảng lưu các tin nhắn chương trình gửi tới người chơi
Tên trường Kiểu dữ liệu Mô tả Bắt buộc
msisdn varchar(20) Số điện thoại người chơi Có
mt varchar(4000) Nội dung tin nhắn MT Có
mo_id int(10) Id của tin nhắn MO tương ứng Không
sent_time datetime Thời gian hệ thống gửi tin nhắn Có
period_id int(10) Id của phiên chơi Có
Bảng 4.15 Bảng MT_TRANSACTION
Sau khi có cấu hình kịch bản và thiết kế cơ sở dữ liệu, cần triển khai chương trình thực hiện việc đọc và thực thi cấu hình bản. Chi tiết về chương trình được mô tả trong mục 4.2.3.3
4.2.3.3 Chương trình thực thi
Chương trình được chia làm hai phần là đọc cấu hình kịch bản và thực thi cấu hình kịch bản.
Việc đọc cấu hình kịch bản được thực hiện đơn giản bằng cách đọc từng Element và các Attribute của nó trong một file định dạng XML.
Việc thực thi các tiến trình được xử lý phân tách trong nhiều Handler: - AddPointHandler: xử lý cộng điểm
- CheckAnswerHandler: xử lý kiểm tra đáp án - CheckBalanceHandler: xử lý kiểm tra tài khoản
- CountContentHandler: xử lý kiểm tra số nội dung đã gửi
- CountMoHandler: xử lý kiểm tra số tin nhắn MO đã gửi tới đầu số dịch vụ - DebitHandler: xử lý trừ tiền
- EndHandler: xử lý kết thúc cuộc chơi
- GenerateTicketHandler: xử lý tạo mã dự thưởng - IsFinishedHandler: xử lý kiểm tra kết thúc phiên
- SendContentHandler: xử lý gửi nội dung tới khách hàng - SmsInHandler: xử lý nhận SMS từ khách hàng
- SmsOutHandler: xử lý gửi SMS tới khách hàng - ValidatePeriodHandler: xử lý kiểm tra phiên hợp lệ
Trong cấu hình dịch vụ (file định dạng XML), mỗi tiến trình được kết nối với các tiến trình khác thông qua các trường “from”, “to”, “toY”, “toN”. Chương trình thực thi cũng cần xử lý để chuyển giữa các tiến trình một cách tự động, sau khi thực thi xong tiến trình này thì tự động chuyển sang tiến trình khác có id được cấu hình trong trường “to” (với tiến trình hoạt động) và trường “toY” hoặc “toN” (với tiến trình kiểm tra trạng thái, tùy theo kết quả kiểm tra).
Việc tự động chuyển sang tiến trình khác được xử lý linh hoạt bằng cách cho các Handler dẫn xuất (extend) từ một lớp (class) ServiceHandler. Trong class
ServiceHandler thực thi một hàm xử lý “execute” để thực thi tiến trình hiện tại và “goToNext” để đi tới tiến trình tiếp theo. Trong đó đầu vào của hàm “goToNext” là “serviceId” tức là id của các tiến trình được cấu hình trong “to”, “toY”, “toN”. Trong đó, hàm xử lý “execute” của tiến trình tiếp theo được gọi. Trong hàm xử lý “execute” của từng tiến trình, lại có đoạn gọi đến hàm “goToNext” với tham số truyền là id của tiến trình tiếp theo.