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年的最佳实践。(投稿CSDN活动,生命不止,写作不息)
SAP整车订单下达接口的最佳实践相关推荐
- Go语言-Go interface 接口的最佳实践
文章目录 Go语言-Go 接口的最佳实践 什么是Golang中的interface 编写接口的最佳实践 1. 保持interfaces足够小 2. Interfaces Should Have No ...
- API接口设计最佳实践
目录 目录 前言 API接口设计 Token设计 API接口设计原则 1.明确协议规范 2.统一接口路径规范 3.统一接口版本管理 4.为你的接口设定调用门槛 5.接口返回规范 6.接口安全规范 7. ...
- SAP UI5对于颜色使用的最佳实践
Created by Wang, Jerry, last modified on Sep 25, 2015 理论上来说尽量不要自己 hardcode css 颜色,最好使用 UI5 提供的 less ...
- SAP ERP 与泛微 OA 系统集成的最佳实践指南
SAP ERP 与泛微 OA 系统集成的最佳实践 简介: <SAP ERP 与泛微 OA 的系统集成>系列文章.SAP ERP 是优秀的企业核心管理系统,泛微 OA 是优秀的企业核心协同系 ...
- 微服务架构10条最佳实践
转载自公众号:SpringForAll社区 确保你在分布式系统中,努力实现这些微服务的最佳实践,例如监控和REST成熟度. 使用微服务架构可以解决所有的软件架构的问题,对吗?当然,这是不对的.但是,使 ...
- Talend“作业设计模式”和最佳实践
作为Talend开发者,不管是入门新手还是资深人士,常常要处理同一个的问题:"在编写这项作业时,哪种方式最好?"我们知道,通常应当高效.易读易写,并且尤其(多数情况下)要易于维护. ...
- OPEN(SAP) UI5 学习入门系列之二: 最佳实践练习(下)
上期我们完成了一个简单的主从页面,但是页面是静态的,不能交互,功能也很简单,只有一个销售订单的列表. 我们今天就一鼓作气把代码全都写完,由于本次的代码量较大,所以只对重点代码部分进行讲解. 具体每个文 ...
- SAP(HANA+S/4)上云基础环境部署最佳实践
简介:为提高客户服务水平及集团管理效率,客户选择了SAP解决方案.但是同时也对客户的IT基础设施提出了更多的要求.对此我们针对SAP上云基础设施选型.云原生产品.灾备方案设计,云上安全环境设计总结出了 ...
- 监控最佳实践--redis及业务接口
简介:监控最佳实践--redis及业务接口 1. 背景 1.1 问题 2020-12-04,客户侧redis集群版监控DB0 CPU突增至100%,导致数据库无法正常服务,经排查客户侧业务上存在2M左 ...
最新文章
- 学计算机需要用手机吗,智能手机能代替电脑吗?
- QT5.14.2基于PCL1.11.1显示点云(基于Windows VS2019开发环境)
- 重写慢日志解析程序,实现打印慢SQL信息及其所属数据库
- String s = new String(xyz);创建了几个对象?
- java赋值父类_java新手求助super和set给父类赋值!
- Image-based Lighting approaches and parallax-corrected cubemap
- 两台200smart以太网通讯_S7-200 SMART PLC之间如何实现以太网通信?(附接线图)
- fat,uat,pre等环境含义
- macbook用户注意了,这个行为可能导致显示屏损坏
- 全面讲解光纤、光模块、光纤交换机、光模块组网设计与案例
- 程序员涨工资大多数靠跳槽吗?
- swift subscript scraps
- mysql notifier什么_MySQLNotifier这个东西有什么作用?
- C7N新增,保存,删除基础模板
- 企业微信自建应用获取用户信息
- win11待机时间怎么设置 windows待机时间设置的步骤方法
- 怎么在html中加入特效文字,如何使用HTML5+css3实现粒子效果文字动画特效(附完整代码)...
- J2EE 框架结构及核心技术基础面面观
- python--自动创建文件和创建目录的方法
- mysql中limit2,1和limit2 offset 1的区别
热门文章
- C语言初阶——5.字符串
- python 常用函数
- CPU内部结构图和MicroBlaze内部结构图对比
- Mandelbrot 并行实现
- Android Jetpack架构组件之Navigation
- [知识图谱] 4.1-知识图谱在金融领域中的应用实践
- nacos 服务注册报错server is DOWNnow, detailed error message: Optional[Distro protocol is not initialized]
- Python GUI之tkinter窗口视窗教程大集合
- 除了这门升级中的V2Pro课程,恐怕你找不到更好的学验证的途径了
- Android技术分享