Phân tích quản lý thông báo

Tất cả các sự kiện phát sinh thông báo phải được gửi lên một kênh thông tin duy nhất opencps/notification/destination

###Các sự kiện thông báo

Các 3 nhóm sự kiện chính sau gồm nhóm sự kiện thông báo cho cán bộ xử lý

• Hồ sơ mới gửi chờ tiếp nhận: mã 101
• Hồ sơ được bổ sung thêm tài liệu: mã 102
• Hồ sơ nhận thông báo thanh toán mới: mã 103
• Hồ sơ có yêu cầu được rút: mã 104
• Hồ sơ có thông báo lỗi kết quả trả về: mã 105
• Hồ sơ chuyển tới cán bộ xử lý: mã 106
• Hồ sơ sắp hết hạn xử lý: mã 107
• Hồ sơ đã quá hạn xử lý: mã 108
• Hồ sơ cần trả kết quả bởi bộ phận một cửa: mã 109

Nhóm sự kiện thông báo cho người dân và doanh nghiệp

• Hồ sơ đã gửi chờ tiếp nhận: mã 201
• Hồ sơ đã được tiếp nhận xử lý: mã 202
• Hồ sơ bị từ chối tiếp nhận: mã 203
• Hồ sơ có yêu cầu bổ sung: mã 204
• Hồ sơ có yêu cầu thanh toán: mã 205
• Hồ sơ đã hoàn thành xử lý: mã 206
• Hồ sơ đã được trả kết quả: mã 207
• Hồ sơ được chấp thuận rút: mã 208
• Hồ sơ được xử lý cấp lại kết quả: mã 209
• Hồ sơ bị lỗi xử lý: mã 301
• Hồ sơ bị delay trong hệ thống: mã 302

Nhóm sự kiện thông báo quản trị

• Hồ sơ bị lỗi xử lý: mã 301
• Hồ sơ bị delay trong hệ thống: mã 302

Các event phải được phân tích và tạo ra bởi mã nguồn của backend theo tình huống cụ thể. Do đó danh sách các event là cố định, khi bổ sung thêm event mới thì phải thay đổi mã nguồn chương trình.

Cấu trúc dữ liệu sinh ra cho mỗi event thông báo gồm

• mã sự kiện thông báo
• user nhận thông báo trực tiếp (to)
• user nhận thống báo gián tiếp (cc)
• mã hồ sơ (oid)
• tiêu đề thông báo
• nội dung mô tả thông báo (html)

Có nhiều kênh phân phối thông tin khác nhau như email, sms, ứng dụng. Mỗi kênh thông tin nhận thông báo được tạo ra như một listener để xử lý event. Các kênh phải tự quản trị việc ghi log cho xử lý phân phối thông báo của nó. �

####Kênh thông báo qua ứng dụng

Quản lý đăng kí thông báo qua restful. Việc đăng kí nhận thông báo theo nguyên tắc gồm các thông tin sau:

• pattern mã của sự kiện
• địa chỉ url gọi để thông báo

Pattern mã sự kiện:

• 000 tất cả các sự kiện
• 100 các sự kiện nhóm 1
• 200 các sự kiện nhóm 2
• 300 các sự kiện nhóm 3
• x0x chỉ một sự kiện cụ thể

Nguyên tắc url là url?code=mã sự kiện&oid=mã hồ sơ&to=ds người nhận trực tiếp&cc=ds người nhận gián tiếp

####Kênh thông báo qua email

####Kênh thông báo qua sms

####Kênh thông báo trong inbox (liferay)

####Các entity dữ liệu

Entity - notificationstatusconfig Cấu hình trạng thái cần thông báo (V1.9)

• dosierNextStatus: Trạng thái cần thông báo , tham chiếu danh mục DOSSIER_STATUS.
• status: 1-hoạt động, 0- không hoạt động.

Entity - notificationstatusevent Cấu hình loại thông báo. (V1.9)

• notiStatusConfigId: Tham chiếu bảng NotificationStatusConfig .
• eventName: Tên sự kiện
• descripton: mô tả
• pattern: EMPLOYEE|CITIZEN|EMAIL|INBOX|SMS|USE_EVENT_DESCRIPTION, mã cấu hình thông báo. EMPLOYEE|CITIZEN dùng 1 trong 2, phân biệt thông báo cho cán bộ hay doanh nghiệp. EMAIL|INBOX|SMS dùng 1 hoặc cả 3, thông báo sẽ được gửi vào email, trên website, điện thoại. USE_EVENT_DESCRIPTION dùng khi muốn thay nội dung thông báo mặc định, giá trị sẽ lấy ở trường description.
• userException: email của các cán bộ không muốn nhận thông báo, mặc định sẽ gửi thông báo cho tất cả các cán bộ có liên quan.
• plId: pageId redirect của thông báo tới hồ sơ, chỉ dùng cho thông báo inbox.
• status: 1-hoạt động, 0- không hoạt động.