基于ESB的系统集成在汽车制造企业中的应用研究

赵业海

（柳州五菱汽车工业有限公司，广西 柳州545007）

0 概述

柳州五菱以生产和销售微型汽车零部件、发动机和专用车为主要业务的汽车及零部件制造企业，是中国汽车工业30强、中国制造业企业500强、全国大型工业企业500强和信息化企业500强之一。

在柳州五菱信息化规划模型中，将信息系统描述为包括计划层、执行层和控制层的三层模型，如图1所示。企业资源规划（ERP系统）需要实时的生产信息来辅助做出经营决策，但来自现场状态的实时信息和生产数据不能直接反应出决策经营者所需的准备数据，包括计划执行进度、物料库存、质量状况、设备状态等信息。生产制造执行系统作为中间的执行层，它的目标就是要实现优化运行、优化控制及优化管理，起承上启下、运筹调度的中枢作用，其作为生产过程系统的基础数据处理平台，具有的功能应包括：生产调度、过程资源配置、物料监控、质量管理、过程数据采集、流程模拟、模型计算及过程优化等。因此，需要通过系统集成，收集所有相关物料、资源的信息及时、准确地反应到ERP上层。

图1 系统业务分布层次图

目前我公司信息系统主要包括PLM、ERP、MES、WMS、QMS、主数据管理、数据采集和控制等多个信息系统，系统间的数据准确实时交换是实现智能制造的前提。作为SOA核心技术的ESB提供了综合、灵活而且一致的集成方法。随着企业智能制造信息系统应用的深入，如何做好系统集成成为信息化建设的关键点。通过对集成以及ESB集成平台的讨论，阐述了构建智能制造ESB集成设计的方法，并形成构建ESB平台的顶层设计。

1 企业服务总线应用

企业服务总线（简称ESB），作为一种耦合的服务和应用之间的集成方式，是当今先进的企业应用整合方案。ESB作为SOA架构的信息传输龙骨，能够帮助简化IT架构（减少应用整合接口的数量和复杂程度），降低运作成本，自动实现系统之间、部门之间甚至厂家之间的应用集成，从而降低企业应用集成的难度和成本，提升业务灵活性和市场响应速度（Time to market），最终提升企业的竞争优势[1]。

1.1 企业服务总线功能定位及集成规划

借鉴IBM等大型咨询公司在汽车行业实施系统间数据集成的经验及解决方案，公司制定基于企业服务总线（Enterprise Service Bus，简称 ESB）的建设思路，解决了系统之间复杂的交互逻辑和复杂的交互技术，图2为柳州五菱个应用系统数据集成规划示意图。

图2 柳州五菱应用系统接口规划示意图

使用任何技术和产品构建的企业服务总线都应包括下列主要功能包括：

路由器：根据信息内容，在不同的应用和服务之间进行信息的传输和路由；

转换器：进行应用之间的通信协议转换；

翻译机：进行应用之间的消息格式转换；

收发室：处理来自不同渠道的业务事件（同步传输、异步传输、发布／订阅等方式）。

1.2 柳州五菱企业服务总线产品选型

柳州五菱在产品选型过程中，试用过多个产品，最终选择使用开源Mule-ESB产品搭建企业数据总线的多系统集成平台，确保公司内部系统之间的数据交互以及公司对外业务数据交互能够安全、可靠、及时的完成。

Mule ESB是一个基于Java的轻量级企业服务总线平台，并支持开源的产品，允许开发人员快速便利地连接多个应用，并支持应用间的数据交换。Mule ESB支持集成现有系统而无论其底层采用何种技术，如 JMS、Web Services、JDBC、HTTP以及其他技术等。目前我公司使用JSON-RPC的通讯方式相同，JSON格式更加高效。

1.3 数据集成流程

柳州五菱根据业务系统实施情况，结合公司整体信息系统集成规划，总结出两类接口设计流程，即业务数据接口系统交互流程和主数据接口系统交互图流程（见图 3、图 4）。

1.3.1 业务数据接口系统交互流程

（1）ESB接收源系统的数据后将会保存到ESB数据库（转储数据库 DumpDB）中，实时返回源系统的状态为ESB的数据接收状态，而非目的系统的数据处理状态。

（2）ESB异步方式将接收到的数据包原样发送给目的系统，目的系统实时返回数据处理状态。

（3）ESB将目的系统返回的数据处理状态通过另一接口“处理结果返回接口”发送给源系统。

1.3.2 主数据接口系统交互图流程

图3 业务数据接口系统交互流程

（1）ESB定时按修改时间索引查询读取数据仓库（源系统）中主数据，并发送维目的系统。

（2）ESB每次仅发送1条数据给目的系统（按更改时间升序），目的系统在处理后返回相应的处理结果。目的系统的处理可以是数据校验等操作。

图4 主数据接口系统交互图流程

2 基于数据路由的ESB技术框架

2.1 业务数据接口规范

（1）源系统发送的数据为JSON格式的数据包，其中包括1个必须字段“PackageID”用于唯一标识数据包：

1）ESB仅确保同一个“PackageID”从源系统接收到的数据以及发送至目的系统的数据一致性，不对其内容作解析；其内容由源系统与目的系统协商确保业务的完整性及可用性。

2）源系统确保：相同数据其PackageID必须相同。如源系统在数据发送失败下次重发时，务必确保同一数据的PackageID相同。

3）原则上，1个数据包只包括1条业务数据。以便源、目的系统的数据发送状态、处理结果的校验及返回。ESB不作强制要求及相关校验。

（2）与源系统关于数据发布接口约定

现在，“宝贝不哭”已成为全院的自觉行动。无论何时何地，听见孩子哭声，医生护士都会停下来，看看孩子为什么哭？SPE组不再单枪匹马，这是马力最乐意看到的。

1）请求数据包格式：源系统主动调用ESB发布数据，以下是HTTP请求示例。

POST[URL]HTTP/1.1 Content-Type:text/xml;charset=utf-8 Content-Length:length{"PackageID":"XXXXXXXXXX",//必需。数据包ID，长度在20个字节以内，英文+数字…… //以下为数据内容}源系统务必确保"PackageID"作为JSON文本中的首字段，以避免不可预期的错误。

2）响应数据包格式：ESB在HTTP响应中即时返回数据接收结果，以下是HTTP响应示例。

HTTP/1.1 200 OK Content-Type:text/xml;charset=utf-8 Content-Length:length{“status”:0,//必须，状态，0-异常,1-正常,2-重复数据"message":"",//非必须，异常时的错误详细描述"resend":"Y"//非必须.Y则表示当前数据包需要再次发送，反之应为N或""或无此字段}

3）处理失败重发Resend机制

A.源系统调用ESB时，如HTTP调用成功（HTTPStatus=200），但由于ESB原因无法将数据包成功保存的，ESB将在返回信息中设置Resend=Y。

HTTP/1.1 200 OK Content-Type:text/xml;charset=utf-8 Content-Length:length{"status":0,//必须，状态，0-异常,1-正常,2-重复数据"message":"",//非必须，异常时的错误详细描述"resend":"Y"//非必须.Y则表示当前数据包需要再次发送，反之应为N或""或无此字段}

B.源系统对于Resend=Y的，当前作业将跳过此包继续发送下一个包。这一个数据包将在Resend时间间隔之后再次重发失败的数据；如Resend多次后仍然失败则不再发送此数据包。

C.建议调用方对以下连接参数设计为每个接口可配置不同参数：Resend次数、Resend时间间隔。

D.对于数据顺序要求极高不允许跳包发送的，需要在接口设计时由源系统、目的系统及ESB三方协商确定。

4）发送失败重试Retry机制

B.发送失败的数据不会被跳过，会在下次作业触发时或Resend时间间隔之后再次发送直至达到最大失败重试次数或直至成功。

C.建议源系统方对以下连接参数设计为每个接口可配置不同参数：HTTP连接信息、超时时长，失败重试次数、失败重试间隔。

D.对于业务时效性极高不允许发送过期数据的，需要在接口设计时由源系统、目的系统及ESB三方协商确定。

5）数据重复性校验原则

A.源系统发出的数据包中必须包括“PackageID”作为数据包唯一性标识。

B.ESB获取数据包ID，将先解析获取数据包的“PackageID”字段，并检索转储库中的历史数据是否曾接收过。如已接收，则该数据包抛弃并返回错误，具体如下：

HTTP/1.1 200 OK Content-Type:text/xml;charset=utf-8 Content-Length:length{"status":0,//必须，状态，0-异常,1-正常,2-重复数据"message":"",//非必须，异常时的错误详细描述"resend":"N"//非必须.Y则表示当前数据包需要再次发送，反之应为N或""或无此字段}

（3）与目的系统关于数据订阅接口约定

1）响应数据包格式：目的系统在HTTP响应中即时数据处理结果，以下是HTTP响应示例。

HTTP/1.1 200 OK Content-Type:text/xml;charset=utf-8 Content-Length:length{"PackageID":"XXXXXXXXXX",//必须，当前处理的数据包ID"status":1 //必须，状态，0-异常,1-正常,2-重复数据"message":"",//非必须，异常时的错误详细描述。成功时可为""或无此字段"billid":"",//单据ID"billno":"",//单据编号"resend":"Y"//非必须.Y则表示当前数据包需要再次发送，反之应为N或""或无此字段}

2）处理失败重发Resend机制

A.ESB调用目的系统时，如HTTP调用成功（HTTPStatus=200），但由于目的系统原因无法成功处理且需要ESB再次发送数据的，目的系统将在返回信息中设置Resend=Y。

HTTP/1.1 200 OK Content-Type:text/xml;charset=utf-8 Content-Length:length{"PackageID":"XXXXXXXXXX",//必须，当前处理的数据包ID"status":0,"message":"…",//详细错误信息"billid":"",//单据ID"billno":"",//单据编号"resend":"Y"}

B.ESB对于Resend=Y的，当前作业将跳过此包继续发送下一个包。这一个数据包将在Resend时间间隔之后再次重发失败的数据；如Resend多次后仍然失败则不再发送此数据包。

C.ESB将对以下连接参数设计为每个接口可配置不同参数：Resend次数、Resend时间间隔。

D.对于数据顺序要求极高不允许跳包发送的，需要在接口设计时由源系统、目的系统及ESB三方协商确定。

3）发送失败重试Retry机制

A.如ESB调用目的系统HTTP调用失败（HTTP Status!=200）时，ESB将会再次发送直至N次失败后结束。

B.发送失败的数据不会被跳过，会在下次作业触发时或Resend时间间隔之后再次发送直至达到最大失败重试次数或直至成功。

C.ESB将对以下连接参数设计为每个接口可配置不同参数：HTTP连接信息、超时时长，失败重试次数、失败重试间隔。

D.对于业务时效性极高不允许发送过期数据的，需要在接口设计时由源系统、目的系统及ESB三方协商确定。

4）数据重复性校验机制

A.目的系统接收数据时需要先校验该数据包PackageID是否曾经接收/处理过。如已接收，则该数据包抛弃并返回错误，具体如下：

HTTP/1.1 200 OK Content-Type:text/xml;charset=utf-8 Content-Length:length{"status":0,"message":"重复数据"//或其他详细描述信息"message":"…",//详细错误信息"billid":"",//单据ID"billno":""//单据编号}

（4）与源系统关于数据处理结果返回接口的约定

ESB从目的系统获得数据处理返回结果后，将主动调用源系统发送数据处理结果。HTTP请求与目的系统返回ESB时一致。

1）响应数据包格式：源系统在HTTP响应中即时接收结果，以下是HTTP响应示例。

HTTP/1.1 200 OK Content-Type:text/xml;charset=utf-8 Content-Length:length{“status”:0,//必须，状态，0-异常,1-正常"message":"",//非必须，异常时的错误详细描述"resend":"Y"//非必须.Y则表示当前数据包需要再次发送，反之应为N或""或无此字段}

2）ESB将从目的系统获得的数据处理结果返回给源系统。但以下处理结果不发送：

A.失败重发的数据（"resend"："Y"）。

B.重复数据（"status"：2）。

3）处理失败重发Resend机制

A.ESB调用源系统时，如HTTP调用成功（HTTPStatus=200），但源系统异常无法成功记录返回状态信息的，源系统将在返回信息中设置Resend=Y。

HTTP/1.1 200 OK Content-Type:text/xml;charset=utf-8 Content-Length:length{"status":0,"message":"…",//详细错误信息，一般为JAVA/SQL抛出错误信息"resend":"Y"}

B.ESB对于Resend=Y的，当前作业将跳过此包继续发送下一个包。这一个数据包将在Resend时间间隔之后再次重发失败的数据；如Resend多次后仍然失败则不再发送此数据包。

C.建议调用方对以下连接参数设计为每个接口可配置不同参数：Resend次数、Resend时间间隔。

D.对于数据顺序要求极高不允许跳包发送的，需要在接口设计时由源系统、目的系统及ESB三方协商确定。

4）发送失败重试Retry机制

A.如ESB调用源系统 HTTP调用失败（HTTPStatus!=200）时，ESB将会尝试再次发送直至N次失败后结束。

B.发送失败的数据不会被跳过，会在下次作业触发时或Resend时间间隔之后再次发送直至达到最大失败重试次数或直至成功。

C.ESB将对以下连接参数设计为每个接口可配置不同参数：HTTP连接信息、超时时长，失败重试次数、失败重试间隔。

3 结束语

本文针对汽车制造企业的业务特点和信息化集成现状，提出基于数据内容路由的企业服务总线框架，该框架基于面向服务的思想、其松散耦合的体系架构和可重用的服务能为企业节约信息化管理成本。基于规则引擎的消息内容路由机制，使集成系统在面对同一服务调用需要跨越多个应用系统时，能更快地对业务规则变化做出及时的响应。在此框架基础上实现了汽车制造企业数据集成平台中的信息集成服务模块，能自动实现企业数据应用集成，相比传统的应用集成方式有明显优势。