®
01
门面层可以限制依赖程度
集成门面层负责在原有逻辑和面向调用方的新契约之间进行转换，并明确处理超时时间、错误代码和数据格式。变更数据捕获可以为读取型或事件驱动的场景提供变更信息，但并不能自动替代业务层面的写操作。在逐步替换的过程中，每项功能都会明确由哪个系统作为权威系统。并行处理需要进行比对，并采取受控的切换方式，避免两个系统对同一订单做出不同的后续更新。
您对 OTOKO® 的委托
我们为您承接的工作。
分析范围涵盖批处理作业、文件交换、数据库访问和人工修正。仅凭一张表格，很少能够完整解释其中适用的业务规则。我们会与掌握相关知识的人员交流，并追踪具有代表性的业务。厂商支持的访问方式会被优先考察。直接修改数据库可能绕过内部管控机制，因此不会被当作替代缺失接口的便捷手段。
可能的服务范围
- 旧系统分析：数据模型、批处理任务、接口、依赖关系和知识持有人
- 在大型机、AS/400 或客户端/服务器应用前方搭建 REST 或消息门面层
- 使用 Debezium 对 Db2、Oracle、PostgreSQL 等数据库进行变更数据捕获
- 文件、SFTP 和 EDI 对接，包含校验、确认回执和失败重试
- 按照绞杀者模式制定替换计划，并为每项功能设定验收标准
具体范围、您的参与方式以及验收标准，我们会在项目开始前明确约定。
把技术讲清楚
我们是这样落实任务的。
02
验证业务连续性
我们使用当前业务中重要或容易出错的具体案例进行测试，并比对两条路径的结果。回退标准会在首次生产变更之前明确约定。文档会特意记录仍然存在的依赖关系。启动阶段，通常只需要用于分析的系统访问权限、数据交接的示例，以及熟悉日常异常情况的联系人。
一个可验证的成果
这将成为您后续工作的基础。
- 分析报告，含依赖关系图
- 门面层，含 OpenAPI 说明文档和测试
- 替换计划，含实施顺序和验收标准
移交环节将实施成果与文档记录结合在一起。我们会共同检查约定的场景，并记录尚待完成的任务。
您的项目详情
接入现有系统，同时不给运维带来过重负担。
我们通过合适的衔接方式，开放老旧应用中的数据和功能。在此过程中，我们会考虑接口的局限性、厂商方面的限制，以及往往只存在于日常使用中的流程知识。
确定访问旧系统的可靠方式
我们首先会审查现有的 API、导出功能、消息通道以及受支持的扩展方式。直接访问数据库可能会绕过业务层面的校验，因此不会被想当然地当作最简单的解决方案。如果只有文件可供使用，也需要就格式、完整性和处理方式约定明确的规范。
我们会与业务负责人一同记录代码、特殊情况以及时间上的依赖关系。如果目标系统中某个状态的含义与源系统不同，那么即便技术传输成功，也毫无意义。一个前置适配器可以封装这类差异，避免每个新应用都必须自行理解历史格式。
分步集成，并为日后的系统替换留出空间
以读取为主的对接方式，通常比写入类对接的风险更低，更适合作为起点。对于旧系统中的写入操作，我们会审查权限设置、校验规则和反馈机制。流量限制和合适的时间窗口，可以保护那些并非为大量并发访问设计的系统。
我们会加入核对机制，用于发现缺失或被重复处理的业务事项。日后系统替换时，只要业务契约保持稳定，适配器就可以切换指向新的目标系统。这样便形成了一个有据可查的过渡方案，而不是又一条未加记录的点对点连接。
示例项目场景
该服务在日常工作中如何发挥作用。
示例：某老旧进销存系统会在夜间生成文件，一个新门户需要从中获取交货信息。我们会核查数据的完整性和对应关系，以受控方式提供数据，并标注数据的更新时间。写入操作暂时仍保留在现有系统中，直到确定合适的处理方式为止。
该示例说明的是一种可能的流程，并非客户案例。
在迈出第一步之前
您关于 对接旧系统 的问题。
旧系统最终一定要被淘汰吗？
不一定。稳定的门面层同样可以支撑长期的持续运行。系统替换和系统对接是两个不同的决策。
缺失的文档能否用扫描来替代？
只能部分替代。技术分析能够呈现结构和访问方式，但无法揭示所有的业务规则。因此，分析结果还需要与业务负责人共同核实。
