目前公司的数据总线设计仅仅是基于数据传输而数据的存储、筛选的功能比较弱。不足以支持大集团业务数据的传输筛选和分析？以目前悬而未决的订单下发问题为例：
目前问题：SAP发送没有经过拆分的订单以及BOM表给总线，而下游系统如MOM 需要得到拆分好的订单数据，且一次不能超过100条。目前的情况是总线在内存中将收到的订单进行拆分形成一车一BOM，拆分后一个订单文件约2.6M，SAP如果下发的订单数据稍大，总线就会内存溢出，导致整个总线性能下降或者死机。
===========================
项目经理（刘欣）回答：
1、按工厂35JPH，一个白班8小时是280台订单数据，一天满3班是840台订单数据。
2、一个订单数据里包含2800个物料和300个配置项。XML数据量是2.6M。
3、如果ERP接口程序一次下达840台订单集合数据。XML的数据量超过2GB。
4、下游系统希望在840台订单集合的数据里面，只接收一单一单的数据，如果上下游系统都不做，这个事情就会希望在ESB上来作。
5、ESB的本质是把接口消息可以化（XML是载体），但要在整一个庞大的XML中做foreach循环运算，靠XML标签再组装XML报文，XML数据量太大的情况下，目前主流总线厂商产品都是不能做的。 Oracle OSB实际测试结果是150台订单数据的XML拆单foreach运算耗用服务器内存37GB,内存溢出。当然内存可以有限制的增加，但是这个大数据 XML中运算时间等待也无法承受。
6、如果不在XML里面作这个foreach运算，在上下游的编程语言环境内存对象中作foreach,那是分分钟的事情。但总线产品用非XML的方式来处理了这块数据，那它一定违背了SOA的本质。我也有开发有自己的中间件工具SAPsender，但我不敢说我的中间件是SOA中间件。
========================
解决方案：总线要求SAP将拆分好的订单发送给数据总线，然后总线再将拆分好的订单放到下游系统各自的MQ中。
隐患：此方案只是暂时解决了MOM的对订单的需求和排序，每发送一个订单就必须去确认一次该订单是否发送成功，而最后还需要确认是否该批次发送的订单已经全部传输到下有系统，虽然算法进行保证，但是做了不少的无用功，以后接入总线的系统数量大幅度上升以后，总线的性能将以几何级数降低（长安福特有过失败的教训）
================================
项目经理（刘欣）回答：
1、 此方案没有解决排序，订单的排序是每个订单时间字段决定的。
2、 无论ERP接口是一次发出还是拆单发出，在下游系统都没有明显的校验机制，此方案是解决这个问题。
3、 如果ERP的数据是一次发出，当产量高时，这个数据量对ESB，LES，MOM都是巨大的数据。相当于上下班高峰期全部的车都涌向固定宽度道路上，所以我们的方案在ERP接口上拆成每一单发出（计划员还是批量选择发出）。这个也是捷豹路虎IDOC的案例。
4、 我们在每一个订单数据中加了一个字段，里面放的是计划员发出该批次订单的总数。这就提供了分布式的校验算法数据，下游系统可以用这个数据检验得到该批次订单得总数是否有遗漏。（ERP开发组长建议用我得名字来命名这个字段）
==================================
建议：总线，或者应该叫做数据管理平台将管理大批量的数据传输、处理、筛选的信息，从理论上来说，数据源系统（如SAP，订单系统，LES，DMS等）只需要将全部数据发送到总线平台，总线平台按照工厂，系统名称等建立相应的数据库，并将数据进行存储。上游系统在发送数据完毕并得到总线的确认以后就不再管该批次数据的后续问题。而下游系统如果需要请求数据，将和总线进行链接，按照需要的字段和传输协议进行请求，总线在建立的数据库中筛选出相应的文件和字段并发送给下游系统（类似于接力赛，交棒成功结束该选手的任务就完成）
结论：目前实施的方案很难支持大数据量，大系统量的并发数据交互和请求，一旦接入总线的工厂和系统数量增加，就会导致总线性能下降或者崩溃，严重影响公司的业务。而如果在总线层建立数据库，并在数据库筛选以后按字段和下游系统所需协议进行传输，将可以避免这一问题，唯一需要注意的是总线需要强大的硬件和网络支持，并要有镜像热备等机制保证出了故障马上恢复。
==================================
项目经理（刘欣）回答：：
1、 ORACLE的总线产品广泛应用在其它大数据行业如石油，通讯（在压力测试报告上甚至占优），并没有那么不堪一击，但是在一个时间点，一个接口上无休止的堆砌海量数据让ESB作XML运算（请注意这里是XML的标签大数据foreach处理），其实相当于把所有的车在一个时间点都放到一个高速路收费站，这种设计本身是不合理的，这个不是产品的问题。
2、 ESB企业服务总线中间件，它的强项应该是支持多种协议去接入多个系统，降低接入难度，而它应该遵循SOA服务的本质是把传输的数据透明化成XML。
3、 ESB它最重要的功能是在多连接和稳定传输上。因为它应该尽可能的避免复杂的业务运算（请注意这里是XML的标签大数据foreach处理）而带来的运行不稳定！所以ESB产品一路演变而来就是简化逻辑运算层和强化多系统连接适配器层。试想，我们一味强调中间件产品要去处理海量的大数据，那我们为何不直接采用中间数据库方案？
===================================