定義済みのバックグラウンドキュー

特殊な管理 > サイトメンテナンス > キュー管理 > バックグラウンドキューについて > バックグラウンドキューの詳細 > 定義済みのバックグラウンドキュー

定義済みのバックグラウンドキュー

この後のセクションでは、各 Windchill ソリューションがインストールされた際に設定されるキューについて説明します。オプションの製品がインストールされると、追加のキューが設定されます。これらのキューは、該当する製品の説明の一部として説明してあります。たとえば、ファイルボルトに使用されるキューについては、外部ボルト用の定義済みバックグラウンドキューで、コンテンツレプリケーションに使用されるキューについてはレプリケーションの定義済みバックグラウンドキューで説明されています。

CollectorBasedPackageQueue

CollectorBasedPackageQueue は、コレクターベースのパッケージコレクションをバックグラウンドプロセスとして更新します。これによってコレクションがバックグラウンドに移ることで、フォアグラウンドプロセスのためのリソースが解放されます。デフォルトで、これは無効になっています。このキューには、以下のプロパティが便利です。

• com.ptc.core.percol.collectorBasedRefreshInBackground - コレクターベースのパッケージコレクションのバックグラウンドでの更新を有効にするかどうかを指定します。デフォルトは false です。true に設定した場合、コレクターベースのパッケージコレクションは、フォアグラウンドプロセスではなくバックグラウンドプロセスとして更新されます。

• com.ptc.core.percol.numBackroundRefreshQueues - コレクターベースのパッケージコレクションのバックグラウンドでの更新が有効な場合に同時に実行するキューの数を指定します。デフォルトは 2 です (CollectorBasedPackageQueue1 と CollectorBasedPackageQueue2)。3 以上に設定した場合、キューが追加されて連番が付きます。

• com.ptc.core.percol.backgroundRefreshCollectorLimit - バックグラウンドで更新される場合にパッケージコレクションに含めることができるオブジェクトの数を指定します。デフォルトは -1 であり、バックグラウンドでの更新はフォアグラウンドと同じ制限 (プロパティ com.ptc.core.collectionsrv.engine.limitDependencyTracing によって指定) に設定されます。1 以上に設定した場合に、バックグラウンドで更新される場合にパッケージコレクションに制限が適用されます。

commonScheduleQueue

このキューは、CleanUpScheduleQueue、MarkForDeleteQueue、PagingScheduleQueue、PurgeOrphanedEffAuditsQueue、および StatisticsScheduleQueue を置き換えます。

commonScheduleQueue は、さまざまな小さなキューエントリに使用されます。小さなエントリは限られたリソースしか要求せず、大抵は一度しか実行されないか、実行される頻度が多くありません。これらのキューエントリをとりまとめて commonScheduleQueue にすることで、システムリソースを解放し、大きなキューエントリを集中的に処理できます。各 commonScheduleQueue エントリタイプについて、次のリストで説明します。

• LicenseGroupMembershipLinks キューエントリは、表示と印刷のみのライセンスグループと「表示と印刷のみのライセンス」テーブルを同期させるためにスケジュールされます。

デフォルトでは、このタイプのキューエントリは毎日真夜中 (0:00 AM グリニッジ標準時) に実行するスケジュールになっています。このエントリの実行時間は、wt.org.CreateLicenseGroupMembershipLinkWeeklyQueueTime および wt.org.CreateLicenseGroupMembershipLinkDayOfWeek プロパティで設定できます。

エントリの実行時間のスケジュールと、グループのメンバーシップ変更のタイミングにより、変更したメンバーシップが「表示と印刷のみのライセンス」テーブルに反映されるまでには最大で 1 日かかります。

• StandardRecentlyVisitedService キューエントリは、リストされているアイテムの総数が wt.properties ファイルの wt.recent.objectStackSize プロパティで指定した値を超える場合に、最近アクセスしたすべてのリストから最も古いアイテムを除去するために作成されます。このプロパティのデフォルト値は 100 です。

StandardRecentlyVisitedService を開始すると、最初はこのタイプのキューエントリは真夜中 (0:00 AM グリニッジ標準時) に実行するようにスケジュールされています。キュータスクが実行されるたびに、次回は翌日の真夜中 (0:00 AM グリニッジ標準時) に実行されるように再スケジュールされます。

• StandardPurgeService キューエントリは、キャンセルされたパージジョブをクリーンアップするために作成されます。このタイプのキューエントリは、wt.queue.executeQueues プロパティが true に設定されている場合のみに作成されます。デフォルトでは、このプロパティは true に設定されます。

このタイプのキューエントリは毎日真夜中 (0:00 AM グリニッジ標準時) に実行されるようにスケジュールされています。このキュータスクが実行されると、1 日以上経過した、プレビュー待ち状態にある、キャンセルされたパージジョブが削除されます。

プレビュー待ちの状態にあるパージジョブは、「キュー管理」ユーザーインタフェースを表示しているユーザーには見えません。

• StandardCollectionService キューエントリは、基準が正しくない照会を無効にするために作成されます。このキューエントリは、wt.queue.executeQueues プロパティと wt.dataops.objectcol.cleanUpEnabled プロパティが両方とも true に設定されている場合にのみ作成されます。デフォルトでは、これらのプロパティは両方とも true に設定されます。

このタイプのキューエントリは毎日真夜中 (0:00 AM グリニッジ標準時) に実行するようにスケジュールされています。これは、基準が正しくない照会を無効にします。たとえば、フォルダ参照が削除されている照会を無効にします。無効にされた照会は、「キュー管理」ユーザーインタフェースを表示しているユーザーには見えません。

• MarkForDeleteQueue エントリは、Windchill ProjectLink がプロジェクトとそのコンテンツを "削除済み" とマーク付けするのに使用されます。プロジェクトが "削除済み" とマーク付けされると (「削除」操作を使用して)、そのプロジェクトはプロジェクトメンバーの「My プロジェクト」リストには表示されなくなります。マーク付けの処理は、ユーザーのレスポンス時間を向上させるため、バックグラウンドで実行されます。

プロジェクトの削除に失敗した場合、自動的に通知がプロジェクトマネージャグループに送信されます。通知には、失敗の原因を示す例外メッセージが記載されています。プロジェクトマネージャは、失敗の原因を調査し、それを修正し、「削除」操作を再び送信してプロジェクトの削除を再試行する必要があります。

失敗した MarkForDeleteQueue エントリがないか、commonScheduleQueue を定期的にチェックしてください。エントリのステータスが "失敗" である場合、必要な処理は、エントリをキューから除去することだけです。

• PagingScheduleQueue エントリは、「ローカルサーチ」でデータベースに保存された一時的な結果をクリーンアップするために使用されます。結果は、各ユーザーのサーチリクエストに関連付けられています。ローカルサーチを実行するユーザーが何人いても、エントリは 1 つだけです。

エントリの失敗は、一時的な結果がクリーンアップされないことを意味します。そのままデータ量が増大するとパフォーマンスに影響します。commonScheduleQueue キューが正常に新規エントリを作成できた場合、引き続いて (以前の試行からのデータも含めて) すべてのデータがクリーンアップされます。

失敗した PagingScheduleQueue エントリがないか、commonScheduleQueue キューを毎日チェックして、データベースに保存される一時的な結果が常にクリーンアップされるようにしてください。単発の失敗は、重大な問題ではありません。1 回失敗しても、次に成功すれば、失敗したときの分までクリーンアップされるからです。しかし、失敗はすべて調査し、PTC テクニカルサポートにお知らせください。

• PurgeOrphanedEffAuditsQueue エントリを使用して、エフェクティビティサービスで監査オブジェクトがクリーンアップされます。

エフェクティビティ監査オブジェクトは、エフェクティビティオブジェクトの作成と事実上の削除を記録するために作成されます。事実上の削除とは、エフェクティビティレコードで削除済みとマークされていても履歴情報が残されていることを意味します。エフェクティビティが実際に削除されると、監査オブジェクトは非参照にできるので、それ以降の目的がなくなります。エフェクティビティオブジェクトが実際に削除されるたびに該当する監査オブジェクトをチェックすることは多大な時間がかかるので、このような急を要さないクリーンアップはスケジュールに沿って実行されます (デフォルトでは 1 日 1 回)。クリーンアップのスケジュールを変更するには、wt.eff.EffChangeAudit.purgeInterval プロパティで設定された時間間隔を変更します。このプロパティは、wt.properties ファイル内にあります。時間間隔は分単位で表示します。デフォルト値は、1440 分 (1 日) です。

wt.eff.EffChangeAudit.purgeInterval プロパティが 0 または負の値に設定されている場合、クリーンアップは実行されません。

失敗した PurgeOrphanedEffAuditsQueue エントリは、監査アイテムの照会と削除の試行が失敗したことを意味します。失敗した PurgeOrphanedEffAuditsQueue エントリのチェックは、定期的に行う必要はありません。各キューエントリの機能は同じなので、失敗したエントリに気付いた場合にはそのエントリを削除できます (それらのエントリはそれ以降のエントリで置き換えられます)。この問題が常時発生する場合は、システムコンフィギュレーションをチェックして PTC テクニカルサポートに問題レポートを提出することを検討してください。また、エフェクティビティサービスは起動時にこのキュー (存在しない場合) を作成するようにプログラムされているので、キューの問題のあるインスタンスはそのエントリとともにすべて (エントリのステータスに関係なく) 簡単に削除できます。

• ソフトのタイプ/属性の照会サービスで StatisticsScheduleQueue を使用し、グローバル属性に関連した統計が収集されます。これらの統計は、照会の最適化の際に使用されます。

失敗したキューエントリは、統計が収集されなかったことを示しています。統計のデータが最新でない場合、ソフトのタイプ/属性の照会パフォーマンスが最適化されていない可能性があります。

統計を収集する頻度は、com.ptc.core.query.optimize.statisticsBasedRankGenerator.queueInvokeTime プロパティの設定によって制御されます。デフォルトでは、1 日 1 回です。詳細については、properties.html を参照してください。

LicenseScheduleQueue

LicenseScheduleQueue は不変キューであり、ライセンス関連のキューエントリに使用されます。このキューは不変なので、このキューやそのエントリに対して中止、無効化、編集、リセット、削除などの操作を実行することはできません。これらの操作は LicenseScheduleQueue の「キュー管理」ユーザーインタフェースでは非表示になっています。ライセンス関連のキューは PTC のみが作成および修正できます。

LicenseScheduleQueue の各エントリタイプについて、次のリストで説明します。

• synchronizeLicense - Windchill を PTC バックエンドシステムと同期化し、ライセンスの資格に対するすべての変更をチェックします。このタイプのキューエントリは 24 時間おきに実行されるようにスケジュールされています。

• createLicenseGroupMembershipLinks - メンバーシップリンクテーブルにライセンスグループメンバーを反映します。このタイプのキューエントリは毎日真夜中 (0:00 M グリニッジ標準時) に実行されるようにスケジュールされています

• UpdateFeatureLicenseCache - 毎日真夜中 (0:00 M グリニッジ標準時) に有効なライセンスの有無をチェックしてライセンス情報テーブルを更新します。

ContentControlQueue

ContentControlQueue は、パッケージのコンテンツ制御機能が有効になっているときに使用されます。コンテンツ制御機能によりユーザーは、パッケージ送信に含めるコンテンツファイルを「ファイル」テーブルから指定できます。このためには、「パッケージコンテンツ」テーブルの「操作」メニューから「ファイルを選択」を選択します。

パッケージのタイプベースのプロパティで説明するように、コンテンツ制御機能はタイプベースのプロパティファイルを使用して明示的に有効化する必要があります。

パッケージのコンテンツ制御機能が有効化され、パッケージがロック (その後ロック解除) されたら、新しいエントリがキューに追加されます。同様に、「パッケージコンテンツ」ユーザーインタフェースを使用して、パッケージメンバーのコンテンツ制御情報の変更が行われると、新しいエントリがキューに追加されます。キューエントリが実行されると、パッケージメンバーのコンテンツ制御データが永続化されます。

CtScheduleQueue

CtScheduleQueue は、チーム更新の自動スケジュール作成機能がオンである場合に使用されます。

チームの更新の自動スケジュールについては、ユーザー定義グループとのチームの同期を参照してください。

dataMonitorProcessingQueue

dataMonitorProcessingQueue は dataMonitorScheduleQueue とともに、Windchill レポートデータモニター機能で使用されます。データモニターのスケジュールされたインスタンスが実行されると、エントリが dataMonitorProcessingQueue に追加されます。データモニターが削除されると、すべての dataMonitorProcessingQueue エントリが実行の完了後に削除されます。dataMonitorProcessingQueue ステータスは、データモニターの情報ページにある「実行されたレポート」テーブルの「ステータス」列に表示されます。

dataMonitorScheduleQueue

dataMonitorScheduleQueue は dataMonitorProcessingQueue とともに、Windchill レポートデータモニター機能で使用されます。データモニターが作成されると、データモニターのスケジュールされたインスタンスが実行されるごとに、エントリが dataMonitorScheduleQueue に追加されます。スケジュールされたインスタンスが実行されると、エントリが dataMonitorProcessingQueue に追加されます。データモニターが削除されると、そのデータモニターのすべての dataMonitorScheduleQueue エントリは削除されます。dataMonitorScheduleQueue ステータスは、「データモニター」テーブルの「ステータス」列に表示されます。

DataSharingQueue

DataSharingQueue は、コンテキスト間でデータの共有がある場合に使用されます。場合によっては、共有ステータスの更新に大量の処理が必要になります。たとえば、フォルダが共有の場合、すべてのフォルダ化オブジェクトも帰納的に共有されます。このキューを使用して、バックグラウンドでこのタイプの更新が処理されます。このキューを使用すると、ユーザーのレスポンス時間は、共有された更新処理の影響を受けません。

DeleteCompletedWorkItemsQueue

DeleteCompletedWorkItemsQueue は、特定のコンテキストの特定の参加者について、完了したワークアイテムを削除します。DeleteCompletedWorkItemsQueue はワークアイテムを削除する前にプリファレンス値を読み取ります。プリファレンス値は数値、ALL、または NO のいずれかです。値が NO である場合、完了したワークアイテムは削除されません。ALL の場合、すべての完了したワークアイテムが削除されます。値が数値の場合、その数値は完了後削除されない最新のワークアイテム数を指します。これを超えるワークアイテムは削除されます。完了したワークアイテムの削除は、過剰な完了ワークアイテム数が指定されたプリファレンス値の 2 倍に達したときに実行されます。たとえば、プリファレンス値が 10 の場合、ワークアイテムの削除は過剰ワークアイテムが 20 に達したときに実行されます。ワークアイテムは、その親プロセスが CLOSED の場合のみ削除されます。完了したプロジェクトワークアイテムは削除されません。

このプリファレンスのデフォルト値は NO です。

このキューに失敗エントリがあると、完了したワークアイテムをプリファレンスに従って削除する際、処理が失敗します。

DigestNotificationQueue

DigestNotificationQueue は、通知サービスでメールの送信リクエストをキューに入れるのに使用されます。即時ではなく、スケジュールに従って配信される購読通知の要約通知電子メールの送信を求めるために、リクエストがキューに入れられます。購読のユーザーインタフェースを使って、オブジェクトを購読する際の配信方法を選択することができます。プリファレンスは、「サイト」レベルまたは「組織」レベルで、要約通知の配信時刻を設定できます。「組織」レベルのプリファレンスはその組織内のユーザーに適用され、「サイト」レベルのプリファレンスは「組織」レベルのプリファレンスの対象にならないユーザーに適用されます。DigestNotificationQueue に対するリクエストは、要約通知電子メールの配信をスケジュールするために、固有のプリファレンス値ごとにキューに入れられます。これらのリクエストによって、リクエストに示されるプリファレンスに含まれるすべてのユーザーに、要約通知電子メールが配信されます。

DTODeliverablesQueue

DTODeliverablesQueue は、成果物リクエストを処理します。つまり、ユーザーはコンフィギュレーション可能部品 (以前のジェネリック部品) からの成果物の生成を要求します。リクエストはキューに入れられ、処理されて、完了するとその結果がユーザーに返されます。初期状態でサポートされている成果物メーカーは BOMMaker で、バリエーション部品構造を生成します。これは、通常は迅速に実行されます。ほかにも成果物メーカーは存在し、お好みの成果物メーカーを書き込むことができますが、長い時間 (数分または数時間) かかる可能性があります。ここに挙げたケースでは、DTODeliverablesQueue が最も便利です。

DTOOffPeakQueue

DTOOffPeakQueue は、オフピーク時間 (夜間など) に実行する必要があるタスクを処理します。これらのタスクの実行には時間がかかり、優先度は高くありません。たとえば、コンフィギュレーション可能部品の潜在的なバリエーションをサーチし、潜在的なバリエーションとして添付するタスクなどがあります。

EMailQueue

EMailQueue は、メールサービスでメールの送信リクエストをキューに入れるのに使用されます。メールサービスに対して電子メールの送信を求めるリクエストを生成すると、そのリクエストは EMailQueue に入れられます。キューからリクエストが処理されると、電子メールが送信されます。メールサービスは、送信に失敗した電子メールの送信を再試行する場合にも、このキューを使用します。電子メール送信のリクエストが失敗すると、メールサービスは一定時間後にそのリクエストの処理を再度要求します。デフォルトでは、電子メールの送信リクエストは 24 時間有効です。それまでにリクエストを正常に処理できない場合、メールサービスはそのリクエストによって電子メールを送信することをあきらめます。

forumEventPropogationQueue

forumEventPropogationQueue は、ディスカッションフォーラムで以下のオブジェクトを削除するのに使用されます。

• ディスカッショントピック (wt.workflow.forum.DiscussionTopic)

• ディスカッションの投稿および応答 (wt.workflow.forum.DiscussionPosting)

• ディスカッションの投稿への添付コンテンツ (wt.workflow.notebook.Bookmark)

失敗したキューエントリは、以下のいずれかを意味します。

• ディスカッションフォーラムのトピックが、正常に削除されなかった。

• ディスカッションフォーラムの投稿または投稿への応答が、正常に削除されなかった。

• 投稿への添付ファイルが、正常に削除されなかった。

このキューを毎日チェックして、キューが適切に動作していることを確認してください。ディスカッションフォーラムが頻繁に使用される場合には、チェックの回数を増やすことができます。キューエントリが失敗するごとに、キューエントリの状態を「準備完了」にリセットしてください。

インデックシングキューおよびバルクインデックシングキュー

インデックシングキューおよびバルクインデックシングキューは、Windchill Index Search をインストールする際に設定されるオプションのキューです。これらのキューは、インデックシングプロセスで使用されます。インデックシングキューおよびバルクインデックシングキューの失敗したエントリについて、定期的にチェックしてください。

インデックシングキューエントリに「重大」ステータスがある場合、インデックシングとサーチエンジンが適切に設定され、Windchill Index Search ソフトウェアが動作していることを確認します。次にキューエントリを「準備完了」にリセットします。キューエントリをリセットすると、インデックシング処理が再起動します。

IXRepositoryQueue

IXRepositoryQueue は、パッケージの標準受信送信物サービスによって、インポート用のオブジェクト情報を作成するために使用されます。この情報は、バッチを作成するためのパッケージのインポート時に使用されます。

ユーザーがパッケージデータを含む Zip ファイルをアップロードすると、ReceivedDeliveryChunkInfo (Zip 情報) で構成されるキューエントリがこのキューに追加されます。キューエントリを実行すると、Zip 内のオブジェクトに対してメタデータ情報が作成されます。

NotificationQueue

NotificationQueue は、キューリクエストへの通知サービスで通知 (ポリシーおよび購読ベースの通知) を生成して送信するために使用されます。

通知サービスは、以下の 2 種類の購読/通知をサポートしています。

• 電子メール購読/通知

• オブジェクトリスナー購読/通知

これらの通知は、購読の「受信者」が wt.notify.ObjectSubscriptionListener インタフェースを実装した Windchill オブジェクトで作成できます。WfSynchRobot は、そのようなオブジェクトの 1 つです。また、これは「ディスカッションフォーラム」、「ディスカッションのトピック」、および「ディスカッションの投稿」のインタフェースに実装されています。これらのオブジェクトリスナー購読が満たされると、電子メールがユーザーに送信されるのではなく、通知サービスが購読者の ObjectSubscriptionListener の「受信者」オブジェクトでメソッドを呼び出し、オブジェクトは必要とされるあらゆる処理を行います。

NotificationQueue は、電子メール購読とオブジェクトリスナー購読のどちらにも使用されるため、WfSynchRobot に対して NotificationQueue を起動して、購読に問題がない場合に必要な処理を実行できるよう通知する必要があります。NotificationQueue を停止すると、電子メール通知が送信されなくなり、オブジェクトリスナー購読が機能しなくなります。

NotificationScheduleQueue

NotificationScheduleQueue は、通知サービスで使用されます。購読を期限切れにするために、リクエストが追加されます。購読の UI によって、購読の期限切れの日付を設定できます。キューに追加されたリクエストによって、期限切れの際に購読が除去されます。

PartsLinkQueue

PartsLinkQueue は、Windchill PartsLink がインストールされた際に設定されるオプションのキューです。このキューは、Windchill PartsLink サービスによって PartsLink サーバーに分類された部品をパブリッシングするのに使用されます。

PartsLinkQueue の失敗したエントリについて定期的にチェックしてください。エントリに失敗したステータスがある場合、必要な操作はキューエントリを「準備完了」にリセットすることのみです。

ProjectScheduleQueue

ProjectScheduleQueue は、従来のプロジェクト管理で見過ごした期限、迫っている期限、および過ぎてしまった期限に対応するイベントを送信するために使用されます。

このキューでの失敗はほとんどないので、このキューの定期的なチェックは必要ありません。プロジェクト管理の期限のメッセージが送信されないという苦情があった場合に、キューをチェックしてください。ただし、通知の失敗はどちらかといえば電子メールサーバーの問題により発生します。

PublisherQueues

PublisherQueues は、Visualization Services がビジュアリゼーションデータのパブリッシングや印刷、および干渉検出などの関連する工学的計算を管理するために作成されます。さらに、パッケージの圧縮 (Zip) 処理中にコンテンツの同期化が必要な場合、このトピックで後述するように、Windchill パッケージが PublisherQueues にエントリを追加します。

Visualization Services の PublisherQueue エントリ

通常、Visualization Services では、CAD データはチェックインの後にパブリッシングされます。その結果、多くの顧客サイトでは、長時間 (数時間程度) 実行されるジョブを実行するために、これらのキューを使用する頻度が高くなります。各 PublisherQueue は、PublishQueue<キューセット>L/M/H または PublishQueue<キューセット>N の命名規則に従います。L/M/H は、低/中/高の各プロパティを表し、N は 1 から始まる連続した整数を表します。同じ <キューセット> を持つキューは、キューセットと呼ばれます。空の文字列を名前として持つデフォルトのキューセットは常に存在します。追加のキューセットはすべて、wvs.properties で publish.publishqueue.setnames プロパティによって宣言されます。初期状態では、以下のキューセットとキューが作成されます。

• デフォルトのキューセット: PublisherQueueL、PublishQueueM、PublisherQueueH、および PublisherQueue1

• CLASH キューセット: PublisherQueueCLASHL、PublishQueueCLASHM、PublisherQueueCLASHH、および PublisherQueueCLASH1

• PRINT キューセット: PublisherQueuePRINTL、PublishQueuePRINTM、PublisherQueuePRINTH、および PublisherQueuePRINT1

サブミットされたすべての WVS ジョブは、ジョブタイプ、ジョブのサブミット方法、およびデータタイプに応じて、優先キュー (末尾が L、M、H の名前) に追加されます。このプロセスは、wvs.properties のプロパティ設定によって制御されます。詳細については、wvs.properties.xconf の以下のプロパティを参照してください。

• パブリッシングジョブ: publish.publishqueue.set.0.0 および publish publishqueue.priorities0.0

• 干渉ジョブ: clash.publishqueue.set.0.0 および clash .publishqueue.priorities0.0

• 印刷ジョブ: print.publishqueue.set.0.0 および print .publishqueue.priorities0.0

wvs.properties および wvs.properties.xconf ファイルの場所に変更があります。$WT_HOME/codebase ディレクトリから $WT_HOME/codebase/WEB-INF/conf ディレクトリにこれらのファイルを移動しました。この場所の変更を反映して、コードに必要な変更を加えてください。

優先度が L、M、または H のキューで実行中のジョブは、同じキューセット内で使用可能な番号キュー (末尾に連続する番号 N を持つ名前) を探します。検出すると、そのキューに WVS ジョブをサブミットし、このジョブはすぐに実行されます。デフォルトでは、各キューセットには番号 1 が付くキューだけが作成されます。Windchill 「キュー管理」ユーティリティで追加のパブリッシングキュー (PublisherQueue2、PublisherQueue3、PublisherQueueCLASH2 など) を作成して、要求される処理量の変化に対応できます。

キューエントリに保存されたオブジェクトは、com.ptc.wvs.server.publish.PublishJob または com.ptc.wvs.server.publish.PrintJob オブジェクトです。これらの WVS ジョブの詳細は、WVS ジョブモニターから表示できます。ジョブが失敗した場合、キューエントリのログ情報 (WVS ジョブモニターに表示される) を使用して、エラーの原因を調査します。問題を修正した後、ジョブを再度サブミットします。

L、M、H のキューから番号付き処理キューに対する印刷、パブリッシング、および干渉検出ジョブのサブミットは、番号付きキューが別のバックグラウンドメソッドサーバーに存在する場合にサポートされます。

Windchill パッケージの PublisherQueue エントリ

Windchill パッケージのエクスポートおよび圧縮時には、デフォルトの PublisherQueue のいずれか (PublisherQueue1 など) にエントリを追加できます。これらのエントリの目的は、エクスポートする CAD コンテンツを更新して、そのコンテンツに関連する Windchill メタデータの変更を含めることです。

パッケージのエクスポートおよび圧縮時に CAD コンテンツの同期化用のキューを使用するには、特定のパッケージプリファレンスを設定する必要があります。プリファレンスの詳細については、パッケージプリファレンスの設定を参照してください。

パッケージプリファレンスでキューの使用を有効に設定した場合、使用されるキュー処理は、製品表現を生成するときに Visualization Services によって使用される処理と同じです。パッケージのキューエントリに保存されるオブジェクトは、com.ptc.wvs.server.publish.PublishJob オブジェクトです。つまり、Windchill パッケージのキューエントリは、Visualization Services のエントリと同じ属性を持つことになります。同様に、これらのジョブの詳細は、WVS ジョブモニターから表示できます。ジョブが失敗した場合、キューエントリのログ情報 (WVS ジョブモニターに表示される) を使用して、エラーの原因を調査します。問題を修正した後、パッケージのエクスポートを繰り返します。

RDImportExecutorQueue

RDImportExecutorQueue は、受信送信物パッケージのインポートを処理します。受信送信物の「インポート」操作を起動すると、受信送信物の ID 情報を含むエントリがこのキューに追加されます。キューエントリを実行すると、受信送信物のインポートがトリガされます。インポートの詳細については、受信送信物ファイルのインポートを参照してください。

受信送信物のインポートの処理は、処理するオブジェクトの数やファイルの数によっては、時間がかかる可能性があります。

WfPropagationQueue

WfPropagationQueue は、ワークフロー (およびその関連付けられたタスク) ですべての状態の変更をワークフローオブジェクトに反映させるのに使用されます。これには、そのような状態の変更に関連付けられたすべてのルーティング定義式と遷移の定義式が含まれます。

多くの Windchill ユーザーがワークフロータスクを同時に完了させている場合、ワークフローキューが頻繁に使用される可能性があります。また、Windchill ビジネスオブジェクトが作成されてライフサイクルを使用する代わりにワークフローを使用すると、ワークフローキューが頻繁に使用される可能性があります。

ワークフローキューのパフォーマンスが問題ならば、WfUserWorkQueue および WfPropagationQueue キューを含むキュープールを設定することができます。プールの WfPropagationQueue キューは WfSharedPropagationQueue<n> と名付けられます。その際、<n> は 1 で始まり、キューが追加されるたびに 1 ずつ増加します。キュープールの設定の詳細については、キュープールを参照してください。

ワークフローキューで失敗したエントリは、何かが適切に処理されていないことを意味します。ほとんどの場合、失敗したワークフローキューエントリはメソッドサーバーログのスタックトレースに対応しています。メソッドサーバーログをチェックしてキューエントリの失敗を分析し、失敗の原因を判断します。場合によっては、「キュー管理」ユーティリティに表示されているメッセージだけで失敗の原因が判断できることがあります。

キューに関連付けられたワークフローアクティビティが適切に実行していないように見える場合には、ワークフローキューを検査してください。さらに、キューを定期的にチェックして古いエントリを除去しておくことをお勧めします。

新しく作成された WfPropagationQueue タイプのデフォルト値は「プール」ですが、キュー値は「プール」または「プロセス」のどちらのタイプにも設定できます。

WfScheduleQueue

WfScheduleQueue は、ワークフローで (およびその関連付けられたタスクで) すべての時間が指定されたイベントをキューに追加するのに使用されます。期限が設定された定義式ベースの同期ロボットを持つワークフローオブジェクトの期限のチェックは、このキュー内で実行されます。

WfUserWorkQueue

WfUserWorkQueue は、ワークフローで (およびその関連付けられたタスクで) ワークフローロボットをインスタンス化し、ワークフローロボットの操作を実行するのに使用されます。

ワークフローキューのパフォーマンスが問題ならば、WfUserWorkQueue および WfPropagationQueue キューを含むキュープールを設定することができます。プールの WfUserWorkQueue キューは WfSharedUserQueue<n> と名付けられます。その際、<n> は 1 で始まり、キューが追加されるたびに 1 ずつ増加します。キュープールの設定の詳細については、キュープールを参照してください。

新しく作成された WfUserWorkQueue タイプのデフォルト値は「プール」ですが、キュー値は「プール」または「プロセス」のどちらのタイプにも設定できます。

WPSyncQueue

WPSyncQueue はパッケージのエクスポートを処理します。パッケージのそれぞれの圧縮操作は、圧縮プロセスの間は WPSyncQueue の 1 つのエントリとなります。多数のオブジェクトや大容量のコンテンツを含むオブジェクトが存在する場合、パッケージの圧縮の実行には時間がかかる場合があります。

また、圧縮プロセスの実行時にコンテンツの同期化が必要な場合、そのコンテンツを同期化するために PublisherQueues にキューエントリが作成されます。サポートされる CAD コンテンツがパッケージ内にあり、コンテンツの同期化が有効になっている場合、コンテンツの同期化が実行されます。

これは役に立ちましたか?