一種企業域間協同組件設計與實現①

施元超, 韓緯杰

?

一種企業域間協同組件設計與實現①

施元超, 韓緯杰

1(上海航天控制技術研究所, 上海 201109)2(上海航天動力技術研究所, 上海 201109)

以企業AVIDM系統應用為背景, 結合企業實際協同需求, 對域間協同組件設計和實現進行了描述, 重點闡述了跨域會簽和外域任務調度, 最后通過實例證明了通過域間協同組件, 實現與同系統其它科研生產聯合體基于圖文檔、產品結構研制過程的協同; 通過信息跨域共享, 提高單位間協調研制效率.

企業協同; 跨域會簽; 外域任務調度; AVIDM; 跨域共享

1　引言

航天型號產品的研制生產, 是一項涉及多學科、多單位協作的系統工程. 隨著網絡的發展, 及智能制造, 工業4.0時代的到來, 航天型號產品研制周期不斷縮減、產品復雜度不斷增加的, 跨地域的設計制造協同日趨頻繁, 三維數字化技術的應用不斷深入, 更對產品研制的可視化協同提出了要求, 現有的航天科研生產聯合體中使用的設計制造系統軟件品類版本多樣, 基本都獨立使用, 仍依靠人工協同, 所以需要依托廣泛適應航天設計制造多樣行軟件的平臺, 構建企業間協同組件, 通過域間協同組件, 實現與同系統其它科研生產聯合體基于圖文檔、產品結構研制過程的協同; 通過信息化協調, 提高各科研生產聯合體間協調研制效率, 為智能制造的發展構建基礎.

2 企業域間協同組件

2.1 組件概述

企業域間協同組件依賴于AVIDM平臺中的底層工作流, 用戶管理, 角色管理等基礎模塊. 組件基于AVIDM平臺進行研發.

企業域間協同組件需要提供支持不同單位應用的AVIDM系統(包括廠所級、院級和集團級應用)之間開展型號研制過程中的協同工作, 提供包括產品設計數據的跨單位共享、設計數據的跨單位會簽、型號數據的正式發布以及受控有效數據的匯總集中管理等協同業務功能, 同時也需要提供對跨院協同任務的管理、協同信息的統計以及協同過程的監控等管控功能.

2.2 實現難點

①多站點協同管理

各科研生產聯合體目前使用的AVIDM版本眾多(如Avidm3.0, Avidm4.0, Avidm5.0), 怎樣有效實現多版本多站點協同管理成為組件設計難點, 為了克服系統版本多樣性, 企業將站點注冊、數據跨站點傳輸等共性功能抽取出來, 能夠為其他站點間的協調業務共用的功能來克服難點.

②海量數據傳輸

科研生產聯合體數量眾多, 涉及的文件也是海量的, 怎樣避免網絡中的海量消息傳輸, 以及消息準確的保證, 都成為企業協同組件設計難點. 本組件設計時, 通過增加初始化路由操作, 避免了每次發送業務消息前都先計算路由的動作, 減少了網絡中的海量消息傳輸.

3 總體設計

3.1 總體功能設計

企業域間協同組件主要實現以下功能來滿足企業制造協同設計需求:

①跨域動態任務分配調度, 實現了任務執行人根據業務邏輯需要通過啟動會簽工作流程發起外域工作項將任務動態分發給本單位AVIDM外相互通的系統中執行人.

②跨域會簽, 接受任務的執行人即在異地的多個應用系統可以實現聯合簽署一個文檔包, 任務發起人通過啟動會簽工作流程發起外域工作項, 然后通過 web service 遠程調用將任務發送給外域用戶, 外域用戶接收并執行任務, 最后將執行結果返回流程發起域.

3.2 總體架構設計

如圖1所示, 企業域間協同組件主要由協同應用組件、數據傳輸組件和公共組件三部分組成:

①協同應用組件負責將各廠所的有效數據匯總到數據中心系統進行統一管理和監控, 并集中管理跨域協同業務的所有配置信息; 如圖2所示, 通過將各科研生產聯合體的獨立PDM系統劃分為分級域, 使用分級域的關鍵技術, 實現域間通訊協作, 數據的共享; 利用動態工作流技術, 實現跨域的圖文檔審批, 跨域共享是通過鏈接的模式進行共享瀏覽. 共享的數據由業務使用的模塊決定, 跨域共享只提供共享機制, 在外部會簽流程節點處將會簽數據發送到外部單位進行簽署.

②數據傳輸組件用來實現跨域系統之間的消息、文件附件的傳輸.

③公共組件負責實現權限控制, 角色定義以及數據的加、解密處理, 記錄程序異常日志以及用戶操作的業務日志.

圖1 企業域間協同組件總體架構

圖2 分級域管理

4 協同組件的設計與實現

4.1關鍵技術

4.1.1分級域管理

域與域之間要有一種組織方式實現兩個或多個域間信息互通時: 對等, 主從或上下級等, 本系統下域間定義為樹型結構, 即域間存在上下級關系當一個域想加入樹形結構時, 先調用域組織信息服務的域組織查詢方面的方法獲得組織信息, 然后選擇自己的父域并調用注冊域方法就可以加入樹形系統中; 想脫離樹型結構時, 調用域組織信息服務的刪除已經注冊的域方法就可以從域樹上脫離出來[1,2].

在這種設計中信任關系的建立和刪除是自動和手工相結合的: 當一個域加入樹形組織結構時, 它會自動的建立對它的父域以及祖先域的信任, 其它情況的信仟則需要各個跨域安全管理員手動建立, 也就是說, 信任關系的建立是單向傳遞的; 當一個域從一個樹型結構中脫離時, 則這個域會自動刪除跟其它域的信任與被信任關系; 當然, 每個跨域的安全管理員可以手工建立與刪除跟其它域的信任關系. 為實現以上的功能, 每個域都要提供建立與取消信任關系的相關服務[2-5].

分級域管理能夠按需為各個科研生產聯合體提供應用系統, 并能有效保證這些應用系統之間的獨立性和安全性; 同時, 組織域下的應用系統能夠共享組織域中的身份等公共信息.

4.1.2動態工作流

動態工作流是指組成工作流的任務組件在運行時才能確定下來, 能夠支持比較靈活的業務邏輯實現, 并在較短的時間內, 建立適應具體業務變化的動態工作流系統. 一般情況下, 工作流程的調整意味著整個業務流程的重新設計, 而基于ADP框架的動態工作流技術的系統由于功能設計和實現相分離, 可以將單純的流程調整通過流程定義調整的簡單方式解決, 而不會影響到如何實現的部分[1,6-8].

本協同組件流程設計遵循WFMC[9]工作流參考模型, 為應用系統提供業務流轉場景的支持. 提供Web模式的流程定義, 流程建模人員能夠以所見即所得的方式定義出流程模板. 支持復雜的流程定制能力和注入機制, 方便應用系統進行擴展和定制.

圖3 動態工作流程定義

4.2協同應用組件的設計

4.2.1跨域會簽

系統用戶在工作流外部會簽節點, 可以進行創建會簽單、修改會簽單、刪除會簽單的操作. 完整的會簽單包括單據信息、目標域信息、接收人員信息、跨域數據信息. 會簽單創建完成后, 還要記錄會簽單對象和工作流節點綁定情況.

會簽單創建成功后, 系統用戶查看會簽單信息頁面, 可以進行發起會簽的操作. 發起方發起會簽, 創建消息發送到接收方, 接收方接收并處理消息, 為接收人員生成任務. 發起方通過視圖層會簽信息查看頁面發起會簽請求, 控制層調用相關方法組織會簽單相關信息, 發送會簽請求消息到接收方. 接收方接收會簽請求消息, 生成任務, 并反饋任務已接收消息、任務拆分消息、文檔綁定消息到發起方, 發起方收到相應消息后進行處理.

對于已經完成的會簽任務, 發起方可以進行意見匯總操作, 將接收方所有參與人員的簽署意見進行匯總, 提供視圖展示, 并將簽署信息回寫到工作流節點中.

接收方人員生成會簽任務后, 通過會簽任務可以瀏覽本次會簽所涉及的實體數據, 包括結構和文檔. 瀏覽的實體數據均在發起方, 是通過指定的URL來進行瀏覽的.

接收人員在查看會簽數據時, 可以對會簽的文檔進行批注操作, 該功能依賴于產品結構和文檔管理模塊提供的批注功能實現.

接收方人員接收到會簽任務后, 在進行轉發會簽任務的時候, 可以將會簽單中的文檔拆分轉發給不同的子任務, 并由不同的人員進行會簽簽署, 最后在發起方經過拆分的文檔的簽署信息各不相同. 會簽拆包信息在任務轉發的時候會同步到發起方.

在外部會簽過程中, 由于會簽單位沒有跨域系統, 不能完成電子會簽的時候, 從而選擇紙質會簽, 即在跨域發起方創建會簽單據, 通過紙質的形式提交到會簽單位, 會簽單位進行簽署后, 將紙質文件返回到發起方, 發起方的紙質錄入員將會簽單位簽署在紙質文件上的意見手動錄入到發起方的會簽單中. 發起紙質會簽的功能包含在發起會簽和增加單位的功能中, 如果選擇的單位是外部單位, 則進行紙質會簽的發起.

4.2.2跨域配置

協同站點采用邦聯模式: 邦聯模式是指點對點的站點同步關聯, 不需要用到第三方中心站點, 在這種模式下, 注冊目標站點成功后, 站點查詢列表會自動刷新出目標站點, 勾選中目標站點, 即可同步對方站點和數據.

4.2.3外域任務調度

外域任務調度提供了對任務的查詢、簽署、督辦和轉發功能, 簽署時用戶發起添加簽署意見信息請求, 控制層組織簽署意見信息, 調用相關方法存儲簽署意見, 并返回操作結果交由視圖層顯示; 簽署任務功能添加簽署信息完成后, 產生簽署信息發送消息. 首先轉換簽署信息的附件對象, 然后調用消息傳輸組件創建簽署信息發送消息. 接收簽署信息是指在發起方收到接收方任務處理人的簽署意見, 并保存到發起方. 如果存在數據中心的情況下, 數據中心的業務邏輯處理與發起方相同. 消息處理模塊調用實現類來完成簽署消息的處理.

系統用戶接收到外域任務后, 還可以對任務進行轉發, 將任務轉發給本系統內其他用戶進行處理. 系統用戶在進行外域任務轉發時, 需要進行如下設置:

①是否等待子任務簽署: 如果選擇等待子任務簽署, 則在待辦任務里會保留該任務等待簽署, 否則直接接入督辦任務.

②子任務是否可以繼續轉發: 如果選擇了子任務可以繼續轉發, 所有下級任務接收人都可以將該任務進行再次轉發, 否則下級任務用戶只能對該任務進行瀏覽和簽署處理.

任務打回: 系統用戶查看跟蹤任務時, 對子任務用戶的處理不同意的情況下, 可將任務打回. 在子任務處理用戶處重新生成一條待辦任務, 并刪除子任務的簽署信息. 用戶在視圖層選擇要打回的任務, 控制層獲取任務標識, 調用相關方法刪除任務簽署信息, 更改任務狀態為“待處理”狀態, 并返回操作結果供視圖層顯示.

4.2.4消息管理設計

消息管理包含對消息的進行下述處理:

(1) 創建消息: 功能主要完成各跨域業務所需要的消息的創建工作, 接受各跨域業務向消息層傳遞的消息實體, 對象列表和文件列表, 完成對象附件的創建, 文件附件的創建, 實現消息實體、對象附件和文件附件的存儲, 置消息實體為“新建”狀態, 等待消息發送隊列的提取.

(2) 添加消息: 消息隊列共有兩種類型: 消息發送隊列和消息處理隊列. 該功能是消息隊列管理的一個子功能, 實現將數據庫中的消息提取, 添加到消息隊列中, 等待消息的發送或處理.

實現方式如下:

專家1對e11的評價為u1,運用式(7)計算該證據對于各個風險等級的隸屬度，進行歸一化，得me111=(0.928 6，0.071 4，0，0)。同理，可得出其他專家對于對e11的模糊評語隸屬于各個風險等級的程度，用矩陣T表示。

1) MessageSendManager為單例實現.

2) MessageSendManager中包括一個私有的發送隊列屬性(sendQueue), 建議使用BlockingQueue類型的隊列(JDK自帶).

3) MessageSendManager類中包括對發送對列的一系列操作, 如: 添加,獲取, 刪除等.

4) 消息創建時, 在MessageDelegate中消息創建成功馬上加入消息隊列等待發送.

5) 在接收方MessageReceiver類中接收完消息后, 馬上將消息放入待處理隊列中進行處理, 調用方法addDealMessage().

6) MessageReceiveManager類中包括一個私有的消息處理隊列, 如與②中的消息發送隊列類型一致. 并包括對消息處理隊列的一系列操作, 如: 添加, 刪除, 獲取等.

7) MessageReceiveManager也單例實現, 并在應用程序啟動時進行初始化.

8) 消息加入到發送隊列后狀態為發送就緒狀態, 接收方接收到消息后, 加入到處理隊列時, 消息為待處理狀態.

(3) 消息提取: 實現根據消息隊列的類型從隊列中提取消息, 進行后續發送或處理操作. 具體是發送方在發送隊列中獲取消息進行發送, 接收方在處理隊列中獲取消息進行處理.

1) 消息發送

消息發送時, 始終有SendWatchThread線程監控消息隊列. 當消息隊列中有消息時, 線程啟動消息發送. 如果沒有消息時, 則處于等待狀態. 當向隊列添加消息后喚醒等待的發送線程.

2) 消息處理

與消息發送相同的處理方法, 監控線程為DealWatchThread.

①消息發送: 該功能實現將消息發送隊列中提取的消息進行發送操作. 消息創建成功并加入消息隊列后, 隊列監控線程將消息提取出來, 并通過線程池內的線程進行消息并發發送[10].

Step1. 消息發送隊列監控線程從隊列中取出消息, 然后生成一個MessageSender的發送線程.

Step2. 將該線程放入到線程池中進行管理. 設定線程池的最小線程數和最大線程數. 這里采用java.util.concurrent中的線程池進行實現, 在發送線程放入線程池后, 將消息狀態置為發送中.

Step3.在MessageSender中, 通過ObjectMessage對象獲取所帶的對象附件, 文件附件取出, 并通過SOAP消息的轉化類, 將該數據轉化為SOAP消息. 最后發送SOAP消息. 發送消息前, 系統進行網絡速度的監控, 當發現測試傳輸速度不大于40Kb/s時, 系統進行提示. 消息發出成功后, 將消息狀態置為發送成功狀態.

②消息接收: 將發起方發送的消息、對象附件、文件附件進行接收并存儲. 并將消息對象加入到待處理隊列中等待處理.

Step1. MessageReceiver為SOAP消息接收器. 接收到消息后通過消息轉換器將SOAP轉化為消息對象(ObjectMessage),對象附件(StoreObject),文件附件(StoreFile).

Step2. 存儲消息對象, 對象附件和文件附件.

Step3. 然后將消息對象加入到待處理的隊列中, 將消息狀態置為消息待處理狀態,

③消息處理: 該功能實現消息的處理, 完成相應的業務邏輯. 具體的消息處理實現類由業務層實現, 此處僅調用消息處理實現類.

Step1. 處理隊列的監控線程DealWathThread先從消息接收隊列中獲取消息.

Step2. 然后生成一個消息處理線程(MessageDealer), 并放入到線程池(ThreadPoolManager)中處理.

Step3. 處理線程(MessageDealer)通過消息對象獲取消息所帶的對象附件, 文件附件.

Step4. 通過消息類型獲取該消息類型的處理方法.

Step5. 處理類提供接口MesssageDealService. 消息類型的處理需要實現該接口. 并配置到消息類型配置文件中.

4.2.5數據傳輸

目前還是采用消息傳輸附件的形式實現, 詳見消息中對附件傳輸的實現.

4.2.6安全策略設計

(1) 消息安全

消息安全主要是指對消息數據進行加解密處理. 在消息發送前, 將消息所帶的實體文件加密后在網絡中傳輸. 目前對消息中的文件暫時采用對稱性加密方式進行安全管理. 在系統服務器中統一管理消息傳輸密鑰[11-13].

(2) 角色權限

1) 角色定義采用ADP框架底層模塊的角色定義;

2) 角色權限使用過濾器進行界面權限控制;

3) 各業務模塊單據的權限除單據創建者本身有所有的權限外, 又分為以下幾種情況:

①系統用戶如果是流程審批人, 只有瀏覽權限;

②系統用戶在產品結構擁有瀏覽跨域數據的權限, 也將擁有瀏覽單據的權限;

③對單據的瀏覽權限由其他業務模塊在業務層進行控制.

4.3 應用實例

目前, 某研究所已經實現了與本院其它五個科研生產聯合體間多個版本AVIDM(avidm 3.0, avidm4.0, avidm 5.0)系統間跨域協同審批簽署功能, 實現紙質傳遞簽署向電子化審簽的轉化, 原來多日人工送達審簽的任務, 現在實時都能響應, 極大的提高的工作效率. 列舉如下應用場景實例: 實現了某文檔在場所AB的不同應用軟件中實現跨域協同會簽, 分發共享, 流程如下:

(1) 初始化: 需要跨域協同的各系統, 需要配置連同, 假設場所A: 使用A5, 場所B: 使用A4.

如下圖所示, 場所A, 在A5 系統中通過協同組件模塊, 注冊場所B的A4 系統為外域站點.

圖4 外站點注冊

圖5 外站點配置

場所B, 在A3系統中通過協同組件模塊, 注冊場所A的A5系統為外與站點.

圖6 外站點域間協同

(2) 假設A場所有文檔需要跨域會簽, 實現電子化審簽, 發放, 具體舉例流程如下:

首先, 對需要分發會簽的文檔, 選擇分發的單位(初始化配置中, 配置連同的系統單位, 都可選).

圖7 外單位分發

然后, 對文檔選擇外域會簽流程進行送審, 點擊“外部會簽”按鈕, 選擇“接收站點”和“接收人”.

圖8 跨域會簽送審

啟動流程后, 當流程到達該節點時, 會動態啟動一個子流程, 發送審簽任務給跨域會簽人, 在場所B的A4系統中都能查看到相關審簽流程.

圖9 跨域會簽

5 結語

隨著AVIDM系統在某研究所內及其他科研生產聯合體的不斷應用, 以信息化手段為核心, 從根本上改變了原有企業管理模式, 縮短了文檔簽署管理流程, 顯著提高了工作效率, 為科研生產聯合體從設計、生產、制造設計一體化的提供基礎保障.

1 張利君.基于動態工作流的子流程研究與實現[碩士學位論文].北京:北京信息工程研究所,2006.

2 宋玉鳴.基于AVIDM的跨域信息集成與訪問控制[碩士學位論文].北京:北京信息工程研究所,2006.

3 龐士宗,肖平陽,唐加福.產品數據管理(AVIDM)現代企業信息化管理與集成的理想平臺.北京:機械工業出版社,2001.

4 Heppelman J. PDM for the enterprise. Mechanical Engineering, 1998, 120(10): 84–86.

5 Chu X, Fan Y. Productdata management based on Web technology. Integrated Manufacturing Systems, 1999, 10(2): 84–90.

6 Miller E. PDM heads for the Web. Maehine Design, 1997, (8).

7 Jorg B, Muehlen M. Workflow application architectures: Classification and characteristics of workfiow based information systems. WFMC Workflow Handbook, 2002.

8 Workflow Management Coalition. Workflow Management Coalition Workflow Client Application (Interface2) Application Programming Interface (WAPI) Naming Conventions[Technical Report]. WFMC- TC-1013. 1997.

9 Casati F, Grefen P. WIDE Workflow Model and Architecture. [Technical Report]. University of Twente, 1996: 96–19.

10 Ferraiolo DF, Barkley JF, Kubn DR. A role based access control model and reference implementation within a coporate Intranet. ACM Trans. on Information Systems Security, 1999, 2(1): 34–64.

11 Meng J, Su SYW, Lam H, Helal S. Achieving dynamic inter-organizational workflow management by integrating business processes, events, and rules. Annual Hawaii International Conference on System Sciences (HICSS’02). Big Island, Hawaii. USA. 2002.

12周航濱,夏安邦,張長昊.基于Web服務的跨企業信息集成框架.計算機集成制造系統-CIMS,2003,9(1):1–5.

13哈進兵,張友良,李舟洲.異地企業協同工作的Web模型及其實現.計算機集成制造系統-CIMS,2001,7(5):38– 41.

Design and Implementation of the Cross-Domain Collaborative Component

SHI Yuan-Chao1, HAN Wei-Jie2

1(Shanghai Institute of Spaceflight Control Technology, Shanghai 201109, China)2(Shanghai Space Propulsion Technology Research Institute, Shanghai 201109, China)

This article is based on one enterprise collaborative product development management system. According to the actual needs of the enterprise, cross-domain component design and implementation are described. This article focuses on cross-border and countersigned outland task scheduling. Finally, this article proves that using the synergistic component can achieve synergies with other units of the inter-domain based on drawing document or product structure. By cross-domain information sharing, it improves the efficiency of research and collaboration between units over a sample.

enterprise collaborative; cross-domain countersigned; cross-domain task scheduling; AVIDM; cross-domain share

2016-06-07;

2016-07-14

[10.15888/j.cnki.csa.005622]