AI Parts Rationalization プラグイン > オンプレミス環境で AI Parts Rationalization プラグインをインストールする前に必要な設定
オンプレミス環境で AI Parts Rationalization プラグインをインストールする前に必要な設定
* 
このトピックは、Windchill オンプレミスシステムを設定する管理者を対象としています。
管理者はプラグインをインストールする前に、次の必要条件を完了する必要があります。
Windchill サーバーの設定
AI プラグインを Windchill 環境にインストールする前に、システムが、このトピックで説明するコンフィギュレーション要件を満たしていることを確認してください。これらの要件を満たすことは、Windchill エコシステム内でのプラグインの互換性、パフォーマンス、安定性を実現するために不可欠です。
Windchill サーバーの設定に関する詳細は、「Windchill のインストールおよびインストールプロセスフロー」を参照してください。
プラグインはメソッドサーバーと同じマシンでホストされるので、スムーズに動作させるためには追加のメモリが必要になります。
• サポートされている Windchill バージョン: Windchill 12.1.2.22、13.0.2.10、および 13.1.3.0
• オプションモジュール (PartsLink) - このプラグインは Windchill 環境へのインストールをサポートします。この柔軟性により、プラグインをさまざまな Windchill セットアップに統合できます。
◦ PartsLink を使用 - 構造化された分類体系を使用して、部品の高度な分類と再使用を可能にします。
* 
「Windchill PartsLink」および「Windchill インデックスサーチ用の手順の実行」のトピックで説明されているように、分類フィルタ機能を有効にするには SOLR サーバーが必要です。
◦ PartsLink を使用しない - 分類機能強化のない標準の Windchill 機能。
• BLOB ストレージのオプション - このプラグインは、クラウドベースの BLOB (バイナリラージオブジェクト) ストレージを使用する Windchill 環境をサポートします。これにより、これらのクラウドサービスに保存されている大きなファイルやドキュメントをシームレスに処理できます。
◦ Microsoft Azure
◦ Amazon Web Services (AWS)
* 
プラグインには、AWS または Azure のいずれかの専用ストレージアカウントが必要です。現在、Windchill ではボルトのコンテンツを BLOB ストレージに保存できますが、これは個別の要件です。お客様がすでにボルトデータに BLOB ストレージを使用している場合でも、このプラグイン専用のストレージアカウントが必要です。
• Apache サーバーコンフィギュレーション - プラグインは、Windchill 12.1.2.22、13.0.2.10、および 13.1.3.0 リリースでサポートされているように、Apache を介して次の認証方法を使用します。
◦ 基本認証 - 単純なユーザー名/パスワードのアクセス
◦ SSO SAML
◦ CAC-PKI (クライアント証明書) - SSL 証明書を使用した強力な認証
◦ OIDC-SSO
* 
AI Parts Rationalization プラグインが Windchill バージョン 12.1.2.22 で使用されている場合、OIDC-SSO 認証はサポートされません。
* 
MPMLink を使用している場合に、長い URL でのインデックシングを有効にするには、次のように AJP および Tomcat サーバーの設定を行います。
1. Windchill シェルで、<HTTP サーバー> フォルダに移動し、次のコマンドを実行します。
ant -f config.xml configureAJPWorkers -DajpMaxPacketSize=16384
2. Windchill シェルで、<Windchill>/Tomcat フォルダに移動し、次のコマンドを実行します。
ant -f config.xml configureConnectors -DajpMaxPacketSize=16384
3. HTTPServer/conf/httpd.conf ファイルを編集し、次の行を追加します。
LimitRequestLine 16384
LimitRequestFieldSize 16384
4. Apache サーバーと Windchill サーバーを再起動して変更を適用します。
「Apache の設定を保持」が有効になっている状態での Windchill のアップデート
Windchill を 12.1.2.22、13.0.2.10、または 13.1.3.0 にアップグレードする際に「Apache の設定を保持」オプションを選択すると、アップグレードプロセス中に Apache サーバーはアップデートされません。つまり、既存の Apache コンフィギュレーションは変更されず、更新プログラムで導入された新しいコンフィギュレーションの変更は自動的に適用されません。
必要な Apache コンフィギュレーションの変更を手動で適用するには、アップデート中に「Apache の設定を保持」として「真」を選択した場合にのみ、次の手順を実行します。このオプションを選択しなかった場合、アップデートされた Apache コンフィギュレーションが自動的に適用されます。
これらの手順は、すべての認証タイプ (SAML SSO および基本認証) に共通して適用されます。
1. 必要なモジュールの読み込み - <Windchill_Home>\HTTPServer\conf\templates\ にある modules-load.conf.template ファイルを更新して、欠落しているモジュールを含めます。
<IfModule !rewrite_module>
LoadModule rewrite_module modules/mod_rewrite.so
</IfModule>
<IfModule !proxy_module>
LoadModule proxy_module modules/mod_proxy.so
</IfModule>
<IfModule !proxy_http_module>
LoadModule proxy_http_module modules/mod_proxy_http.so
</IfModule>
<IfModule !proxy_hcheck_module>
LoadModule proxy_hcheck_module modules/mod_proxy_hcheck.so
</IfModule>
<IfModule !proxy_balancer_module>
LoadModule proxy_balancer_module modules/mod_proxy_balancer.so
</IfModule>
<IfModule !slotmem_shm_module>
LoadModule slotmem_shm_module modules/mod_slotmem_shm.so
</IfModule>
<IfModule !watchdog_module>
LoadModule watchdog_module modules/mod_watchdog.so
</IfModule>
<IfModule !lbmethod_byrequests_module>
LoadModule lbmethod_byrequests_module modules/mod_lbmethod_byrequests.so
</IfModule>
2. Apache を再設定します。次に進む前に、Apache フォルダのバックアップを作成します。次に、以下のコマンドを実行して Apache を再設定します。
ant -f config.xml reconfigure
• SAML SSO
a. 共通の手順 1の説明に従って、必要なモジュールを読み込みます。
b. ディレクティブ ShibUseHeaders On が REMOTE_USER の /apache/conf/conf.d/30-app-Windchill-1Auth.conf にある LocationMatch エレメント内に存在することを確認します。存在しない場合は追加します。
• 基本認証
1. 共通の手順 1の説明に従って、必要なモジュールを読み込みます。
2. <Windchill_Home>\HTTPServer\conf\templates\xsl にある webAppAuthResToConf.xsl ファイルを更新し、Require valid-user 行の後に次のコードを追加します。
<xsl:if test="$resource='WCPlugins'">
RewriteRule .* - [E=PROXY_USER:%{LA-U:REMOTE_USER}]
RequestHeader set REMOTE_USER %{PROXY_USER}e
</xsl:if>
3. app-Windchill-AuthRes.xml を修正します。\<Windchill_Home>\HTTPServer\conf にある app-Windchill-AuthRes.xml ファイルを更新して、<resources> 開始タグの直後で、既存のすべての <resource> エントリの前に、次の行を追加します。
<resource>WCPlugins</resource>
4. Apache を再設定します。次に進む前に、Apache フォルダのバックアップを作成します。次に、以下のコマンドを実行して Apache を再設定します。
ant -f webAppConfig.xml regenAllWebApps
ant -f config.xml reconfigure
「Apache の設定を保持」を真に設定して Windchill をアップグレードする場合、Apache を手動でアップデートする必要があります。SAML SSO では、ShibUseHeaders On ディレクティブが正しく設定されていることを検証する必要があります。基本認証では、追加のコンフィギュレーション変更と Web アプリケーションの再生成が必要です。SAML SSO および基本認証に関連する手順を完了した後、Apache を再設定します。
* 
Windchill が HTTPS 用に設定されていることを確認します。詳細については、PTC HTTP Server および Windchill の HTTPS の設定を参照してください。
* 
カスタム証明書が Windchill でカスタムアプリケーション (Navigate アプリケーションなど) 用に設定されている場合は、カスタム証明書ファイルのコンテンツを手動で HTTPServer/conf/sslvhostconf.d/allClientCerts.crt にコピーし、カスタム証明書を参照するコンフィギュレーションファイルを除去します。
プラグインのインストールディレクトリの設定
専用のプロパティ wt.plugins.installed.dir が既成 (OOTB) で提供され、管理者はプラグインファイルを解凍してインストールするディレクトリを定義できます。デフォルトでは、このプロパティは空白のままです。つまり、インストールパスは事前に定義されていません。
Windchill をインストールする管理者は、Windchill ホームディレクトリ以外のセキュリティで保護されたディレクトリを手動で作成する必要があり、そのディレクトリには読み取り、書き込み、および実行のアクセス許可を付与する必要があります。その後、このプロパティを設定する必要があります。
xconfmanager を使用して、wt.properties ファイルで wt.plugins.installed.dir プロパティを追加および適用するには、次のコマンドを使用します。次に例を示します。
xconfmanager -s wt.plugins.installed.dir=<your_custom_path> -t codebase/wt.properties && xconfmanager -pF
* 
Windows でプラグインのインストールディレクトリのパスを指定する場合、有効なパスの形式に関するガイダンスについては、「URI と URL の指定」のトピックを参照してください。
インストールディレクトリへのアクセスが管理者ユーザーのみに付与されていることを確認します。このアクセス許可はその他のユーザーに付与しないでください。
* 
プラグインのインストールディレクトリが説明どおりに作成されていない場合、プラグインのインストールは続行されません。
ディレクトリを作成し、プロパティを使用してディレクトリを定義すると、Windchill サーバーを再起動せずにプラグインをインストールできます。
Windchill クラスタ環境におけるプラグインインストール用の共有ディレクトリの設定
Windchill クラスタ環境では、プラグインをインストールするために、クラスタ内のすべてのノードからアクセス可能な共有ディレクトリが必要です。この共有場所により、環境全体で一貫した展開とプラグインの可用性が確保されます。
* 
プラグインのインストールは共有ディレクトリを介してのみサポートされ、クラスタコンフィギュレーションでローカルディレクトリはサポートされません。共有ディレクトリが適切に設定されていない場合、またはどのノードからもアクセスできない場合、プラグインのインストールプロセスは失敗します。
管理者は次のガイドラインに従って、共有ディレクトリを正しく設定し、セキュリティで保護する必要があります。
• すべての Windchill ノードからアクセス可能な、共通プラグインインストールディレクトリとして機能するネットワーク共有フォルダを作成します。
• 有効なネットワークパスを指定します。
◦ \\shared\plugins (UNC パスフォーマットを使用する Windows システムの場合)
◦ /mnt/shared/plugins (マウントされたネットワークパスを使用する Linux システムの場合)
• すべてのノードが共有フォルダに対する読み取りアクセス権および書き込みアクセス権を持っていることを確認し、Windchill インストーラユーザーに実行アクセス許可を付与します。Windows クラスタ設定では、プラグインサーバーは常にヘッドレスモードで動作します。
• xconfmanager ユーティリティを使用して、各ノードの wt.plugins.installed.dir プロパティを設定し、このプロパティが一貫して共有ディレクトリを指していることを確認します。
• 共有ディレクトリに、すべてのプラグインを格納するのに十分な空き領域があることを確認します。たとえば、10 個のプラグインをインストールする予定で、各プラグインのサイズが異なる場合は、すべてのプラグインのサイズを合計して、必要な総容量を算出します。共有ディレクトリには、インストール後にすべてのプラグインを収容するのに十分な空き容量が必要です。
* 
クラスタ設定では、プラグインのインストール中にいずれかのノードが停止した場合、プラグインはその時点で稼働しているノードにのみインストールされます。停止したノードがオンラインに戻ると、プラグインはそのノードに自動的にインストールされ、それに応じて Apache コンフィギュレーションの変更が更新されます。
たとえば、ノード 1 とノード 2 がある設定について考えてみます。プラグインのインストール中にノード 2 が停止するかオフラインになった場合、その時点でプラグインはノード 2 にインストールされません。サーバーと Apache サービスが再起動してノード 2 がオンラインに戻った後、必要なすべてのインストールファイルがノード 2 で自動的に更新されます。手動での手順は必要ありません。
プラグインのインストールディレクトリ内のログファイル
プラグインのインストールディレクトリには、プラグインによって生成されたファイル (/opt/ptc/plugins/logs など) を持つログフォルダが含まれています。管理者は、これらの詳細なログを参照して、問題のトラブルシューティングや操作の確認を行うことができます。これらのログには、タイムスタンプ、リクエストの詳細、およびエラーメッセージが含まれます。
プラグインログを生成するためのカスタムの場所を指定する専用のプロパティ wt.plugins.logs.dir が用意されています。
• このプロパティが設定されていない場合、プラグインのログはプラグインのインストールディレクトリ (/opt/ptc/plugins/logs など) に生成されます。
• プロパティが設定されている場合、プラグインログはプロパティで指定されているディレクトリに生成されます。
* 
Windchill 関連のログは、Windchill インストールのログディレクトリ内にある Apache および MethodServer のログにあります。
プラグインのテンポラリディレクトリの設定
新しいプロパティ wt.plugins.temp.dir が導入されました。これはオプションのプロパティで、プラグインのテンポラリファイルを保存するディレクトリを定義します。デフォルトでは、ディレクトリパスは ${wt.temp}/<pluginId> に設定されています。wt.temp は、Windchill の一時的な場所を定義する既存の wt プロパティです。このディレクトリへの書き込みアクセスは、管理ユーザーのみに付与することが重要です。このアクセス許可はその他のユーザーに付与しないでください。
このプロパティを設定するには、次のコマンドを使用します。
xconfmanager -s wt.plugins.temp.dir=<your_custom_path> -t codebase/wt.properties && xconfmanager -pF
PUBLISHCLOUDENTRY テーブルの VIZSERVERJOBID コラムにおける一意のインデックスの作成
外部ジョブの作成と AI Parts Rationalization 操作のパフォーマンスを向上させるには、PUBLISHCLOUDENTRY テーブルの VIZSERVERJOBID コラムに一意のインデックスを作成します。
一意のインデックスを作成するには、次の手順を実行します。
1. インデックスを作成する前に、VIZSERVERJOBID コラムに重複する値がないことを確認してください。このコラムは、Windchill で既成 (OOTB) では使用されないため、現時点では空になっています。
2. データベースベンダーによって提供された適切な SQL コマンドを使用して、PUBLISHCLOUDENTRY テーブルの VIZSERVERJOBID コラムに一意のインデックスを作成します。
Oracle データベースの例を以下に示します。データベース管理者は、そのデータベースシステムに固有の要件とベストプラクティスに従って、構文とオプションを調整する必要があります。
CREATE UNIQUE INDEX "VIZSERVERJOBID_UNIQUE_IDX" ON "PUBLISHCLOUDENTRY" ("VIZSERVERJOBID")
PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS
STORAGE(INITIAL 24576 NEXT 24576 MINEXTENTS 1 MAXEXTENTS 2147483645
PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
TABLESPACE "INDX";
3. 必要に応じて、新しく作成したインデックスを再構築します。
4. インデックスが正常に作成されたことを確認します。
組織のシステムパラメータに応じて、データベース管理者が適切な処置を取る必要があります。
* 
VIZSERVERJOBID は、部品サーチおよび外部ジョブフローでキー識別子として使用されます。
* 
VIZSERVERJOBID コラムに一意のインデックスを作成する場合、インデックス固有のパラメータはオプションです。本番環境のデータベースサーバーのデフォルト設定を使用することをお勧めします。適切なテーブルスペース名が指定されている基本的なインデックス作成照会のみが実行されます。
顧客ストレージの設定
次のセクションでは、サポートされている各ストレージオプション (Microsoft Azure Blob Storage と Amazon S3 バケット) のコンフィギュレーション手順について概説します。
オンプレミスの Windchill サーバーコンフィギュレーションの場合、AI Part Rationalization では、Microsoft Azure Blob Storage および Amazon S3 バケットに接続する際に SECURITY_CREDENTIALS 認証のみがサポートされます。
ストレージのコンフィギュレーション中に提供されるすべての機密情報は、キーストアを使用して安全に保管されます。これにより、資格証明が暗号化され、不正アクセスから保護され、データの機密性と整合性が維持されます。
詳細については、「Configuring Customer Storage」のトピックを参照してください。
• Azure Storage
◦ アカウント名 - ご使用の Azure Storage アカウント名。
◦ アカウントキー - アクセスの認証に使用される秘密キー。
◦ コンテナ名 - 既存のコンテナまたは新規作成したコンテナの名前。
* 
ストレージのアカウント名とアクセスキーは、Azure Storage ページの「セキュリティとネットワーク」で確認できます。
Azure Storage アカウントをすでにお持ちの場合は、セキュリティとストレージの編成を強化するために、追加のアカウントを作成することをお勧めします。既存のアカウント名は、「Azure Portal」 > 「Storage Account」で確認できます。
Azure Storage は、VCS で使用するためにパブリックにアクセスできる必要があります。「Azure Storage」 > 「Security + networking」 > 「Networking」 > 「Firewalls and virtual networks」 > 「Public network access」で、「Enabled from all networks」オプションを設定します。
• Amazon S3
◦ バケット名 - Amazon S3 バケットの名前
◦ アクセスキー ID - ご使用の AWS アクセスキー ID
◦ シークレットアクセスキー - 認証用のシークレットキー
◦ リージョン - バケットがホストされている AWS リージョン
* 
上記の詳細は、AWS コンソールで確認できます。
• Amazon S3 バケット名 - AWS コンソールで Amazon S3 サービスに移動します。バケット名は、メイン S3 ダッシュボードの「バケット名」コラムにリストされます。現在、AI Parts Rationalization プラグインは、Amazon S3 バケットの下のフォルダ構造をサポートしていません。
• アクセスキー ID - 「IAM」 > 「ユーザー」 > 「ユーザー名」 > 「セキュリティ認証情報」タブに移動して、アクセスキー ID を表示または作成します。
• シークレットアクセスキー - シークレットアクセスキーは、「IAM」 > 「ユーザー」 > 「ユーザー名」 > 「セキュリティ認証情報」で新しいアクセスキーを作成する場合にのみ見つけることができます。一度だけ表示され、後でもう一度表示されることはありません。
• リージョン - AWS コンソールで Amazon S3 サービスに移動します。バケットリストでは、各バケット名の横の「AWS リージョン」コラムにリージョンが表示されます。
• Amazon S3 バケットでポリシーを定義します。Amazon S3 バケット AIPlugin-s3-bucket で定義されたポリシーのサンプルスナップショットは次のとおりです。
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": "s3:*",
"Resource": [
"arn:aws:s3::: AIPlugin-s3-bucket",
"arn:aws:s3::: AIPlugin-s3-bucket/*"
]
}
]
}
このポリシーは、顧客のセキュリティ要件に基づいてカスタマイズできます。Amazon S3 バケットに対して、読み取り、書き込み、リスト、削除、および存在確認のアクセス権を必ず付与してください。
詳細については、「IAM の使用開始」を参照してください。
選択したストレージタイプに関連するフィールドのみを表示して入力できます。
プラグインの設定時には、ストレージアカウントの詳細情報が必要になります。詳細については、AI Parts Rationalization プラグインの設定のセクションを参照してください。
インデックシングユーザーの設定
既成では、プラグインコンフィギュレーション UI のインデックシングユーザーフィールドは空白です。インデックシングを有効にするには、有効なインデックシングユーザーを設定する必要があります。
サイト管理者がインデックシングユーザーとして設定されている場合、すべてのサイトデータがインデックシングの対象となります。サイト管理者は、新規アクセス制御規則を設定する必要はありません。
サイト管理者は、Windchill システムでインデックシングユーザーを作成および設定します。インデックシングユーザーは、インデックシング操作を開始するために特別に指定された管理者以外のユーザーでなければなりません。
適切なコンテキストレベルのアクセス制御を使用して、インデックシングユーザーは特定の製品コンテンツをインデックシングに含めたりインデックシングから除外したりすることができます。
* 
• インデックシングユーザーにサイトレベルとコンテキストレベルの両方のアクセスを付与します。
• インデックシングユーザーを作成してコンフィギュレーションを追加しても、そのユーザーに対してポリシー管理規則を定義して、コンテキストアクセスを付与しなければ、データはインデックシングされません。
• ライセンス除外グループを使用して、インデックシングユーザーをいずれかの基本ライセンスに追加します。詳細については、「ライセンス除外グループ」を参照してください。
インデックシングユーザーを設定するには、次の手順を実行します。
1. サイトレベルのアクセス制御を設定します。
a. Windchill で「ユーティリティ」 > 「ポリシー管理」に移動します。
b. 「単一のコンテキスト」 > 「サイト」を選択します。
インデックシングユーザーの名前 (IndexUser) は、コンフィギュレーション時にユーザーによって定義されます。
* 
プラグインを設定する際にインデックシングユーザー ID (IndexUser) を指定する必要があります。詳細については、AI Parts Rationalization プラグインの設定のセクションを参照してください。
2. コンテキストレベルのアクセス制御を設定します。
a. Windchill で「ユーティリティ」 > 「ポリシー管理」に移動します。
b. 「すべてのコンテキスト」を選択します。テーブルから、「デフォルト」 > 「PDM」 > 「コンテキスト」を選択します。これらのアクセス制御は、部品をインデックシングする必要がある「製品」コンテキストに対して設定します。
c. 次のコンフィギュレーションで新規アクセス制御規則を作成します。
タイプ
ユーザー
アクセス制御
部品
IndexUser
読み取り
派生イメージ
IndexUser
読み取り、ダウンロード
インデックシングユーザーには、「派生イメージ」タイプに対するダウンロードアクセス権が必要です。このアクセス許可は、サイトレベルのコンテキストから継承することも、特定のコンテキストに明示的に追加することもできます。
* 
インデックシングユーザーを設定する際には、そのユーザーに対して特定のコンテキスト (サイト、製品、ライブラリ、プロジェクト、組織など) へのアクセス権を付与することをお勧めします。特定のコンテキスト内の特定のデータのみをインデックシングする場合は、そのコンテキスト内の「部品」タイプおよび「派生イメージ」タイプに対するアクセス許可が適切に付与されていることを確認する必要があります。アクセスを制限しない場合、Windchill データベース内のすべての部品がインデックシングされます。そのようなインデックシングは不要な場合があり、インデックシングの所要時間が大幅に増加します。
このライセンスは AI クレジットを使用するため、インデックシングの対象を慎重に選択してください。不要なインデックシングによってこれらのクレジットが消費され、後で追加クレジットを購入するための追加コストが発生する可能性があります。アクセス許可を慎重に設定することで、インデックシングの対象を制御し、不要なリソース消費を防ぐことができます。
3. インデックシングプロセスを開始するには、重複部品のサーチページの「インデックシングを開始」をクリックします。詳細については、管理者による重複部品のサーチおよびデータのインデックシングを参照してください。
4. 「プロジェクト」および「ライブラリ」のコンテキストにおけるインデックシングユーザーを設定するには、ユーザーは「プロジェクト」または「ライブラリ」の作成者としてログインする必要があります。
◦ 「プロジェクト」コンテキストについては、「プロジェクト」 > 「ユーティリティ」 > 「ポリシー管理」に移動します。
◦ 「ライブラリ」コンテキストについては、「ライブラリ」 > 「ユーティリティ」 > 「ポリシー管理」に移動します。
5. 手順 2c の説明に従って、PDM コンテキストで設定したものと同じポリシーアクセスを設定します。
* 
インデックシングユーザーを変更するか、コンテキストに対してそのユーザーに関連付けられているアクセス許可を変更した場合、後でこれらのアクセス許可を除去しても、インデックシング済みのデータはベクトルインデックス内に残ります。つまり、インデックシングの完了後は、コンテキストに対するアクセス許可を除去しても、対応するエントリがインデックスから削除されることはありません。
たとえば、インデックシングユーザーが 2 つのコンテキストに対するアクセス許可を持っており、両方のコンテキストのインデックシングが完了したとします。後で、一方のコンテキストに対するアクセス許可を除去しても、その埋め込みは除去されません。アクセス許可が除去されても、インデックスにはそのコンテキストのエントリが保持されます。
これは役に立ちましたか?