任务补偿机制

背景与目标

• 任务中心接收第三方系统推送的待办任务，并向用户展示。但在实际推送过程中，可能因网络闪断、业务逻辑异常、接口超时等不可控因素，导致推送失败或丢失，从而造成第三方系统与任务中心的任务数据不一致。
• 这种不一致会导致用户在任务中心看不到本应处理的待办，或者看到已失效的任务，严重影响业务流程和用户体验。因此需要建立一套可靠的任务补偿机制，通过自动化手段定期消除两侧的数据差异，保障最终一致性。

补偿任务范围与时间窗口

• 补偿范围：仅针对“待处理”状态的任务。
• 时间窗口：以任务创建时间为准，覆盖最近 6 个月的数据。
• 设计原因：超过半年的待办任务若无处理，通常已失去业务时效性；同时限定窗口可避免对历史全量数据的无限对比，降低系统负载。

补偿原理

任务补偿由任务中心主动发起，基于 “定时触发 + 推送时触发” 的双重机制，对第三方系统与任务中心的任务进行精确比对，逐步将两侧数据拉齐。

比对规则与动作：

• 若某任务在第三方系统存在，但任务中心不存在 → 说明推送丢失，执行任务重新推送。
• 若某任务在任务中心存在，但第三方系统不存在 → 说明业务侧任务已失效，执行任务删除。

触发方式：

• 定时触发：通过定时任务周期执行补偿比对。
• 推送时触发：在任务中心接收到新的任务推送时，即时触发一次针对该业务系统/用户的补偿检查。

第三方系统接入

申请流程

• 向信息办提交任务补偿接入申请。
• 按照下述接口规范实现并开放两个接口，供任务中心调用。

接口规范

待办任务查询接口

• 用途：按工号查询待办任务列表，作为比对的基准数据来源。
• 请求方式：GET
• 必选参数：
  • 工号
  • 任务开始时间
  • 任务结束时间
• 响应参数：
  • 任务ID（第三方系统内唯一标识，后续重推依据）
  • 发起人工号
  • 发起人姓名
  • 任务名称
  • 任务创建时间
• 注意：任务中心会传入 6 个月时间窗口，第三方系统必须支持按任务创建时间进行过滤查询。

任务重推接口

• 用途：根据任务ID，指示第三方系统对指定任务进行重新推送。
• 请求方式：POST
• 参数：
  • 任务ID（来源于待办任务查询接口）
• 行为约定：
  • 第三方系统收到重推请求后，应重新执行一次完整的任务推送流程，将任务数据推送到任务中心的统一任务接收接口。
  • 重新推送的任务必须保留原始的创建时间、发起人等信息，不刷新为当前时间。