Teamcenter Enterprise 2005流程、权限在我所PDM系统中的实现-雷波

  • 格式:pdf
  • 大小:1.25 MB
  • 文档页数:24

Teamcenter Enterprise 2005流程、权限在我所PDM系统中的实现雷 波中国兵器工业集团Teamcenter Enterprise 2005流程、权限在我所PDM系统中的实现雷波中国兵器工业集团摘 要:在现实工作中,设计人员经常需要在项目组内查找图纸、文档,到各个部门进行签审。

如果有一套成熟的产品数据管理系统,实现图纸、文档的电子签审、电子归档,将节省很多用于查找、签审的时间,从而大大提升项目进度。

本文主要是介绍Teamcenter Enterprise 2005流程、权限在我所PDM系统中的实现过程。

论文分为三大部分,第一部分对Teamcenter Enterprise 2005流程、权限进行简介,第二部分通过实例介绍流程、权限在我所PDM系统中的实现过程,第三部分介绍了流程、权限的维护。

关键词: 流程 权限 PDM 实现1 Teamcenter Enterprise 2005流程、权限简介1.1 Teamcenter Enterprise 2005流程简介1.1.1 流程概念Teamcenter Enterprise 2005流程机制可以反映一个流程对象的生命周期过程。

对象进入流程后,会沿着已制定好的步骤前进,直至流程结束。

在流程过程中,对象的状态和位置可能会发生变化。

1.1.2 流程类型在Teamcenter Enterprise 2005中主要有以下一些流程类型:Life Cycles 工作流工作流是通过定义和连接各种任务以及流程对象的状态变化来实现定制企业业务流程。

Assignment Processes 作业分配任务用来分配工作给用户;当各种对象通过该过程时,用户被分配一个具体的执行任务。

Review Processes 签审任务用来定义指定签审人员(用户/用户组/角色/动态参与者)在数据被提升到一个新的生命周期状态前对数据信息执行签审任务,当对象在这样的任务中通过时,多个参与者可以通过投票表决的方式来表达同意或否决的意见。

Distribution List Processes 分发通知用于在产品数据对象的生命周期内向相关事件的收信人发布有重要的产品更新信息或通知。

Condition Processes 条件任务为了在工作流中创建多个分支而设计的用于评估条件的任务。

Message Processes 自动处理任务可以对流程中运行的对象执行的经过二次开发的自动程序。

Breakdown Processes 分解流程由工作流组成,一个复杂对象的不同组成部分可以分别独立进入不同的工作流。

Taskflow Processes 任务流与工作流类似, 区别在于任务流中每个步骤中任务的对象不能发生状态或者数据仓库(位置)的变化。

Parallel Processes 并行流程由任务流组成,同一个对象可同时在不同的任务流中。

Vault Transfer Processes 数据仓库传递任务将对象传递到数据仓库,使对象的位置发生变化。

Calendars 工作日历定义一个工作流的工作日历,使作业任务能够依照企业特定的日历执行,当任务执行期限到后,可以自动推动相关流程动作。

Process History 工作流历史工作流历史是工作对象进行的所有任务的列表。

每一个工作流历史都将记录工作对象进入和退出任务时的工作流状态、任务开始和完成的日期和时间,态。

及任务的退出状Routing Lists 顾问清单由用户创建、维护和使用,用于对工作项获取非正式的注释的手段不属于流程的一部分。

1.1.3 流程的参与者在流程中,1.1.2节提到的作业分配任务、签审任务、分发通知都需要人员进行参与才能完成,Teamcenter Enterprise 2005中主要有以下几种流程的参与者: 用户是流程中的单个参与者,由于单个用户有很大的变动性,所以一般不推荐将用户作为流程的参与者。

用户组通过将用户加入用户组中,可以使用户组中的用户都可以收到流程任务,同时可以随时增加或移出用户,相比较替代单个用户作为流程的参与者有更大的灵活性。

角色通过角色的使用,可以用一个任务为不同的项目构造相同的工作流,而不需要重新定义人员,只需给用户指定在项目中的角色就可以了。

动态参与者除了以上三种参与者,还可以指定动态参与者参与流程。

在流程中动态参与者是不确定的,他是依据对象的属性值来进入流程,和其他几种参与者一样参与流程的。

1.1.4 定义流程参与者可进行的操作确定了流程的参与者,还需要确定参与者在流程中可以进行哪些操作。

Teamcenter Enterprise 2005中是为参与者指定其使用的消息或消息组来实现的。

消息的内容定义了参与者可以进行的操作,如果单条消息无法定义完全所有的操作,则推荐使用消息组来定义,使用消息组有以下好处:组合有类似功能的消息和消息组通过组合有类似功能的消息和消息组,可以大大减少定义时的繁琐性。

简化了规则的编写如果只使用单条消息进行定义,则要在消息中编写大量规则。

而使用消息组,可以大大简化规则的编写。

1.1.5 对象在流程中状态和位置的变化当对象在流程中时,根据流程步骤的变化,它的状态也会随着变化,比如校核中、审查中、工艺检查中、标准检查中、审定中等。

同样,对象在流程中,所处位置也会根据流程步骤的变化而变化,主要有三个位置变化:用户、公司公用数据仓库、公司归档数据仓库,对象所处的位置不同,相应的操作权限也会不同。

对象在流程中的位置变化可以用图1形象表示。

图1 对象在流程中的位置变化1.1.6 流程搭建的一般步骤流程的搭建一般可分为如下几步:绘制Visio图定义流程中用的任务a)作业分配任务、签审任务、分发通知:确定参与的人员以及相关的规则b)自动处理任务:确定所要使用的消息c)分解流程:确定所使用的流程的分支d)任务流:确定任务流的步骤e)并行流程:确定所要使用的任务流创建工作流a)指定进入流程的条件b)指定进入流程的类对象编辑工作流的各个执行步骤a)创建流程步骤b)将任务和步骤相关联c)指定某些步骤成功或者失败后状态和数据仓库的变化(可选)d)将定义好的各个步骤连接起来e)保存确认1.1.7 流程任务的处理当对象在流程中时,用户如何处理流程任务呢?可以用一个例子来说明:a)用户登陆系统后,会收到相应的工作任务,如图2。

b)用户选中文档,浏览文档内容,如图3。

图3 用户浏览文档内容c)系统打开PDF文件供用户浏览,用户可以在其中进行批注,如图4。

图4 用户对文档进行批注d)用户对工作任务进行签发,如图5。

e)用户选中“已批准”或“拒绝”,完成工作任务,如图6。

1.1.8 流程状态监控对流程状态的监控,可以通过查看流程历史来实现。

通过查看流程历史,可以清楚地看到对象在流程中所处的位置,以及已完成的步骤和未完成的步骤,如图7所示,其中绿色框表示已完成的步骤,黄色框表示当前的步骤,灰色框表示未完成的步骤,蓝箭线表示步骤成功时的出口,红箭线表示步骤失败时的出口。

图7 流程历史1.2 Teamcenter Enterprise 2005权限简介1.2.1 权限概念Teamcenter Enterprise 2005权限机制用来控制用户操作数据的能力,对用户访问数据的控制主要是考虑信息的安全性和用户使用的便利性。

规定谁能够对什么数据进行什么操作以支持以前定义的业务流程和数据完整性的要求。

同时,权限控制还可以过滤用户不感兴趣的信息和操作以使操作界面对用户更加友好。

1.2.2 权限的目标和原则权限设置的作用是规定系统中的角色在什么条件下可以运用哪些功能。

其目标和原则是:a)控制信息共享b)便于进行安全监督c)分别对不同的访问方式进行控制d)但是不要影响用户对系统的使用1.2.3 权限设计的要素系统权限的划分主要考虑四个因素:人员+数据+操作+条件设计条件主要考虑:数据位置+数据状态+特定条件1.2.4 权限类型Teamcenter Enterprise 2005中的权限主要分为三类:静态权限、授权和流程权限:a)静态权限(MAR)根据用户参与的项目、担任的角色、所在的不同组,所访问的对象类型、对象所处于的位置状态以及用户执行的操作功能动态地解算用户对数据的访问操作权限适用。

b)授权(ACL)由具有授权权限的管理者用户(如总师)在某些特殊情况下,对某个具体的数据对象为某个用户或者用户小组授权(如:复制、浏览等),并且可以灵活设定授权的有效时限。

c)流程权限(LCM)流程参与者根据所参与活动类型的不同具有相对应的流程对象操作权限,这些活动类型包括签审任务、作业分派任务、分发通知等。

1.2.5 静态权限设计a)MAR权限定义Teamcenter Enterprise 2005使用消息访问规则来控制对对象发送操作的权限,创建页面如图8所示。

图8 创建消息访问规则b)规则的组成部分Condition:条件名称,由规则处理器计算的表达式,以确定规则是否能够适用。

Class Name:类名,权限规则将适用于指定类的所有对象,类可以是抽象类或者是实例化的类。

Inherit:继承,该标志指明规则是仅仅适用于所指定的类(取值为FALSE),还是包括该类和该类的子类(取值为TRUE)。

Message Name/Message Group Name:消息名称/消息组名称,指明该规则将授予权限的操作类型。

Participant:参与者,指明该规则适用的用户、用户组或者角色。

规则的组成可以用图9形象表示。

图9 规则的组成部分c)静态权限设计四要素参与者条件类操作1.2.6 授权用户可以对文档进行某项操作,通过将这种操作授权给别的用户,使被授权的用户也可以执行该操作。

授权的目的就是为了使用户获得相关权限,可以进行浏览或复制等操作。

授权的过程如图10、11、12所示。

图10 授权页面图11 填写相关信息图12 授权成功1.2.7 流程权限用户在流程中的权限是为流程参与者指定所使用的消息或消息组来实现的,这在1.1.4节已经提到了。

1.2.8 权限消息组和流程中的消息组一样,将一组操作功能组合在一起,可以减少权限控制的工作量。

比如一个用户需要查找一个对象,可能要用到下列消息:Expand_grpGetInfo_grpQuery_grp LcmProcessHistory_grpQueryObj_grpReport_grp如果没有Query_grp消息组,那么用户访问这些消息就需要写五条规则,而如果采用消息组,那么就只需要书写一条规则。

1.2.9 权限跟踪通过使用权限跟踪,可以获得某一操作的规则报告,从中得知权限的相关信息。

何时使用权限跟踪:¾确定权限时¾某一用户拥有超出他权限范围之外的操作,比如删除不允许删除的对象¾确定静态权限是否起作用如何进行权限跟踪:¾在config.cfg文件中设定下面的参数变量set "RDBBROWSER" "C:\\Program Files\\Internet Explorer\\iexplore.exe";set "RDBERRORLOG" "D:\\ygstst\\ygsdir\\ruledebuger\\rdberror.log";set "RDBTRACEFLAG" "1";set "RDBTRACEUSER" "user1";set "RDBTRACEFILE" "D:\\ygstst\\ygsdir\\ruledebuger\\trace.txt";¾重新启动系统mux和dsp服务¾以用户user1登陆,做相关的操作,在系统的目录D:\ygstst\ygsdir\ruledebuger 下查看文件trace.txt****2 流程、权限在我所PDM系统中的实现2.1 流程的实现过程2.1.1 所内调研情况PDM系统调研阶段,我们在所内各部门进行了1个多月的详细调研。