カスタムパブリッシング
目的
別の製品領域またはカスタムコードからパブリッシングを開始します。また、OOTB パブリッシングメカニズム (チェックイン駆動、スケジュールされたパブリッシング) に対するネーミング、説明、コンフィギュレーション仕様などの表現作成の代替入力を定義します。
バックグラウンド
デフォルトの Windchill Visualization Services では、3 とおりの方法で表現を作成できます。Windchill UI から手動で作成する方法、製品表現対象オブジェクト (製品表現を持つオブジェクト、つまり EPMDocument、WTPart、WTDocument) のチェックイン、スケジュールジョブを使用する方法です。このガイドでは、ワークフローのカスタムコード、カスタム UI の使用など、別の方法でパブリッシングを開始する方法について説明します。
また、製品表現対象のチェックイン、スケジュールジョブの使用など、既存のメカニズムによる表現の作成をカスタマイズする方法についても説明します。手動での作成と異なり、パブリッシングのための特別なコンフィギュレーション仕様を指定したり、製品表現の名前や説明に取り込むビジネス固有の情報を提供するデフォルトの方法はありません。
範囲/適用可能性/前提条件
カスタムパブリッシングは、Windchill で標準外の方法でパブリッシングを開始する必要がある場合 (チェックイン、手動、スケジュール以外)、または製品表現の入力情報を修正する必要がある場合に使用します。パブリッシングは、wt.representation.Representable オブジェクト (つまり、ソフトおよびハードタイプの子を含む EPMDocuments、WTPart、WTDocuments) でのみ実行できます。
予測される結果
このトピックの説明を使用すると、デフォルトのパブリッシングメカニズムではビジネス要件に合わない場合でも、エンドユーザーは常に要件に合わせてパブリッシングを実行できます。
ソリューション
カスタムコードに Public WVS API を実装し、適切な WVS プロパティの変更により WVS がこのカスタムコードを認識するようにして、パブリッシングをカスタマイズします。
前提となる知識
この目的を達成するには、次のことを理解している必要があります。
Java 開発
標準 WVS パブリッシングのセットアップと設定
製品表現対象オブジェクト、製品表現などの WVS 概念
EPMDocuments、WTParts、WTDocuments などのパブリッシング可能なビジネスオブジェクトとその関係、構造に関する基本的な理解
コンフィギュレーション仕様 (ConfigSpecs) の使用
* 
コンフィギュレーション仕様 (ConfigSpecs) の使用その他のリソースには、これらの各項目に対する参照が含まれています。
ソリューションエレメント
エレメント
タイプ
説明
Publisher.class
クラスファイル
コードからパブリッシングを開始するのに必要な doPublish の API が含まれています。
ランタイム場所: <Windchill>\codebase\com\ptc \wvs\common\ui
PublisherAction. class
クラスファイル
パブリッシャで doPublish メソッドに渡される、オプションの actionString を作成するのに使用します。詳細については、Javadoc を参照してください。
ランタイム場所: <Windchill>\codebase\com\ptc \wvs\common\ui
VisualizationHelper.class
クラスファイル
カスタムコードでよく必要とされる findRepresentable、getRepresentation などのヘルパー API が含まれています。
ランタイム場所: <Windchill>\ codebase\com\ptc \wvs\common\ui
ScheduleJobs.class
クラスファイル
カスタムスケジュールジョブの記述に必要となる getCurrentContainer メソッドが含まれています。
ランタイム場所: <Windchill>\codebase\com\ptc \wvs\server\schedule
wvs.properties
プロパティファイル
Windchill Visualization Service で使用される特定のプロパティが含まれています。
ランタイム場所: <Windchill>\codebase
手順 - カスタムコード/ワークフローからパブリッシングを開始する
このセクションでは、以下の Supported API とクラスを使用する方法について説明します。
Publisher クラスの doPublish - 単純なパブリッシングを参照
doPublish の高度な使用法のための PublisherAction クラス - 高度なパブリッシングを参照
カスタムコードまたはワークフローの定義式ロボットからパブリッシングを開始するには、com.ptc.wvs.common.ui.Publisher クラスのサポートされている doPublish メソッドを理解し、使用することが重要です。
public boolean doPublish (boolean viewableLink,
boolean forceRepublish,
String objectReference,
ConfigSpec configSpec,
ConfigSpec partConfigSpec,
boolean defaultRep,
String repName,
String repDescription,
int structureType,
String actionString,
int jobSource)
このメソッドの詳細とパラメータについては、<Windchill>\codebase\wt\clients\library\api\index.html にある Javadoc を参照してください。
単純なパブリッシング
パブリッシング可能なデータを持つ EPMDocument インスタンスがあり、これでデフォルトの製品表現を作成します。
String objRef =
ObjectReference.newObjectReference(myepmdoc).toString();
Publisher pub = new Publisher();
boolean result = pub.doPublish(false, true, objRef,
(ConfigSpec)null,
(ConfigSpec)null, true, null, null,
Publisher.EPM, null, 0);
この簡単な例は、パブリッシュジョブを myepmdoc のパブリッシングキューに追加するだけのものです。wvs.properties で定義された As-Stored または Latest ConfigSpec を使用して (publish.configspec.default.useasstoredifavailable)、"default" という名前のデフォルトの結果表示がパブリッシングされます。forceRepublish パラメータが true だったので、同じ名前の既存の表示は置換されます。
プログラムによって表示名を指定する場合、または有意のビジネス情報を説明に挿入する場合は、パラメータを修正します。以下に例を示します。
Publisher pub = new Publisher();
boolean result = pub.doPublish(false, true, objRef,
(ConfigSpec)null,
(ConfigSpec)null, true, “MyRep”,
(ConfigSpec)null, true, “MyRep”,
“My Description”, Publisher.EPM, null,
0);
この例と前の例の違いは、デフォルトの結果表示が "MyRep" となり、説明 "My Description" が付くことだけです。
既存の製品表現への参照を読み込むには、viewableLink パラメータを true に、forceRepublish パラメータを false に設定します。指定した製品表現対象の repName に既存の製品表現がある場合は、doPublish 呼び出しの後に、getViewableObjRef() を呼び出します。これにより、製品表現が見つかった場合には、String オブジェクト参照を取得できます。見つからなかった場合は、null が返されます。
String repObjRef = null;
Publisher pub = new Publisher();
if (pub.doPublish(true, false, objRef, (ConfigSpec)null,
(ConfigSpec)null,
true, “MyRep”, “My Description”, Publisher.EPM,
null, 0)) {
repObjRef = pub.getViewableObjRef();
}
既存の製品表現のオブジェクト参照を取得するほかに、HTML フラグメントを取得し、それを使用して Creo View を開始し、表示を画面表示することができます。これを行うには、doPublish 呼び出しの後に、getViewableLink() API を使用します。ここでも、viewableLink は true に、forceRepublish は false に設定し、repName の名前として渡される製品表現が、objRef パラメータで指定されている製品表現対象に存在する必要があります。
String repLink = null;
Publisher pub = new Publisher();
if (pub.doPublish(true, false, objRef, (ConfigSpec)null,
(ConfigSpec)null,
true, “MyRep”, “My Description”, Publisher.EPM,
null, 0)) {
repLink = pub.getViewableLink();
}
高度なパブリッシング
パブリッシュ可能なデータを持つ EPMDocument インスタンスがあり、独自のコンフィギュレーション仕様を使用してデフォルトの製品表現を作成します。また、パブリッシュジョブを優先度の高いパブリッシングキューで処理します。
パブリッシングの高度な機能を使用するには、PublisherAction クラスを使用する必要があります。詳細については、JavaDoc を参照してください。ここではいくつかの例を示します。
String objRef =
ObjectReference.newObjectReference(myepmdoc).toString();
PublisherAction pa = new
PublisherAction(PublisherAction.QUEUEPRIORITY, “H”);
ConfigSpec configSpec = <MyHelper.getBaselineConfigSpec()>;
Publisher pub = new Publisher();
boolean result = pub.doPublish(true, true, objRef, configSpec,
null, true,
null, null, Publisher.EPM,
pa.toString(), 0);
いくつかのコンテンツを持つ WTDocument があります。たとえば、doc1.doc、doc2.doc、doc3.doc はすべて WTDocument のコンテンツです。このうち、doc3.doc のみをパブリッシングします。
String objRef = ObjectReference.newObjectRefer-
ence(mydoc).toString();
PublisherAction pa =
new PublisherAction(PublisherAction.DOCUMENTFILE, “doc3.doc”);
Publisher pub = new Publisher();
boolean result = pub.doPublish(true, true, objRef, (Config-
Spec)null,
(ConfigSpec)null, null, null,
Publisher.NONE, pa.toString(), 0);
* 
WTDocuments については、ConfigSpec は使用されず、structureType は Publisher.NONE です。
PublisherAction.DOCUMENTFILE ファイル名を指定しない場合、Worker が関連付けられている 1 つ目のファイルがパブリッシングされます。
このような処理は、特定のコンテンツファイルをパブリッシングする際に、ビジネス上の必要に応じて特定の方法でそのファイルをネーミングする場合に役立ちます。
手順 - 製品表現対象と製品表現の取得
このセクションでは、以下の Supported API とクラスを使用する方法について説明します。
VisualizationHelper クラスの findReprentable - findRepresentableを参照してください。
VisualizationHelper クラスの getRepresentation および getRepresentations - getRepresentableを参照してください。
製品表現対象から製品表現への関連付けは、一対多です。このような関連付けを見つける際に重要なことは、EPMDocument (つまり、製品表現対象) があっても、その製品表現が必ずしも直接関連付けられているとは限らないということです。EPMDocument にアクティブに関連付けられた WTPart (EPMDocument のチェックイン時に、Workgroup Manager に関連部品を作成するオプションを使用) がある場合、製品表現は WTPart にリンクされます。その他の場合は、製品表現が直接製品表現対象 (アクティブに関連付けられていない EPMDocuments、DynamicDocuments、WTParts、WTDocuments、MPMLink 製品表現対象) に関連付けられます。
findRepresentable
com.ptc.wvs.common.ui.VisualizationHelper には、前述の考え方を簡潔にした findRepresentable というメソッドがあります。このメソッドを使用すると、製品表現対象を渡し、アクティブに関連付けられた部品がある場合には常に正しい製品表現対象を取得できます。アクティブに関連付けられた部品がない場合は、単純に渡したオブジェクトが返されます。メソッド署名を以下に示します。public Representable findRepresentable(Persistable d)
public Representable findRepresentable(Persistable d)
製品表現対象に関するカスタムコードがある場合は、このメソッドを使用して、製品表現に関連付けられた正しい製品表現対象を使用できるようにしてください。また、製品表現対象でない永続可能オブジェクトを渡すと、メソッドは null を返す点にも注意してください。このメソッドを使用するには、VisualizationHelper のインスタンスを持っている必要があります。以下に例を示します。
VisualizationHelper vizHelper = new VisualizationHelper();
Representable repable = vizHelper.findRepresentable(d);
getRepresentation
また、com.ptc.wvs.common.ui.VisualizationHelper には、製品表現対象から製品表現を取得する便利なメソッドもあります。
public Representation getRepresentation(Persistable d)
前述のとおり、製品表現対象から製品表現への関係は、一対多です。ただし、製品表現の 1 つは "デフォルト" の製品表現となります。デフォルトの数は 0 または 1 です。デフォルトが存在する場合、上記のメソッドはデフォルトの製品表現を返します。見つからなかった場合は、null が返されます。public RepresentationgetRepresentation(Persistable d, String repName)
public Representation getRepresentation (Persistable d,
String repName)
上記のメソッドは、永続可能オブジェクトに関連付けられ、repName 引数に渡された名前の付いた製品表現を返します。製品表現がない、または指定した名前の付いたものが見つからない場合は、null が返されます。
public QueryResult getRepresentations(Persistable d)
このメソッドは、渡された永続可能オブジェクトに関連付けられたすべての製品表現を返します。製品表現がない場合は、null が返されます。
このサブセクションに示したメソッドは、すべて以下の VisualizationHelper のインスタンスを持つ必要があります。
VisualizationHelper vizHelper = new VisualizationHelper();
Representation rep = vizHelper.getRepresentation(d);
* 
上記の 3 つのメソッドは、すべて findRepresentable メソッドを使用するので、呼び出すときにアクティブに関連付けられた部品があるかどうかを心配する必要はありません。また、渡された永続可能オブジェクトが製品表現対象でない場合は、null が返ります。
手順 - カスタムスケジュールジョブの作成
このセクションでは、以下の Supported API とクラスを使用する方法について説明します。
カスタムスケジュールジョブの作成手順と ScheduleJobs クラスの Supported API getCurrentContainer の使用方法については、カスタムスケジュールジョブの基本を参照してください。
カスタムスケジュールジョブに Publisher クラスの doPublish の使用を組み込む方法については、カスタムスケジュールジョブの高度なテクニックを参照してください。
カスタムスケジュールジョブの基本
デフォルトのジョブのほかに、独自のカスタムジョブを作成することができます。これを行うには、Windchill codebase にカスタムクラスを作成または追加します。たとえば、ext.wvs.CustomJobs です。このクラスで、以下の署名でメソッドを作成します。
public static WTList <nameOfMethod>() or public static QuerySpec <nameOfMethod>() or public static QueryResult <nameOfMethod>()
任意のメソッド名を使用できますが、public、static であり、WTList を返し、引数を取らないメソッドである必要があります。
次に、以下を wvs.properties.xconf ファイルに追加 (必要に応じて編集) します。
<Property default="MyCustomJob" name="myJob.description"/>
<Property default="ext.wvs.CustomJobs" name=" myJob.class"/>
<Property default="myCustomJob" name=" myJob.method"/>
<Property default="true" name=" myJob.enableOnContainers"/>
<Property default="myJob" name="schedulejobs<N>"/>
行 1 (<Property default="MyCustomJob" name="myJob.description"/>) は、スケジューラ UI に表示されカスタムジョブを示します。
行 2 (<Property default="ext.wvs.CustomJobs" name=" myJob.class"/>) は、カスタムメソッドが存在する完全修飾クラスです。
行 3 (<Property default="myCustomJob" name=" myJob.method"/>) は、カスタムメソッド名です。
行 4 (<Property default="true" name=" myJob.enableOnContainers"/>) は、スケジュールジョブが開始されたコンテナにジョブコードがアクセスできるかどうかを定義します。たとえば、デフォルトのスケジュールジョブは、値が true に設定されているため、スケジュールジョブが開始されたコンテナ (Project、Product、Library、または Organization) のオブジェクトのみを処理します。値が false に設定されている場合は、どのコンテナからスケジュールジョブが開始された場合でも、Exchange コンテナのコンテキストによるジョブの実行と同じになります。
行 5 (<Property default="myJob" name="schedulejobs<N>"/>) は、パブリッシュスケジューラアドミニストレータにカスタムジョブを表示します。name の文字列中の <N> は連番です。定義済みの最新の schedulejobsN の N に 1 を足したものを指定します。
パブリッシュジョブの例を以下に示します。
public static WTlist myCustomJob() {
WTList wtl = new WTArrayList();
try {
QuerySpec qs = new QuerySpec(WTDocument.class);
WTContainerRef cr = ScheduleJobs.getCurrentContainer();
if (cr != null) {
ContainerSpec cs = new ContainerSpec();
cs.addSearchContainer(cr);
qs.setAdvancedQueryEnabled(true);
qs.appendWhere(
WTContainerHelper.getWhereContainerIn(cs, ,new Class[] {WTDocument.class}),
new int[]{0});
}
if (cr != null) qs.appendAnd();
qs.appendWhere(new SearchCondition(WTDocument.class,
Iterated.LATEST_ITERATION,
SearchCondition.IS_TRUE),
new int[]{0});
Representable doc = null;
int offset = 0;
BasicPageableQuerySpec bpqs = new BasicPageableQuerySpec();
bpqs.setPrimaryStatement(qs);
bpqs.setOffset(offset);
bpqs.setRange(1000);
PagingQueryResult qr =
(PagingQueryResult)PersistenceHelper.manager.find(bpqs);
long sessionId = qr.getSessionId();
int total = qr.getTotalSize();
while (true) {
while (qr.hasMoreElements()) {
doc = (Representable)((Object[])qr.nextElement())[0];
wtl.add(doc);
}
offset += qr.size();
if (offset >= total) break;
PageableQuerySpec pqs = new PagingSessionSpec(sessionId);
pqs.setOffset(offset);
pqs.setRange(1000);
qr = (PagingQueryResult)PersistenceHelper.manager.find(pqs);
}
if (sessionId > 0) PagingSessionHelper.closePagingSession(sessionId);
} catch(Exception e) {e.printStackTrace(); wtl = new WTArrayList ();}
return wtl;
}
* 
この例では、メモリ不足エラーを防ぐために、BasicPageableQuerySpec と PagingSessions が使用されています。詳細については、wt.query および wt.fc パッケージで Javadoc を参照してください。
この例では、現在のコンテナで見つかったパブリッシングされる WTDocuments の最新の作業版数すべてを効果的に要求できます。
例の行 6 では、下記のメソッドが com.ptc.wvs.server.schedule.ScheduleJobs から使用されます。
public static WTContainerRef getCurrentContainer()
このメソッドの結果は、スケジュールジョブが Exchange コンテナ (サイト) から開始された場合、またはジョブ定義の enableOnContainers 値が false の場合 (上記例の前に示したプロパティの行 4 を参照) は null となります。enableOnContainers の値が true の場合は、スケジュールジョブが開始されたコンテナの WTContainerRef が返されます。コード例では、これはクエリ範囲を組織またはスケジュールジョブが開始された製品 / プロジェクト / ライブラリコンテナに限定するフィルタとして使用しています。
* 
カスタムスケジュールジョブは複数持つことができます。同じクラスで別のメソッド名を使用するか、または完全に新しいクラスを使用します。例:
public static WTList anotherCustomJob();
次に、以下を wvs.properties.xconf ファイルに追加 (必要に応じて編集) します。
<Property default="AnotherCustomJob"
name="anotherJob.description"/>
<Property default="ext.wvs.CustomJobs" name=" anotherJob.class"/>
<Property default="anotherCustomJob" name=" anotherJob.method"/>
<Property default="true" name=" anotherJob.enableOnContainers"/>
<Property default="anotherJob" name="schedulejobs<N>"/>
カスタムスケジュールジョブの高度なテクニック
カスタムスケジュールジョブの基本のテクニックでは、パブリッシングジョブを作成するための入力を行い、製品表現名、製品表現の説明などを指定することはできません。手順 - カスタムコード/ワークフローからパブリッシングを開始するカスタムスケジュールジョブの基本の考え方を組み合わせると、スケジュールジョブの柔軟性が飛躍的に増します。
そのテクニックとは、Publisher クラスの doPublish メソッドを myCustomJob メソッドに挿入するだけです。myCustomJob は QueryResult を返す必要があるので、空の QueryResult を返します。doPublish メソッドにより、パブリッシングジョブが実行待ちキューに入っているからです。
public static WTList myCustomJob() {
WTList wt = new WTArrayList();
try {
QuerySpec qs = new QuerySpec(WTDocument.class);
WTContainerRef cr = ScheduleJobs.getCurrentContainer();
if (cr != null) {
ContainerSpec cs = new ContainerSpec();
cs.addSearchContainer(cr);
qs.setAdvancedQueryEnabled(true);
qs.appendWhere(
WTContainerHelper.getWhereContainerIn(cs, WTDocument.class),
new int[]{0});
}
if (cr != null) qs.appendAnd();
qs.appendWhere(new SearchCondition(WTDocument.class,
Iterated.LATEST_ITERATION,
SearchCondition.IS_TRUE),
new int[]{0});
Representable doc = null;
String objRef;
int offset = 0;
BasicPageableQuerySpec bpqs = new BasicPageableQuerySpec();
bpqs.setPrimaryStatement(qs);
bpqs.setOffset(offset);
bpqs.setRange(1000);
PagingQueryResult qr =
(PagingQueryResult)PersistenceHelper.manager.find(bpqs);
long sessionId = qr.getSessionId();
int total = qr.getTotalSize();
while (true) {
while (qr.hasMoreElements()) {
doc = (Representable)((Object[])qr.nextElement())[0];
objRef =
ObjectReference.newObjectReference(doc).toString();
Publisher pub = new Publisher();
pub.doPublish(false, true, objRef, (ConfigSpec)null,
(ConfigSpec)null, true, "My Rep",
"My Description", Publisher.NONE, null, 0)
;
}
offset += qr.size();
if (offset >= total) break;
PageableQuerySpec pqs = new PagingSessionSpec(sessionId);
pqs.setOffset(offset);
pqs.setRange(1000);
qr =
(PagingQueryResult)PersistenceHelper.manager.find(pqs);
}
if (sessionId > 0)
PagingSessionHelper.closePagingSession(sessionId);
} catch(Exception e) {e.printStackTrace();}
return new wtl;
}
カスタムスケジュールジョブの基本で使用されたものと同じ例ですが、太字で示すように doPublish メソッドが使用されています。このカスタムジョブは、"My Rep" という名前と "My Description" という説明の製品表現を作成します。また、メソッドから返される WTList が空になることに注意してください。
doPublish メソッドのその他の有用な使い方については、手順 - カスタムコード/ワークフローからパブリッシングを開始するを参照してください。
手順 - チェックインベースのパブリッシングのカスタマイズ
このセクションでは、以下のプロパティ駆動カスタムフックを使用する方法について説明します。
publish.service.filterepmdocumentpublishmethod - EPMDocument チェックイン用パブリッシングのフィルタを参照してください。
publish.service.filterdocumentpublishmethod - WTDocument チェックインまたはアップロード用パブリッシングのフィルタを参照してください。
カスタムフックコードに Publisher クラスの doPublish の使用を組み込む方法については、カスタムチェックインベースのパブリッシングの高度なテクニックを参照してください。
EPMDocument チェックイン用パブリッシングのフィルタ
オーサリングアプリケーション (Creo Parametric) 用にパブリッシングを設定すると、チェックインしたオーサリングアプリケーションのすべての EPMDocuments について、デフォルトでパブリッシングが実行されます。ビジネス上の必要から、特定の基準に基づいて、一部の EPMDocuments をパブリッシング対象から除外するフィルタが必要になる場合があります。たとえば、特定のライフサイクル状態、EPMDocumentType、EPMDocSubType などです。Windchill Visualization Services では、そのような基準に基づくフィルタコードをプラグインするためのコードフックを使用できます。
カスタムクラスで、次の署名でメソッドを定義できます。
public static Boolean epmFilterMethod(EPMDocument epmdoc)
epmFilterMethod の代わりに任意の名前を使用できます。カスタムメソッドを含むクラスが Windchill codebase (ext.wvs.MyFilterMethods) でアクセス可能である必要があります。
次に、クラスおよびメソッドを wvs.properties.xconf に追加します。下記のプロパティのデフォルトは空です。これを更新して、クラスとメソッドを "class/method" の形式で含めます。
<Property default="ext.wvs.MyFilterMethods/epmFilterMethod"
name="publish.service.filterepmdocumentpublishmethod"/>
変更した後、xconfmanager を使用して、変更を wvs.properties に反映させます。
通常 EPMDocument のパブリッシングが行われるチェックインのたびに、このメソッドが開始されるようになります。メソッドが Boolean.TRUE を返すと、特定の EPMDocument のパブリッシングを試みます。メソッドが Boolean.FALSE を返すと、パブリッシングは試みません。
以下に、特定の EPMDocumentType をフィルタで除外する方法の簡単な例を示します。
public static Boolean epmFilterMethod(EPMDocument epmdoc) {
if (epmdoc.getDocType().equals(
EPMDocumentType.toEPMDocumentType("MANIKIN_POSTURE"))) {
return Boolean.FALSE;
}
return Boolean.TRUE;
}
別の例として、LifeCycle 状態が InWork の場合に、EPMDocuments のパブリッシングをフィルタで除外する方法を示します。
public static Boolean epmFilterMethod(EPMDocument epmdoc) {
if (epmdoc.getLifeCycleState() != State.INWORK) {
return Boolean.TRUE;
}
return Boolean.FALSE;
}
WTDocument チェックインまたはアップロード用パブリッシングのフィルタ
EPMDocuments のパブリッシングのフィルタと非常によく似ていて、WTDocument パブリッシングにもフィルタを行う方法があります。たとえば、特定のファイル名、ライフサイクル状態に基づくフィルタが必要な場合があります。Worker が特定の WTDocument 内容をパブリッシングするように設定されている場合は、カスタムフィルタメソッドを使用して、一部の内容をパブリッシング対象から除外できます。
カスタムクラスで、以下の署名でメソッドを定義できます。
public static Boolean docFilterMethod(WTDocument doc, ContentItem ci)
docFilterMethod の代わりに任意の名前を使用できます。カスタムメソッドを含むクラスが Windchill codebase (ext.wvs.MyFilterMethods) でアクセス可能である必要があります。このメソッドは、パラメータとして ContentItem を含む点が EPMDocument フィルタメソッド署名と異なります。このメソッドは、チェックイン時に、WTDocument に関連付けられた各 ContentItem について呼び出されます。アップロード時にも呼び出されます。たとえば、.doc ファイルをプライマリコンテンツとして、.xls ファイルをセカンダリコンテンツとして持つ WTDocument がある場合、このメソッドは各コンテンツアイテムに対して、合計 2 回呼び出されます (Worker の保留が両タイプのコンテンツと関連付けられている)。
次に、クラスおよびメソッドを wvs.properties.xconf に追加します。下記のプロパティのデフォルトは空です。これを更新して、クラスとメソッドを "class/method" の形式で含めます。
<Property default="ext.wvs.MyFilterMethods/docFilterMethod"
name="publish.service.filterdocumentpublishmethod"/>
変更した後、xconfmanager を使用して、変更を wvs.properties に反映させます。
通常 WTDocument のパブリッシングが行われるチェックインまたはアップロードのたびに、このメソッドが開始されるようになります。メソッドが Boolean.TRUE を返すと、特定の WTDocument ContentItem のパブリッシングを試みます。メソッドが Boolean.FALSE を返すと、パブリッシングは試みません。
以下の例では、WTDocument の説明が "Do Not Publish" の場合、またはコンテンツのファイル名が "donotpublish" で始まる場合にフィルタを適用する方法を示します。
public static Boolean docFilterMethod(WTDocument doc, ContentItem ci) {

if (doc.getDescription().equals("Do Not Publish")) {
return Boolean.FALSE;
}
if (ci instanceof ApplicationData) {
String filename = ((ApplicationData)ci).getFileName();
if (filename.startsWith("donotpublish") {
return Boolean.FALSE;
}
}
return Boolean.TRUE;
}
カスタムチェックインベースのパブリッシングの高度なテクニック
EPMDocument チェックイン用パブリッシングのフィルタWTDocument チェックインまたはアップロード用パブリッシングのフィルタのテクニックでは、パブリッシングジョブを作成するための入力を行って、製品表現名、製品表現の説明などを指定することはできません。手順 - カスタムコード/ワークフローからパブリッシングを開始するの考え方とEPMDocument チェックイン用パブリッシングのフィルタおよびWTDocument チェックインまたはアップロード用パブリッシングのフィルタの考え方を組み合わせると、チェックインベースのパブリッシングの柔軟性が飛躍的に増します。
そのテクニックとは、Publisher クラスの doPublish メソッドを、前のサブセクションで示した epmFilterMethod または docFilterMethod メソッドに挿入するだけです。2 つのフィルタメソッドは Boolean を返す必要があるので、Boolean.FALSE を返し、doPublish メソッドにより、パブリッシングジョブが実行待ちキューに入れます。
public static Boolean epmFilterMethod(EPMDocument epmdoc) {

if (epmdoc.getDocType().equals(
EPMDocumentType.toEPMDocumentType("MANIKIN_POSTURE"))) {
return Boolean.FALSE;
}
String objRef = ObjectReference.newObjectReference(epmdoc).toString();
Publisher pub = new Publisher();
pub.doPublish(false, true, objRef, (ConfigSpec)null,
(ConfigSpec)null,
"My Rep", "My Description", Publisher.EPM, null, 0);

return Boolean.FALSE;
}
EPMDocument チェックイン用パブリッシングのフィルタで使用されたものと同じ例ですが、太字で示すように doPublish メソッドが使用されています。このカスタムジョブは、"My Rep" という名前と "My Description" という説明の製品表現を作成します。また、メソッドから返される Boolean が Boolean.FALSE になることに注意してください。
doPublish メソッドのその他の有用な使い方については、手順 - カスタムコード/ワークフローからパブリッシングを開始するを参照してください。
手順 - 一般的パブリッシングのカスタマイズ
このセクションでは、以下の方法について説明します。
プロパティ駆動フック: publish.service.filterpublishmethod の使用方法 - すべてのパブリッシングのフィルタを参照してください。
カスタムフックに Publisher クラスの doPublish の使用を組み込む方法 - カスタムチェックインベースのパブリッシングの高度なテクニックを参照してください。
すべてのパブリッシングのフィルタ
手順 - チェックインベースのパブリッシングのカスタマイズで説明した EPMDocuments および WTDocuments 専用のフィルタのほかに、Windchill Visualization Services には、パブリッシング可能なものすべて (EPM および WTDocuments を含む) を呼び出す一般的なフックがあります。すべての製品表現対象のフィルタをサポートするほかに、このフックには変換済みデータのパブリッシングも含まれます。
カスタムクラスで、以下の署名でメソッドを定義できます。
public static Boolean filterMethod(Persistable p, Boolean
publishFromDB)
filterMethod の代わりに任意の名前を使用できます。カスタムメソッドを含むクラスが Windchill codebase (ext.wvs.MyFilterMethods) でアクセス可能である必要があります。このメソッドには publishFromDB パラメータが含まれます。この Boolean は、Windchill 内に保存されているデータ、つまり EPMDocument または WTDocument オブジェクトのコンテンツに対してパブリッシングが開始された場合は、Boolean.TRUE となります。Windchill に保存されていないデータ、つまりファイルシステムから変換されたローカルデータまたはクリップボードのデータの場合、値は Boolean.FALSE となります。必要に応じて、publishFromDB の値を使用して、カスタムコードで 2 つのケースのみを処理することもできます。
次に、クラスおよびメソッドを wvs.properties.xconf に追加します。下記のプロパティのデフォルトは空です。これを更新して、クラスとメソッドを "class/method" の形式で含めます。
<Property default="ext.wvs.MyFilterMethods/filterMethod"
name="publish.service.filterpublishmethod"/>
変更した後、xconfmanager を使用して、変更を wvs.properties に反映させます。
通常のパブリッシングが行われるたびに、このメソッドが呼び出されるようになります。メソッドが Boolean.TRUE を返すと、永続可能オブジェクトのパブリッシングを試みます。メソッドが Boolean.FALSE を返すと、パブリッシングは試みません。
以下に、永続可能オブジェクトが LifeCycleManaged で、LifeCyle の最終フェーズにある場合は、コンテンツのパブリッシングをフィルタで除外する方法の簡単な例を示します。
public static Boolean filterMethod(Persistable p, Boolean publishFromDB) {
if (!publishFromDB) return Boolean.TRUE;
if (!(p instanceof LifeCycleManaged)) return Boolean.TRUE;
try {
if (LifeCycleHelper.service.isInFinalPhase((LifeCycleManaged)p)) {
return Boolean.FALSE;
}
} catch (WTException wte) {
wte.printStackTrace();
}
return Boolean.TRUE;
}
* 
上記の例では、パブリッシングを要求されたデータが Windchill DB のものでない場合には、true を返すと 2 行目に記述されています。たとえば、誰かがローカルディスクからアップロードした WTPart のデータをパブリッシングしようとした場合には、それをフィルタで除外することは適切でないので、単に Boolean.TRUE を返します。
制限事項
カスタマイズの制限
デフォルトの CadConvert クラス (パブリッシャ)、Worker Agent、WVS ローダーのカスタマイズはサポートされません。WVS のこれらのコンポーネントはカスタマイズを目的としたものではなく、これらのコンポーネントに対して行われたカスタマイズが将来のリリースで無効とならないとは限りません。
カスタムスケジュールジョブのパフォーマンス
スケジュールジョブは、キューを使用してバックグラウンドで実行されますが、カスタムコードでリソースを大幅に消費する照会を作成し、返すこともできます。ページングを使用して巨大な結果セットによって起こる問題を防ぐためのテクニック例が手順 - カスタムスケジュールジョブの作成のセクションに示されています。カスタムスケジュールジョブは必ず本番環境に準じたデータセットでテストを行ってください。結果が 100 の場合にうまくいった動作が、結果が 1 万や 10 万の場合にもうまくいくとは限りません。
カスタムチェックインフィルタのパフォーマンス
手順 - チェックインベースのパブリッシングのカスタマイズに示すチェックインフィルタのテクニックを使用する場合、メソッドがパブリッシング対象のすべての製品表現対象について実行される点に注意してください。メソッドは効率的にし、true または false 結果を返す判断はできるだけ少なくします。フィルタメソッドでリソースを大幅に消費するロジックが必要な場合は、実行する前に、できるだけ必要性を除外してください。
その他のリソース
Java 開発: http://java.sun.com
<Windchill>\codebase ディレクトリ内の wvs.properties.xconf ファイル
関連パッケージ/クラスの Javadoc
com.ptc.wvs.common.ui
com.ptc.wvs.server.schedule
その他の関連 Windchill ドキュメント
Windchill Business Administrator's Guide
Creo® View MCAD Adapters Installation and Configuration Guide
Creo® View ECAD Adapters Installation and Configuration Guide
これは役に立ちましたか?