结束
是
推送结果状态设置为等待处理
如果有下一步骤任务，则生成，否则跳过
否
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
处理结果是否成功
等待一段时间重新尝试获取处理结果
获取当前考勤需要推送区域
考勤推送通知
