# CloudCC 定时器类分析说明 ## 1. 分析口径 本文用于回答以下问题： - 定时器类能干什么 - 定时器类的主要作用是什么 - 为什么要用定时器类 - 定时器类能解决哪些问题 - 在什么情况下使用 - 在什么业务场景下使用 ## 2. 定时器类是什么 定时器类是运行在 CloudCC 服务端、由调度机制按时间规则自动触发执行的 Java 业务代码载体。 它的核心特征不是“谁触发”，而是“什么时候触发”。 如果说： - 触发器更偏向“某条记录发生变化时立刻执行” - 自定义类更偏向“承载可复用业务能力” - 定时器类更偏向“按时间批量扫描并自动执行” 那么定时器类就是 CloudCC 中典型的“后台自动作业”实现方式。 在当前项目里，定时器类通常会按如下模式工作： - 查询一批满足条件的数据 - 判断是否达到某个时间点、状态点或规则阈值 - 执行更新、生成、同步、提醒或推进动作 - 回写执行结果、状态、标记或日志 因此，定时器类更适合承接那些： - 周期性发生 - 规则相对稳定 - 需要批量处理 - 不要求毫秒级实时 - 需要后台自动运行 的业务任务。 ## 3. 定时器类能干什么 ### 3.1 主动提醒与催办 定时器类可以自动识别“超期未处理”“长时间未推进”“达到提醒时间点”的业务记录，然后： - 发送邮件 - 创建任务 - 发起催办 - 通知负责人、区域负责人、项目经理等角色 这类能力通常用于解决“人容易忘记，但业务又必须被持续跟进”的问题。 ### 3.2 数据同步与外部系统集成 一批定时器明显承担了平台与外围系统之间的同步职责。 它们可以： - 按批次推送数据到 SAP、财务、采购等系统 - 定时调用外部接口 - 同步字典、主数据或经营数据 - 对失败任务做补偿性重试 - 将外部系统结果回写到 CloudCC 这使定时器类成为“跨系统定时对接层”的重要落点。 ### 3.3 数据刷新、修正与回填 这是数量最多的一类。 定时器类可以： - 刷新派生字段 - 修正历史数据 - 回填缺失值 - 统一编号、状态、负责人或关联关系 - 批量修复迁移后遗留问题 - 对旧数据重新计算并回写结果 这类任务通常不是新建记录时立即完成，而是要通过后台批量方式持续治理。 ### 3.4 报表、底表与看板支撑 一批定时器并不直接面向业务动作，而是面向分析层。 它们可以： - 构建经营底表 - 汇总报表数据 - 刷新台账 - 为看板预计算分析结果 - 让前台报表直接读取已加工的数据层 这说明定时器类不仅处理业务流程，也承担了部分“分析型数据加工层”的职责。 ### 3.5 自动生成下游对象或推进流程 部分定时器会在满足条件时自动创建新的业务对象，或者自动推进节点。 这类能力包括： - 自动生成服务商机 - 自动生成分期、产品线等派生记录 - 自动创建项目目录或资料结构 - 自动推进里程碑节点 - 在满足条件时自动翻牌或进入下一阶段 本质上，这类定时器承担的是“流程衔接自动化”职责。 ### 3.6 权限、共享与负责人治理 还有一小批定时器明确承担治理类工作。 它们可以： - 根据负责人变化重算共享关系 - 自动补齐读写权限 - 删除过期或错误共享 - 保证相关对象上的责任人和访问权限保持一致 这类任务适合放在后台批量执行，因为它们通常涉及多对象、多角色联动。 ## 4. 定时器类与触发器、自定义类的区别 在当前项目里，这三类能力的分工非常清楚。 ### 4.1 定时器类 重点解决“按时间自动执行”的问题。 适合： - 每天、每周、每月定时执行 - 达到某个日期后处理 - 扫全量或扫增量数据 - 失败补偿和后台批处理 ### 4.2 触发器 重点解决“记录发生变化时立即执行”的问题。 适合： - 新增、修改、删除时立即校验 - 实时联动 - 单次事务内必须完成的控制 ### 4.3 自定义类 重点解决“业务能力复用”的问题。 适合： - 承载复杂逻辑 - 被按钮、页面、触发器、定时器共同调用 - 作为服务层或工具层复用 因此，定时器类通常不是独立存在的，它往往会调用自定义类完成核心业务处理，只是负责把执行时机放到“定时调度”上。 ## 5. 定时器类的主要作用是什么 综合来看，当前项目中的定时器类主要作用可以概括为以下 5 点。 ### 5.1 把重复性业务自动化 将每天、每周、每月都要做的动作交给系统自动执行，减少人工反复处理。 ### 5.2 把时间规则系统化 把“超期多久提醒”“每月何时同步”“月底何时汇总”“节点满足后何时推进”等规则固化到后台执行逻辑中。 ### 5.3 把批量治理放到后台 让历史修正、状态重算、字段回填、编号修复、共享重算等任务不占用前台实时事务。 ### 5.4 作为流程推进器 在业务推进过程中，定时器类可以主动发现卡点、补齐动作、推进后续节点。 ### 5.5 作为系统之间的批处理桥梁 在 CloudCC 与 SAP、财务、采购、主数据源之间，定时器类常常承担定时推送、失败补偿、周期同步的桥梁角色。 ## 6. 为什么要用定时器类 ### 6.1 因为很多业务不是实时触发，而是时间触发 有些动作不是记录一保存就该执行，而是： - 到期前提醒 - 到期后催办 - 每月汇总 - 月初同步 - 过几天未处理再通知 这类任务天然更适合定时器，而不是触发器。 ### 6.2 因为人工执行不稳定 如果依赖人工每天查报表、盯超时、做同步、补修数据，往往会出现： - 忘记执行 - 执行不及时 - 执行标准不一致 - 执行后缺少留痕 定时器类可以把这些动作标准化、自动化。 ### 6.3 因为批量任务不适合塞进实时事务 很多任务需要： - 扫描大量记录 - 汇总计算 - 调接口 - 修复历史数据 如果放在触发器或页面动作里，会拖慢实时链路，甚至影响用户操作体验。 ### 6.4 因为需要失败补偿能力 跨系统同步和推送很难保证每次都成功。 定时器类可以： - 按批次重试 - 定时补偿失败数据 - 异常后通知相关人员 - 用后台重跑方式恢复业务连续性 ### 6.5 因为需要长期治理而不是一次性处理 很多问题不是一次脚本能彻底解决，而是需要长期巡检、长期修正、长期维护。 这类治理型任务最适合放到定时器体系中持续运行。 ## 7. 定时器类能解决哪些问题 从当前项目的定时器分布看，它们主要在解决以下问题。 ### 7.1 解决“业务节点没人盯”的问题 例如： - 商机超期无人处理 - 合同评审后迟迟不移交 - 线索长时间未分配、未确认、未推进 - 负责人没有及时跟进 ### 7.2 解决“系统间数据不同步”的问题 例如： - CRM 与 SAP 经营数据不同步 - 项目、合同、回款、采购等外围系统接口调用失败 - 字典或主数据需要周期同步 ### 7.3 解决“历史数据脏乱差”的问题 例如： - 编号缺失或不规范 - 派生字段长期不准确 - 迁移后旧数据未补齐 - 负责人、状态、共享关系不一致 ### 7.4 解决“报表口径不稳”的问题 例如： - 看板依赖的底表没有持续刷新 - 台账数据与业务对象不一致 - 报表统计需要预加工 ### 7.5 解决“流程到了但动作没跟上”的问题 例如： - 条件满足后没有自动生成下游记录 - 节点可以推进但没有及时翻牌 - 派生对象没有按规则创建 ## 7. 在什么情况下使用定时器类 定时器类最适合以下场景。 ### 8.1 周期性任务 例如： - 每天执行 - 每周执行 - 每月执行 - 月初、月末执行 ### 8.2 时间敏感但不要求实时 例如： - 提前 7 天提醒 - 超过 15 天未更新即通知 - 每晚统一批处理 ### 8.3 需要批量扫描与批量处理 例如： - 扫全部项目 - 扫昨日变更数据 - 扫本月待同步记录 - 扫失败记录并补偿 ### 8.4 需要将重计算放到后台 例如： - 经营底表重建 - 历史数据修正 - 权限重算 - 派生字段统一刷新 ### 8.5 需要系统自动巡检 例如： - 巡检超时事项 - 巡检未完成流程 - 巡检缺失数据 - 巡检失败接口 ## 9. 什么情况下不适合用定时器类 以下场景一般不适合优先使用定时器类。 ### 9.1 强实时控制场景 如果用户保存数据时必须立刻校验、立刻拦截、立刻联动，那么更适合使用触发器。 ### 9.2 强交互场景 如果动作依赖用户逐步确认、页面即时反馈、人工选择分支，那么更适合页面按钮、组件或流程交互。 ### 9.3 一次性临时任务 如果只是临时清洗一次数据，通常更适合脚本或临时类，而不一定需要长期保留一个定时器。 ### 9.4 需要复杂人工判断的场景 如果业务结论高度依赖人工判断、审批意见或线下协同，定时器类通常只能做提醒，不能替代人工决策。 ## 10. 典型业务场景 结合当前项目现状，定时器类主要落在以下业务场景。 ### 10.1 销售与线索管理 - 线索待分配、待确认、待决策、重复线索提醒 - 商机超时提醒 - 赢单、失单分析提醒 - 商机移交时间更新提醒 ### 10.2 合同、报价与审批协同 - 合同评审提醒 - 移交合同提醒 - 报价单催办 - 合同额分配表催办 - 合同相关状态和底表更新 ### 10.3 项目交付与里程碑推进 - 项目出厂自动翻牌 - 配置管理各阶段自动更新 - 项目、开箱单、资产台账类数据刷新 - 项目目录或资料结构自动创建 ### 10.4 财务、经营与集成 - 预计总成本、预算、回款流水定时推送 - 记账接口、采购接口调用 - 收入看板底表更新 - 月初、月末经营数据同步 ### 10.5 主数据与基础资料治理 - 省市信息接口同步 - 客户信息、交通信息、工业园区信息补齐 - 产品线、规格、付款方式、物料类数据刷新 ### 10.6 权限与共享治理 - 商机权限自动维护 - 合同负责人变更后的共享修正 - 项目负责人变更后的共享修正 ## 11. 总结 一句话概括，当前项目中的定时器类适合承接“时间驱动、规则明确、批量执行、允许后台处理”的业务自动化任务。 它们的价值不只是“定时跑代码”，而是把以下能力持续、稳定、标准化地放到后台： - 业务提醒 - 数据治理 - 流程推进 - 集成补偿 - 报表支撑 - 权限维护 因此，在 CloudCC 项目中，定时器类通常不是边缘能力，而是连接“运营动作、数据质量、流程节点、系统集成、经营分析”的核心后台机制。