推送流程图

结束

是

推送结果状态设置为等待处理

如果有下一步骤任务，则生成，否则跳过

否

Job调度开始

注：如果是即时考勤推送将不更新PushTaskItem

是否是异步推送

否，根据查询次数计算延迟时间

查询要推送的业务数据

获取任务信息（external_job_taskdata

Ack

是否FirstTask

有推送数据

若存在下一步骤任务，则生成，否则跳过此步骤

重试查询业务数据

推送是否成功

检查上次任务是否完

发送获取处理结果延迟队列消息

查询异步结果

重试时，无论成功还是失败，都会更新EsPushRecord。因为每次推送失败的原因可能不一样，最新的错误原因有助于我们检查并排除问题，更重要的是同时会更新重试次数，若当MQ发生灾难性问题时，EsPushRecord中依然有最新的推送失败情况纪录。

更新external_jobtask_data表EditDate、BusinessData

获取可执行PushTaskItems

推送到第三方平台

如果有下一步骤任务，则生成，否则跳过此步骤

重新发送延迟消息，重复重试逻辑

发送失败推送消息至MQ

推送时采用图1：遍历数据进行推送逻辑

为FirstTask生成PushTaskItem

遍历数据进行推送

MQ延迟消息处理失败推送流程

写入EsPushRecord

图4，说明：因为考勤数据量非常大，同时要求很高的及时性，放弃原通过Job调度方式，改为当产生考勤时主动发送RabbitMQ消息主动通知模式。即时考勤产生时RabbitMQ交互机类型：directqueueName: labor-workerattendance-project-instant-{SysCode}如果消费压力大，通过增加消费者数量增加消费能力。

异步结果查询延迟消息处理流程

所有状态的数据都会纪录到EsPushRecord中，不仅仅是失败状态。同时对同一业务数据只保留最新推送的一次纪录。例如某人因为修改信息，增量推送了N次，这里会纪录它最后一次推送的情况。

是否需要推送

 及时考勤推送

是否达到最大查询次数

更新最新状态到EsNewestLog

检查当前要重试的纪录推送状态是否为成功

收到消息

更新PushTaskItem，纪录本次推送的位置

产生考勤时人脸机上传/现场端上传

更新最新推送状态至EsPushRecord

生成RoutingKeys发送Mq消息

发送预警通知邮件

是否推送失败

累加查询次数并发送Mq延迟消息

批量Push推送结果至EsPushRecord

第一次送延迟1小时队列消自息

发送迟队列消息，重试次数+1，延时时间=2小时*次数

发送延迟队列消息，RoutingKey：labor.{SysCode}.getasynchandle.{TaskCode}延迟时间：20S

遍历EsPushTaskTeam任务执行推送任务

是否达到最大重试次数

是否等待处理

有可执行的任务

考勤推送

当收到失败MQ消息时

发送失败推送消息至MQ 

记录推送日志ApiLog

推送单位、班组、工人......(除考勤外)

图2，说明：exchange: labor.topic.externalpush.push.retry   Type: x-delayed-messageruningkey: labor.{SysCode}.externalpush.push.retry#最大重试次数=3次，队列消息延迟时间，首次为1h，其它为重试次数 X 2h

处理结果是否成功

等待一段时间重新尝试获取处理结果

获取当前考勤需要推送区域

考勤推送通知