使用BizTalk構(gòu)建汽車行業(yè)現(xiàn)場打印系統(tǒng)

顧 超

0 引言

隨著國內(nèi)汽車行業(yè)的蓬勃發(fā)展，傳統(tǒng)的按庫存生產(chǎn)已經(jīng)無法滿足各個整車廠的需求，隨之而來的按訂單生產(chǎn)與按訂單定位等概念，都已經(jīng)被國內(nèi)先進的汽車制造公司實現(xiàn)。

本文試圖探索的方法是通過 Microsoft的產(chǎn)品 BizTalk整合整個打印流程，保證打印隊列的時序，同時集成上游數(shù)據(jù)接口，對不同種類的數(shù)據(jù)執(zhí)行相應(yīng)的流程從而重組織數(shù)據(jù)，并通過BizTalk的內(nèi)部機制保證在應(yīng)用崩潰時，可以做到數(shù)據(jù)恢復(fù)與緩存，保證數(shù)據(jù)不丟失；此外，在數(shù)據(jù)庫層面新系統(tǒng)通過用戶，角色，權(quán)限3者的關(guān)聯(lián)來解決操作的權(quán)限問題，通過ASP.NET的Web網(wǎng)頁來控制主數(shù)據(jù)以及業(yè)務(wù)數(shù)據(jù)的版本問題，同時還通過MOM來整體監(jiān)控BizTalk流程、打印程序以及數(shù)據(jù)庫的執(zhí)行情況。總的來說本文研究的系統(tǒng)將是在原有系統(tǒng)上的一次飛躍，它將對柔性制造汽車行業(yè)的現(xiàn)場打印業(yè)務(wù)帶來一次革新。

1 BizTalk在打印系統(tǒng)中的應(yīng)用[1][2]

BizTalk是微軟SOA戰(zhàn)略中非常重要的一個產(chǎn)品，它的產(chǎn)品定位是作為企業(yè)業(yè)務(wù)協(xié)同與數(shù)據(jù)交換的核心樞紐，是SOA架構(gòu)解決方案的企業(yè)服務(wù)總線的重要產(chǎn)品。

隨著2000年 BizTalk Server 的問世，微軟就旨在引發(fā)了一場整合集成行業(yè)的革命，用以證明整合集成與過程自動化技術(shù)并不一定意味著價格昂貴和難以使用。今天，超過7,000家企業(yè)依靠 BizTalk Server 來進行全球供應(yīng)鏈的系統(tǒng)集成和過程自動化。隨著第五個版本的發(fā)布，BizTalk Server 2006 R2構(gòu)建與先前版本的業(yè)務(wù)流程管理和 SOA/ESB 功能基礎(chǔ)之上，并結(jié)合新功能如對電子數(shù)據(jù)交換（Electronic Data Interchange，EDI），AS2 和 RFID 的完全支持，以及與微軟 Office 2007和Windows Vista，包括關(guān)鍵的 .NET 框架技術(shù)如 Windows Workflow Foundation(WF) 和 Windows Communication Foundation(WCF)的緊密兼容，幫助組織機構(gòu)增強核心流程管理能力[3][4][5]。

而BizTalk在本文所述打印系統(tǒng)中亦處在一個核心的位置，下文將從部署方式、上下游系統(tǒng)接口以及BizTalk流程本身進行進一步的分析。

1.1 BizTalk的部署[8]

BizTalk應(yīng)用都是企業(yè)級應(yīng)用，對可用性要求比較高，如同之前已經(jīng)介紹的對于此次的現(xiàn)場打印系統(tǒng)來說更是如此，所以，BizTalk的高可用部署是十分重要和必要的。而BizTalk本身的部署方式有很多種：

1） 沒有高可用能力的，不可用于生產(chǎn)環(huán)境的部署：測試環(huán)境常用的單服務(wù)器方案（在一臺服務(wù)器上安裝BizTalk、BizTalk數(shù)據(jù)庫和所有相關(guān)組件），以及最為簡單的雙服務(wù)器方案（在一臺服務(wù)器上安裝 BizTalk、另一臺服務(wù)器上安裝BizTalk數(shù)據(jù)庫）

2） 基本的高可用性：BizTalk Group方案（所有BizTalk Server都加入到同一個group，一個group共享一套相關(guān)的數(shù)據(jù)庫）以及BizTalk cluster方案（兩臺服務(wù)器上的host instance不要同時運行，正常時候一臺服務(wù)器的 host instance運行，這臺服務(wù)器宕機后，能夠自動切換到另一臺的服務(wù)器的host instance）

3） 大規(guī)模的高可用性：對于大并發(fā)量關(guān)鍵系統(tǒng)度身定做的兼容了BizTalk Group與BizTalk Cluster方案的部署方式。

而此次探究的打印系統(tǒng)由于并發(fā)量有限，因此選用了BizTalk Cluster的方案，如圖1所示：

圖1 BizTalk Cluster方案的部署方式

BizTalk支持 windows cluster，可以把 host宿主作為windows cluster的資源加入到cluster，這樣這個host的host instance就會只運行在一臺服務(wù)器上，另外一臺服務(wù)器上的host instance會在第一臺服務(wù)器宕機后自動切換。

1.2 BizTalk在打印系統(tǒng)中的邏輯位置[6][7]

1.2.1 SOA的意義

如同之前介紹，BizTalk作為微軟SOA戰(zhàn)略的重要產(chǎn)品，因此，理解SOA的概念對于更好地利用BizTalk也就變得相當有意義。SOA與大多數(shù)通用的客戶端/服務(wù)器模型的不同之處，在于它著重強調(diào)軟件組件的松散耦合，并使用獨立的標準接口。”SOA有這樣幾個關(guān)鍵特性：一種粗粒度、松耦合服務(wù)架構(gòu)，服務(wù)之間通過簡單、精確定義接口進行通訊，不涉及底層編程接口和通訊模型。或許在本論文討論的打印系統(tǒng)中，BizTalk還未完全將SOA的這些特性展現(xiàn)出來，但是對于作為最基礎(chǔ)的接口通迅，或者說企業(yè)內(nèi)部的系統(tǒng)集成，BizTalk已經(jīng)將其優(yōu)勢淋漓盡致地展現(xiàn)出來了。

首先看一下本文論述的汽車行業(yè)現(xiàn)場打印系統(tǒng)的邏輯架構(gòu)，如圖2所示：

圖2 打印系統(tǒng)邏輯架構(gòu)

整個打印系統(tǒng)的核心或者說系統(tǒng)領(lǐng)域就在 3根虛線框內(nèi)：左側(cè)的BizTalk Server（雙節(jié)點組成Cluster），右上側(cè)的Database Server（雙節(jié)點Cluster），以及右下方的Print Control Server（雙節(jié)點 Cluster）。

而外圍的設(shè)備、服務(wù)、系統(tǒng)都是整個打印系統(tǒng)的上下游，本文將著重針對BizTalk從上至下，對整個系統(tǒng)的邏輯架構(gòu)以及數(shù)據(jù)流程進行完整的描述。

1.2.2 上游數(shù)據(jù)的接受：BizTalk Adapter[9]

本文所論述的打印系統(tǒng)，有一個最為重要的上游系統(tǒng)：生產(chǎn)制造系統(tǒng)，該系統(tǒng)擁有了幾乎所有的車輛信息（包括車輛的訂單信息、配置信息以及制造信息），而打印系統(tǒng)正是從該系統(tǒng)，接受不同的數(shù)據(jù)根據(jù)業(yè)務(wù)需求，進行相應(yīng)的數(shù)據(jù)分發(fā)以及打印工作。由于該生產(chǎn)制造系統(tǒng)有其特殊性，其系統(tǒng)的傳輸方式都是自定義的，根據(jù)傳輸方式的不同，打印系統(tǒng)接受到的消息分為兩種：SFE消息與BSJ消息，而歸根到底打印系統(tǒng)接受到的都是平文件，只是因為上游系統(tǒng)，必須通過既定的接口程序，去傳輸消息，使得消息看上去有所區(qū)別。而BizTalk Server為了接受消息，都會通過數(shù)據(jù)適配器進行數(shù)據(jù)的接受，BizTalk自定義了一系列常用的數(shù)據(jù)適配器，比如SQL Adapter，WCF Adapter等，同時BizTalk也允許開發(fā)者開發(fā)自定義的數(shù)據(jù)適配器，針對上游系統(tǒng)的特殊性，打印系統(tǒng)定制了兩個數(shù)據(jù)適配器：SFE Adapter以及BSJ Adapter，這兩個適配器，使用C#將上游系統(tǒng)的規(guī)定接口性進行了封裝，作為黑盒存在于系統(tǒng)中。可以簡單的這么理解：打印系統(tǒng)通過C#實現(xiàn)了BizTalk的adapter，而又在底一層的代碼上，用C++實現(xiàn)了Socket連接，即在C++的代碼中，調(diào)用了上游系統(tǒng)規(guī)定的接口（SFE或BSJ接口給出的dll程序集），從而實現(xiàn)了socket連接。

BizTalk的數(shù)據(jù)適配器，在接受到上游系統(tǒng)的消息后，會先將消息經(jīng)過接受管道，做一些簡單的解析工作，同時，會將上游的平文消息轉(zhuǎn)換成 BizTalk內(nèi)部通訊的格式---XML，而此后轉(zhuǎn)換后的XML消息，會被發(fā)送至BizTalk自帶的數(shù)據(jù)庫中（Message Box）。

至此，從上游數(shù)據(jù)的下發(fā)，一直到數(shù)據(jù)轉(zhuǎn)換成XML發(fā)布到Message Box，上游的處理已告完畢。

2 BizTalk消息處理的性能與機制[4][5]

正如之前多次強調(diào)的，此次BizTalk構(gòu)建的是一個工業(yè)級別的現(xiàn)場打印系統(tǒng)，良好的實時性、高可復(fù)用性以及消息處理的性能都非常重要，此外當系統(tǒng)發(fā)生宕機時，需要多少時間進行恢復(fù)，也是系統(tǒng)性能的重要考量。下面我們將就這兩點進行分析：

2.1 BizTalk消息處理能力

與對于汽車行業(yè)的現(xiàn)場來說，每輛車要將近打印40輛不同的單據(jù)，而每小時有大約45-60輛車的單據(jù)需要打印。BizTalk應(yīng)用對于這些數(shù)據(jù)的處理能力也是整個系統(tǒng)的關(guān)鍵所在，經(jīng)過測試，BizTalk在每輛車40張單的情況下，支持平均每小時150JPH，峰值每小時300JPH。即峰值為每小時12000張單據(jù)的打印。而各類消息的大小以及處理時間如下：

各類消息的大小：

L類(隨車的標簽等)、M類(裝車單等)消息：1kb

R類(物料排序單等)消息：1-2kb

C類(與車型配置有關(guān)的單據(jù)等) 消息：1kb

各類消息的處理時間:

L類(隨車的標簽等)、M類(裝車單等)消息：2-3秒

R類(物料排序單等)消息：2-3秒

C類(與車型配置有關(guān)的單據(jù)等) 消息：4秒

2.2 BizTalk宕機時的恢復(fù)時間

假要討論系統(tǒng)宕機時的恢復(fù)時間，首先要知道系統(tǒng)宕機時BizTalk做了些什么。BizTalk在宕機時的處理機制如下：

(1) Offline時BizTalk消息處理機制

關(guān)閉接收上游消息的端口

關(guān)閉主流程

關(guān)閉子流程

關(guān)閉發(fā)送端口

(2) Online時BizTalk消息處理機制

開啟發(fā)送端口

開啟子流程

開啟主流程

開啟接收上游消息的端口

(3) 而這些步驟所花費的時間大致如下：

Offline節(jié)點所花時間：1-2分鐘

關(guān)閉各個資源所花時間：<=1秒

Online節(jié)點所花時間：1-2分鐘

關(guān)閉各個資源所花時間：<=1秒

總體來說，BizTalk在宕機時可能會需要2-5分鐘進行恢復(fù)，由于現(xiàn)場打印的觸發(fā)到打印是留有緩沖與余量的，因此2-5分鐘的宕機時間是可以被接受的。

2.3 BizTalk其它性能指標

除了上述的BizTalk消息處理能力、宕機恢復(fù)時間外，還有些其它的性能問題。

對于BizTalk處理的實時性來說，根據(jù)SRS文檔當中的數(shù)據(jù)需求，REALIME類型單據(jù)，系統(tǒng)處理時間，即從本系統(tǒng)接口接收到數(shù)據(jù)、對數(shù)據(jù)進行處理、并將處理后的數(shù)據(jù)推到打印機的整個時間不能超過20秒。NORMAL單據(jù)整個時間不能超過15分鐘[10]。

而在此應(yīng)用中BizTalk的多通道設(shè)計也對性能帶來了優(yōu)勢，對于打印單據(jù)必須順序處理，同種類型的單據(jù)不能并發(fā)執(zhí)行，所以在系統(tǒng)的設(shè)計過程當中，設(shè)計多個通道對不同類型的單據(jù)可以進行并行處理。針對 Realtime, Normal和Batch3種類型的表單打印，都有專門的通道進行處理，使得三者可以并發(fā)執(zhí)行，不會相互影響。

3 結(jié)論

隨著國內(nèi)汽車業(yè)的蓬勃發(fā)展，柔性制造的概念必將逐漸被越來越多的整車廠所接受，從而帶來的業(yè)務(wù)與需求變化，必將不斷挑戰(zhàn)現(xiàn)有的IT系統(tǒng)，而本文嘗試用BizTalk這一產(chǎn)品去構(gòu)建柔性制造前提下的打印系統(tǒng)，也僅僅是在這個可以預(yù)見的變革浪潮中的一小步探索。實際上，BizTalk的作用不僅僅于此，對于制造行業(yè)供應(yīng)鏈乃至售前售后鏈，BizTalk都可用做整車廠與供應(yīng)商、經(jīng)銷商以及維修站4S店的交互工具，而這一切都需要不斷地去探索與嘗試，從而探究出更合理更強健的解決方案[11]。

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

[2]Jeffrey Richer，.Net框架程序設(shè)計，.[j]Net，2006年9月.

[3]Mark E.Russinovich, David A.Solomon，深入解析Windows操作系統(tǒng)，[j]操作系統(tǒng)，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大規(guī)模高性能高可用部署方案, [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]彭俊松，汽車行業(yè)整車訂單交付系統(tǒng)，[M]北京，電子工業(yè)出版社，2009