谈谈亲历的WMS、MES与ERP的集成之路
文章目录
- <章一>困惑篇
- <章二>初尝篇
- <章三>求索篇
- <章四>感想篇
<章一>困惑篇
- 2016年集团信息部初建。领导、决策层对企业信息化的重视与认知，作为实践者倍感压力巨大，大面积的周边系统迁移与基础建设忙得不可开交。然而当希冀与现实发生完美邂逅的时候，却倍感庆幸，能去付诸实践、去逐步完成设想与规划。同时不得不感慨自己的渺小，决策当前，怎么多管齐下、有条不紊的进行工作。这一年里，在领导带领下团队完成了流程系统的支撑、订单前端系统的开发、决策数据收集、展示以提供数据支撑、数据与业务双驱动。
- 在2017年时决策层在遵循试、快、用原则下从集团企业中优选了一家做试点，旨在建立WMS、MES智慧工厂。
- 选型阶段时，多方齐动。业务需求方汇点成面，多维度梳理、评估与制定业务需求；IT团队从软硬件方面更多考虑支撑完善度与二次开发功能的扩展能力；供方从专业角度答疑解惑，蓝图初构。
- 随着需求明确，软硬件评估，以及供方的最终确定。从决策层的目标指向上我们把这次项目的重点管控列为：系统间交互与智能响应；管理方案、体系化建立（量化、流程化、标准化）；软件业务层实现与管控。不难理解，软件层将由内外双方共同拟定方案及实现落地，这也是供方的基本交付能力；同时双方应共同建立管理方案、业务及管理能量化的量化、不能量化的流程化，不能流程化的标准化来管控业务流向、过程约束，达到简单操作、高效健壮运行提升效率。然而多个供方沟通后背我们首先列入可识别风险的重要项都指向：接口交互怎么实现。
- 在意识首当其冲的大难题时，内部团队与WMS、MES厂商进行了第一次面对面的深入沟通，当然做为小白的我们，正以待哺的姿势接受第一次洗礼：
开放ERP查询及回写接口给对方查询或调度；
ERP端触发到WMS、MES厂商提供的中间库，以供对方定时载 入，同时定时抓取WMS、MES厂商传回的数据回写ERP；
人工处理。
- 面对困惑，已然不再是庸人自扰，而是难以支撑决策，从现实来看，当时还在服役的ERP没有接口、无法挂载触发器(当然也不推崇，后文有叙)，此为软件之困惑；集团下属此企业属于小批量多品种生产，业务单据变更犹如波诡云谲，业务需求方显然无法接受人工大量干预，IT团队面临技术与人员配备困惑。
- 诚然，与会人士众多，都各怀己见。又到了团队头脑风暴的时刻，此时此刻的你心所向为何？在我们集各种方案思考、各抒己见后觉得这无论是我方、还是WMS、MES供方，甚至试图沟通的第三方都是一条难以逾越的鸿沟。想必每逢此景的IT团队，心里都有一杆秤衡量它：理想中的接口交互应是各大软件集成商声声念念的无缝集成、即时交互、握手验证等等。因为这个概念目标在于降低运营成本、降低维护成本，缩短沟通时间、提高服务效率，提供历史记录。
那么问题来了，怎样才能实现它？
谁来实现，是供方、第三方、还是作为“消防员”的我方？
凡事谋定而后动，知止而有得，从管理维度怎么构建平台？
怀着不矜不伐、敏而好学的端正态度我们不难发现有很多概念已被提出：
EAI（Enterprise Application Integration，企业应用集成）：界面集成、业务过程集成、应用集成、数据集成、平台集成五大类型。
ESB（Enterprise Service Bus），企业服务总线，面向服务的体系结构已经逐渐成为IT集成的主流技术。面向服务的体系结构(service-oriented
architecture，SOA)是一种软件系统设计方法，通过已经发布的和可发现的接口为终端用户应用程序或其它服务提供服务。
- 就像歌词写的：我跌跌撞撞奔向你，你也不能一个人离去，我们在一起说过，无论如何一起经历风雨。前方高能已经指明方向，我等将势必跟随。当然这次崇拜式的追随，热情与念头也就如后面歌词：平平淡淡安安静静的死去。
当我们对上述系统进一步研究后得出它的重大功能：转换和集成。转换是指转换协议和消息格式，集成是指将原子服务按照要求有规律的进行串接。询过专业上述集成厂家，最后得出的结论：系统太过昂贵(免费开源的Mule ESB也二次开发、应用过，坑太多，运行不稳定，或者认定为技术要求太高，非一般人玩得转。)用它同样需要大量繁琐的开发工作才能帮助他们实现互联互通，且要求颇高太过陈旧，已难适应轻量、快速响应、开发难度高、冗余的配置功能变得非常不灵活。
作为IT决策者你是否会考虑到虽前期转嫁了风险、却低估甚至忽略了后续的运维及管理？你是否有魄力重金之下，求勇夫？
<章二>初尝篇
上篇困惑每逢回想起至今尤寒，虽前路不明，也定要披荆斩棘，谁让你担当这现代化建设者，谁让你履行“消防员”的责任。
自然，我们抛弃了供方提供的方案3.人工处理的方式，理由也非常充分：数据量、单据量大，操作完一个系统需配备一定素质的人继续另外系统的操作，效率低下，出错率最高，且并非所愿，虽然大企业大批量可以这样玩，即便你玩得很开心，不乏人力，但是不low吗？很low，妥妥的，且以后的自动化述求何时能实现？不积跬步,无以至千里.不积小流,无以成江海。
方案1，我们将把需求的实现转嫁给ERP或WMS、MES厂家或者第三方，需评估以下方面:
需求制定、开发、测试周期；
没有接口的ERP的开发模式决定了难度，比如单据插件开发模式需要考虑单据量(功能考虑不周将导致周期与预算大大超出)，又比如按钮事件开发模式需要评估和制定操作功能标准(在世的众多ERP都面临单据有按钮操作，列表有操作，其他单据也能后端操作等等)；
二次开发带来的升级、迁移弊端(如果开发带来严重影响升级或者升级包执行后二开失效请谨慎再谨慎，”消防员”宁赴死却承担不了灵魂的拷问啊。)。
当然就是成本与维护的考虑了，初次预算下来起码需交付几十万，虽风险已转嫁，但维护、优化却受制于人，且重用性基本为零，更谈不上管理，IT决策者请试想怎么有效的管理及运维它，付出与得到差距甚远。
- 方案2，在此基础上，我们第一次最终无奈选择了它，确实无奈、请恕在下无能。此次集成部分全部由内部团队对ERP各个数据表以及关联表附写定时调度查询功能，以时间戳记录为筛选依据，进行了浩浩荡荡的数据转移到中间表。回写部分梳理了业务关联性，从少量数据传回前提下，去抓取上下游关系数据，回写ERP业务数据表。为时一月有余，战战兢兢地上阵。
此处谈谈为什么建议慎用触发器：主要原因是合理的触发器编写对设计者和编写者的要求很高，必须比较全面的分析相关业务，同时全面了解触发器工作原理。也就是说写出的触发器要求在业务上考虑全面，在技术上作到最好，才能不影响业务和性能。触发器也确实不容易被注意，给后期维护带来困难。同时业务往往需要考虑触发器的挂载，例如单据存在子表、孙表的时候需要验证业务系统事务处理的机制以及是否在事务中，否则数据不完整，逻辑不完善都会带来严重的后果，同时对性能和开销都要有一定的考虑，更有系统厂商鉴于触发器造成的数据混乱会告诫不在维护之列。
当后来我们还沉浸在完工的喜悦时，自觉得会不断的修复bug来完善此方案，现实的打击接憧而至： - 1> 业务从开始1小时定时调度不满逐步转成30分钟定时、5分钟定时、1分钟定时甚至更甚，因为理由确实充分，生产在等数据才能操作。此时发现了越来越多的数据紊乱，天生的时序已经出现了各种问题，虽不断修复，但我们已经痛苦不迭，每日埋没在修改数据的事务之中，业务抱怨纷繁踏至；
- 2> 数据虽然在传输，但是业务之间始终没有相互制约，举个例子ERP采购订单下发后，A料采购数量100PCS，WMS供应商已经释放条码，包装，甚至送货途中，ERP因特殊原因变更了采购数量为80PCS，WMS何其无辜的说了声，你叫我修改的，好，那么修改后多余的20PCS后续会出现怎么对待的问题，此时WMS弥补性的再发声，我加一个校验返回到中间表不能修改，ERP再定时去抓取禁止ERP修改，长此以往，数据穿插交互犹如蛛网，IT每日都在头晕之中，谁来为这现实埋单？是制定标准用管理来约束？还是配备人员在不断的查证纠错修改工作中辛勤耕作？答案往往都很难具备说服力，限制功能往往带来更复杂的操作才能撤销和弥补，大量的维护也将得不偿失，效率低下。
可想而知在这一年多里，心有所绊，却非念想，何其无奈。IT外出团建都带着电脑，产线加班都有IT默默在陪伴。如果幸运的你在几班倒的企业，是决定做你的男人24小时不睡觉待命还是翻牌伺寝，当然也不乏乐在其中的人儿，想想兴许还有点其他福利，或者自觉得不可或缺。
就像夹在和田籽料里面的水石，虽外表一样光滑亮丽，但它终不是来自昆仑经山流水千万年岁月的沉淀，结果可想而知。
<章三>求索篇
长此以往，IT虽劳苦，但收效甚微，很能理解给业务带来的工作困难与无奈，于是团队决策者开始静下来着手解决之道，个中不断寻求系统厂商助力，但似乎都已成世纪难题。从寻求专业的系统集成解决商，例如ESB、数据中台等等，寻而往来，却不得解，路漫漫其修远兮，吾将上下而求索！
知己所需还应知彼长短。初心未变，变的是岁月，此情此景我想聊聊我们对服务交互探索的浅见：
人工处理实现：人工传递、手工录入，不限于两边系统对照、邮件等沟通后人工在各自系统中录入、导入、修改等方式；大量及重复的操作、查询沟通才能处理，虽适合大批量，少单据、少变化的企业。但终不是正确之道。短期方案可备选。
中间库模式：各自系统实现逻辑传递到中间库，同时相关信息各自获取进行后续处理；难以完成时序、逻辑校验，优势在于边界清晰，错误定位责任清晰；但数据复杂，查找问题困难，处理问题往往需要在纷繁的事务中不断摸索、优化。此模式目前为90%左右实施方标准方案，为啥？管杀不管埋，保证双方责任边界清晰，同时有记录，项目得以必要保障。
调度模式：适用于双方系统提供查询、回写接口，需求方定时获取数据及变化来更新目的库数据，同样需要在时间段内去对比信息，事务处理非常困难，同样难以承载时序、逻辑校验。
数据库触发器开发模式：适用于简单基础资料类对接(无逻辑处理)，其他业务要求考虑全面，在技术上作到最好，才能不影响业务和性能。触发器也确实不容易被注意，给后期维护带来困难。同时业务往往需要考虑触发器的挂载和事务处理。此方法目前大量被乙方实施公司采用，主要原因为实现快，逻辑相对于简单，它不用考虑操作端局限，只监听数据库对应的变化。作为甲方我们应该严格抵制它，这种不完善的方案终将如深埋的雷，往往带来的风险、后果会超出你的想象。慎用之更应禁用之。
代码开发模式：适用于定向开发，优势明显在于可靠实现清晰的业务流程，数据交互，握手校验，劣势也非常明显，在于开发很多不了解业务，业务很多讲不清需求，理解不了开发架构。在企业业务变化为不变的真理时，往往会大量投入资源来应对，同时周期及交付难以把控，常常会牵涉多方沟通、管理接入、调整难，维护更难的局面，管理者应重视管理、运维、系统迁移、改造、代码管理等等情形。同时应考虑怎么合理分配资源，协调资源可靠、快速完成以及人员培养定位、团队建设。
平台模式：要实现系统的集成，底层的结构、软件、硬件以及异构网络的特殊需求都必须得到集成。平台集成处理一些过程和工具，以保证这些系统进行快速安全的通信。平台兼备管理、运维、消息等机制。
通过对比分析、取长补短，毋容置疑，平台模式为我们奋斗的目标，选择的根本，不难发现我们需要的平台功能它应该具备:
必须建立一套完善的系统来管理所有数据传输，并能够快速扩展以响应客户变化的需求，满足应用程序可用性和用户数目的增加。
需要正视网络非可靠传输的因素，应建立端、或者类似网关的机制，可本地部署、云部署或者混合部署解决安全可靠、跨域的问题，实时系统监控,自动警报。
轻量、高效、标准不失灵活的平台功能，具备服务治理管理、更新管理、应具备核心的转换和集成开发功能，同时提供可视化、快速实现、运维的需求。
应杜绝大量繁琐的工作才能实现互联互通，建立服务生态系统，服务开放即可重用，系统迁移或新上时，更多倾向考虑本身API的功能即可交互。
应具备清晰的数据记录、结果记录、应对系统业务不可重现时平台需支持数据交互的传递及运维，同时应具备完整的操作日志、运行日志、消息机制的推送等。
应具备完整的安全机制、加密机制，身份验证，授权和访问，通用的访问管理解决方案集成兼容，多种认证机制，标准和令牌类型等
平台开发启动同时启动了ERP的接口开发：此次开发监管ERP数据底层，在ERP本身功能及API上进行二次开发封装，实现了ERP触发时机、对接数据、单据流关联等可视化配置操作，例如标准采购(订单)指定组织，
由开立→审核触发异步模式新增服务到WMS系统中，
由审核→审核触发变更修改服务，同步模式校验WMS数据，校验成功允许修改，否则弹窗报错不允许修改，事务回滚。
由审核→开立触发删除服务同步模式校验WMS数据，校验成功允许删除，否则弹窗报错不允许删除，事务回滚。
同时启动了WMS、MES接口开发与封装；
接着我们将此子公司的接口全部进行测试、迁移、优化，将近三个月，发现业务交互事件化，清晰透明，追溯查找方便；在后面几个分子公司的系统上线时，接口配置，上线仅仅只用了一个星期。从以往的开发多方沟通实现，转变为由实施人员根据业务自主配置实体触发、手工批量触发等方式来完成及交换。上线后异常服务提示对应人员，分析查找问题变得非常容易，数据不再是底层不可见的交互。同时对平台实现自动分发，即时交互，服务上传即生效，设计节点接收、传输数据，大大降低宕机、网络传输带来的数据丢失。支持同步模式:系统间需要握手交互验证；异步无序：负责数据传输、无序系统间校验，效率最高；异步有序：数据包执行需考虑先后顺序执行。
<章四>感想篇
经过几年的求知之路，更加坚定了设想的初衷，所谓正确的选择，更多的是认准了思路。虽然项目是短期的经营活动、资源的分配利用、以及成果的交付，但作为信息化的支撑团队，我们更应像掌舵者，虽然路途漫长，过程艰辛。但苦中带甘。更加觉得企业应自身强大起来，成为信息化自主的实现者、管理者、决策者、运维者以及引路人。是以分享经历，学知识，传递己见，赠人玫瑰，手留余香。在这个我认为的平行世界里，也许存在众多的同道者、
