パブリッシング規則の評価
以下のセクションでは、パブリッシング規則の評価のためのイベントとロジックについて説明します。
パブリッシング規則の評価をトリガするイベント
パブリッシング規則の有効化で説明しているように、パブリッシング規則の評価は次のイベントによってトリガされます。
• EPMDocument のチェックイン。
• スケジュール設定された EPMDocument のパブリッシング
• EPMDocument の「製品表現」リスト (または関連する WTPart の「製品表現」リスト) でのユーザーによる「新規製品表現」操作の選択
• 手動再パブリッシング、変更時の再パブリッシング、ワークフローなどのその他のイベントによって発生するパブリッシングジョブ
パブリッシング規則のロジックの評価
このセクションでは、パブリッシング規則の評価のロジックについて、パブリッシング規則のファイルの断片を含めて説明します。特に指定のないかぎり、評価プロセスでは大文字と小文字の区別を含む文字列の比較を使用します。
パブリッシング規則のファイルは、<rules> をそのルートエレメントとする適格な XML ドキュメントでなければなりません。
このセクションの趣旨は、評価プロセスのハイレベルの概要を提供することであることに留意してください。独自のパブリッシング規則のファイルを首尾よく構築するために必要な詳細の多くは、この後のセクションに記載されています。パブリッシング規則の XML ファイルの例も参照してください。
 |
パブリッシング規則のファイルのパラメータと値では大文字と小文字が区別されます。
|
ステップ 1: <authoring-application> の比較
<rules> エレメントには、WVS プロパティ publish.usesPublishRules で指定されている各オーサリングアプリケーションごとに <authoring-application> の子が 1 つ必要です。
たとえば、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> エレメント以外の子がある場合もありますが、それらのエレメントはパブリッシング規則の XML ファイルで <epm-number> エレメントの前に配置されている場合でも、このステップでは無視されます。
|
<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> エレメントのサーチのルートとなります。<publish> エレメントについてはステップ 8 で説明しています。それ以外の場合は、評価はステップ 3 に進みます。
ステップ 3: 'value' 属性のある <epm-iba> の比較
評価が続行され、ステップ 1 で一致した <authoring-application> の子エレメントにおいて、EPMDocument 内でグローバル属性名/値のペアに対応する <epm-iba> エレメントがサーチされます。
|
|
<epm-iba> の 'value' 属性はオプションの属性です。ステップ 3 では、'value' 属性が存在する <epm-iba> エレメントのみが考慮されます。'value' 属性が存在しない場合の動作については、ステップ 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> エレメントのサーチのルートとなります。<publish> エレメントについてはステップ 8 で説明しています。それ以外の場合は、評価はステップ 4 に進みます。
ステップ 4: 'value' 属性のない <epm-iba> の比較
評価が続行され、ステップ 1 で一致した <authoring-application> の子エレメントにおいて、EPMDocument 内でグローバル属性名に一致する 'iba' 属性を持つ <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> エレメントのサーチのルートとなります。<publish> エレメントについてはステップ 8 で説明しています。それ以外の場合は、評価はステップ 5 に進みます。
ステップ 5: <epm-type> の比較
評価が続行され、ステップ 1 で一致した <authoring-application> の子エレメントにおいて 'type' 属性が EPMDocument のオブジェクトタイプと一致する <epm-type> エレメントが検索されます。'type' 属性の値は EPMDocument の「内部名」です。内部名は Windchill の「タイプおよび属性の管理」ユーティリティで定義されます。
処理中にグローバル属性を設定するには、まず「タイプおよび属性の管理」ユーティリティで type のグローバル属性を定義する必要があります。詳細については、タイプおよび属性の管理ユーティリティの使用 を参照してください。
<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> エレメントのサーチのルートとなります。<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」がない場合、上記の Begin と End のコメント行に示したとおり、サーチのルートは <authoring-application> になります。
|
|
フォールスルーの比較を使用すると、特定のオーサリングアプリケーションの任意の 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> の各エレメントのいずれである場合もあります。
パブリッシュジョブは、'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" という 5 番目のトリガについては、この後で説明します。詳細については、パブリッシング後の手動処理を参照してください)。上記の例では、checkin に 2 つ、schedule に 1 つ、合計 3 つの "on" 値があります。パブリッシング規則の評価のトリガが EPMDocument のチェックインに起因している場合、2 つのパブリッシュジョブが作成されます。トリガが EPMDocument のスケジュール済みジョブに起因している場合は、1 つのパブリッシュジョブが作成されます。トリガが、ユーザーインタフェースから手動で「新規製品表現」ウィザードを実行したことに起因している場合は、パブリッシュジョブは作成されません。
• output - 上記 3 番目の <publish> 行に示したように、'output' 属性が存在する場合、それは Worker が使用できるパブリッシュジョブの一部になります。この属性の使用は、すべての Worker で有効であるとは限りません。
• 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...> エレメントが検索されます。それぞれが同じ XML ファイル内の異なる param-set 定義を参照する複数の <param-set-ref...> サブエレメントを追加して、1 つの <publish on=...> エレメントブロックでパブリッシング後の委任を複数呼び出すことができます。
• overlay-recipe-file - 属性 'overlay-recipe-file' が存在する場合 (上の 4 番目の <publish> 行に表示)、「Visualization コンフィギュレーション管理」 UI で RECIPE_FILE_NAME の値と一致するファイルがサーチされ、見つかった場合は、パブリッシングジョブのその他のファイルとともにこのファイルが Worker に送信されます。Worker はこのオーバーレイレシピファイルを使用して、製品表現またはビューデータを生成します。
|
|
指定した名前のオーバーレイレシピファイルが存在しない場合、パブリッシングジョブは失敗します。そのような場合、必要でない場合はパブリッシング規則から属性 'overlay-recipe-file' を除去するか、正しいファイル名を入力します。
|
ステップ 9 では一致した <param-set-ref> エレメントの処理について説明しています。
ステップ 9: <param-set-ref> の処理
たとえば、AdditionalFilesPostPublishDelegate を使用してファイルタイプごとに別個の WTDDocument オブジェクトを作成するように各種追加ファイルタイプのパブリッシング後の設定を行う場合など、同じ XML ファイル内の複数の <param-set> エレメント定義を参照するには、1 つの <publish on=...> エレメントブロック内で <param-set-ref> サブエレメントを使用します。
<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 に渡すために使用します。詳細については、パブリッシング後の処理を参照してください。
処理中にグローバル属性を設定するには、まず「タイプおよび属性の管理」ユーティリティで type のグローバル属性を定義する必要があります。パブリッシング規則は文字列を含む 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 のオーサリングアプリケーションによって決定されます。
これらのエレメントは、同一の構造を持っています。すなわち、それぞれパラメータを識別する '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> 名に同じものを 2 つ使用することはできません)。
子が処理される際、そのパラメータ識別子が前に検出されたものであれば、そのテーブルのエントリが新しいパラメータ値で更新され、同じ名前で以前に検出された値が置換されます。
<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> パラメータ 'name' の値は 'From SET1' になります。要素の配置が逆の場合、この値は '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}
|
セカンダリの追加ファイルのベース名 (ファイル拡張子なし)複数のセカンダリファイルが存在する場合、この名前に対して 1 つのファイルがランダムに選択されます。
|
|
{ADDITIONAL_FILE_SECONDARY_EXTENSION}
|
セカンダリの追加ファイルのファイル拡張子複数のセカンダリファイルが存在する場合、この名前に対して 1 つのファイルがランダムに選択されます。
|
たとえば、<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 に対して 0 個～多数個のドキュメントが作成されます。さらに、作成された一部またはすべてのパブリッシュジョブに対してパブリッシング後の Worker 固有のパラメータが定義してある場合があります。
パブリッシングジョブが正常に行われると、製品表現が作成されます。その後、パブリッシング規則に基づき、パブリッシング後の動作を定義できます。