|
|
@ -146,7 +146,9 @@ REST API遵循REST最佳实践，规范命名URL中的每个部分。注意POST
|
|
|
ParticipantAvatar: '/:session_id/participants/:participant_id/avatars' // 会话单个成员头像
|
|
|
}
|
|
|
### 业务分析
|
|
|
|
|
|
**消息类型**：
|
|
|
|
|
|
muc_messsges,p2p_messages,group_messages,system_messages表对应的type字段
|
|
|
0、系统消息
|
|
|
1、文本消息
|
|
|
@ -162,18 +164,67 @@ REST API遵循REST最佳实践，规范命名URL中的每个部分。注意POST
|
|
|
11、预留
|
|
|
12、小视频消息
|
|
|
13、预留
|
|
|
|
|
|
**会话类型**
|
|
|
|
|
|
sessions的type字段
|
|
|
a、type =1 消息保存muc_messsges、患者的三师、家庭咨询会话
|
|
|
|
|
|
b、type=2 消息保存p2p_messages、患者的名医咨询，医生间的p2p、名医咨询会话
|
|
|
|
|
|
c、type =3 消息保存group_messages、行政团队聊天会话
|
|
|
|
|
|
d、type =0 消息保存system_messages 系统聊天会话
|
|
|
|
|
|
sessions的business_type字段
|
|
|
|
|
|
a、business_type =1 此会话不包含患者
|
|
|
|
|
|
b、business_type =2 此会话包含患者
|
|
|
|
|
|
sessions的status字段
|
|
|
|
|
|
**此字段只针对议题的会话有效**
|
|
|
|
|
|
标示当前会话是否有活跃的议题
|
|
|
|
|
|
**议题相关**
|
|
|
|
|
|
议题的ID就是wlyy库的wlyy_consult 的code字段可以关联wlyy_consult_team 查询对应的咨询行政团队信息，和签约医生信息，及咨询医生信息
|
|
|
|
|
|
目前有wlyy_consults的视图做关联，可根据实际业务逻辑拓展相关字段。
|
|
|
|
|
|
议题topics status及type字段讲解
|
|
|
|
|
|
status =0 reply = 0 新增的咨询
|
|
|
|
|
|
status = 0 reply =1 医生已经回复的咨询
|
|
|
|
|
|
status = 10 reply = 0 医生未回复就结束掉的咨询，PS:目前统计要求这部分数据不纳入未回复的咨询，请知悉
|
|
|
|
|
|
status = 10 reply = 1 医生已经回复，且已经结束的咨询
|
|
|
|
|
|
### Web Socket
|
|
|
|
|
|
Web Socket提供页面内长连接，并且能够通过Web Socket收发消息。
|
|
|
Web Socket提供页面内长连接，并且能够通过Web Socket收发消息。
|
|
|
|
|
|
Web Socket 客户端类型包含患者、医生
|
|
|
|
|
|
Web Socket 客户端登录需带上对应的会话ID用作于区分推送对象
|
|
|
|
|
|
Web Socket 客户端在线在推送消息的时候会更新用户的活跃时间用作于消息统计
|
|
|
|
|
|
### 微信相关模板消息 目前只有咨询回复的模板消息回复是在IM内发送微信模板
|
|
|
|
|
|
微信模板消息:结合Web Socket 当用户的sockt的连接不存在，则通过微信模板推送给予患者信息提醒，由于患者咨询只能存在一个，所以在推送的时候没有添加会话是否同一个的校验。后期出现多个需增加客户端的会话ID是否相同做校验。
|
|
|
|
|
|
### 相关问题排查处理SQL及处理思路
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
