增强的升级进程
当前没有预设解决方案,无法将升级对象刷新至其最新小版本,也无法自动修订通过修订版本系列更改升级的升级候选对象。
背景
在升级请求审阅和批准进程中,参与者发现与升级候选对象相关问题并不罕见。与拒绝升级请求相比,引入返工循环会使得进程更高效。此返工循环允许升级请求的创建者审阅备注,对升级候选对象进行适当的调整,并使工作流自动刷新升级请求以进行其他审阅和批准。
在结果将为验证错误时,避免发送升级目标进行批准也是一种好的做法。返工循环是否包含此验证取决于升级目标的当前小版本或刷新的小版本 (如果已启用“自动刷新”)。
对于使用升级请求作为生产的“关口审阅”的公司,最好是将对象的修订版本标签从数字系列切换到字母数字系列。使用正确的生命周期设计,可对此类关口状态进行建模,以实现所需的目标状态,并自动将升级候选对象修订为新修订版本系列的初始修订版本标签。
范围/适用性/假设
这些说明假设已事先掌握有关修改工作流进程以及如何在工作流中调用 Windchill 方法的知识。
预期结果
预期目标是使您能够将自动刷新或自动修订功能添加到您的自定义工作流。
解决方案
系统预设的升级请求进程模板用于说明如何实现自动刷新和自动修订功能。模板中还包括审阅验证。
必备知识
要获得此结果,需要了解以下内容:
基础 Java 开发
工作流进程修改包括计数表达式和自动机表达式
资源束文件的管理。
Windchill 首选项管理实用程序
* 
出厂时提供的工作流进程模板不应直接修改。在修改这些进程模板之前应对其进行重命名。
解决方案元素
元素
类型
说明
wt.maturity.MaturityServerHelper.service.unlockTargets (pn)
方法
此方法调用可添加到工作流表达式中,以便在这种情况下解锁升级目标以进行返工。这样做的结果是升级目标将处于创建升级请求时的状态。解锁升级目标可能会允许分配用户进行返工以对对象执行更新 (受访问控制)。
wt.workflow.work.WfTally
此类用于对工作流任务的投票进行计数。例如,如果将任务分配给批准角色,则可以有多个用户收到该任务且这些用户可通过不同方式进行投票。此类提供了方法,可根据 "all have to vote for that option" 或 "any have to vote for that option" 来定义要采用的路由。
com.ptc.windchill.enterprise.maturity.PromotionNoticeWorkflowHelper.refresh(pn);
方法
此方法可添加到用于提供升级对象更新处理的工作流表达式中。在内部,此方法使用新的首选项“最新小版本刷新”来控制行为。值如下所示
1. 刷新升级候选对象 (默认设置)。此值仅刷新升级候选对象。
2. 刷新所有对象。此值将刷新所有升级对象:升级候选对象和成熟度基线中的其他对象。
3. 不执行任何操作。此选项不会刷新任何升级对象。
4. 验证升级目标。(有关详细信息,请参阅“过程 - 验证返工中的升级目标”一节。)
wt.maturity.MaturityServerHelper.service.lockTargets (pn);
方法
此方法调用可添加到将锁定升级目标的工作流表达式中。只有具有锁定转变的升级目标才会受锁定约束。
com.ptc.core.ui.validation.UIValidationResultSet set= com.ptc.windchill.enterprise.maturity.PromotionNoticeWorkflowHelper.revisePromotables(pn, pn.getCreator(), locale);
方法
可将此方法添加到工作流表达式,以自动修订升级对象。在内部,此方法使用两个新的首选项:
1. 自动修订模式。有 3 种模式:
a. 不执行任何操作。
此模式不会执行任何自动版本修订。
b. 仅自动修订升级候选对象。
此模式将仅自动修订升级候选对象
c. 仅自动修订版本方案已更改的升级候选对象
此模式仅修订那些将被修订为可导致版本方案发生更改的状态的升级候选对象。
2. 自动修订状态。
此首选项是一个多值列表,其中包含对于自动版本修订有效的状态。此首选项仅在“自动修订模式”首选项不是“不执行任何操作”时才会生效。
过程 - 添加自动刷新
可对升级请求使用的自定义工作流进程模板进行修改以支持自动刷新。以下示例将概述在出厂设置时提供的“升级请求批准进程”的最新小版本中使用的过程。
在本示例中,已添加返工循环。循环从批准升级请求任务开始。升级批准者的成员会收到此任务。已将附加路由添加到批准升级请求任务 (称为返工)。
在本示例中,定义了用于根据所有批准者的投票来确定采取路由的计数表达式。
Vector v = new Vector();
v.addElement("Approve");
v.addElement("Reject");
v.addElement("Rework");
Vector vResult = wt.workflow.work.WfTally.any(self, v);
if( vResult.contains("Rework")) {
result = "Rework";
} else if ( vResult.contains("Reject") ) {
result = "Reject";
}else {
vResult = WfTally.all(self,v);
if( !vResult.isEmpty() ) {
result = (String)vResult.get(0);
}
}
此表达式指示有任何批准者选择返工时,系统将执行返工选项。如果没有任何批准者选择返工,但有任一批准者选择“拒绝”,则采取“拒绝”。否则,将采用“批准”路径。
批准者任务不再包含特殊说明。但是,存在一个名为 special_instructions 的进程变量。此字段适用于整个进程,因此可通过编程进行设置。增强工作流将使用批准升级请求任务的备注字段来收集批准者对返工进行投票的备注字符串。设置此字符串旨在收集返工特殊说明。例如,如果批准者角色中有三个用户:user1、user2 和 user3。
User1 投票批准,备注:“看起来不错”
User2 投票返工,备注:“修改”
User3 投票返工,备注:“调整大小”
在这种情况下,返工者将收到包含特殊说明的任务:
[User2]:修改
[User3]:调整大小
选择返工路线后,升级目标将被锁定以进行返工,并且升级创建者将收到返工升级请求任务。此任务将提供由批准者所提供的需要返工升级项的特殊说明。此特殊说明字段对于批准任务是可写入字段,而对于返工任务是只读字段。然后,创建者可以为此任务迭代某些可升级对象。创建者可以决定升级不再可行,并且可以选取拒绝选项。在这种情况下,升级请求将被拒绝。
执行返工的用户仅可更新其有权修改的对象。如果升级请求的内容不能进行修改,则升级请求的主返工将请求拒绝,随后进行一个具有返工项的新升级请求。返工循环旨在解决一些小问题,如排版错误、数量或单位问题、次要几何更改,而不是解决重大结构更改。
升级创建者选择“提交”选项后,升级请求将执行“刷新升级对象”表达式。
wt.maturity.PromotionNotice pn = (wt.maturity.PromotionNotice)primaryBusinessObject;
try
{
com.ptc.windchill.enterprise.maturity.PromotionNoticeWorkflowHelper.refresh(pn);
wt.maturity.MaturityServerHelper.service.lockTargets (pn);
catch( Exception wte )
}
{
wte.printStackTrace();
}
PromotionNoticeWorkflowHelper.refresh(pn) 方法将按照“解决方案”部分中定义的首选项规则将升级对象刷新为其最新小版本。最后,该循环完成,同时批准者会再次收到批准升级请求任务。如果支持锁定,将调用包括到 lockTargets(),以确保在批准前不会无意修改升级目标非常重要。
FIT 表
以下 FIT 表将介绍“最新小版本刷新”首选项如何影响自动刷新。
可升级
是升级目标
最新小版本刷新首选项值
符合刷新条件
part_1
不可用
不执行任何操作
false
part_2
Y
刷新升级候选对象
true
part_3
Y
全部
true
part_4
N
刷新升级候选对象
false
part_5
Y
全部
true
过程 - 添加自动版本修订
可对升级请求使用的工作流模板进行修改以支持自动版本修订。
以下示例将概述在出厂设置时提供的“升级请求批准进程”的最新小版本中使用的过程。
在本示例中,添加了一个附加条件表达式。它将添加到升级目标的条件之后。条件如下所示:
展开的路由表达式:
wt.maturity.PromotionNotice pn = (wt.maturity.PromotionNotice)primaryBusinessObject;
try
{
java.util.Locale locale = wt.session.SessionHelper.getLocale();
com.ptc.core.ui.validation.UIValidationResultSet set= com.ptc.windchill.enterprise.maturity.PromotionNoticeWorkflowHelper.
revisePromotables(pn, pn.getCreator(), locale);
reviseValidationMsg= com.ptc.windchill.enterprise.maturity.validators.PromotionTargetsReviseValidator.getReviseResultSetMessage(set, locale);
if (!reviseValidationMsg.isEmpty() )
result="Partial";
else
result="Full";

}
catch( Exception wte )
{
wte.printStackTrace();
}
方法 revisePromotables(pn, pn.getCreator(), locale); 会遵循上文在“解决方案”部分中定义的首选项来执行升级对象的版本修订。
在对符合条件的升级对象进行修订后,将创建一则消息,其中包含不符合升级条件的升级目标以及升级对象不合格的原因。此消息将发送到升级创建者。将修订任何有效的升级目标,而无论是否存在任何不合格的目标。
* 
一起升级 CAD 文档和部件时,如果修订不合格项目为部件或 CAD 文档,则这些对象将不会一起修订,并且需要在升级后由升级请求创建者 (或其他用户) 集中修复。
作为关口审阅进程的升级进程
对于使用升级请求作为生产的“关口审阅”的公司,最好是将对象的修订版本标签从数字系列切换到字母数字系列。使用正确的生命周期设计,可对此类关口状态进行建模,以实现所需的目标状态,并自动将升级候选对象修订为新修订版本系列的初始修订版本标签。
以下 FIT 表格说明此方案如何根据“解决方案”部分中所述的各种首选项值来使用。
可升级
是基于生命周期状态
首选项
首选项值
首选项
首选项值
对修订有效
part_1
自动修订状态
Released
自动修订模式
自动修订所有升级候选对象
part_2
自动修订状态
Released
自动修订模式
仅自动修订版本方案已更改的升级候选对象
part_3
自动修订状态
Released
自动修订模式
仅自动修订版本方案已更改的升级候选对象
part_4
自动修订状态
In Work
自动修订模式
自动修订所有升级候选对象
对于本示例,升级请求的成熟度状态为“已发布”。此外,每个部件都位于其自身的唯一容器中。
过程 - 验证返工中的升级目标
在“过程 - 添加自动刷新”一节中详细介绍的自动刷新功能已进行了扩展,以检查:升级目标是否有更高的小版本要进行刷新,此小版本对于升级是否有效。进行了以下检查:
升级目标未检出。
创建者具有升级目标的修改权限。
升级目标的生命周期自创建升级后未发生更改。
升级目标的状态自创建升级后未发生更改。
工作流模板
这里是已展开的升级通告工作流模板,包含验证。
已添加用于执行上述检查的条件。将向创建者发送电子邮件,其中包含无法升级的升级目标列表 (如果有)。如果升级请求的某些目标无法升级,则会将升级请求发送回来以进行返工,此时,创建者可以提交或拒绝。如果所有目标均有效,则会发送升级请求以进行审批。
这对您有帮助吗?