谈谈亲历的WMS、MES与ERP的集成之路(第三篇:求索+感想)

[某夏]

长此以往，IT虽劳苦，但收效甚微，很能理解给业务带来的工作困难与无奈，于是团队决策者开始静下来着手解决之道，个中不断寻求系统厂商助力，但似乎都已成世纪难题。从寻求专业的系统集成解决商，例如ESB、数据中台等等，寻而往来，却不得解，路漫漫其修远兮，吾将上下而求索！
知己所需还应知彼长短。初心未变，变的是岁月，此情此景我想聊聊我们对服务交互探索的浅见：
人工处理实现：人工传递、手工录入，不限于两边系统对照、邮件等沟通后人工在各自系统中录入、导入、修改等方式；大量及重复的操作、查询沟通才能处理，虽适合大批量，少单据、少变化的企业。但终不是正确之道。短期方案可备选。
中间库模式：各自系统实现逻辑传递到中间库，同时相关信息各自获取进行后续处理；难以完成时序、逻辑校验，优势在于边界清晰，错误定位责任清晰；但数据复杂，查找问题困难，处理问题往往需要在纷繁的事务中不断摸索、优化。此模式目前为90%左右实施方标准方案，为啥？管杀不管埋，保证双方责任边界清晰，同时有记录，项目得以必要保障。
调度模式：适用于双方系统提供查询、回写接口，需求方定时获取数据及变化来更新目的库数据，同样需要在时间段内去对比信息，事务处理非常困难，同样难以承载时序、逻辑校验。
数据库触发器开发模式：适用于简单基础资料类对接(无逻辑处理)，其他业务要求考虑全面，在技术上作到最好，才能不影响业务和性能。触发器也确实不容易被注意，给后期维护带来困难。同时业务往往需要考虑触发器的挂载和事务处理。此方法目前大量被乙方实施公司采用，主要原因为实现快，逻辑相对于简单，它不用考虑操作端局限，只监听数据库对应的变化。作为甲方我们应该严格抵制它，这种不完善的方案终将如深埋的雷，往往带来的风险、后果会超出你的想象。慎用之更应禁用之。
代码开发模式：适用于定向开发，优势明显在于可靠实现清晰的业务流程，数据交互，握手校验，劣势也非常明显，在于开发很多不了解业务，业务很多讲不清需求，理解不了开发架构。在企业业务变化为不变的真理时，往往会大量投入资源来应对，同时周期及交付难以把控，常常会牵涉多方沟通、管理接入、调整难，维护更难的局面，管理者应重视管理、运维、系统迁移、改造、代码管理等等情形。同时应考虑怎么合理分配资源，协调资源可靠、快速完成以及人员培养定位、团队建设。
平台模式：要实现系统的集成，底层的结构、软件、硬件以及异构网络的特殊需求都必须得到集成。平台集成处理一些过程和工具，以保证这些系统进行快速安全的通信。平台兼备管理、运维、消息等机制。

通过对比分析、取长补短，毋容置疑，平台模式为我们奋斗的目标，选择的根本，不难发现我们需要的平台功能它应该具备:
必须建立一套完善的系统来管理所有数据传输，并能够快速扩展以响应客户变化的需求，满足应用程序可用性和用户数目的增加。
需要正视网络非可靠传输的因素，应建立端、或者类似网关的机制，可本地部署、云部署或者混合部署解决安全可靠、跨域的问题，实时系统监控,自动警报。
轻量、高效、标准不失灵活的平台功能，具备服务治理管理、更新管理、应具备核心的转换和集成开发功能，同时提供可视化、快速实现、运维的需求。
应杜绝大量繁琐的工作才能实现互联互通，建立服务生态系统，服务开放即可重用，系统迁移或新上时，更多倾向考虑本身API的功能即可交互。
应具备清晰的数据记录、结果记录、应对系统业务不可重现时平台需支持数据交互的传递及运维，同时应具备完整的操作日志、运行日志、消息机制的推送等。
应具备完整的安全机制、加密机制，身份验证，授权和访问，通用的访问管理解决方案集成兼容，多种认证机制，标准和令牌类型等

平台开发启动同时启动了ERP的接口开发：此次开发监管ERP数据底层，在ERP本身功能及API上进行二次开发封装，实现了ERP触发时机、
对接数据、单据流关联等可视化配置操作，例如标准采购(订单)指定组织，
由开立→审核触发异步模式新增服务到WMS系统中，
由审核→审核触发变更修改服务，同步模式校验WMS数据，校验成功允许修改，否则弹窗报错不允许修改，事务回滚。
由审核→开立触发删除服务同步模式校验WMS数据，校验成功允许删除，否则弹窗报错不允许删除，事务回滚。
同时启动了WMS、MES接口开发与封装；

接着我们将此子公司的接口全部进行测试、迁移、优化，将近三个月，发现业务交互事件化，清晰透明，追溯查找方便；在后面几个分子公司的系统上线时，接口配置，上线仅仅只用了一个星期。从以往的开发多方沟通实现，转变为由实施人员根据业务自主配置实体触发、手工批量触发等方式来完成及交换。上线后异常服务提示对应人员，分析查找问题变得非常容易，数据不再是底层不可见的交互。同时对平台实现自动分发，即时交互，服务上传即生效，设计节点接收、传输数据，大大降低宕机、网络传输带来的数据丢失。支持同步模式:系统间需要握手交互验证；异步无序：负责数据传输、无序系统间校验，效率最高；异步有序：数据包执行需考虑先后顺序执行。
经过几年的求知之路，更加坚定了设想的初衷，所谓正确的选择，更多的是认准了思路。虽然项目是短期的经营活动、资源的分配利用、以及成果的交付，但作为信息化的支撑团队，我们更应像掌舵者，虽然路途漫长，过程艰辛。但苦中带甘。更加觉得企业应自身强大起来，成为信息化自主的实现者、管理者、决策者、运维者以及引路人。是以分享经历，学知识，传递己见，赠人玫瑰，手留余香。在这个我认为的平行世界里，也许存在众多的同道者、困惑者，还望不吝赐教，相互学习。再次感谢拨冗翻阅拙文，如若不弃，可互友把酒桑麻。

[以专业开发人员为伍]

我感觉在动物园看戏，感觉 lz 的企业太“码农化”了，太时髦太流行化，堆砌包袱的思想太重，缺少真正的自己动脑的创造力。

[以专业开发人员为伍]

任何一个改造最终都会叫做一个“平台”，只要钱、人到位，都可以推出一个平台，通过一套 api 来集成。所以“平台”这个词儿最方便来实现各种概念。之前的4种（或者更多种）模式的思考，更多地是码农的思考，甚至考虑到“是否用触发器就能解决问题”这类问题，就好像是架构师讲解如何建造船舶时而工人们在认为只要会焊钢板然后耗费十年时间就必然拼凑出船舶一样；所谓“中间库”概念，原本用于采集各种实时信息的技术基于“大数据、快”的前提，采集和工作流是不可能相互替代、相互排斥的东西，被你们用于相互排斥；所谓“代码开发”其实是个标题党，在外边封装一套统一 api 就是“平台”，而故意不设计一套统一的 api 这就是“开发”，是用来凑数量的说词儿，如果领导多给钱多给加工资就号称“平台”，如果少给钱不涨工资就号称只能进行“代码开发”；“调度模式”是所谓的现有系统上的 api 互通，这本来就是取决于你们到底是花多少钱重新写多少东西这个决策下的。实际上整个纠结的东西是拍脑袋、开会的时候才需要纠结那些东西，真正技术的东西并没有多少。就好像古代韩信打仗，如果从一开始就有谋臣在汉王驾前鼓噪，那么韩信早就死了，历史上也不会有韩信。韩信给后代的战例属于韩信，而不是属于弄死韩信的汉王和谋臣们的！所以有些指挥，干扰了开发，能最终开发成功往往是因为另外有一位没有留下名字的系统架构师。