評估發佈規則
下列幾節將會描述評估「發佈規則」的事件與邏輯。
觸發發佈規則評估的事件
如啟用發佈規則所述，「發佈規則評估」會由下列事件觸發：
• 入庫 EPMDocument。
• 排程 EPMDocument 的發佈。
• 使用者選取 EPMDocument 的「表示清單」(或其關聯的 WTPart 的「表示清單」) 上的「新建表示」動作。
• 從其他任何事件產生的發佈工作，例如從手動重新發佈、變更時重新發佈或啟動的工作流程。
評估發佈規則邏輯
本節描述「發佈規則」評估的邏輯並包含「發佈規則」檔案的片段。除非有其他指定，否則評估流程都會使用區分大小寫字串比較。
「發佈規則」檔案是格式設定妥當的 XML 文件，<rules> 是其根元素。
請記住，本節嘗試提供評估流程的高階層概觀。隨後各節將說明成功建構您自己的「發佈規則」檔案所需的許多詳細資訊。另請參閱發佈規則 XML 檔案的範例。
 |
發佈規則檔案中的參數與值區分大小寫。
|
步驟 1：比對 <authoring-application>
<rules> 元素必須針對在 WVS 內容 publish.usesPublishRules 中指定的每個編寫應用程式擁有一個 <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>
「發佈規則評估」會搜尋具有符合 EPMDocument 「編寫應用程式」之「名稱」屬性的 <authoring-application> 元素。如果找不到符合的元素，則不會生成任何「發佈工作」；否則，評估會繼續步驟 2。
步驟 2：比對 <epm-number>
評估會透過在步驟 1 中符合的 <authoring-application> 元素的子項中搜尋其「編號」屬性符合 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 討論了當未顯示任何 'value' 屬性時發生的情況。
|
<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> 元素的子項中搜尋其「類型」屬性符合 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>
在步驟 7 中，評估會透過在步驟 1 中符合的 <authoring-application> 元素的子項中搜尋其 type 屬性符合要發佈之結構類型的 <structure-type> 元素來繼續。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> 元素。
會針對此根的每個 <publish> 元素子項建立「發佈工作」，此根的 'on' 屬性符合導致呼叫「發佈規則評估」的事件。如果沒有符合的 <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 - 如果存在 'output' 屬性 (如上文第三 <publish> 行所示)，它會成為可由 Worker 使用的「發佈工作」中的資訊的一部份。並非所有 Worker 都可以使用此屬性。
• param-set - 如果存在 'param-set' 屬性，會在「發佈規則」XML 檔案中尋找具有符合 'param-set' 屬性值的 'name' 屬性的 <param-set> 元素。步驟 9 描述處理符合的 <param-set> 元素。在上例中，param-set 值為 "SET1"。
• param-set-ref - 如果 <publish on=...> 元素區塊中存在 <param-set-ref...> 子元素，會在發佈規則 XML 檔案中搜尋具有符合 param-set-ref "name" 屬性值的 'name' 屬性的 <param-set...> 元素。可以新增多個 <param-set-ref...> 子元素，每一個都參考相同 XML 檔案中的不同 param-set 定義，藉以呼叫單一 <publish on=...> 元素區塊的多個後發佈委派。
• overlay-recipe-file - 如果存在 'overlay-recipe-file' 屬性 (如上面的第四個 <publish> 行所顯示)，會在「視覺化組態管理」UI 中搜尋符合 RECIPE_FILE_NAME 值的檔案，如果找到，會將此檔案與其他檔案一起傳送至 Worker，以用於「發佈工作」。然後，Worker 會使用此覆蓋 recipe 檔案來產生表示或可檢視項。
|
|
如果不存在具有指定名稱的覆蓋 recipe 檔案，發佈工作會失敗。在這種情況下，如果不需要 '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 - 如果 Worker 支援此元素，它可用來將額外資訊傳送到 Worker。Worker 由評估期間要使用的 EPMDocument 的編寫應用程式決定。
這些元素具有相同的結構；每個元素都有一個可識別參數的「名稱」屬性，而且元素的文字內容是參數的值。
<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>，由於 SET1 中的 <include> 元素在 <post-publish> 元素之前顯示，因此 <post-publish> 參數「名稱」將會擁有值 'From SET1'。如果元素的位置反向，值將會是 'From COMMON'。
<include> 元素可讓 <param-set> 元素有效地鏈接在一起。處理完整個鏈之後，處理會繼續步驟 11。
步驟 11：替換文字值
處理完 <param-set> 元素並填入了步驟 9 的參數表之後，會掃描表格中的參數值以尋找「替換碼」。替換碼 是預先定義的一系列字元 (永遠以開啟括號開始，以關閉括號結束)，當遇到它時，會使用下列表格中所顯示的資訊來取代它。
|
替換碼
|
替換資料
|
|---|---|
|
{AUTHORING_APP}
|
來源 EPMDocument 的編寫應用程式
|
|
{EPM_NAME}
|
來源 EPMDocument 的名稱
|
|
{EPM_NUMBER}
|
來源 EPMDocument 的編號
|
|
{FIG_NAME}
|
零件清單 C3DI 插圖中的圖名稱
|
|
{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 的許多發行工作設定為零。此外，您可能已為某些或所有建立的發行工作定義後發行與 Worker 特定參數。
成功的發行工作可產生「表示」。然後，您可以根據「發行規則」定義後發行行為。