一种企业域间协同组件设计与实现①

施元超, 韩纬杰



一种企业域间协同组件设计与实现①

施元超, 韩纬杰

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]