顧 超
隨著國內(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í)行相應的流程從而重組織數(shù)據(jù),并通過BizTalk的內(nèi)部機制保證在應用崩潰時,可以做到數(shù)據(jù)恢復與緩存,保證數(shù)據(jù)不丟失;此外,在數(shù)據(jù)庫層面新系統(tǒng)通過用戶,角色,權限3者的關聯(lián)來解決操作的權限問題,通過ASP.NET的Web網(wǎng)頁來控制主數(shù)據(jù)以及業(yè)務數(shù)據(jù)的版本問題,同時還通過MOM來整體監(jiān)控BizTalk流程、打印程序以及數(shù)據(jù)庫的執(zhí)行情況??偟膩碚f本文研究的系統(tǒng)將是在原有系統(tǒng)上的一次飛躍,它將對柔性制造汽車行業(yè)的現(xiàn)場打印業(yè)務帶來一次革新。
BizTalk是微軟SOA戰(zhàn)略中非常重要的一個產(chǎn)品,它的產(chǎn)品定位是作為企業(yè)業(yè)務協(xié)同與數(shù)據(jù)交換的核心樞紐,是SOA架構解決方案的企業(yè)服務總線的重要產(chǎn)品。
隨著2000年 BizTalk Server 的問世,微軟就旨在引發(fā)了一場整合集成行業(yè)的革命,用以證明整合集成與過程自動化技術并不一定意味著價格昂貴和難以使用。今天,超過7,000家企業(yè)依靠 BizTalk Server 來進行全球供應鏈的系統(tǒng)集成和過程自動化。隨著第五個版本的發(fā)布,BizTalk Server 2006 R2構建與先前版本的業(yè)務流程管理和 SOA/ESB 功能基礎之上,并結合新功能如對電子數(shù)據(jù)交換(Electronic Data Interchange,EDI),AS2 和 RFID 的完全支持,以及與微軟 Office 2007和Windows Vista,包括關鍵的 .NET 框架技術如 Windows Workflow Foundation(WF) 和 Windows Communication Foundation(WCF)的緊密兼容,幫助組織機構增強核心流程管理能力[3][4][5]。
而BizTalk在本文所述打印系統(tǒng)中亦處在一個核心的位置,下文將從部署方式、上下游系統(tǒng)接口以及BizTalk流程本身進行進一步的分析。
BizTalk應用都是企業(yè)級應用,對可用性要求比較高,如同之前已經(jīng)介紹的對于此次的現(xiàn)場打印系統(tǒng)來說更是如此,所以,BizTalk的高可用部署是十分重要和必要的。而BizTalk本身的部署方式有很多種:
1) 沒有高可用能力的,不可用于生產(chǎn)環(huán)境的部署:測試環(huán)境常用的單服務器方案(在一臺服務器上安裝BizTalk、BizTalk數(shù)據(jù)庫和所有相關組件),以及最為簡單的雙服務器方案(在一臺服務器上安裝 BizTalk、另一臺服務器上安裝BizTalk數(shù)據(jù)庫)
2) 基本的高可用性:BizTalk Group方案(所有BizTalk Server都加入到同一個group,一個group共享一套相關的數(shù)據(jù)庫)以及BizTalk cluster方案(兩臺服務器上的host instance不要同時運行,正常時候一臺服務器的 host instance運行,這臺服務器宕機后,能夠自動切換到另一臺的服務器的host instance)
3) 大規(guī)模的高可用性:對于大并發(fā)量關鍵系統(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就會只運行在一臺服務器上,另外一臺服務器上的host instance會在第一臺服務器宕機后自動切換。
1.2.1 SOA的意義
如同之前介紹,BizTalk作為微軟SOA戰(zhàn)略的重要產(chǎn)品,因此,理解SOA的概念對于更好地利用BizTalk也就變得相當有意義。SOA與大多數(shù)通用的客戶端/服務器模型的不同之處,在于它著重強調(diào)軟件組件的松散耦合,并使用獨立的標準接口?!盨OA有這樣幾個關鍵特性:一種粗粒度、松耦合服務架構,服務之間通過簡單、精確定義接口進行通訊,不涉及底層編程接口和通訊模型。或許在本論文討論的打印系統(tǒng)中,BizTalk還未完全將SOA的這些特性展現(xiàn)出來,但是對于作為最基礎的接口通迅,或者說企業(yè)內(nèi)部的系統(tǒng)集成,BizTalk已經(jīng)將其優(yōu)勢淋漓盡致地展現(xiàn)出來了。
首先看一下本文論述的汽車行業(yè)現(xiàn)場打印系統(tǒng)的邏輯架構,如圖2所示:
圖2 打印系統(tǒng)邏輯架構
整個打印系統(tǒng)的核心或者說系統(tǒng)領域就在 3根虛線框內(nèi):左側的BizTalk Server(雙節(jié)點組成Cluster),右上側的Database Server(雙節(jié)點Cluster),以及右下方的Print Control Server(雙節(jié)點 Cluster)。
而外圍的設備、服務、系統(tǒng)都是整個打印系統(tǒng)的上下游,本文將著重針對BizTalk從上至下,對整個系統(tǒng)的邏輯架構以及數(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è)務需求,進行相應的數(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,上游的處理已告完畢。
正如之前多次強調(diào)的,此次BizTalk構建的是一個工業(yè)級別的現(xiàn)場打印系統(tǒng),良好的實時性、高可復用性以及消息處理的性能都非常重要,此外當系統(tǒng)發(fā)生宕機時,需要多少時間進行恢復,也是系統(tǒng)性能的重要考量。下面我們將就這兩點進行分析:
與對于汽車行業(yè)的現(xiàn)場來說,每輛車要將近打印40輛不同的單據(jù),而每小時有大約45-60輛車的單據(jù)需要打印。BizTalk應用對于這些數(shù)據(jù)的處理能力也是整個系統(tǒng)的關鍵所在,經(jīng)過測試,BizTalk在每輛車40張單的情況下,支持平均每小時150JPH,峰值每小時300JPH。即峰值為每小時12000張單據(jù)的打印。而各類消息的大小以及處理時間如下:
各類消息的大?。?/p>
L類(隨車的標簽等)、M類(裝車單等)消息:1kb
R類(物料排序單等)消息:1-2kb
C類(與車型配置有關的單據(jù)等) 消息:1kb
各類消息的處理時間:
L類(隨車的標簽等)、M類(裝車單等)消息:2-3秒
R類(物料排序單等)消息:2-3秒
C類(與車型配置有關的單據(jù)等) 消息:4秒
假要討論系統(tǒng)宕機時的恢復時間,首先要知道系統(tǒng)宕機時BizTalk做了些什么。BizTalk在宕機時的處理機制如下:
(1) Offline時BizTalk消息處理機制
關閉接收上游消息的端口
關閉主流程
關閉子流程
關閉發(fā)送端口
(2) Online時BizTalk消息處理機制
開啟發(fā)送端口
開啟子流程
開啟主流程
開啟接收上游消息的端口
(3) 而這些步驟所花費的時間大致如下:
Offline節(jié)點所花時間:1-2分鐘
關閉各個資源所花時間:<=1秒
Online節(jié)點所花時間:1-2分鐘
關閉各個資源所花時間:<=1秒
總體來說,BizTalk在宕機時可能會需要2-5分鐘進行恢復,由于現(xiàn)場打印的觸發(fā)到打印是留有緩沖與余量的,因此2-5分鐘的宕機時間是可以被接受的。
除了上述的BizTalk消息處理能力、宕機恢復時間外,還有些其它的性能問題。
對于BizTalk處理的實時性來說,根據(jù)SRS文檔當中的數(shù)據(jù)需求,REALIME類型單據(jù),系統(tǒng)處理時間,即從本系統(tǒng)接口接收到數(shù)據(jù)、對數(shù)據(jù)進行處理、并將處理后的數(shù)據(jù)推到打印機的整個時間不能超過20秒。NORMAL單據(jù)整個時間不能超過15分鐘[10]。
而在此應用中BizTalk的多通道設計也對性能帶來了優(yōu)勢,對于打印單據(jù)必須順序處理,同種類型的單據(jù)不能并發(fā)執(zhí)行,所以在系統(tǒng)的設計過程當中,設計多個通道對不同類型的單據(jù)可以進行并行處理。針對 Realtime, Normal和Batch3種類型的表單打印,都有專門的通道進行處理,使得三者可以并發(fā)執(zhí)行,不會相互影響。
隨著國內(nèi)汽車業(yè)的蓬勃發(fā)展,柔性制造的概念必將逐漸被越來越多的整車廠所接受,從而帶來的業(yè)務與需求變化,必將不斷挑戰(zhàn)現(xiàn)有的IT系統(tǒng),而本文嘗試用BizTalk這一產(chǎn)品去構建柔性制造前提下的打印系統(tǒng),也僅僅是在這個可以預見的變革浪潮中的一小步探索。實際上,BizTalk的作用不僅僅于此,對于制造行業(yè)供應鏈乃至售前售后鏈,BizTalk都可用做整車廠與供應商、經(jīng)銷商以及維修站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操作系統(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