SAP整车订单下达接口的最佳实践

        中国汽车保有量已达3.07亿辆，是世界上汽车体量最大的国家，汽车企业也成为了中国经济的支柱；全国800多块有汽车生产资质的企业中，有一半在制造汽车。博主从2014年在第一家车企工作开始至今，已经到过4家车企，历经多次项目的经验积累，已经对相关的领域比较熟悉，自认为其中有一些有趣的经验，作一个标记与各位共勉。下面是一个订单下达接口和三任企业总线项目经理博主的故事。 （ESB企业服务总线，是在企业中集中管理接口的一套IT系统）

一、和整车订单下达接口的第一次相遇

        2014年博主的主要角色还是SAP系统管理员，因为也兼做开发，所以领导也让客串了企业服务总线的运维，这个时候的总线技术其实已经十分成熟，WebService已经大量使用、IBM的MB，MQ、SAP的PI、甚至微软的MSMQ都有大量的成功案例，博主甚至还搞出了自己的ETL工具叫SAPsender (详情：SAPsender ETL中间件工具_james-lx的博客-CSDN博客_etl中间件)。如果你是总线的项目经理，在整车企业各种IT系统相互通讯的成百上千的接口中，有一个整车订单下达接口需要你去特别的关注，因为它有如下特点：

单次数据量很大

2010年以后建的整车厂，生产数据大都采用一车一单一BOM的方案，最终到生产订单上，就是一个生产订单数据包含：

1）这台汽车的零部件BOM，

2）这台汽车的配置选项（比如车身颜色、内饰外饰）、

3）订单抬头（状态、生产日期等订单本身的信息）。

这样一台车的数据总共大概有3000条。如果100台车下达，数据量会有100*3000 = 300000行这么多。

对发送时间要求高

一个整车工厂每天按需完成上百台汽车的生产，在生产伊始，就是ERP系统要把计划生产订单下达给生产线场管理的MES系统，所以这个订单下达时间越快越好，如果时间太长，会影响后续汽车各生产车间的实际生产。

        2015年收购重庆渝州汽车厂资质的潍柴汽车属于初创品牌，销量不好，工厂经常一天只有50台的产量，ESB总线系统项目建设完成后，交由我来负责运维，在运维中我发现，这个接口成了老大难，生产计划员隔三岔五的来找我，因为接口太慢了，50个订单要发送1个小时以上。甚至有一次遭遇到年底年节的场景，工厂要在年底的最后几天干完一些未清订单，记得加起来有几百台，这个接口成了IT系统的瓶颈，只这一步就用了一整天时间。

        因为主要采用相对成熟的技术方案，所以企业IT技术的领域其实并不深，经过分析，造成接口慢的原因其实就很清楚，是因为SAP系统接口下发数据是一个大数据包，下游系统解析会很慢。（技术细节：SAP把全部的数据放在BOM、配置、订单三张表中，接口把这三张表一次传给下游系统，而数据报文的载体是XML，下游系统提取数据，需要从一个巨大的XML中查找提取，才能还原出每一个订单的三项数据，对大XML的解析同文本处理有关，它就快不起来）

        而这种方式最糟糕的是，生产订单是没有上限的，生产订单越多，XML文件就会越大，XML文件越大处理XML的效率就会很惨更糟糕。从运维的实践验证看，这个接口技术方案可以说这是一个LOW的设计或BUG。不过，因为反正工厂的产量也低，计划员虽然报怨接口慢，但花些时间还是可以把订单下下去，花费的时间还在可以容忍阈值内。

二、整车订单下达接口的重生

        2017年，博主到了一个新的汽车企业，各业务域的IT系统都重新开始建设，SAP系统也是如此；并且SAP服务器采用了最新的S4 HANA和IS AUTO的汽车行业解决方案。博主的角色是ESB企业数据总线项目经理，为PLM研发、DMS销售、MES生产、LES物流、SRM供应链、SAP财务六大业务域系统铺设数据高速公路。

        因为汽车企业大都采用成熟的解决方案，所以新企业的IT系统环境同上个公司差别不大，PLM、SAP、MES的软件厂商都是完全一样的（MES的ROCKWALL FTPC软件我还有过专题介绍）。对于一个对旧系统有抱怨但无法改变的管理员，迎来一个新系统的重构，那真是非常难能可贵的机遇；而新企业重点打造的整车工厂是“重庆标杆、中国领先、世界一流”的数字化工厂，在新系统中可以去改掉之前的设计错误于个人于公司都有义不容辞的情绪使然。

        因为在新工厂该接口同潍柴汽车完全一样，甚至连数据结构都是一样的，我们也了解到上汽、捷豹路虎、宝沃、观致等等整车工厂，这个接口的数据结构都是惊人的相似。所以博主有了一个很简单的目的，就是要把整车订单下达接口，从一次发出全部数据的大报文拆成每次发出一个订单的小报文。

        在SAP系统上线前，博主在ESB项目组中做了一个测试，果然如果还是老方案，ESB甚至吃不下280个订单的大报文，下游的MES、LES同样吃不下。

         但博主并不是ERP项目经理，可能当时对这个接口有改变强烈欲望的人只有博主（应该还有OSB乙方经理李玉奇，我只给他讲了一遍原因，他马上就意识到问题）。其实单单只看测试结果，就可以知道如果按原方案，工厂下达280个订单就可能下不去，更不用说耗时延迟的问题。于是，博主就和SAP项目经理PK，出方案，找6大业务域掌门开会，甚至进入SAP系统给出拆单的方案ABAP代码，下图是当年的代码，历时2个月，最终SAP系统在这个接口上拆单：

新工厂ESB项目的验收文档中，压力测试部分我们可以看到，整车订单下达接口对6720个订单下达的表现，只需要1个小时30分钟，这个接口可谓获得了重生：

三、整车订单下达接口的惊人提速

        2019年，博主到深圳宝能汽车去学习，认识了更多的小伙伴，担任过ERP、ESB项目经理，到华强北去攒了自己的第一台S4 HANA服务器、也在博客写了大家熟知的SAP PO开发系列专题。最后，随姚老板的汽车梦碎，魂归故里。

        2年后，回到原来的工厂，发现订单下达的数据已经发给了十几个下游系统，但接口的速度变慢了，一个订单下达接口要耗时10秒钟，而工厂销量又迎来爆发性的增长；再一次，订单下达接口被视为了IT系统的瓶颈。这时博主的角色是SAP 项目的ABAP开发人员，每天低头写代码，有问题就问何喜、兴伟两位开发大牛，很是恶补了一些ABAP的开发技术，开发能力有了一些提升。从使用到的ABAP新语法来看，ABAP语言的开发效率已经能够模仿C#的一些地方了。

        其实SAP APO 模块的订单下达程序的业务逻辑门槛较高，但要优化程序必须先吃掉理解怎么排序、怎么使用订单下达，所以该接口的优化也不是一件简单的事情。从年初开始，优化缩短订单下达时间就排给了我和一鸣作为专题项目，我们想了各种方案，也找过SAP售后，最后终于在近期，在整车订单将要把我们淹没的时间点，取得了决定性的突破：

500个订单下达程序读取阶段耗时，从1200秒缩短到120秒。

500个订单下达程序下达阶段耗时，从5000秒缩短到1000秒。

500个订单场景中，整个程序下达耗时从6200秒缩短到1120秒，从近2个小时缩短为20分钟。

按工厂的最大产能，当前优化后的订单下达速度已经完全可以满足了。

对于读取的优化使用了SAP并行技术，这在SAP优化的案例中并不多见，关于SAP并发的技术被使用的技术详情在这里：对ABAP程序调优的学习（三）并发读取_james-lx的博客-CSDN博客

这就是博主和订单下达接口历时7年的最佳实践。