受信送信物の処理のベストプラクティス
受信送信物ファイルのアップロードのベストプラクティス
受信送信物のアップロードは、パッケージ Zip ファイルをインポートするために必要な最初のステップです。
• 受信した Zip ファイルのサイズが大きい場合は、Zip ファイルを Windchill サーバーに保存して「新規外部ストレージを添付」オプション 
を選択すると、アップロード速度を向上できます。
を選択すると、アップロード速度を向上できます。• Windchill サーバーがクラスタ環境の場合、すべてのクラスタレイヤから受信した ZIP ファイルにアクセス可能であることを確認してください。
• 送信元からマニフェストファイルまたはオフラインビューアが提供されている場合は、これらをレビューしてください。オフラインビューアをレビューするには、インポートの前に Zip ファイルをファイルシステム上に抽出する必要があります。アップロードには元の Zip ファイルが要です。マニフェストファイルをレビューするには、Zip ファイルをアップロードして、受信送信物からレビューする必要があります。
マッピング定義の使用に関する最良事例
マッピング定義は、ソースシステムの情報をターゲットシステム上の有効な情報に変換するための有効なツールです。マッピング定義により、ガイドとして提供されている属性 (コンテキスト、フォルダ、ライフサイクルテンプレートなど) や、システムでローカルに管理されている業務上重要な意味を持つ属性 (オーナー組織、ライフサイクル状態、セキュリティラベルなど) を変換できます。
• 「受信送信物のインポートをプレビュー」操作を使用して、受信送信物をインポートする前にマッピング定義を設定します。
• プレビューウィンドウの情報を、マッピング定義内のソースシステム情報に直接コピーできるように、プレビューとマッピング定義を並べて使用します。
• マッピング定義を作成する前に、タイプ定義、属性定義、およびバージョンスキーム定義に不一致がないか確認し、ある場合は対処します。
◦ 情報をソースシステムから直接受信側の設定に追加する (たとえば、同じ名前のフォルダを作成する) 場合と、マッピングを定義する場合の、どちらが効率的かを検討します。
◦ ライフサイクルテンプレートのマッピングは、インポートされたオブジェクトが従う業務プロセスを表しているため、通常はこれを使用します。ターゲットシステムにインポートされたオブジェクトを、ソースシステムと同じ業務プロセスに従わせる必要はほとんどないため、通常は、オブジェクトでワークフロープロセスを開始しないライフサイクルテンプレートへのマッピングを定義してください。
▪ ソースシステムのライフサイクルテンプレートとの相互関係を維持する場合は、ソースシステムの基本ライフサイクルテンプレートの製品表現にマッピングするか、単純に送信側システムからインポートされた情報の基本ライフサイクルを使用します。
▪ アドバンスライフサイクルテンプレートへのマッピングは、ワークフローをインポートしたオブジェクトで開始する必要がある場合だけに制限します。
▪ アドバンスライフサイクルを使用する場合は、オブジェクトを変更しないワークフロープロセスに関連付けます。ターゲットシステムで行った編集は、オブジェクトが再度インポートされたときに上書きされます。
• 可能な場合は、特定のソースシステムから最初の受信送信物をインポートした後に、マッピングを変更しないようにします。マッピング定義を変更すると、データの構成に問題が生じる場合があります。
• 属性をマッピングするためにソースシステム情報を入力する際は、「受信送信物のインポートをプレビュー」ウィンドウの「コンテキスト関連の情報」セクションにある「ソースの値」フィールドで使用可能なテキストを使用します。
• マッピングを定義するユーザーには、システム内の関連オブジェクト (フォルダの場所、ライフサイクルテンプレートなど) に対する適切な権限が必要です。
• 定期的にマッピング定義をレビューして、不正なマッピング定義や古いマッピング定義を除去または変更します。
• データが失われないように、タブごとに変更を保存します。
• 「受信送信物のインポートをプレビュー」操作を並行して使用すると、「マッピングを定義」操作を、並行して使用します。「受信送信物のインポートをプレビュー」ウィンドウでコピーした情報を、適切なマッピング定義のソースシステム情報に貼り付けることができます。
バージョンマッピングに関する最良事例
バージョン情報は重要なビジネス情報を表すので、ソースシステムからのバージョン情報を保持するか暗黙的にマッピングするかは重要な決定となります。
• ソースシステムからのバージョン情報を保持する必要がある場合、ターゲットシステムにもソースシステムと同じリストベースおよび状態ベースのリビジョン連続用のバージョンスキームが定義されている必要があります。詳細については、「オブジェクトの番号付けとバージョン指定」を参照してください。
• ターゲットシステムで設定されているオブジェクトバージョンプロパティを、ソースシステムで設定されているプロパティと一致させることをお勧めします。
• パッケージをインポートする前に、ソースシステムで使用可能なバージョンスキームを指定します。以降のインポートで予期しない結果やコンフリクトが発生する可能性があるので、データをレプリケーションした後でバージョンスキームを変更することはお勧めしません。
• インポートを開始する前に、「受信送信物をインポート」または「受信送信物のインポートをプレビュー」ダイアログボックスを使用して、バージョンマッピングのコンフィギュレーションが正しく設定されていることを確認します。
• ソースシステムでリストベースまたは状態ベースの連続が履歴定義とともに使用されている場合、暗黙的なマッピングを行わずにソースシステムからのバージョン情報を使用することをお勧めします。
バージョンマッピングの詳細については、受信送信物バージョンマッピングの定義を参照してください。
受信送信物オブジェクトのインポートのベストプラクティス
• 受信送信物のインポートパフォーマンスは、いくつかのプロパティを使用して制御できます。それらのプロパティは受信送信物のインポートの管理方法を制御します。インポートは、順次処理するか、トランザクションまたはスレッドを使用して処理できます。次のプロパティを設定してパフォーマンスを最大化できます。
◦ wt.ixb.import.noOfParallelImportPaths: インポートの同時実行に使用するトランザクション数を設定します。
複数のトランザクションを使用すると、インポート中に問題が発生しても部分的に正常なインポートが可能なため、受信送信物のインポートパフォーマンスを向上できます。正常なトランザクションの一部としてインポートされたオブジェクトは、許可されたユーザーが使用できます。失敗したトランザクションは、調整後、再実行できます。デフォルトでは、このプロパティは 1 に設定されます。wt.ixb.tag.apply.TransactionTag.enableCount プロパティを 75000 より大きい値に設定した場合は、このプロパティは 4 に設定されます。
◦ wt.ixb.tag.apply.TransactionTag.enableCount: 受信送信物ファイルのオブジェクト数に基づいて、複数のトランザクションに分割するしきい値を設定します。
サイトが受信送信物ファイルのインポートに複数のトランザクションを使用する場合は、このプロパティ値を設定してトランザクションに含まれるオブジェクト数の最大値を指定する必要があります。その値は、オブジェクト間のリンクを除いた、1 つの受信送信物ファイルに含まれるオブジェクト数で数えられます。たとえば、その値に 3000 を設定し、かつ送信物が 5500 個のオブジェクトを含む場合は、インポートは 2 つのトランザクションに分割されます。デフォルトでは、このプロパティは 75000 に設定されます。
◦ wt.ixb.import.maxThreads: 1 つのトランザクションで使用されるスレッド数を設定します。
マルチスレッドの使用は、受信送信物のインポートパフォーマンスに最も大きな影響を与えます。スレッドが同じデータベース接続を共有するので、その数がしきい値に到達すると、パフォーマンスに影響する可能性があります。オブジェクト数もパフォーマンスに影響する可能性があります。オブジェクト数が増えるほど、マルチスレッドを使用したときにパフォーマンスが大きく向上するようになります。一般的に、差分パッケージ送信には 1 つのスレッドで十分です。特にインポートタイムウィンドウが小さい場合、最初のパッケージ送信がマルチスレッドによるメリットを得ることになります。デフォルトでは、このプロパティは 1 に設定されます。
 | wt.ixb.import.maxThreads プロパティの値は、インポートに使用するトランザクション数を決定する wt.ixb.import.noOfParallelImportPaths プロパティと組み合わせて使用します。 • 単一トランザクションのシナリオ: wt.ixb.import.noOfParallelImportPaths プロパティを 1 に設定した場合、wt.ixb.import.maxThreads プロパティの値は、インポートに使用するスレッドの合計数になります。 • 複数トランザクションのシナリオ: wt.ixb.import.noOfParallelImportPaths の値を 1 より大きい数に設定した場合、wt.ixb.import.maxThreads プロパティの値は、インポートトランザクションごとに使用されるスレッドの数になります。 |
◦ wt.ixb.import.batchSize: 1 つのスレッドのバッチサイズを設定します。
バッチサイズは、受信送信物のインポートパフォーマンスにそれほど大きな影響を与えません。各インポートバッチ内のオブジェクト数を決定するためのプロパティを設定できます。デフォルトでは、このプロパティは 10000 に設定されます。
• インポート時の「インポート情報」オプションには、「受信送信物のインポートをプレビュー」ウィンドウで選択したオプションと同じものを使用します。
• インポート時に「このインポートプロセス中に指定した最新の解決内容を保存」オプションを使用して、解決内容を保存します。これにより、以後、同じソースシステムから別の受信送信物をインポートするときに、保存した選択内容を再使用できます。
• インポート時に「以前に保存した解決内容を使用」オプションを選択して、以前に保存した解決内容を再使用します。
• 受信送信物のインポートが正常に完了した後、インポートサマリーレポートを確認します。
• 受信送信物のインポートは、RDImportExecutorQueue を使用して処理されます。詳細については、定義済みのバックグラウンドキューを参照してください。
• 受信送信物のインポートが正常に完了した後、送信に関連付けられているアップロード済みの Zip ファイルを除去すると、アーカイブのパフォーマンスを向上できます。com.ptc.windchill.rd.cleanupFilesOnSuccessfulImport プロパティを True に設定すると、インポートが成功したときに Zip ファイルが自動的に除去されます。
受信送信物ログファイルのレビューに関する最良事例
受信送信物の情報ページで、ログファイルを使用できます。ログファイルには、プレビューおよびインポート操作中に検出された情報が詳細に記録されています。これらのログファイルを使用して、インポートプロセス中に発生した警告やエラーの調査、インポートされたオブジェクトとリンクの識別、およびインポート時にコンフリクトが生じたオブジェクトまたはコンフリクトが原因でスキップされたオブジェクトの検索が可能です。詳細については、受信送信物のインポートログの確認を参照してください。