施元超, 韓緯杰

?

一種企業(yè)域間協(xié)同組件設(shè)計與實現(xiàn)①

施元超, 韓緯杰

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

以企業(yè)AVIDM系統(tǒng)應(yīng)用為背景, 結(jié)合企業(yè)實際協(xié)同需求, 對域間協(xié)同組件設(shè)計和實現(xiàn)進行了描述, 重點闡述了跨域會簽和外域任務(wù)調(diào)度, 最后通過實例證明了通過域間協(xié)同組件, 實現(xiàn)與同系統(tǒng)其它科研生產(chǎn)聯(lián)合體基于圖文檔、產(chǎn)品結(jié)構(gòu)研制過程的協(xié)同; 通過信息跨域共享, 提高單位間協(xié)調(diào)研制效率.

企業(yè)協(xié)同; 跨域會簽; 外域任務(wù)調(diào)度; AVIDM; 跨域共享

1　引言

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

2 企業(yè)域間協(xié)同組件

2.1 組件概述

企業(yè)域間協(xié)同組件依賴于AVIDM平臺中的底層工作流, 用戶管理, 角色管理等基礎(chǔ)模塊. 組件基于AVIDM平臺進行研發(fā).

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

2.2 實現(xiàn)難點

①多站點協(xié)同管理

各科研生產(chǎn)聯(lián)合體目前使用的AVIDM版本眾多(如Avidm3.0, Avidm4.0, Avidm5.0), 怎樣有效實現(xiàn)多版本多站點協(xié)同管理成為組件設(shè)計難點, 為了克服系統(tǒng)版本多樣性, 企業(yè)將站點注冊、數(shù)據(jù)跨站點傳輸?shù)裙残怨δ艹槿〕鰜? 能夠為其他站點間的協(xié)調(diào)業(yè)務(wù)共用的功能來克服難點.

②海量數(shù)據(jù)傳輸

科研生產(chǎn)聯(lián)合體數(shù)量眾多, 涉及的文件也是海量的, 怎樣避免網(wǎng)絡(luò)中的海量消息傳輸, 以及消息準確的保證, 都成為企業(yè)協(xié)同組件設(shè)計難點. 本組件設(shè)計時, 通過增加初始化路由操作, 避免了每次發(fā)送業(yè)務(wù)消息前都先計算路由的動作, 減少了網(wǎng)絡(luò)中的海量消息傳輸.

3 總體設(shè)計

3.1 總體功能設(shè)計

企業(yè)域間協(xié)同組件主要實現(xiàn)以下功能來滿足企業(yè)制造協(xié)同設(shè)計需求:

①跨域動態(tài)任務(wù)分配調(diào)度, 實現(xiàn)了任務(wù)執(zhí)行人根據(jù)業(yè)務(wù)邏輯需要通過啟動會簽工作流程發(fā)起外域工作項將任務(wù)動態(tài)分發(fā)給本單位AVIDM外相互通的系統(tǒng)中執(zhí)行人.

②跨域會簽, 接受任務(wù)的執(zhí)行人即在異地的多個應(yīng)用系統(tǒng)可以實現(xiàn)聯(lián)合簽署一個文檔包, 任務(wù)發(fā)起人通過啟動會簽工作流程發(fā)起外域工作項, 然后通過 web service 遠程調(diào)用將任務(wù)發(fā)送給外域用戶, 外域用戶接收并執(zhí)行任務(wù), 最后將執(zhí)行結(jié)果返回流程發(fā)起域.

3.2 總體架構(gòu)設(shè)計

如圖1所示, 企業(yè)域間協(xié)同組件主要由協(xié)同應(yīng)用組件、數(shù)據(jù)傳輸組件和公共組件三部分組成:

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

②數(shù)據(jù)傳輸組件用來實現(xiàn)跨域系統(tǒng)之間的消息、文件附件的傳輸.

③公共組件負責實現(xiàn)權(quán)限控制, 角色定義以及數(shù)據(jù)的加、解密處理, 記錄程序異常日志以及用戶操作的業(yè)務(wù)日志.

圖1 企業(yè)域間協(xié)同組件總體架構(gòu)

圖2 分級域管理

4 協(xié)同組件的設(shè)計與實現(xiàn)

4.1關(guān)鍵技術(shù)

4.1.1分級域管理

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

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

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

4.1.2動態(tài)工作流

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

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

圖3 動態(tài)工作流程定義

4.2協(xié)同應(yīng)用組件的設(shè)計

4.2.1跨域會簽

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

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

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

接收方人員生成會簽任務(wù)后, 通過會簽任務(wù)可以瀏覽本次會簽所涉及的實體數(shù)據(jù), 包括結(jié)構(gòu)和文檔. 瀏覽的實體數(shù)據(jù)均在發(fā)起方, 是通過指定的URL來進行瀏覽的.

接收人員在查看會簽數(shù)據(jù)時, 可以對會簽的文檔進行批注操作, 該功能依賴于產(chǎn)品結(jié)構(gòu)和文檔管理模塊提供的批注功能實現(xiàn).

接收方人員接收到會簽任務(wù)后, 在進行轉(zhuǎn)發(fā)會簽任務(wù)的時候, 可以將會簽單中的文檔拆分轉(zhuǎn)發(fā)給不同的子任務(wù), 并由不同的人員進行會簽簽署, 最后在發(fā)起方經(jīng)過拆分的文檔的簽署信息各不相同. 會簽拆包信息在任務(wù)轉(zhuǎn)發(fā)的時候會同步到發(fā)起方.

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

4.2.2跨域配置

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

4.2.3外域任務(wù)調(diào)度

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

系統(tǒng)用戶接收到外域任務(wù)后, 還可以對任務(wù)進行轉(zhuǎn)發(fā), 將任務(wù)轉(zhuǎn)發(fā)給本系統(tǒng)內(nèi)其他用戶進行處理. 系統(tǒng)用戶在進行外域任務(wù)轉(zhuǎn)發(fā)時, 需要進行如下設(shè)置:

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

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

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

4.2.4消息管理設(shè)計

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

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

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

實現(xiàn)方式如下:

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

1) MessageSendManager為單例實現(xiàn).

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

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

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

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

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

7) MessageReceiveManager也單例實現(xiàn), 并在應(yīng)用程序啟動時進行初始化.

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

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

1) 消息發(fā)送

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

2) 消息處理

與消息發(fā)送相同的處理方法, 監(jiān)控線程為DealWatchThread.

①消息發(fā)送: 該功能實現(xiàn)將消息發(fā)送隊列中提取的消息進行發(fā)送操作. 消息創(chuàng)建成功并加入消息隊列后, 隊列監(jiān)控線程將消息提取出來, 并通過線程池內(nèi)的線程進行消息并發(fā)發(fā)送[10].

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

Step2. 將該線程放入到線程池中進行管理. 設(shè)定線程池的最小線程數(shù)和最大線程數(shù). 這里采用java.util.concurrent中的線程池進行實現(xiàn), 在發(fā)送線程放入線程池后, 將消息狀態(tài)置為發(fā)送中.

Step3.在MessageSender中, 通過ObjectMessage對象獲取所帶的對象附件, 文件附件取出, 并通過SOAP消息的轉(zhuǎn)化類, 將該數(shù)據(jù)轉(zhuǎn)化為SOAP消息. 最后發(fā)送SOAP消息. 發(fā)送消息前, 系統(tǒng)進行網(wǎng)絡(luò)速度的監(jiān)控, 當發(fā)現(xiàn)測試傳輸速度不大于40Kb/s時, 系統(tǒng)進行提示. 消息發(fā)出成功后, 將消息狀態(tài)置為發(fā)送成功狀態(tài).

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

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

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

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

③消息處理: 該功能實現(xiàn)消息的處理, 完成相應(yīng)的業(yè)務(wù)邏輯. 具體的消息處理實現(xiàn)類由業(yè)務(wù)層實現(xiàn), 此處僅調(diào)用消息處理實現(xiàn)類.

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

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

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

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

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

4.2.5數(shù)據(jù)傳輸

目前還是采用消息傳輸附件的形式實現(xiàn), 詳見消息中對附件傳輸?shù)膶崿F(xiàn).

4.2.6安全策略設(shè)計

(1) 消息安全

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

(2) 角色權(quán)限

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

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

3) 各業(yè)務(wù)模塊單據(jù)的權(quán)限除單據(jù)創(chuàng)建者本身有所有的權(quán)限外, 又分為以下幾種情況:

①系統(tǒng)用戶如果是流程審批人, 只有瀏覽權(quán)限;

②系統(tǒng)用戶在產(chǎn)品結(jié)構(gòu)擁有瀏覽跨域數(shù)據(jù)的權(quán)限, 也將擁有瀏覽單據(jù)的權(quán)限;

③對單據(jù)的瀏覽權(quán)限由其他業(yè)務(wù)模塊在業(yè)務(wù)層進行控制.

4.3 應(yīng)用實例

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

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

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

圖4 外站點注冊

圖5 外站點配置

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

圖6 外站點域間協(xié)同

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

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

圖7 外單位分發(fā)

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

圖8 跨域會簽送審

啟動流程后, 當流程到達該節(jié)點時, 會動態(tài)啟動一個子流程, 發(fā)送審簽任務(wù)給跨域會簽人, 在場所B的A4系統(tǒng)中都能查看到相關(guān)審簽流程.

圖9 跨域會簽

5 結(jié)語

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

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

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

3 龐士宗,肖平陽,唐加福.產(chǎn)品數(shù)據(jù)管理(AVIDM)現(xiàn)代企業(yè)信息化管理與集成的理想平臺.北京:機械工業(yè)出版社,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服務(wù)的跨企業(yè)信息集成框架.計算機集成制造系統(tǒng)-CIMS,2003,9(1):1–5.

13哈進兵,張友良,李舟洲.異地企業(yè)協(xié)同工作的Web模型及其實現(xiàn).計算機集成制造系統(tǒng)-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]