# 1.变动消息长时间未确认
平台默认的策略是1分钟循环推送消息，所以正常情况下，人事变动消息到各个领域的确认时长不会超过1分钟。当出现消息状态迟迟不更新的情况后，我们应该怎么去排查呢？
## 1.1在ces.jsp界面查看是否有线程卡顿情况
在界面查找领域关键字ats，如果没有找到，在数据库执行查找sql死锁语句（每个库都不一样，具体百度查找下，都会有），查找到后可以下载日志提单处理，如果以上两步都没有查找到，则说明线程是正常运行的。
1.2在客户端查找消息日志
由卡顿的话，结束时间为空。
以上情况都排除后，查看消息是否被平台已扫描
如果是已扫描状态，则说明平台线程正常公告。
## 常见未确认情况总结
常见消息未确认的情况：
1、 用工关系占人头(去员工信息页面查看是否占人头)
2、 规则(T_ATS_AtsPCRule)的entrollChangeType=3也就是手动（入错职和撤销用这个参数，查看comfirm.log中confirm msgid:4i4AAAAoHghwHB+P,atsPCRuleInfo id=:4i4AAAAFGNqHPXqV，看对应的规则entrollChangeType）
3、 消息t_hr_personburelaconfirm中没有默认的业务组织 defaultHrOrgUnit(基本不会出现)
4、 开启了全局参数ATS_COMFIRMNORULE，并且没有匹配上任何规则(通过comfirm.log查看isSatisfy=false表示未匹配上规则)
5、 撤销消息，未匹配上任何规则(通过comfirm.log查看isSatisfy=false表示未匹配上规则)，并且存在业务数据(详见撤销文档)
6、 处理消息报错（程序错误，查看apusic日志）
7、 线程没跑 T_HR_BizManageACCLog（下面有sql）
8、 线程跑了，但是跑这个线程的服务器代码没更新（只出现在测试环境，有二开的情况下）
9、 消息类型为其它，bizDefineType=5(一般没有这种消息)
comfirm.log中记录了是匹配上的规则。
日志中confirm msgid:4i4AAAAoHghwHB+P,atsPCRuleInfo id=:4i4AAAAFGNqHPXqV
其中4i4AAAAFGNqHPXqV就是匹配上的规则ID
消息未确认排查流程：
1、 查看消息是否被扫描，isAlreadyDeal=1。（如果没有被扫描到，则等待，或者重启）
2、 确认消息处理的线程正在运行，并且对应待确认的消息的最后更新时间对应的T_HR_BizManageACCLog 中的时间段中的ip是目标服务器，SELECT * from T_HR_BizManageACCLog WHERE FBeginTime > {ts'2019-04-12 00:00:00'} and FDESCRIPTION ='SHRBizDataComfirmMessageTask' ORDER BY FBeginTime DESC
3、 拿对应ip服务器上的eas\Server\server\shr_ats_log\shr_ats_confirm\comfirm.log日志，搜索对应的消息id是否存在。comfirm.log日志中包含了是否满足条件，是否自动处理以及被哪个类处理等等。
查询消息sql: select * from t_hr_personburelaconfirm where FPERSONID in (select
