评估发布规则
下面几节介绍评估“发布规则”的事件和逻辑。
触发发布规则评估的事件
如启用发布规则中所述，发布规则评估可由以下事件触发：
• 检入 EPMDocument。
• 安排发布 EPMDocument。
• 用户在“EPMDocument 的表示列表”(或其关联的 WTPart 的“表示列表”) 中选择“新建表示”操作。
• 从任何其他事件 (如手动重新发布、更改的重新发布或工作流启动等) 中产生的发布作业。
评估发布规则逻辑
本节介绍发布规则评估的逻辑并包括发布规则文件的片段。除非另有说明，否则评估过程将使用区分大小写的字符串比较。
发布规则文件是一个组成良好的 XML 文档，以 <rules> 作为其根元素。
请注意本节试图提供评估过程的高度概述。成功构建您自己的发布规则文件所需的许多详细信息将在后面的几节中提供。另请参阅发布规则 XML 文件示例。
 |
发布规则文件中的参数和值区分大小写。
|
步骤 1：匹配 <authoring-application>
对于在 WVS 特性 publish.usesPublishRules 中指定的每个创作应用程序，<rules> 元素都必须有一个 <authoring-application> 子项。
例如，要将 Arbortext 和 Creo Parametric 指定为创作应用程序，应使用以下命令：
<rules>
<authoring-application name=”ARBORTEXT”>
*
*
*
</authoring-application>
<authoring-application name=”PROE”>
*
*
*
</authoring-application>
</rules>
<authoring-application name=”ARBORTEXT”>
*
*
*
</authoring-application>
<authoring-application name=”PROE”>
*
*
*
</authoring-application>
</rules>
一般情况下，概念为：
<rules>
<authoring-application name=”MY_AUTH_APP”>
*
*
*
</authoring-application>
</rules>
<authoring-application name=”MY_AUTH_APP”>
*
*
*
</authoring-application>
</rules>
发布规则评估搜索 "name" 属性和 EPMDocument 的创作应用程序匹配的 <authoring-application> 元素。若未找到匹配，则不会生成发布作业；否则进行评估的步骤 2。
步骤 2：匹配 <epm-number>
通过在步骤 1 中匹配的 <authoring-application> 元素的子项中搜索其 "number" 属性与 EPMDocument 的编号匹配的 <epm-number> 元素，评估继续进行。
|
|
<authoring-application> 元素可以有 <epm-number> 元素以外的子项；在此步骤中将忽略这些元素，即使它们先于 <epm-number> 元素出现在发布规则 XML 文件中。
|
<authoring-application name=”MY_AUTH_APP”>
<epm-number number=”1111”>
*
*
*
</epm-number>
<epm-number number=”2222”>
*
*
*
</epm-number>
</authoring-application>
<epm-number number=”1111”>
*
*
*
</epm-number>
<epm-number number=”2222”>
*
*
*
</epm-number>
</authoring-application>
如果找到匹配，则匹配的 <epm-number> 元素将成为搜索 <publish> 元素的根，该元素将在步骤 8 中介绍；否则进行评估步骤 3。
步骤 3：在存在 "value" 属性的情况下，匹配 <epm-iba>
可通过在步骤 1 中匹配的 <authoring-application> 元素的子项中搜索与 EPMDocument 中的全局属性名称/值对相对应的 <epm-iba> 元素继续进行评估。
|
|
<epm-iba> 的 "value" 属性是可选属性；步骤 3 仅考虑具有 "value" 属性的 <epm-iba> 元素。在步骤 4 中，将讨论当没有任何“值”属性存在时会发生什么情况。
|
<authoring-application name=”MY_AUTH_APP”>
<epm-iba iba=”IBA_NAME_1” value=”IBA_VALUE_1”>
*
*
*
</epm-iba>
<epm-iba iba=”IBA_NAME_2” value=”IBA_VALUE_2”>
*
*
*
</epm-iba>
</authoring-application>
<epm-iba iba=”IBA_NAME_1” value=”IBA_VALUE_1”>
*
*
*
</epm-iba>
<epm-iba iba=”IBA_NAME_2” value=”IBA_VALUE_2”>
*
*
*
</epm-iba>
</authoring-application>
如果找到匹配，则匹配的 <epm-iba> 元素成为搜索 <publish> 元素的根，该元素将在步骤 8 中介绍；否则进行评估步骤 4。
步骤 4：在不存在 "value" 属性的情况下，匹配 <epm-iba>
可通过在步骤 1 中匹配的 <authoring-application> 元素的子项中搜索其 "iba" 属性与 EPMDocument 中的全局属性名称相匹配的 <epm-iba> 元素继续进行评估。
|
|
<epm-iba> 的 "value" 属性是可选属性；步骤 4 仅考虑不具有 "value" 属性的 <epm-iba> 元素。满足此条件的 <epm-iba> 元素将按照其在发布规则 XML 文件中出现的顺序来进行考虑。
|
<authoring-application name=”MY_AUTH_APP”>
<epm-iba iba=”IBA_NAME_1”>
*
*
*
</epm-iba>
<epm-iba iba=”IBA_NAME_2”>
*
*
*
</epm-iba>
</authoring-application>
<epm-iba iba=”IBA_NAME_1”>
*
*
*
</epm-iba>
<epm-iba iba=”IBA_NAME_2”>
*
*
*
</epm-iba>
</authoring-application>
如果找到匹配，则匹配的 <epm-iba> 元素成为搜索 <publish> 元素的根，该元素将在步骤 8 中介绍；否则进行评估步骤 5。
步骤 5：匹配 <epm-type>
通过在步骤 1 中匹配的 <authoring-application> 元素的子项中搜索其 "type" 属性与 EPMDocument 的对象类型匹配的 <epm-type> 元素，评估继续进行。"type" 属性的值是 EPMDocument 的“内部名称”。内部名称是在 Windchill“类型和属性管理”实用程序中定义的。
要在处理过程中设置全局属性，则必须首先在“类型和属性管理”实用程序中定义类型的全局属性。有关详细信息，请参阅使用类型和属性管理实用程序。
<authoring-application name=”MY_AUTH_APP”>
<epm-type type=”MyLogicalId”>
*
*
*
</epm-type>
<epm-type type=”AnotherLogicalId”>
*
*
*
</epm-type>
</authoring-application>
<epm-type type=”MyLogicalId”>
*
*
*
</epm-type>
<epm-type type=”AnotherLogicalId”>
*
*
*
</epm-type>
</authoring-application>
如果找到匹配，则匹配的 <epm-type> 元素成为搜索 <publish> 元素的根，该元素将在步骤 8 中介绍；否则进行评估步骤 6。
步骤 6：贯穿匹配
如果评估在上述步骤中未找到搜索根，<authoring-application> 元素将成为搜索 <publish> 元素的根。在步骤 8 中将介绍发布元素。
以下是贯穿发布的示例：
<authoring-application name=”MY_AUTH_APP”>
<epm-number number=”1111”>
*
*
*
</epm-number>
<epm-type type=”MyInternalName”>
*
*
*
</epm-type>
<!-- Begin: Fall-through search root -->
*
*
*
<!-- End: Fall-through search root -->
</authoring-application>
<epm-number number=”1111”>
*
*
*
</epm-number>
<epm-type type=”MyInternalName”>
*
*
*
</epm-type>
<!-- Begin: Fall-through search root -->
*
*
*
<!-- End: Fall-through search root -->
</authoring-application>
在此示例中，如果 EPMDocument 的编号不是 1111 或没有内部名称 "MyInternalName"，则 <authoring-application> 将成为搜索根 (如上面的 Begin 和 End 注解行之间所提到的那样)。
|
|
不建议使用贯穿匹配，因为如果这样，您在特定创作应用程序的任何 EPMDocument 上都将无法绕过发布。测试发布规则时贯穿匹配很有用，可使您将注意力仅集中在匹配 <authoring-application> 上。
|
步骤 7：匹配 <structure-type>
可通过在步骤 1 中匹配的 <authoring-application> 元素的子项中搜索其 type 属性与所发布结构的类型相匹配的 <structure-type> 元素在步骤 7 中继续进行评估。type 属性的值可为 epm、part、epm_plus_parts、part_and_epm、epm_wc_structure、epm_wc_structure 或 type_based_object_structure。步骤 2 到 步骤 6 确定了用于搜索 <publish> 元素的根。此根可能是 <epm-number>、<epm-iba>、<epm-type> 或 <authoring-application> 元素。
<authoring-application name=”PARTLIST”>
<structure-type type=”type_based_object”>
*
*
</structure-type>
<structure-type type=” type_based_object_structure”>
*
*
</structure-type>
</authoring-application >
如果找到了匹配，则匹配的 <structure-type> 元素将成为搜索 <publish> 元素的根；否则，<authoring-application> 元素将成为搜索 <publish> 元素的根。在这种情况下，可将 <authoring-application> 元素视为步骤 6 中所描述的“贯穿”条件。搜索 <publish> 元素将在下一步骤中进行说明。
步骤 8：匹配 <publish>
步骤 2 到 步骤 6 确定了用于搜索 <publish> 元素的根。此根可能是 <epm-number>、<epm-iba>、<epm-type> 或 <authoring-application> 元素。
如果根的 "on" 属性与引起调用发布规则评估的事件相匹配，系统将为该根的每一个 <publish> 元素子项创建一个发布作业。如果没有匹配的 <publish> 元素，则不会创建发布作业。
< … root for publishing … >
<publish on=”checkin” param-set=”SET1”/>
<publish on=”checkin”/>
<publish on=”schedule” output=”VALID_WORKER_OUTPUT” param-set=”SET1”/>
<publish on="checkin" overlay-recipe-file="RECIPE_FILE_NAME"/>
</ … end of root for publishing … >
<publish on=”checkin” param-set=”SET1”/>
<publish on=”checkin”/>
<publish on=”schedule” output=”VALID_WORKER_OUTPUT” param-set=”SET1”/>
<publish on="checkin" overlay-recipe-file="RECIPE_FILE_NAME"/>
</ … end of root for publishing … >
对每个匹配，系统处理匹配 <publish> 元素的属性。可能的属性如下所示：
• on - 可能的 "on" 值与本部分开头介绍的触发器相关。它们是 "checkin"、"schedule"、"create-representation" 和 "unknown-source"。(本文档后面会介绍名为 "manual-post" 的第五种触发器。有关详细信息，请参阅手动发布后。)在上例中有三个 "on" 值：其中的两个用于检入，另一个用于安排。如果由于检入 EPMDocument 触发了发布规则评估，将创建两个发布作业。如果由于 EPMDocument 的已安排作业而触发评估，则创建一个发布作业。如果是由于用户界面中的手动“新建表示”向导而导致的触发，则不会创建发布作业。
• 输出 - 如果出现 "output" 属性 (如上面第三 <publish> 行所示)，那么，它将成为可被工作器使用的发布作业中信息的一部分。此属性的使用并不是对所有工作器都有效。
• param-set - 如果 "param-set" 属性出现，系统将在发布规则 XML 文件中搜索 "name" 属性与 "param-set" 属性的值相匹配的 <param-set> 元素。步骤 9 将介绍如何处理匹配的 <param-set> 元素。在上面的示例中，param-set 的值为 "SET1"。
• param-set-ref - 如果在 <publish on=...> 元素块中出现 <param-set-ref...> 子元素，系统将在发布规则 XML 文件中搜索 "name" 属性与 param-set-ref "name"属性的值相匹配的 <param-set...> 元素。可以添加多个 <param-set-ref...> 子元素，每个子元素参考相同 XML 文件中不同的 param-set 定义，以调用单个 <publish on=...> 元素块的多个后发布委派。
• overlay-recipe-file - 如果存在 "overlay-recipe-file" 属性 (如上面的第四个 <publish> 行所示)，则会在“可视化配置管理”用户界面中搜索与 RECIPE_FILE_NAME 值匹配的文件，如果能找到，则会将此文件与“发布作业”的其他文件一起发送到工作器。随后，工作器会使用此覆盖脚本文件来生成表示或可视项。
|
|
如果不存在具有指定名称的覆盖脚本文件，则发布作业会失败。在这种情况下，如果不需要，请从发布规则中移除属性 "overlay-recipe-file"，或者输入正确的文件名。
|
步骤 9 将介绍如何处理匹配的 <param-set-ref> 元素。
步骤 9：处理 <param-set-ref>
在单个 <publish on=...> 元素块中使用 <param-set-ref> 子元素，以参考相同 XML 文件中的多个 <param-set> 元素定义，以便 (例如) 利用 AdditionalFilesPostPublishDelegate 配置不同“其他文件类型”的后发布，为每个文件类型创建单独的 WTDDocument 对象。
<publish on="checkin” display-label="CAD Part - Check-in" additional-files="part_files">
<param-set-ref name="Additional Files Post Publish to STEP Document"/>
<param-set-ref name="Additional Files Post Publish to IGES Document"/>
</publish>
<param-set-ref name="Additional Files Post Publish to STEP Document"/>
<param-set-ref name="Additional Files Post Publish to IGES Document"/>
</publish>
有关语法插图，请参阅 <Windchill>/codebase/com/ptc/wvs/server/xml 中的 PublishRules-AdditionalFiles.xml 文件。
步骤 10：处理 <param-set>
<param-set> 元素可以出现在发布规则 XML 文件中的 <rules> 标记之间的任何地方。它经常用于从若干 <publish> 元素中引用相同的 <param-set> 元素。<param-set> 元素的子项包含作为发布作业一部分的信息。该信息包含在下列元素中：
post-publish - 这些元素用于向 PostPublishDelegate 传递必要的信息。有关详细信息，请参阅发布后。
iba - 这些元素也用于向 PostPublishDelegate 传递可选信息。有关详细信息，请参阅发布后。
要在处理过程中设置全局属性，则必须首先在“类型和属性管理”实用程序中定义类型的全局属性。由于发布规则位于包含字符串的 XML 文件中，因此需要了解要传递到后发布委派的非字符串值的表示方式。有关详细信息，请参阅使用类型和属性管理实用程序。
以下是一个包含受支持的全局属性以及每个全局属性示例值的列表：
<iba name="com.ptc.MyTypeBoolean">Yes</iba>
<iba name="com.ptc.MyTypeDateTime">2007-07-13 11:12:32</iba>
<iba name="com.ptc.MyTypeInteger">36</iba>
<iba name="com.ptc.MyTypeRealNumber">0.12321345</iba>
<iba name="com.ptc.MyTypeRealUnitsArea">25 m**2</iba>
<iba name="com.ptc.MyTypeString">string test</iba>
<iba name="com.ptc.MyTypeURL">http://www.ptc.com (PTC)</iba>
<iba name="com.ptc.MyTypeDateTime">2007-07-13 11:12:32</iba>
<iba name="com.ptc.MyTypeInteger">36</iba>
<iba name="com.ptc.MyTypeRealNumber">0.12321345</iba>
<iba name="com.ptc.MyTypeRealUnitsArea">25 m**2</iba>
<iba name="com.ptc.MyTypeString">string test</iba>
<iba name="com.ptc.MyTypeURL">http://www.ptc.com (PTC)</iba>
worker - 此元素用于向工作器传递额外的信息 (如果该工作器支持此操作)。工作器由评估过程中使用的 EPMDocument 的创作应用程序来确定。
这些元素具有相同的结构；各元素都具有用于标识参数的 "name" 属性，并且元素的文本内容是该参数的值。
<param-set name=”SET1”>
<post-publish name=”name1”>VALUE1</post-publish>
<post-publish name=”name2”>VALUE2</post-publish>
<iba name=”iba_name1”>IBA_VALUE1</iba >
<iba name=”iba_name2”>IBA_VALUE2</iba >
<worker name=”worker_info_name”>WORKER_INFO_VALUE</ worker >
</param-set>
<post-publish name=”name1”>VALUE1</post-publish>
<post-publish name=”name2”>VALUE2</post-publish>
<iba name=”iba_name1”>IBA_VALUE1</iba >
<iba name=”iba_name2”>IBA_VALUE2</iba >
<worker name=”worker_info_name”>WORKER_INFO_VALUE</ worker >
</param-set>
<param-set> 元素可有任意数量的 <worker>、<post-publish> 和 <iba> 元素；然而，这些元素出现的顺序十分重要，这一点和其他大多数评估步骤不同。当步骤 8 匹配了某个 <publish> 元素时，评估过程会为每个元素构建一个内部表，例如 <worker> 表、<post-publish> 表和 <iba> 表。<param-set> 元素的子项按照其在文件中的出现顺序来检索。
处理各个子项时，会用名称/值对填充表格。参数名称在每个表中必须唯一，但在各个表之间不必唯一。(例如，<post-publish> 名称和 <iba> 名称可以相同，但两个 <post-publish> 的名称不能相同。)
处理子项时，如果之前遇到过该子项的参数标识符，则会用新参数值更新其表格条目，从而替换之前遇到的同名值。
<param-set> 元素也可能有 <include> 元素子项。<include> 元素将与指定 <param-set> 关联的参数添加到表格。这与调用子程序的过程类似。
<param-set name=”SET1”>
<include param-set=”COMMON”/>
<post-publish name=”name”>From SET1</post-publish>
</param-set>
<param-set name=”COMMON”>
<post-publish name=”name”>From COMMON</post-publish>
</param-set>
<include param-set=”COMMON”/>
<post-publish name=”name”>From SET1</post-publish>
</param-set>
<param-set name=”COMMON”>
<post-publish name=”name”>From COMMON</post-publish>
</param-set>
在上面的片段中，如果在发布规则文件中引用了 SET1 <param-set>，则 <post-publish> 参数 "name" 的值将为 "From SET1"，这是因为 SET1 中的 <include> 元素应显示在 <post-publish> 元素之前。如果两个元素位置颠倒，则该值将为 "From COMMON"。
<include> 元素能有效地将多个 <param-set> 元素连接在一起。连接全部完成后，处理过程继续步骤 11。
步骤 11：替换文本值
在处理了 <param-set> 元素和填充了步骤 9 中的参数表之后，系统将扫描表中的参数值以查找“替代关键字”。替代关键字是预定义的字符序列 (总是以起始大括号开始并以终止大括号结束)，遇到时会用下表所示的信息将其替换。
|
替代关键字
|
替代的数据
|
|---|---|
|
{AUTHORING_APP}
|
源 EPMDocument 的创作应用程序
|
|
{EPM_NAME}
|
源 EPMDocument 的名称
|
|
{EPM_NUMBER}
|
源 EPMDocument 的编号
|
|
{EPM_TYPE}
|
源 EPMDocument 的类型
|
|
{OUTPUT_TYPE}
|
<publish> 元素的 "output" 属性的值
|
|
{PARAM_SET_NAME}
|
<publish> 元素的 "param-set" 属性的值
|
|
{PARAM_SET_REF_NAME}
|
<publish> 元素的 "param-set-ref" 属性的值
|
|
{ADDITIONAL_FILE_PRIMARY_BASENAME}
|
无文件拓展名的主要附加文件基础名称
|
|
{ADDITIONAL_FILE_PRIMARY_EXTENSION}
|
主要附加文件的文件拓展名
|
|
{ADDITIONAL_FILE_SECONDARY_BASENAME}
|
无文件拓展名的次要附加文件基础名称。如果有多个次要文件，则将为此名称随机选择一个文件。
|
|
{ADDITIONAL_FILE_SECONDARY_EXTENSION}
|
次要附加文件的文件拓展名。如果有多个次要文件，则将为此名称随机选择一个文件。
|
例如，如果在 <param-set> 中遇到了如下元素：
<post-publish name=”name”>{EPM_NUMBER} authored by
{AUTHORING_APP}</post-publish>
{AUTHORING_APP}</post-publish>
则目标对象的名称将如下所示。(本例中 EPMDocument 的编号是 000047。)
000047 authored by MY_AUTH_APP
替代全部完成后，系统会把参数表和发布作业关联，同时评估返回到步骤 8 以搜索其他 <publish> 元素。
步骤 12：评估完成
在对发布规则进行了评估之后，针对单一 EPMDocument 可能有零到多个发布作业。此外，您还可能为部分或全部创建的发布作业定义了发布后参数和作业器特定的参数。
成功的发布作业将生成一个“表示”。随后，您可根据“发布规则”定义发布后行为。