Windchill 工作流的提示和技巧
Windchill 工作流的提示和技巧
以下提示和技巧汇集了有关工作流的一系列实用研究成果。特别地，对经历其生命周期（由工作流自动化）而成熟的业务对象进行了重点说明。
一般指南：
工作流适用性
工作流通常在业务对象实例的基础上（如文档、部件、变更请求等）与生命周期一起应用。在设计工作流时，请记住进程（工作流的实例）应用于修订版本。这意味着：
- 进程实例将为给定对象修订版本的所有小版本执行一次
- 不同的修订版本将通过不同的进程实例
也可以独立于业务对象来实例化工作流，但通常不会这样做。通常，使用工作流的诱因是：存在着通过进程路由并且经过一系列状态而成熟的概念数据包。
在 Windchill PDMLink 中，工作流通常在对象创建时启动。在 Windchill ProjectLink 中，专门通过使用路由功能为对象启动工作流，而且也以协调的方式启动以自动执行项目计划。
此外，在 Windchill PDMLink 中，升级功能会启动类似于 Windchill ProjectLink 路由的功能，用于多对象的状态转变管理。
工作流与生命周期
工作流自动执行公司的作业程序，具体做法是定义一组基于用户的和系统自动化的任务，定义任务关联和路由规则，并提供自动交付的用户体验。要看到进程状态，最简单的方法其实是使用生命周期状态。可直接在业务对象上看到生命周期状态，而且该状态可由工作流进程控制。生命周期提供以下功能：
- 测量和显示信息成熟度等级
- 搜索条件
- 按状态控制对数据的访问的方法
- 可关联到工作流
可使用进程监视器以图形方式了解详细的进程测量信息。这些信息非常有用，并且非常丰富。但是，生命周期状态通常传递的是对象在进程中处于哪个位置的经过简化的恰当信息。
生命周期管理的对象
生命周期管理的对象与一个生命周期模板关联，并在每个状态的基础上与一个或多个工作流模板关联。对于报告数据的成熟度、按成熟度控制对该数据的访问，以及为该数据提供基于状态的过滤器而言，生命周期状态很重要。在不需要基于状态的行为时，建议开发继承对象模型中的高层对象的对象。文件夹驻留对象是较简单的对象类的示例。特别是在涉及到大量对象实例的情况下，从尽可能最简单的对象类继承能提供最佳性能。
容器策略
在 Windchill 中，工作流模板可存储在三个基本级别上 — 站点、组织和容器。建议将工作流模板存储在最高的级别上，以便能够重新使用。例如，如果所有组织均可利用某个工作流模板，则应将其存储在站点级别上。工作流模板的重新使用是一个非常有用的概念，因此应对其加以考虑。如果工作流模板确实只在单个存储库中相关，则很可能应在该存储库中管理它。如果工作流模板确实不可重新使用，则将该模板存储在最低的级别上（如存储库）是一个很好的做法，因为这样做减少了可能在整个系统中造成的混乱。
工作流定义：
活动
- 定义新的活动时，标识负责角色。在活动逾期和/或进程出错时将通知的人员由负责角色确定
- 输入活动说明。系统将显示此说明以供审阅进程模板之用，它也可以显示在工作列表中。可以包含 URL 以引用更详细的文档，或提供对存储表单模板的现成访问以连接到业务对象。
- 有指示告诉您应针对任务做些什么。在这里，您应解释为何要指定某项任务、何时单击“任务完成”按钮，以及之后将会发生什么情况。提供的信息（支持 html 格式）越多越好
- 确保最终用户对信息具有正确的访问权限（读取、修改等）。通过在域级别应用这些访问策略，可以跨现有的全部业务对象轻松地在下游调整这些策略，但必须考虑到在正在执行的工作流进程上更改 ACL 所带来的影响
- 在某些情况下，必须提供特定的“基于活动的”访问权限，原因是访问控制特定于该实例及其活动。通常，只应在最复杂的工作流情况下使用这些权限
工作流变量
- 建议不要在工作流变量名称中使用“空格”字符。Windchill 允许在工作流变量中使用“空格”。但是，这些字符在工作流自动机 java 代码中不可用
- Java 基元是最常用和建议使用的工作流变量。它们优于工作流任务表单中的现成用户界面
- Windchill 工作流的变量跟踪功能非常强大。由于工作流变量在存留到数据库时是序列化的，因此，留意该类是如何序列化的非常重要。如果序列化签名在进程的两次发放之间有变化，则会遇到进程实例包含不可解码的序列化变量的风险。因此，如果更改对象的序列化签名，则为所有以前的签名提供序列化支持很重要
并行活动
- 在多个并行活动连接到一个分支中时，使用“和”或“或”连接器（图 1 和 2）
循环链接
- 应将工作流路径中第一个可使用多次的链接标识为“循环链接”（图 3）
在几乎所有工作流实施中，都建议将单个父工作流与生命周期关联，以控制对象的所有可能状态。以下是此建议背后的一些原因：
- 管理工作流与生命周期的一个关联要比为每个阶段单独管理一个关联更轻松
- 跨所有活动共享变量
- 跨不同的生命周期状态共享变量
- 使用单个工作流时，可以在任何活动上定义循环。不能在各个独立的进程中的活动之间循环
- 进程的开销越少，性能就越佳
- 正在运行的进程实例较少会使管理和监视变得更轻松
父工作流不必太大或太复杂。可以将此工作流分解为多个块和子进程，这样就能获得单个父工作流下的重新使用性优点和复杂性降低的优点，就像您在与每个阶段和关口关联的工作流下所获得的这些优点一样。
活动的角色在运行时得到解析，这样就能重新使用工作流。角色解析只是一种指定参与某个活动的行为的机制。
从在该活动中指定的团队按名称或变量来解析角色，或者从对象的团队来解析角色。对象的团队使用团队模板、生命周期模板和上下文团队（对于 Windchill PDMLink 和 Windchill ProjectLink）进行解析。
- 对象类型的对象初始化规则为该对象声明生命周期和团队模板
- 在对象实例化时，会为该对象创建和初始化团队实例
- 团队角色由生命周期模板和团队模板角色联合确定。注意这并不包括容器角色
- 角色成员资格由容器团队和团队模板联合确定
- 如果角色在团队模板中不存在，则角色成员资格由容器团队和生命周期模板联合确定
- 请注意，如果在创建对象后修改了容器团队或团队模板，并希望这些修改在进程中始终保持最新状态，则必须扩大（刷新）对象的团队
工作流 Java 代码
请注意，活动的 Java 代码被限制为 2000 个字符，因此将需要创建类才能进行更复杂的处理。
静态代码
- 使用静态代码调用帮助程序（本身又调用服务器的方法）
- 应尽可能减少工作流中的 Java 代码，使清晰的工作流编码主要包含对帮助程序类的调用。这允许重新使用工作流帮助程序功能，而且还通过模块化提高了测试效率
异常处理
须正确处理异常，因为不正确的异常处理会：
- 隐藏异常并且不采取任何操作
- 造成工作流未完成
- 引起不想要的行为
好的做法是：
- 返回“结果”属性，以便明确地路由工作流进程
- 返回“错误消息”属性，以便工作流的下一步获得要提供的一些信息
测试
- 如果工作流包含多段 Java 代码，则先使用小型的独立 Windchill 客户端应用程序测试此代码（与工作流分隔开）。还要经常执行“验证代码”以确保代码起作用。
同步
工作流测试
- 小版本：在测试工作流之前在工作流上执行检入。如果忘记检入工作流模板，则在终止已启动的工作流实例之前，将无法再修改工作流模板
- 流逻辑：审阅者应检查流逻辑是否合理，以确保没有未终止的路径
- 所有循环路径均应包含图 4 中以红色表示的循环链接
- 如果每个循环只能激发一条路径，则多条路径可以会合到任务上。在图 7 中，三条路径会合在一起，但一次只能激发一条路径
- 最新的工作流实例：生命周期应始终指向最新的工作流小版本
- 验证工作流：在工作流编辑器中，执行“全部验证”命令
- 语法检查：在工作流编辑器中，为所有表达式自动机、任务计数、Java 代码等执行“检查语法”
- 数据：如果工作流修改它所应用于的数据，或甚至修改状态，则使用 csv 载入文件来创建测试数据可能很有帮助。这允许快速删除和重新载入数据，以供其他测试之用
wt.org.WTPrincipal creator=(wt.org.WTPrincipal)wtcr.getCreator().getObject(); wt.session.SessionHelper.manager.setPrincipal( creator.getName() );
wt.lifecycle.LifeCycleHelper.service.reassign(wtcr,wt.lifecycle.LifeCycleHelper.service.getLifeCycleTemplateReference(“My Lifecycle Template”));
转：http://www.pisx.com/bbs/topic.php?filename=7347&extra=page%3D57