SPDM系統(tǒng)與其他系統(tǒng)數(shù)據(jù)集成技術選型

陸 琦，肖 峰

（滬東中華造船（集團）有限公司，上海 200136）

0 引言

SPDM集成的數(shù)據(jù)主要分為2部分：1）從上游船舶設計軟件集成設計數(shù)據(jù)；2）向下游企業(yè)資源計劃系統(tǒng)（Enterprise Resource Planning，ERP），計劃管理系統(tǒng)，制造執(zhí)行系統(tǒng)（Manufacturing Execution System，MES）下達各種設計和制造的相關數(shù)據(jù)。從上游船舶設計系統(tǒng)集成的數(shù)據(jù)主要包括產(chǎn)品的各個專業(yè)的零部件結構和零部件信息、焊縫信息、套料余料信息、物量信息、圖紙信息以及材料信息等；向下游系統(tǒng)下發(fā)的信息主要有圖紙目錄信息、各個專業(yè)的按托盤劃分的零部件及材料信息、采購需求信息、物料定額信息以及圖紙計劃信息等。

1 集成方式選擇

數(shù)據(jù)的集成通常有通過接口訪問對方數(shù)據(jù)、直接訪問對方數(shù)據(jù)表和將對方數(shù)據(jù)獲取后在自身系統(tǒng)中構建數(shù)據(jù)等幾種模式[1]。由于SPDM系統(tǒng)集成的系統(tǒng)較多，對數(shù)據(jù)的需求也有差異，存放數(shù)據(jù)的方式也不同。因此，采取將對方數(shù)據(jù)獲取后在自身系統(tǒng)構建數(shù)據(jù)的模式，即SPD數(shù)據(jù)發(fā)送給SPDM后，SPDM 按自身需要在 SPDM 系統(tǒng)中構建數(shù)據(jù)。SPDM將數(shù)據(jù)發(fā)送給其他系統(tǒng)，其他系統(tǒng)也按他們的要求在各自系統(tǒng)中構建數(shù)據(jù)。

系統(tǒng)間的數(shù)據(jù)交換，通?？梢酝ㄟ^事件驅動或人工驅動[1]?？紤]到數(shù)據(jù)的及時性和完整性，以及SPDM系統(tǒng)的特點，SPDM數(shù)據(jù)交換的方式主要采用了手動驅動和流程驅動 2種方式。上游系統(tǒng)向SPDM系統(tǒng)發(fā)送數(shù)據(jù)和SPDM框架性的數(shù)據(jù)下發(fā)采用了手動驅動的方式，如：SPD系統(tǒng)向SPDM發(fā)送數(shù)據(jù)，采用了手動點擊數(shù)據(jù)提交的方式。圖紙目錄、托盤目錄、設備目錄等框架性的數(shù)據(jù)也采用手動發(fā)送的方式。SPDM系統(tǒng)向下游系統(tǒng)發(fā)送數(shù)據(jù)，多采用流程驅動方式下發(fā)，如文檔審簽和發(fā)布情況、清單數(shù)據(jù)的下發(fā)以及物量數(shù)據(jù)的下發(fā)等。

由于上游系統(tǒng)的數(shù)據(jù)集成開始時間無法通過事件確定，圖紙目錄、托盤目錄、設備目錄等框架性的數(shù)據(jù)通常管理人員比較固定，且不需要審批，因此，采用手動發(fā)送的方式有利于設計人員和設計管理人員控制發(fā)送時機，也符合各自的管理要求。在使用過程中，這種模式得到了用戶的認可。而SPDM系統(tǒng)數(shù)據(jù)的狀態(tài)變化，都是通過流程驅動的。因此，采用流程驅動的方式觸發(fā)數(shù)據(jù)集成，杜絕了人工干預過程，大大減少了用戶的工作量，同時提高了數(shù)據(jù)流轉的及時性和有效性，使得設計人員的工作更為專注，得到了用戶的好評。

2 集成技術選型

本文采用系統(tǒng)間數(shù)據(jù)分離的集成方式，這主要涉及數(shù)據(jù)交換技術的選型和大數(shù)據(jù)傳遞的處理技術。數(shù)據(jù)交換技術選型主要涉及交換數(shù)據(jù)格式的選型和接口技術選型。大數(shù)據(jù)傳遞的處理技術主要通過隊列技術完成。

2.1 交換數(shù)據(jù)格式

交換數(shù)據(jù)格式目前主要采用XML和JSON 2種格式。

XML可擴展標記語言（標準通用標記語言的子集）是一種簡單的數(shù)據(jù)存儲語言。使用一系列簡單的標記描述數(shù)據(jù)，而這些標記可以用方便的方式建立。雖然相較二進制數(shù)據(jù)要占用更多的空間，但可擴展標記語言極其簡單、易于掌握和使用。雖然設計軟件集成的數(shù)據(jù)需要比較強的可讀性，設計軟件種類繁多（比如 SPD，TRIBON，CATIA等），且其使用的開發(fā)語言也各有不同，但是操作 XML的功能都是比較完善的。因此，SPDM 系統(tǒng)采用XML格式作為數(shù)據(jù)集成的格式。

JS對象簡譜（JavaScript Object Notation，JSON）是一種輕量級的數(shù)據(jù)交換格式。它基于ECMAScript（歐洲計算機協(xié)會制定的JS規(guī)范）的一個子集，采用完全獨立于編程語言的文本格式來存儲和表示數(shù)據(jù)。簡潔和清晰的層次結構使得JSON成為理想的數(shù)據(jù)交換語言，易于閱讀和編寫，同時也易于機器解析和生成，并可有效地提升網(wǎng)絡傳輸效率[2]。SPDM系統(tǒng)采用JSON格式作為與下游的管理軟件進行數(shù)據(jù)集成的格式，因為近幾年JSON格式在軟件配置，數(shù)據(jù)交換等方面被廣泛使用，JSON第 3方庫還提供對數(shù)據(jù)交換對象方便地進行序列化和反序列化的API，可大幅提高開發(fā)效率。此外，JSON格式的讀取速度要比XML更快。

我國有一個名為中國醫(yī)學知識倉庫（CHKD）的數(shù)據(jù)庫，醫(yī)院可以借此搭建一個網(wǎng)絡平臺，建立電子閱讀室。一方面實現(xiàn)了醫(yī)院的信息化建設，另一方面也能極大的滿足醫(yī)院醫(yī)務人員的閱讀需求[5]。而且電子書籍與紙質書籍相比有一個明顯的優(yōu)勢就是能夠快速找到需要的關鍵知識點。這是紙質書籍的弱項，傳統(tǒng)查閱資料方式需要對大量的相關文獻進行查找，費時費力[6]。而電子書籍可以借助網(wǎng)絡檢索功能對知識點進行關鍵字搜索，查詢起來方便快捷，這也是現(xiàn)代年輕人青睞于網(wǎng)絡書籍的原因[7]。

根據(jù)上述 2種格式的特點，本文主要采用了JSON這種數(shù)據(jù)容量大，開發(fā)方便的數(shù)據(jù)格式。同時考慮到歷史原因和數(shù)據(jù)交換習慣原因，保留了部分XML交換格式。

2.2 接口技術

接口技術目前主要有Web Service和RPC 2種方式。

Web Service是一個平臺獨立的、低耦合的、自包含的、基于可編程的web應用程序，可使用開放的XML標準來描述、發(fā)布、發(fā)現(xiàn)、協(xié)調和配置這些應用程序，用于開發(fā)分布式的交互操作應用程序[3]。Web Service技術，能使得運行在不同機器上的不同應用無須借助附加的、專門的第3方軟件或硬件，就可相互交換數(shù)據(jù)或集成。依據(jù)Web Service規(guī)范實施的應用之間，無論它們所使用的語言、平臺或內部協(xié)議是什么，都可以相互交換數(shù)據(jù)。Web Service是自描述、自包含的可用網(wǎng)絡模塊，可以執(zhí)行具體的業(yè)務功能。

SPDM 采用 WebService與企業(yè)內提供WebService接口的信息系統(tǒng)進行數(shù)據(jù)交互，比如與人力資源系統(tǒng)交互用戶信息，向檔案管理系統(tǒng)發(fā)送電子圖紙，歸檔完工圖紙等。

RPC是遠程過程調用（Remote Procedure Call）的縮寫形式。簡單的理解是一個節(jié)點請求另一個節(jié)點提供的服務。RPC在設計復雜業(yè)務操作時的API非常簡單，其通信機制高效緊湊，在交換大量消息時效率高，在遠程調用和傳遞消息時可以采用雙向流式消息方式。此外，RPC客戶端和服務端支持多種語言編寫，互操作性強。

由于船舶的零件數(shù)量級為百萬級，在設計完成后，設計軟件需要向SPDM發(fā)送大量的設計數(shù)據(jù)和生產(chǎn)制造數(shù)據(jù)。由于數(shù)據(jù)量非常龐大，所以在設計軟件與SPDM數(shù)據(jù)集成時接口主要采用RPC技術。

2.3 消息隊列技術

SPDM系統(tǒng)在解耦和求解耗時較長的等待問題時采用了消息隊列技術。消息隊列中間件是分布式系統(tǒng)中重要的組件，主要解決耦合應用、消息異步、流量削鋒等問題，構建高性能、高可用、可伸縮的架構。

目前，在生產(chǎn)環(huán)境中使用較多的消息隊列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ和RocketMQ等。由于消息隊列的處理方式和性能相差不大，SPDM系統(tǒng)選用開源的RabbitMQ[4-5]作為消息隊列中間件。

3 集成難點和解決方式

在數(shù)據(jù)集成接口中，最難處理的主要有大數(shù)據(jù)量處理、數(shù)據(jù)完整性保證、多系統(tǒng)間重復數(shù)據(jù)處理以及重發(fā)控制4個方面。為此，SPDM開發(fā)了一個處理框架來解決以上問題。框架開發(fā)了一個基礎的消息類，用以描述消息的關鍵信息，比如全局唯一的消息ID、消息的發(fā)送者、發(fā)送時間、發(fā)送到的隊列、處理命令，處理的結果和處理完成的時間等，并可在一個消息類中采用鍵/值的方式承載多個JSON和文件數(shù)據(jù)?？蛻舳瞬捎肦PC的方式提交消息，在服務端在接收到消息后，按消息所要發(fā)送到的消息隊列，轉發(fā)到相應的RabbitMQ消息隊列，并在數(shù)據(jù)庫中記錄消息的狀態(tài)。在服務端還有另一個消息處理服務負責監(jiān)視各個RabbitMQ消息隊列，一旦消息隊列接收到消息，就按消息的隊列名稱和處理命令，調用處理服務配置中對應的消息處理者對消息進行處理，并更新數(shù)據(jù)庫中消息的處理結果。系統(tǒng)可以通過專門的監(jiān)控程序，查看系統(tǒng)中各個處理隊列的運行情況和消息的處理情況。

對于大數(shù)據(jù)量處理，由于采用該框架后所要處理的消息都按順序排隊進入隊列，減少了對服務器的瞬時大并發(fā)連接和處理請求。框架支持分布式部署多個數(shù)據(jù)處理服務同時處理一個消息隊列中的數(shù)據(jù)，如果遇到消息隊列中數(shù)據(jù)猛增，可以快速地部署多個數(shù)據(jù)處理服務加快消息的處理。如果消息間沒有先后的邏輯關系，比如對文件進行電子簽名，那么框架還支持對同一條處理命令啟動多個數(shù)據(jù)處理者，從而加快數(shù)據(jù)處理速度。

對于數(shù)據(jù)完整性保障，由于數(shù)據(jù)在網(wǎng)絡和多個系統(tǒng)間傳輸，數(shù)據(jù)的完整性和防篡改是十分重要的?？蚣茉谙⒌谝淮萎a(chǎn)生和發(fā)送時都對消息生成一個MD5碼，消息進入框架后每次對消息進行接收、轉發(fā)和處理時都會驗證該MD5碼，通過此措施來保證該消息沒有被人為篡改或由于誤操作導致消息內容與發(fā)送時的消息內容不符。

在日常業(yè)務中，存在相同的數(shù)據(jù)需要發(fā)送到不同系統(tǒng)，不同的系統(tǒng)對相同的數(shù)據(jù)有不同的處理要求的情況。數(shù)據(jù)的發(fā)送端不需要考慮接受的系統(tǒng)是什么，只需發(fā)送到該消息的處理隊列即可。處理端可以針對不同系統(tǒng)的處理要求，對要處理的消息部署對應的消息處理者。這樣，架構就非常清晰明了，避免發(fā)送者對于相同的消息需要硬編碼調用不同系統(tǒng)的不同接口進行處理。做到接口與系統(tǒng)之間的解耦。

由于目前系統(tǒng)間的集成需求越來越多，集成的復雜度越來越高，難免會出現(xiàn)數(shù)據(jù)發(fā)送給A系統(tǒng)處理成功，而發(fā)送給B系統(tǒng)處理失敗的情況。數(shù)據(jù)重發(fā)時一般都是直接全部重發(fā)，而采用該框架由于在數(shù)據(jù)庫中記錄了數(shù)據(jù)的處理狀態(tài)，可以做到只發(fā)送處理失敗的數(shù)據(jù)，成功的數(shù)據(jù)不重發(fā)，或者不管處理失敗還是成功都重發(fā)。

框架對處理的消息都會留有備份，萬一出現(xiàn)消息處理錯誤，框架可以把處理失敗的消息以文件的形式提供給開發(fā)者，開發(fā)者可以迅速地讀取該消息，對處理程序進行調試，成功后更新到服務端，框架可以對原來處理失敗的消息重新進行處理，避免用戶再次發(fā)送數(shù)據(jù)進行處理。

4 結論

SPDM系統(tǒng)與設計軟件、ERP系統(tǒng)、生產(chǎn)管理系統(tǒng)以及集配系統(tǒng)等多個系統(tǒng)間共28個接口，且接口的內容和數(shù)據(jù)仍有增加。接口數(shù)據(jù)發(fā)送可靠、處理迅速，目前已實現(xiàn)了多型船數(shù)十萬數(shù)據(jù)的集成。接口處理數(shù)據(jù)時發(fā)生問題能快速發(fā)現(xiàn)、復現(xiàn)問題，開發(fā)人員可方便地調試程序和解決問題。業(yè)務人員能根據(jù)數(shù)據(jù)的處理情況及時處理數(shù)據(jù)，保證了數(shù)據(jù)的完整性、及時性和有效性。根據(jù)系統(tǒng)的運行情況，可證明本文集成技術的選型和集成方案是成功的。