顾 超

0 引言

随着国内汽车行业的蓬勃发展，传统的按库存生产已经无法满足各个整车厂的需求，随之而来的按订单生产与按订单定位等概念，都已经被国内先进的汽车制造公司实现。

本文试图探索的方法是通过 Microsoft的产品 BizTalk整合整个打印流程，保证打印队列的时序，同时集成上游数据接口，对不同种类的数据执行相应的流程从而重组织数据，并通过BizTalk的内部机制保证在应用崩溃时，可以做到数据恢复与缓存，保证数据不丢失；此外，在数据库层面新系统通过用户，角色，权限3者的关联来解决操作的权限问题，通过ASP.NET的Web网页来控制主数据以及业务数据的版本问题，同时还通过MOM来整体监控BizTalk流程、打印程序以及数据库的执行情况。总的来说本文研究的系统将是在原有系统上的一次飞跃，它将对柔性制造汽车行业的现场打印业务带来一次革新。

1 BizTalk在打印系统中的应用[1][2]

BizTalk是微软SOA战略中非常重要的一个产品，它的产品定位是作为企业业务协同与数据交换的核心枢纽，是SOA架构解决方案的企业服务总线的重要产品。

随着2000年 BizTalk Server 的问世，微软就旨在引发了一场整合集成行业的革命，用以证明整合集成与过程自动化技术并不一定意味着价格昂贵和难以使用。今天，超过7,000家企业依靠 BizTalk Server 来进行全球供应链的系统集成和过程自动化。随着第五个版本的发布，BizTalk Server 2006 R2构建与先前版本的业务流程管理和 SOA/ESB 功能基础之上，并结合新功能如对电子数据交换（Electronic Data Interchange，EDI），AS2 和 RFID 的完全支持，以及与微软 Office 2007和Windows Vista，包括关键的 .NET 框架技术如 Windows Workflow Foundation(WF) 和 Windows Communication Foundation(WCF)的紧密兼容，帮助组织机构增强核心流程管理能力[3][4][5]。

而BizTalk在本文所述打印系统中亦处在一个核心的位置，下文将从部署方式、上下游系统接口以及BizTalk流程本身进行进一步的分析。

1.1 BizTalk的部署[8]

BizTalk应用都是企业级应用，对可用性要求比较高，如同之前已经介绍的对于此次的现场打印系统来说更是如此，所以，BizTalk的高可用部署是十分重要和必要的。而BizTalk本身的部署方式有很多种：

1） 没有高可用能力的，不可用于生产环境的部署：测试环境常用的单服务器方案（在一台服务器上安装BizTalk、BizTalk数据库和所有相关组件），以及最为简单的双服务器方案（在一台服务器上安装 BizTalk、另一台服务器上安装BizTalk数据库）

2） 基本的高可用性：BizTalk Group方案（所有BizTalk Server都加入到同一个group，一个group共享一套相关的数据库）以及BizTalk cluster方案（两台服务器上的host instance不要同时运行，正常时候一台服务器的 host instance运行，这台服务器宕机后，能够自动切换到另一台的服务器的host instance）

3） 大规模的高可用性：对于大并发量关键系统度身定做的兼容了BizTalk Group与BizTalk Cluster方案的部署方式。

而此次探究的打印系统由于并发量有限，因此选用了BizTalk Cluster的方案，如图1所示：

图1 BizTalk Cluster方案的部署方式

BizTalk支持 windows cluster，可以把 host宿主作为windows cluster的资源加入到cluster，这样这个host的host instance就会只运行在一台服务器上，另外一台服务器上的host instance会在第一台服务器宕机后自动切换。

1.2 BizTalk在打印系统中的逻辑位置[6][7]

1.2.1 SOA的意义

如同之前介绍，BizTalk作为微软SOA战略的重要产品，因此，理解SOA的概念对于更好地利用BizTalk也就变得相当有意义。SOA与大多数通用的客户端/服务器模型的不同之处，在于它着重强调软件组件的松散耦合，并使用独立的标准接口。”SOA有这样几个关键特性：一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。或许在本论文讨论的打印系统中，BizTalk还未完全将SOA的这些特性展现出来，但是对于作为最基础的接口通迅，或者说企业内部的系统集成，BizTalk已经将其优势淋漓尽致地展现出来了。

首先看一下本文论述的汽车行业现场打印系统的逻辑架构，如图2所示：

图2 打印系统逻辑架构

整个打印系统的核心或者说系统领域就在 3根虚线框内：左侧的BizTalk Server（双节点组成Cluster），右上侧的Database Server（双节点Cluster），以及右下方的Print Control Server（双节点 Cluster）。

而外围的设备、服务、系统都是整个打印系统的上下游，本文将着重针对BizTalk从上至下，对整个系统的逻辑架构以及数据流程进行完整的描述。

1.2.2 上游数据的接受：BizTalk Adapter[9]

本文所论述的打印系统，有一个最为重要的上游系统：生产制造系统，该系统拥有了几乎所有的车辆信息（包括车辆的订单信息、配置信息以及制造信息），而打印系统正是从该系统，接受不同的数据根据业务需求，进行相应的数据分发以及打印工作。由于该生产制造系统有其特殊性，其系统的传输方式都是自定义的，根据传输方式的不同，打印系统接受到的消息分为两种：SFE消息与BSJ消息，而归根到底打印系统接受到的都是平文件，只是因为上游系统，必须通过既定的接口程序，去传输消息，使得消息看上去有所区别。而BizTalk Server为了接受消息，都会通过数据适配器进行数据的接受，BizTalk自定义了一系列常用的数据适配器，比如SQL Adapter，WCF Adapter等，同时BizTalk也允许开发者开发自定义的数据适配器，针对上游系统的特殊性，打印系统定制了两个数据适配器：SFE Adapter以及BSJ Adapter，这两个适配器，使用C#将上游系统的规定接口性进行了封装，作为黑盒存在于系统中。可以简单的这么理解：打印系统通过C#实现了BizTalk的adapter，而又在底一层的代码上，用C++实现了Socket连接，即在C++的代码中，调用了上游系统规定的接口（SFE或BSJ接口给出的dll程序集），从而实现了socket连接。

BizTalk的数据适配器，在接受到上游系统的消息后，会先将消息经过接受管道，做一些简单的解析工作，同时，会将上游的平文消息转换成 BizTalk内部通讯的格式---XML，而此后转换后的XML消息，会被发送至BizTalk自带的数据库中（Message Box）。

至此，从上游数据的下发，一直到数据转换成XML发布到Message Box，上游的处理已告完毕。

2 BizTalk消息处理的性能与机制[4][5]

正如之前多次强调的，此次BizTalk构建的是一个工业级别的现场打印系统，良好的实时性、高可复用性以及消息处理的性能都非常重要，此外当系统发生宕机时，需要多少时间进行恢复，也是系统性能的重要考量。下面我们将就这两点进行分析：

2.1 BizTalk消息处理能力

与对于汽车行业的现场来说，每辆车要将近打印40辆不同的单据，而每小时有大约45-60辆车的单据需要打印。BizTalk应用对于这些数据的处理能力也是整个系统的关键所在，经过测试，BizTalk在每辆车40张单的情况下，支持平均每小时150JPH，峰值每小时300JPH。即峰值为每小时12000张单据的打印。而各类消息的大小以及处理时间如下：

各类消息的大小：

L类(随车的标签等)、M类(装车单等)消息：1kb

R类(物料排序单等)消息：1-2kb

C类(与车型配置有关的单据等) 消息：1kb

各类消息的处理时间:

L类(随车的标签等)、M类(装车单等)消息：2-3秒

R类(物料排序单等)消息：2-3秒

C类(与车型配置有关的单据等) 消息：4秒

2.2 BizTalk宕机时的恢复时间

假要讨论系统宕机时的恢复时间，首先要知道系统宕机时BizTalk做了些什么。BizTalk在宕机时的处理机制如下：

(1) Offline时BizTalk消息处理机制

关闭接收上游消息的端口

关闭主流程

关闭子流程

关闭发送端口

(2) Online时BizTalk消息处理机制

开启发送端口

开启子流程

开启主流程

开启接收上游消息的端口

(3) 而这些步骤所花费的时间大致如下：

Offline节点所花时间：1-2分钟

关闭各个资源所花时间：<=1秒

Online节点所花时间：1-2分钟

关闭各个资源所花时间：<=1秒

总体来说，BizTalk在宕机时可能会需要2-5分钟进行恢复，由于现场打印的触发到打印是留有缓冲与余量的，因此2-5分钟的宕机时间是可以被接受的。

2.3 BizTalk其它性能指标

除了上述的BizTalk消息处理能力、宕机恢复时间外，还有些其它的性能问题。

对于BizTalk处理的实时性来说，根据SRS文档当中的数据需求，REALIME类型单据，系统处理时间，即从本系统接口接收到数据、对数据进行处理、并将处理后的数据推到打印机的整个时间不能超过20秒。NORMAL单据整个时间不能超过15分钟[10]。

而在此应用中BizTalk的多通道设计也对性能带来了优势，对于打印单据必须顺序处理，同种类型的单据不能并发执行，所以在系统的设计过程当中，设计多个通道对不同类型的单据可以进行并行处理。针对 Realtime, Normal和Batch3种类型的表单打印，都有专门的通道进行处理，使得三者可以并发执行，不会相互影响。

3 结论

随着国内汽车业的蓬勃发展，柔性制造的概念必将逐渐被越来越多的整车厂所接受，从而带来的业务与需求变化，必将不断挑战现有的IT系统，而本文尝试用BizTalk这一产品去构建柔性制造前提下的打印系统，也仅仅是在这个可以预见的变革浪潮中的一小步探索。实际上，BizTalk的作用不仅仅于此，对于制造行业供应链乃至售前售后链，BizTalk都可用做整车厂与供应商、经销商以及维修站4S店的交互工具，而这一切都需要不断地去探索与尝试，从而探究出更合理更强健的解决方案[11]。

[1]Benny Nerium，ASP.NET MVC Framework 系列，[j]ASP.NET，2008年3月.

[2]Jeffrey Richer，.Net框架程序设计，.[j]Net，2006年9月.

[3]Mark E.Russinovich, David A.Solomon，深入解析Windows操作系统，[j]操作系统，2004年3月.

[4]Joseph Bustos, Karili Watson, Beginning .[M]NET Web Service Using C#,2003.

[5]Kevin Hoffman, Lonny Kruger, [M]Microsoft Visual C# .NET 2003 Unleashed,2006.

[6]Juval Lowy, Programming WCF Service, [G]WCF, 2009.

[7]Thomas H.Cormen, Introduction To Algorithms, [C]Algorithm, 2007

[8]chnking, biztalk大规模高性能高可用部署方案, [ol]http://www.cnblogs.com/chnking/archive/2011/04/26/2029678.html,BizTalk, July 2010.

[9]chnking, biztalk中使用biztalk adapter Pack适配器之一[ol]WCF-SQL,BizTalk,http://www.cnblogs.com/chnking/archive/2010/05/09/1731098.html ,January 2010

[10]Craig Larman, Applying UML and Patterns, [C]UML,Feb 2007.

[11]彭俊松，汽车行业整车订单交付系统，[M]北京，电子工业出版社，2009