数据库工单接入流程设计

这是学习笔记的第 1803篇文章

最近在落地工单接入的过程中，也沉淀了一些实践经验，在总结的基础上，也希望自己能够在后续的对接中把一些不足的地方改善，能够尽可能抽象出通用的模块复用。

整体来说，工单初期的接入是一种模糊状态，对接参数和对接标准不够统一，为了尽可能降低这种对接的成本，我们可以使用迭代的方式来完成，这种迭代是一种缓存策略，就是下图中的第1步，使用RESTful API对接，对于接口的初步对接，不需要对参数信息进行校验，而是先做持久化，至少从接收端来说，能够很清晰的得到数据参数结构和明细信息，有了这一层保证，如果存在接收端的逻辑或者解析异常，就可以尝试重试的方式，不至于对于源端的过度依赖，所以在这个地方，我把它的角色成为适配器。

而对于工单的概要信息，则是记录从源端推送的最粗粒度的工单信息，粒度为工单类型和单号，比如这是一个权限申请工单，这是一个对象变更工单，这是2步的工作。

在第3步的工作会完成流转的工作，比如是权限工单，就流转到权限的页面，如果是对象变更工单就流转到对象变更的页面，在这里是根据单号做一个分发器和总体状态的标识。

第4步是工单分解器，通过分解器可以根据工单类型工单场景把工单拆分为多种/多个工单，其中一个通用的子工单就是分解工单状态表，这个状态表只标识子工单的状态，如果子工单完成则记录相应的状态，即第5步所做的工作，如果相关的子工单都完成，则标识整个工单完成，会触发标识概要工单完成，即第6步所做的工作。

最后可以约定好工单回调接口，确认整个工单流程结束。

而在第一个工单的接入中，对于工单分解器一直处于模糊地带，所以随着多种数据库业务的接入，原来的逻辑会变得很臃肿，很多逻辑是写成了硬编码的方式，可以在这个地方补充这个角色，实现配置化的工单拆解。

所以整体的思路来说，如果要接入另外一个工单，则整个工单流程的设计也会变得更加平滑。

所以在这个流程贯通的过程中，也能够重新梳理目前的业务问题，通过流程的闭环发现我们自身的问题，是支持的能力不足还是沟通的差异导致。