問題の監視、診断、および解決に関するガイドライン
このセクションでは、以下の項目について説明します。
• 問題の監視および診断を行う方法に関する一般的なガイドラインと、その問題を解決するための具体的な方法のリスト
• 具体的な問題、原因、および解決策のリスト
問題の監視
Windchill ESI 管理者には、ヘルプデスクで記録されたトラブルチケットを含むユーザーレポートなどのレポートチャネルを通じて、または電子メールや自動システム警告を通じて問題が警告されます。
ユーザーレポートは受動的で事後対応型の問題検出方法です。Windchill ESI システムの安定性を向上させ、総所有コストを削減するには、自動システム警告を使用してユーザーレポートを補ってください。自動システム警告は事前対応型の方法であり、問題が重大化する前に防ぐことができます。
以下のセクションでは、問題を監視する方法について説明します。
• TIBCO BusinessWorks の監視サービス
• エラー処理プロセスとログサービス
• イベントルールと問題検出方法
BusinessWorks による監視
TIBCO BusinessWorks は、Windchill EAI ソフトウェアコンポーネントの監視とシステム問題の処理を行うために Windchill ESI エラー処理プロセスによって使用されます。TIBCO Administrator では、管理ドメイン内のハードウェアおよびソフトウェアコンポーネントを監視して維持するためのグラフィカルユーザーインタフェースとマイクロエージェントが提供されています。これらのツールを設定して、BusinessWorks の処理エンジン、アダプタ、ログファイルエントリ、空きディスク容量、オペレーティングシステムパラメータなどを監視できます。展開設定を定義した後、TIBCO Administrator を使用して、コンポーネントエラー、サスペンドプロセス、ログイベントなど、あらかじめ定義したイベントによってトリガされる警告およびエスカレーションルールを作成できます。
BusinessWorks を使用すると、以下の問題を監視できます。
• BusinessWorks エンジンの問題
• アダプタの問題
• JMS の問題
BusinessWorks エンジンの問題
TIBCO BusinessWorks エンジンは、Windchill ESI で使用されているすべてのプロセスに対して実行する必要があります。したがって、BusinessWorks 監視コンポーネントは以下の項目を実行できる必要があります。
• BusinessWorks エンジンのエラーによってメッセージが失われたり処理が停止したりした場合に発生したイベントの処理
• エラー発生時の TIBCO Administrator 監視に対する警告の送信
• エラー頻度の増加に応じた操作のエスカレート
エラーのカテゴリ
公開において、エラーは以下のカテゴリに分類できます。
• 「Any Failure」:すべてのエラーを取得し、操作を実行します。
• 「First Failure」:エンジンの最初のエラーを取得し、操作を実行します。
• 「Second Failure」:エンジンの 2 番目のエラーを取得し、操作を実行します。
• 「Subsequent Failure」: 2 番目のエラーの後に発生したエラーを取得し、操作を実行します。
推奨公開設定
さまざまなタイプのエラーに対して展開時に設定できる推奨操作は以下のとおりです。
• 「Any Failure」:管理者に警告を発します。
• 「First Failure」:エンジンを再起動します。
• 「Second Failure」:エンジンを再起動し、2 回目のエラー警告を発します。
• 「Subsequent Failure」:エンジンを再起動し、管理者に電子メールを送信します。
エラー数をいつ初期値にリセットするかを決定するコンフィギュレーション可能なカウンタおよびタイマーがあります。このカウンタのタイマー設定を使用して、特定の時間枠に設定します。この時間枠内で 3 つ以上のエラーがあると、システム全体の整合性に重大な問題が発生します。
1. TIBCO Administrator GUI の以下のページに移動します。
◦ 「Application Management」 > 「<アプリケーション名>」 > 「Configuration」 > 「Process Archive.par」
2. 「Monitoring」タブをクリックします。
3. 「Event」の下にある「Add」ボタンをクリックします。「Add Event」画面が表示されます。
4. 監視するイベントのタイプを選択します。たとえば、JMS キューでエラーが発生すると、プロセスがサスペンドされますが、処理のサスペンドを監視する警告を設定できます。
システム管理者は、TIBCO BusinessWorks Administrator を使用してエンジンを再起動できます。詳細については、下記のトピック「JMS の問題」を参照してください。
アダプタの問題
アダプタの配布ターゲットシステムは、Windchill ESI で使用されている多数のプロセスに対して実行する必要があります。したがって、TIBCO BusinessWorks 監視コンポーネントは以下の項目を実行できる必要があります。
• エラー発生時のアダプタインスタンスの再起動
• エラー発生時の TIBCO Administrator に対する警告の送信
• エラー頻度の増加に応じた操作のエスカレート
エラーのカテゴリ
公開において、エラーは以下のカテゴリに分類できます。
• 「Any Failure」:すべてのエラーを取得し、操作を実行します。
• 「First Failure」:アダプタの最初のエラーを取得し、操作を実行します。
• 「Second Failure」:アダプタの 2 番目のエラーを取得し、操作を実行します。
• 「Subsequent Failure」: 2 番目のエラーの後に発生したエラーを取得し、操作を実行します。
推奨公開設定
さまざまなタイプのエラーに対して展開時に設定できる推奨操作は、次のとおりです。
• 「Any Failure」:管理者に警告を発します。
• 「First Failure」:アダプタを再起動します。
• 「Second Failure」:アダプタを再起動し、2 回目のエラー警告を発します。
• 「Subsequent Failure」:アダプタを再起動し、管理者に電子メールを送信します。
エラー数をいつ初期値にリセットするかを決定するコンフィギュレーション可能なカウンタおよびタイマーがあります。このカウンタのタイマー設定を使用して、特定の時間枠に設定します。この時間枠内で 3 つ以上のエラーがあると、システム全体の整合性に重大な問題が発生します。
JMS の問題
マスタープロセスフローとエラー処理プロセスが正常に動作するには、EMS サーバーを実行する必要があります。TIBCO Administrator は以下の項目を実行できる必要があります。
• EMS サーバーエラーの発生時に生成されたイベントの処理
• エラー発生時のエラー処理プロセスに対するエラーの送信
TIBCO BusinessWorks では、EMS サーバーエラーの発生時にイベントが作成されません。これに対処するために、以下のいずれかの操作を行うことができます。
• サスペンドなし:「サスペンド」チェックボックスがオフの状態で、repeat-on-error-until-true グループの後の実行時に JMS キューが応答しないか接続できない場合、BusinessWorks によって、JMS アクティビティのタイムアウトを示す処理エンジンのログエントリが生成されます。ログを監視してこのエントリが発生した場合に警告を発するように、TIBCO Administrator のログイベントを設定できます。
• サスペンド: 「サスペンド」チェックボックスがオンの状態で、repeat-on-error-until-true グループの後の実行時に JMS キューが応答しないか接続できない場合、BusinessWorks によって処理がサスペンドされます。警告を発するように TIBCO Administrator のルールベースを設定できます。
デフォルトでは、Windchill ESI はサスペンド方式に設定されています。これにより、JMS キューのエラーを取得したプロセスを EMS サーバーの再起動後に続行できます。
EMS サーバーの問題に関する特別なガイドライン
Windchill PDMLink では、一度に使用できる JMS プロバイダは 1 つだけです。TIBCO EMS サーバーは、Windchill ESI アーキテクチャに不可欠な部分となっており、Windchill PDMLink ユーザーは、Windchill ESI アプリケーション以外の機能のために TIBCO EMS サーバーを使用する場合があります。したがって、JMS の問題に関連した Windchill ESI の問題が発生したときに自動的に EMS サーバーが再起動するように Windchill ESI を設定することは適切ではない場合があります。デフォルトの推奨設定は、重大な JMS 問題が検出された場合に、エラー処理プロセスによって現在の BusinessWorks ジョブをサスペンドモードにすることです。
サスペンドモードでは手動介入が可能であり、データを失う危険性がありません。対象の BusinessWorks ジョブ、つまりパブリッシング中の製品データトランザクションのみがサスペンドされ、同じ処理エンジン内のほかのジョブは続行できます。ほかのジョブで同じ JMS 問題が発生した場合は、そのジョブも個別にサスペンドされます。ジョブを個別に再開するには、TIBCO BusinessWorks Administrator を使用します。ジョブは、最後のチェックポイントではなくサスペンド位置から再開されます。
TIBCO Administrator には、TIBCO EMS の管理ドメイン監視機能が組み込まれていません。ただし、EMS サーバーがサスペンドされるか再起動が必要な場合に警告を発するように TIBCO BusinessWorks を設定できます。エンドユーザーは TIBCO EMS の基本管理コンソールを使用して、EMS サーバーがサスペンドされるか再起動が必要な場合に警告を発するように TIBCO BusinessWorks を設定できます。詳細については、下記のトピック「電子メール警告の設定」を参照してください。
Oracle Applications の問題
Oracle Applications 用の TIBCO アダプタのログファイルでは、無効な Oracle ApplicationsWindchill ESI ユーザーアカウントなどの問題をレポートできます。このような状況は通常、インストール時の入力ミスやパスワードの期限切れなどの問題が原因で発生します。これらは予想外の場合があり、診断は困難です。したがって、関連するメッセージテキストがログファイルにないかどうかを監視し、イベントが発生した場合は警告を発するように TIBCO BusinessWorks を設定できます。
エラー処理プロセスとログサービスの使用
ベースになる TIBCO 製品で問題に対する警告を設定するだけでなく、エラー処理およびログ共有サービスを使用して Windchill ESI の問題を検出および特定できます。
イベントルールと問題検出方法の開発
イベントルールはハードウェア展開に密接に関係しているため、Windchill ESI ではすぐに使用できる定義済み設定を提供できません。ただし、必要に応じて、ベースになる TIBCO 製品および Windchill ESI ビジネスロジックコンポーネントに合わせて非侵襲的な方法で徐々にイベントルールの開発と調整を行うことができます。最も一般的または最も困難な問題に基づいてルールの開発に優先順位を付け、事後対応型の問題検出方法から事前対応型の問題検出方法に徐々に移行できます。
問題の診断
自動的に修正できず、ユーザーも修正できない問題を検出した場合は、その問題の診断を開始する必要があります。これには、根本原因を調べるための問題の分類および特定が含まれます。
問題の特定
問題の原因を特定するには、以下のようなことを検討する必要があります。
• その問題は、記録方式違反などのビジネスプロセスの問題、無効データなどの機能的な問題、またはサーバーダウンなどの技術的な問題のどれに関連しているか。
• その問題は Windchill PDMLink、TIBCO、または配布ターゲット ERP システムのどれに関連しているか。
• TIBCO に関連する問題の場合、その問題は TIBCO Enterprise for EMS、BusinessWorks、または Oracle Applications 用のアダプタのどれに関連しているか。
• その問題は BusinessWorks 公開エージェントや実行時エージェントに関連しているか。
• その問題は、Windchill ESI ではなく、ベースになる物理ネットワークおよびコンピューティングに関連しているか。
• その問題のシナリオを実稼働環境と同じ設定のテストシステムで再現できるか。
問題の分類: トラブルシューティングの重点事項
問題を分類するには、主要な問題領域に焦点を当て、エラーログやエラー処理コードなどのエラー処理レポートをよく理解する必要があります。
ほとんどのシステム関連の技術的な問題は、根本原因の位置に応じて分類できます。適切な設定を確認して修正するには、Oracle Applications 環境での Windchill ESI の管理 と、必要に応じてシステムインテグレーターから提供される関連ドキュメントを参照してください。
業務プロセスおよび機能のトラブルシューティングの情報を十分に理解することも重要です。この情報をよく理解していないユーザーから、このような問題が管理者にエスカレートされる場合があります。
以下の問題のカテゴリとその説明は、詳しい段階的な手順を網羅したものではありません。技術的な問題の主要な根本原因または潜在的な根本原因に焦点を当てるのに役立つように提供されています。
• Windchill ESI で発生する問題
• 以下のような TIBCO コンポーネントで発生する問題
◦ EMS
◦ BusinessWorks
◦ Oracle Applications 用のアダプタ
• 配布ターゲットで発生する問題
• Windchill ESI のログに示される問題
Windchill ESI の問題
以下のリストは、Windchill ESI サービスで発生する可能性のある問題の対処方法を示しています。
• Windchill サーバーおよびアプリケーションが動作していることを確認します。
• Windchill JMS クライアントが TIBCO EMS サーバーに接続されていることを確認します。
• EMS サーバーの Windchill ESI ユーザーアカウントが正しく設定されていることを確認します。
• ほかのすべての JMS 関連設定を確認します。
• Windchill 管理ログにエラーメッセージがないかどうかを調べます。
• そのリリースの配布ターゲットとその属性を確認します。
• Windchill Enterprise Integration Access Remote Procedure Call (RPC) が正常に動作していることを確認します。
• 各種 Windchill ESI プリファレンスに設定した値が正しいかどうかを確認します。
TIBCO の問題
以下のリストは、TIBCO コンポーネントで発生する可能性のある問題の対処方法を示しています。
EMS の問題
• EMS サーバーが動作していることを確認します。
• EMS サーバーが正しく設定されていることを確認します。
• 必要な Windchill ESI JMS キューが定義されていることを確認します。
• EMS サーバーの BusinessWorks Windchill ESI ユーザーアカウントが正しく設定されていることを確認します。
• セキュリティ保護されたキューの認証設定を確認します。
• 未サポートのバージョンやメモリオーバーフローエラーなど、Java Virtual Machine (JVM) の問題を切り分けます。
BusinessWorks の問題
• 必要なすべての TIBCO サービスが動作していることを確認します。次の必要なサービスが実行されていないと、処理エンジンは起動しません。必要なすべての TIBCO サービスが動作していることを確認します。
◦ TIBCO Administrator <バージョン> (ドメイン名)
◦ TIBCO HAWK Agent (ドメイン名)
• 必要な Windchill ESI BusinessWorks アプリケーションプロパティおよびコンフィギュレーションファイルの存在と内容を確認します。
◦ ESIORAEMailMessageLookups.properties
◦ ESIORADefaults.properties
◦ ESIORAErrorHandlingCodes.properties
◦ ESIORALookups.properties
◦ ESIORAMessageLookups.properties
◦ FilesToRead_ORA.properties
• BusinessWorks JMS クライアントが TIBCO EMS サーバーに接続されていることを確認します。
• ほかのすべての EMS 関連設定を確認します。
• 未サポートのバージョンやメモリオーバーフローエラーなど、Java Virtual Machine (JVM) の問題を切り分けます。
• Windchill ESI コンポーネントが適切なドメインに展開されていることを確認します。
• グローバル変数値を含む Windchill ESI ビジネスロジック設定および展開設定を確認します。
|
|
新しいグローバル変数値を有効にするには、処理エンジンを再起動する必要があります。
|
• Java クラスパスを確認します。
• TRA ファイル内の設定を確認します。
• 以下の方法で BusinessWorks Administrator サーバーの設定を確認します。
◦ ユーザーアカウントを認証します。
◦ BusinessWorks 管理ドメインにかかわらず、同じサブネット上で同じランデブーコンフィギュレーション (ネットワーク、サービス、デーモン) を持つ複数のリポジトリが固有の名前を持っていることを確認します。
◦ サーバーベースのリポジトリ (.dat) ファイルが直接削除されていないことを確認します。管理ドメインからサーバーベースのプロジェクトを適切に削除するには、以下の手順に従ってください。
▪ プロジェクトの公開を解除します (これにより .tra および .cmd ファイルがすべて除去されます)。
▪ 管理サーバーのサービスを停止します。
▪ <Tibco_ホーム>/tra/domain/<ドメイン名>/application/<アプリケーション名>/作業フォルダの内容を削除します。
▪ 管理サーバーのサービスを再起動します。
|
|
前述の参照パスの <アプリケーション名> の意味は、アプリケーションの展開名が <ドメイン名>-<アプリケーション名> の形式であることから理解できます。
|
• 国際化またはロケール設定に関する問題を切り分けます。以下の項目を確認します。
◦ メッセージの JMS ヘッダの com_infoengine_localeWindchill ESI 属性
◦ ESIOMAdapter/Locale グローバル変数
◦ データマッピングで使用されるデフォルト値および相互参照照会ファイルエントリ
Oracle Applications 用のアダプタの問題
以下のリストは、Oracle Applications 配布ターゲットで発生する可能性のある問題の対処方法を示しています。詳細については、Oracle Applications 環境での Windchill ESI の管理 を参照してください。
• すべての Oracle Applications サーバーが動作していることを確認します。
• 動作中の Oracle Applications システムのバージョンが、サポートされているバージョンであることを確認します。
• すべての ESITarget インスタンスで Oracle Applications 用の TIBCO アダプタによって使用される有効な ESISYS Oracle Applications ユーザーアカウントが存在することを確認します。
• ESISYS ユーザーアカウントに必要なセキュリティ権限プロファイルがあることを確認します。
• 国際化またはロケール設定に関する問題を切り分けます。
Oracle Applications の問題
以下のリストは、Oracle Applications 配布ターゲットで発生する可能性のある問題の対処方法を示しています。詳細については、Oracle Applications 環境での Windchill ESI の管理 を参照してください。
• すべての Oracle Applications サーバーが動作していることを確認します。
• 動作中の Oracle Applications システムのバージョンが、サポートされているバージョンであることを確認します。
• すべての ESITarget インスタンスで Oracle Applications 用の TIBCO アダプタによって使用される有効な ESISYS Oracle Applications ユーザーアカウントが存在することを確認します。
• ESISYS ユーザーアカウントに必要なセキュリティ権限プロファイルがあることを確認します。
• 国際化またはロケール設定に関する問題を切り分けます。
ログとエラー処理コード
問題の診断に役立つように、Windchill ESI で説明されている主要な Oracle Applications 環境での Windchill ESI の管理 ログについて十分に理解する必要があります。また、EAI のエラー処理アーキテクチャおよびエラーコードについて熟知している必要があります。以下の表は、使用可能なログとそのアクセス方法を示しています。
|
ログ
|
アクセス方法
|
|
Windchill Enterprise Systems のトランザクションログ
|
Windchill PDMLink のユーザーインタフェース
|
|
TIBCO BusinessWorks 処理エンジンログ
|
|
Windchill ESI アプリケーションメッセージが、標準 TIBCO 製品のメッセージと区別するための ESI という役割指定とともに表示されます。
|
|
TIBCO BusinessWorks Administratorログファイルの場所は、<TIBCO_ホーム>/tra/domain/<ドメイン名>/application/logs/<アプリケーション名>-Process_Archive.log[.シーケンス番号] です。
|
|
TIBCO EMS ログ
|
ファイル名とパスは tibemsd.conf ファイル内の logFile に関連した設定パラメータによって決定されます。
|
|
Oracle Applications TIBCO アダプタのログ
|
<TIBCO_ホーム>/tra/domain/<ドメイン名>/application/logs/<アプリケーション名>-ESIOMAdapter.log.[.シーケンス番号]
|
|
Oracle Applications ログ
|
Oracle Applications 管理者に問い合わせてください。
また、Oracle Applications 配布ターゲットと Windchill ESI の影響を受けるデータオブジェクトおよび属性についてもよく理解する必要があります。Oracle Applications でのデータの表示および操作を直接担当するか、Oracle Applications 管理者とともにこれらの作業を調整する必要があります。Oracle Applications によって Windchill ESI に転送されたデータを表示するには、以下のウィンドウが特に重要です。
• Master Item (マスターアイテム)
• 部品表
• 変更オーダー
• ルーティング
|
問題の解決
問題を監視し、検出し、診断した後、その問題を解決する必要があります。以下のセクションでは、トラブルシューティング時に使用できる一般的な方法について説明し、具体的な問題とその解決策のリストを示します。
問題の解決方法
以下のセクションでは、問題の解決に使用できるトラブルシューティング方法について説明します。
トラブルシューティングチームの編成と問題のエスカレート
Windchill ESI 管理者は、生産に関する問題を完全に解決するためにさまざまな専門家の関与と連携を図る必要があります。この関係者には、エンドユーザー、機能専門家、Windchill PDMLink 管理者、Oracle Applications 管理者、データベース専門家、オペレーティングシステム専門家、ネットワーク管理者などが含まれます。問題を診断して特定した後、社内ではその問題を解決できないと判断した場合は、システムインテグレーションパートナーと PTC テクニカルサポートのどちらかまたは両方にエスカレートして支援を求める必要があります。標準的な Windchill ESI 製品に対して行われた特殊な設定やカスタマイズに関する問題を解決するために、システムインテグレーションパートナーは特に重要です。
チェックポイントの手動オーバーライド
Windchill ESI アプリケーションは、TIBCO BusinessWorks 処理フローの重要点でチェックポイントアクティビティを利用します。チェックポイントでは、後でエラーが発生した場合に復元できるように、現在実行中の処理インスタンスの処理データおよび状態が保存されます。処理エンジンでエラーが発生した場合、すべての処理インスタンスを復元し、処理定義内の最後のチェックポイント位置から実行を再開できます。最新の状態のみがチェックポイントによって保存されます。処理に複数のチェックポイントがある場合でも、最後のチェックポイントの状態のみが処理の復元に使用できます。
Windchill ESI チェックポイントの位置は、トランザクションの整合性を向上させる一方でパフォーマンスへの悪影響を最小限に抑えるために効果的に配置されています。場合によっては、アクティブなチェックポイントを手動でオーバーライドして、処理エンジンの再起動時にトランザクション処理を最初から再開する必要があります。
|
|
チェックポイントのオーバーライドは、データの重複、不完全なデータ、不正確なエクスポート履歴レコード、データの破壊などの原因になる可能性があるため、細心の注意を払って行う必要があります。
|
ただし、状況によっては、<Tibco_Home>/tra/domain/<Domain_Name>/application/<Application_Name>/working ディレクトリおよびその内容を削除することにより、チェックポイントをオーバーライドしてください。処理エンジンのモードによっては、削除する必要のある /working サブディレクトリが /tibco パスの下に数多く存在する場合があります。/working をサーチし、これらのサブディレクトリをすべて見つけて除去してください。
Solaris プラットフォームの問題の解決
Solaris プラットフォームでは、以下のような原因で発生する問題を解決する必要があります。
• 環境変数の問題
• Designer の公開設定の問題
以下のセクションでは、これらの問題を解決する方法について説明します。
環境変数の問題
一部の UNIX プラットフォームでは、ライブラリの依存性が原因で特定の TIBCO コンポーネントが起動に失敗します。そのような特定のコンポーネントの bin ディレクトリに *.sh または * .csh ファイルが存在する場合は、それらを実行し、'ldd' コマンドを使用してライブラリの依存性を特定してください。すべての必要なライブラリへのパスを、*.tra ファイルにある tibco.env.CUSTOM_EXT_PREPEND 変数に追加する必要があります。
Designer の公開設定の問題
場合によっては、Solaris プラットフォームの TIBCO Administrator および TIBCO Runtime Agent (TRA) が破壊され、警告なしでシャットダウンされることがあります。TIBCO Designer の実行中にこれが発生すると、公開設定と TIBCO Designer が以下のように誤動作する場合があります。
• プロジェクトを開いたときに、サーバーベースのリポジトリが現在のドメインのプロジェクトプルダウンリストに表示されません。
• 公開履歴に公開済みと示されているにもかかわらず、公開コンポーネントが新規として表示されます。
• 公開済み、変更済み、または新規の公開コンポーネントに対して公開および公開解除オプションが使用できません。
このような現象が発生した場合は、Solaris マシンを再起動し、TRA と TIBCO Administrator を再起動し、Designer を再起動します。
UNIX プラットフォームでの TIBCO プロセスの検索と終了
場合によっては、問題解決の一部として、実行中のすべての TIBCO プロセスを終了する必要があります。
UNIX プラットフォームでは、UNIX コマンド ps を使用して、実行中のすべてのプロセスをリストできます。ただし、標準の 'all' フラグ ('-a') では、TIBCO Rendezvous などの低レベル TIBCO プロセスが必ずしもリストされるとは限りません。このようなプロセスを表示するには、以下のコマンドを実行します。
# ps -ef | grep <filter>
例:
# ps -ef | grep tibco
このコマンドを実行すると、以下のように表示されます。
root 5559 1 0 09:10:02 pts/1 0:18
/opt/tibco/administrator/<version>/bin/tibcoadmin --propfile /opt/
'kill' コマンドにフラグ -9 とプロセス ID ('ps -ef' コマンドの 2 番目の列) を付けて実行し、リストされたプロセスを強制終了できます。
# kill -9 5559
-9 フラグを使用すると、プロセスが実際に終了します。一般的に、すべての TIBCO プロセスが終了していることを確認するには、以下のコマンドを実行します。
ps -ef | grep tibco
ps -ef | grep hawk
および
ps -ef | grep rvd
その後、実行中のプロセスが見つからないことを確認します。
電子メール警告の設定
前述のとおり、Windchill ESI ビジネスロジックでのエラー発生時に電子メール警告メッセージを送信するように Windchill ESI を設定できます。
• Windchill PDMLink への ESIPostResult メッセージの送信
• Windchill PDMLink からの ESIResultResponse メッセージの待機
• ESIResultResponse メッセージの解析
この設定は、以下のグローバル変数を使用して行います。
• ESIMail/ToAddress
• ESIMail/FromAddress
• ESIMail/CCAddress
• ESIMail/BCCAddress
サーバーはグローバル変数 ESIMail/SMTPHostServer を使用して設定します。
グローバル変数の設定方法の詳細については、Oracle Applications 環境での Windchill ESI の管理 を参照してください。
Windchill ESI ビジネスロジックでは、EMS 関連の操作が TIBCO BusinessWorks のグローバル変数 ESIJMS/RetryCount で指定された回数だけ再試行されます。したがって、同じ問題に関する複数の電子メールメッセージを受信する場合があります。最後の試行に失敗した後、Windchill ESI ビジネスロジックによって関連 BusinessWorks プロセスがサスペンドされます。これにより、電子メール警告メッセージで説明されているエラーを調査し、根本的な問題を修正し、TIBCO Administrator を使用して BusinessWorks プロセスを再開または終了できます。このインタフェースの使用方法については、TIBCO Administrator User's Guide を参照してください。
具体的な問題の解決
以下のセクションでは、具体的な問題、考えられる原因、その解決策を示します。
TIBCO Administrator に、BW エンジンまたはアダプタプロセスのステータスが不明と表示される
場合によっては、問題解決の一部として、実行中のすべての TIBCO プロセスを終了する必要があります。
UNIX プラットフォームでは、UNIX コマンド ps を使用して、実行中のすべてのプロセスをリストできます。ただし、標準の 'all' フラグ ('-a') では、TIBCO Rendezvous などの低レベル TIBCO プロセスが必ずしもリストされるとは限りません。このようなプロセスを表示するには、以下のコマンドを実行します。
# ps -ef | grep <filter>
例:
# ps -ef | grep tibco
このコマンドを実行すると、以下のように表示されます。
root 5559 1 0 09:10:02 pts/1 0:18
/opt/tibco/administrator/<version>/bin/tibcoadmin --propfile /opt/
'kill' コマンドにフラグ -9 とプロセス ID ('ps -ef' コマンドの 2 番目の列) を付けて実行し、リストされたプロセスを強制終了できます。
# kill -9 5559
-9 フラグを使用すると、プロセスが実際に終了します。一般的に、すべての TIBCO プロセスが終了していることを確認するには、以下のコマンドを実行します。
ps -ef | grep tibco
ps -ef | grep hawk
および
ps -ef | grep rvd
その後、実行中のプロセスが見つからないことを確認します。
電子メール警告の設定
前述のとおり、Windchill ESI ビジネスロジックでのエラー発生時に電子メール警告メッセージを送信するように Windchill ESI を設定できます。
• Windchill PDMLink への ESIPostResult メッセージの送信
• Windchill PDMLink からの ESIResultResponse メッセージの待機
• ESIResultResponse メッセージの解析
この設定は、以下のグローバル変数を使用して行います。
• ESIMail/ToAddress
• ESIMail/FromAddress
• ESIMail/CCAddress
• ESIMail/BCCAddress
サーバーはグローバル変数 ESIMail/SMTPHostServer を使用して設定します。
グローバル変数の設定方法の詳細については、Oracle Applications 環境での Windchill ESI の管理 を参照してください。
Windchill ESI ビジネスロジックでは、EMS 関連の操作が TIBCO BusinessWorks のグローバル変数 ESIJMS/RetryCount で指定された回数だけ再試行されます。したがって、同じ問題に関する複数の電子メールメッセージを受信する場合があります。最後の試行に失敗した後、Windchill ESI ビジネスロジックによって関連 BusinessWorks プロセスがサスペンドされます。これにより、電子メール警告メッセージで説明されているエラーを調査し、根本的な問題を修正し、TIBCO Administrator を使用して BusinessWorks プロセスを再開または終了できます。このインタフェースの使用方法については、TIBCO Administrator User's Guide を参照してください。
具体的な問題の解決
以下のセクションでは、具体的な問題、考えられる原因、その解決策を示します。
TIBCO Administrator に、BW エンジンまたはアダプタプロセスのステータスが不明と表示される
この問題には、以下の 2 つの原因が考えられます。
• 特定のサービスの microhawk エージェントが、Administrator にステータスを送信するのに時間がかかっている。これは数分で解消されるはずです。
• hawk サービスがまだ設定変更を取得していない。hawk サービスを再起動すればこの問題は解消します。
JMS トランスポートによってアダプタが起動に失敗する
TIBCO Runtime Agent <version> および TIBCO Runtime Agent <version>.1 をインストール後に、Enterprise Message Service をトランスポートとして使用する TIBCO アダプタプロジェクトが TIBCO Designer から起動できず、その際に以下のエラーを出します。
Message "Code = AESDKC-0156,Category = JmsComm, Severity = errorRole, Description = could not open JMS shared library jms." displays
これは、Adapter SDK のライブラリに互換性がないことが原因の可能性があります。この問題を解決するには、以下の手順に従います。
• Windows の場合: <TIBCO_ホーム>/adapters/sdk/version/lib から、ファイル libeay32.dll、ssleay32.dll を削除します。
• UNIX の場合: <TIBCO_ホーム>/adapters/sdk/version/lib ディレクトリから、ライブラリ libssl、libcrypto openssl を削除します。
未解決のライブラリの依存性
TIBCO Runtime Agent <version> および TIBCO Runtime Agent <version>.1 をインストール後に、Enterprise Message Service をトランスポートとして使用する TIBCO アダプタプロジェクトが TIBCO Designer から起動できず、その際に以下のエラーを出します。
Message "Code = AESDKC-0156,Category = JmsComm, Severity = errorRole, Description = could not open JMS shared library jms." displays
これは、Adapter SDK のライブラリに互換性がないことが原因の可能性があります。この問題を解決するには、以下の手順に従います。
• Windows の場合: <TIBCO_ホーム>/adapters/sdk/version/lib から、ファイル libeay32.dll、ssleay32.dll を削除します。
• UNIX の場合: <TIBCO_ホーム>/adapters/sdk/version/lib ディレクトリから、ライブラリ libssl、libcrypto openssl を削除します。
TIBCO BusinessWorks Engine のログに "Coyote connector has not been started" エラーが表示される
これは、ESIOthers/WSHost および ESIOthers/WSPort 変数の値が不正であることが原因の可能性があります。この問題を解決するには、適切な値を設定します。
EMS サーバーを手動で起動した後に、EMS サーバーの設定が消滅する
これは、EMS サーバーを起動するコマンドが、バージョン 5.1.4 で変更されたことが原因の可能性があります。EMS のバージョン 4.x の場合、EMS を起動するコマンドは、"./tibemsd" でした。EMS v5.1.4 のコマンドは、"./tibemsd64 -config ../tibco/cfgmgmt/ems/data/tibemsd.conf" です。このコマンドは相対パスを使用するため、"<TIBCO_HOME>\ems\<バージョン>\bin" から起動する必要があります。
この問題を解決するには、次のコマンドで開始したプロセスを停止します。
"./tibemsd"
次に、EMS サーバーを正しいコマンドで起動します。
"./tibemsd64 -config ../tibco/cfgmgmt/ems/data/tibemsd.conf"
TIBCO Administrator の GUI を使用してアプリケーションを展開した際に、失敗のメッセージが表示される
これは、以前の展開または展開解除によって誤ってロックが取得され、その後解放されていないことが原因の可能性があります。
この問題を解決するには、コマンドプロンプトから AppManage コマンドを実行し、問題に応じた診断と解決を実行します。
• <TIBCO_ホーム>\tra\<バージョン>\bin を開きます。
• 次のコマンドを実行します。
例を示します。
AppManage -deploy -app ORA_ESI_Solution -user admin -pw admin
-domain I4590
詳細については、<TIBCO_ホーム>\tra\domain\<ドメイン名>\logs\ApplicationManagement.log ファイルを参照してください。
TIBCO BusinessWorks からエラーメッセージが返される
TIBCO BusinessWorks から以下のようなエラーメッセージが返されます。
-2003 Feb 19 13:27:12:294 GMT -5 Engine Error [] PE-Error
process initialization failed for
ProcessDefinitions/Services/WCResult_Service
--Initialization error in
[ProcessDefinitions/Services/WCResult_Service/JMSRepeatUntilTru
e_ESIPostResult_Result/JMSSender_ESIResult_PostResult]
--javax.naming.ServiceUnavailableException: Failed to query
JNDI: Failed to connect to the server at tcp://localhost:7222.
Root exception is javax.jms.JMSException: Failed to connect to
the server at tcp://localhost:7222
これは、EMS サーバー名が無効な場合に発生することがあります。
この問題を解決するには、処理エンジンの展開設定の ESIJMS/JNDIContextURL グローバル変数が、<TIBCO_ホーム>/ems/<バージョン>/tibco/cfgmgmt/ems/data にある、factories.conf ファイルの QueueConnectionFactory URL の値に一致していることを確認します。
ESIJMS/JNDIContextURL グローバル変数は以下のように設定します。
tibjmsnaming://<マシン名>:<ポート>
また、QueueConnectionFactory URL は以下のように設定します。
tcp://<マシン名>:<ポート>
このマシン名とポートの値が一致している必要があります。
たとえば、ESIJMS/JNDIContextURL が tibjmsnaming://mymachine.mycompany.com:7222 に設定されている場合は、QueueConnectionFactory URL が tcp://mymachine.mycompany.com:7222 に設定されている必要があります。
この変数の詳細については、Oracle Applications 環境での Windchill ESI の管理 の「プロセスエンジンのグローバル変数」を参照してください。
BusinessWorks から以下のようなエラーメッセージが返される
BusinessWorks から以下のようなエラーメッセージが返されます。
-2003 Feb 19 18:57:29:051 GMT -5 Engine Error [] PE-Error process
initialization failed for
ProcessDefinitions/DataProcessing/JMS_ESIEvent_TransactionRelease_
End_PD
--Initialization error in
[ProcessDefinitions/DataProcessing/JMS_ESIEvent_TransactionRelease
_End_PD/JMSReceiver_Event_ESIEvent]
--Could not establish connection or session with EMS provider.
--javax.naming.AuthenticationException: Not permitted: invalid name
or password. Root exception is javax.jms.JMSSecurityException:
invalid name or password
これは、JMS サーバーに対するユーザー名とパスワードが無効な場合に発生することがあります。
この問題を解決するには、処理エンジンの展開設定の ESIJMS/Username および ESIJMS/Password グローバル変数が、EMS サーバーでキューに対して指定されているユーザー名とパスワードの値に一致していることを確認します。
EMS サーバーに対して設定されているユーザー名とパスワードの値は、<TIBCO_ホーム>/ems/<バージョン>/tibco/cfgmgmt/ems/data ディレクトリにある users.conf ファイルに保存されています。この変数の詳細については、Oracle Applications 環境での Windchill ESI の管理 の「プロセスエンジンのグローバル変数」を参照してください。
EMS 管理ツールを使用して設定した場合、パスワードは明確に表示されません。設定したパスワードを思い出せない場合は、パスワードを再設定する必要があります。
UNIX で TIBCO コンポーネントを起動するときに、以下のエラーが返される
UNIX で TIBCO コンポーネントを起動するときに、以下のエラーが返されます。
/usr/lib/dld.sl: Call to mmap() failed - TEXT (UNIX path)
/usr/lib/dld.sl: Permission denied
たとえば、次のようになります。
/usr/lib/dld.sl: Call to mmap() failed - TEXT
/opt/tibco/tra/5.6/lib/libmaverick50.sl
/usr/lib/dld.sl: Permission denied
これは、ファイルに対するアクセス許可が適切に設定されていない場合に発生することがあります。
この問題を解決するには、TEXT の後ろに記載のファイルに対して、chmod 555 コマンドを実行します。たとえば、次のようになります。
# chmod 555 /opt/tibco/tra/<version>/lib/libmaverick50.sl
BusinessWorks と Windchill ESI のどちらかまたは両方が EMS に接続できない
これは、EMS サーバーが正しく設定されていない場合に発生する可能性があります。EMS サーバーの名前をローカルホストとして指定した場合、そのサーバーは実行されているマシンでのみ認識されます。ほかのマシンからは JMS サーバーに接続できません。ローカルホストに設定されているアプリケーションは、同じマシン上で実行されている EMS サーバーを見つけようとします。JMS サーバーが見つからない場合は、エラーになります。サーバー名にマシン名を指定すると、ほかのマシンから EMS サーバーに接続できます。
この問題を解決するには、<TIBCO_ホーム>/ems/<バージョン>/tibco/cfgmgmt/ems/data/factories.conf ファイル内の QueueConnectionFactory 値と、処理エンジンの展開設定のグローバル変数 ESIJMS/JNDIContextURL が適切に設定されていることを確認します。
• factories.conf ファイル内の QueueConnectionFactory は tcp://<マシン名>:7222 に設定します。ここで、マシン名は EMS サーバーが実行されているマシンです。
• BW エンジンのグローバル変数 ESIJMS/JNDIContextURL は tibjmsnaming://<EMS サーバーが実行されているマシン名>:7222 に設定します。
この EMS サーバーがどこにあるかは無関係です。Windchill PDMLink と同じマシンでも、TIBCO 処理エンジンと同じマシンでも、まったく異なるマシンでも構いません。上記の値が正しく設定されているかぎり (また、マシンが同じネットワーク上にあるかぎり)、Windchill ESI および EAI コンポーネントは適切な EMS サーバーに接続できます。
EMS サーバーに接続しているマシンおよびユーザー名を調べるには、TIBCO EMS 管理ツールで以下のコマンドを入力します。
>show connections
これにより、接続中のユーザーと接続元のマシンのリストが表示されます。
トランザクションが保留状態のままになります。
これは、EMS サーバーキューが、
JMS キューの設定と管理で説明されているとおりに購読されていない場合に発生する可能性があります。
一般的な根本原因としては、Windchill メソッドサーバーの起動時に JMS サーバーが実行されていないこと、Windchill アダプタの JMS プロパティの設定が間違っていること、または JMS サーバーの設定が間違っていることが考えられます。
Windchill ESI サービスが、結果メッセージ受け取りのための JMS キューの購読に成功すると、以下の情報が Windchill PDMLink メソッドサーバーのログに記録されます。
Thread-10: subscription to queue "com.ptc.windchill.esi.Result" successful
この情報がログにない場合は、Windchill がこのキューの購読に成功しなかったことを意味します。この場合は、すべての Windchill ESI トランザクションが保留状態のままになります。Windchill がキューの購読に成功すれば、トランザクションは処理されます。
通常、JMS サーバーが利用できないという理由で Windchill ESI によるキューの購読ができない場合は、Info*Engine は例外を受け取ります。Windchill ESI サービスは、この例外を Windchill アダプタトランザクションログに記録します。TIBCO EMS が JMS プロバイダである場合は、メッセージに以下のテキストが含まれます。
javax.ems.JMSException:Failed to connect to the server at tcp
検出の手段として、このテキストまたは類似のテキストを探すように監視ソフトウェアを設定できます。問題を解決するには、メソッドサーバーの前に EMS サーバーが起動していることを確認し、Windchill アダプタの JMS 設定と JMS サーバー設定に関する問題をすべて解決してください。
この問題を回避するには、以下の点を確認してください。
• EMS サーバーに接続しているユーザーが 1 人のみであること (TIBCO EMS 管理ツールの「Show connections」で確認できます)。
• ClientID (BW-ESIMaster_JMSConnection-queue-<アプリケーション名>-Process_Archive) を持つ ESISYS の接続数が、設定済みの ERP インスタンスと同数であること (TIBCO EMS 管理ツールの「Show connections」で確認できます)。
• すべての接続が、現在テスト中の製品群内の TIBCO または Windchill サーバーからのものであること。以前の製品群または無関係のマシンからの接続がないことを確認します (TIBCO EMS 管理ツールの「Show connections」で確認できます)。
• Windchill とプロセスアーカイブが同じ JMS キューに接続すること (TIBCO EMS 管理ツールの「Show queues」で確認できます)。
• com.ptc.windchill.esi.Result キューは、ただ 1 つの受信者を持つこと (TIBCO EMS 管理ツールの「Show queues」で確認できます)。
• どのキューの中にもメッセージがないこと (TIBCO EMS 管理ツールの「Show queues」で確認できます)。
• Windchill が DataResponse キューの購読に成功していること。JMS サーバーに接続して、DataResponse キューが作成されていること、および WCESI ユーザーが DataResponse キューでの送信権限を付与されたファイルを確認します。「Show quees」で、DataResponse キュー名の前に * が表示されている場合は、キューが一時的なものであり、作成する必要があることを示します。EAR が手動で展開された場合にこの問題が起きています。この問題を解決するには、JMS 管理ウィンドウで以下のコマンドを実行します。
◦ create queue <DataResponse>
◦ setprop queue <DataResponse> secure
◦ grant queue <DataResponse> <EAI ユーザー> receive
◦ grant queue <DataResponse> <WC ESI ユーザー> send
◦ setprop factory QueueConnectionFactory url=tcp://<JMSServer>:7222
◦ commit
• プロセスアーカイブが、Windchill が購読しているのと同じ DataResponse キューに接続していること。JMS 管理ウィンドウで、DataResponse キューがプロセスアーカイブによって購読されていることを確認します。手動で展開された場合は、このステップが見落とされていることがときどきあります。DataResponse キューが購読されているかどうかは、TIBCO Administrator--> Application Management --> アプリケーション名 --> Configuration-->展開名--> Advanced -->ESIJMS/DataResponseQueue の順に選択して確認します。
TIBCO BusinessWorks 処理エンジンがエラーメッセージをログ記録する
TIBCO BusinessWorks 処理エンジンログに以下のメッセージテキストが含まれます。
Job terminated: Please check following 1) FilesToRead_ORA.properties exists at %TIBCO_HOME%\\esi\\bin 2) %TIBCO_HOME%\esi\bin exists in tibco.env.STD_EXT_CP path in %TIBCO_HOME%\
bw\<version>\bin\bwengine.tra
これらの現象は通常、TIBCO BusinessWorks プロセスエンジンが起動時に Windchill ESI ビジネスロジックプロパティファイルを読み込めなかったことを示します。これらのプロパティファイルには、データマッピングで使用される相互参照やデフォルト値、ログ作成に使用されるテキストなどが含まれています。この問題には、以下のような複数の原因が考えられます。
1. プロパティファイルが <TIBCO_ホーム>\esi\bin ディレクトリに正しくインストールされていない。
2. FilesToRead_ORA.properties ファイルの Path 変数に無効な値が指定されている。Path 変数は、ファイルが格納されているディレクトリを指している必要があります。この値には、パス名の後にスラッシュを入力する必要があります。例: C:/tibco/esi/bin (Windows) または /opt/tibco/esi/bin (UNIX)
3. プロパティファイルのセキュリティ権限で TIBCO BusinessWorks プロセスエンジンの読み取りアクセス権限が許可されていない。
この問題を解決するには、以下の手順に従います。
1. FilesToRead_ORA.properties ファイルの Path 変数に無効な値が指定されている場合は、正しい値を入力して、ファイルを保存し、TIBCO BusinessWorks プロセスエンジンを再起動します。
2. プロパティファイルへのアクセス権限がない場合は、TIBCO BusinessWorks プロセスエンジンに必要なアクセス権限を付与します。展開時の Windchill ESI ビジネスロジックプロパティファイルの設定およびクラスパスの指定についての詳細は、Oracle Applications 環境での Windchill ESI の管理 を参照してください。
TIBCO BusinessWorks 処理エンジンが TIBCO EMS サーバーに接続できない
これは、EMS サーバーより先に BusinessWorks エンジンが起動された場合に発生することがあります。
この問題を回避するには、必ず BusinessWorks エンジンの前に EMS サーバーを起動します。この問題の検出に関する詳細については、トピック「JMS の問題」を参照してください。
Windows サーバーで、Adbagent が次のエラーとともに起動に失敗する: The ordinal 3823 could not be located in dynamic link library LIBEAY32.dll
この問題を解決するには、以下のコマンドを実行します。
1. MOVE /Y <TIBCO_ホーム>/adapter/sdk/<バージョン>/bin/libeay32.dll <TIBCO_ホーム>/adapter/sdk/5.5/bin/libeay32_bk.dll
2. MOVE /Y <TIBCO_ホーム>/adapter/sdk/<バージョン>/bin/ssleay32.dll <TIBCO_ホーム>/adapter/sdk/5.5/bin/ssleay32_bk.dll
3. COPY /Y <TIBCO_ホーム>/tibrv/<バージョン>/bin/libeay32.dll <TIBCO_ホーム>/adapter/sdk/<バージョン>/bin/libeay32.dll
4. COPY /Y <TIBCO_ホーム>/tibrv/<バージョン>/bin/ssleay32.dll <TIBCO_ホーム>/adapter/sdk/<バージョン>/bin/ssleay32.dll
Windchill ESI で配布ターゲットシステムにビジネスオブジェクトをパブリッシングできない
Windchill ESI で配布ターゲットシステムにビジネスオブジェクトをパブリッシングできません。ビジネスオブジェクト全体の障害や、入力が必要なフィールドに値が入力されていないなどのエラーが発生します。また、以下の例に示すように、TIBCO BusinessWorks プロセスエンジンログに Windchill ESI メッセージテキストが含まれていません。
2003 Aug 11 18:55:31:722 GMT -4 Engine ESI [] PE-ESI Job-15000
[ProcessDefinitions/Services/Logging_Service/WriteLog_ESIMaster
]: ,98,,3,1,0,40012,,,, 2003 Aug 11 18:55:32:563 GMT -4 Engine
ESI [] PE-ESI Job-15000
[ProcessDefinitions/Services/Logging_Service/WriteLog_ESIMaster
]: ,98,,3,1,0,40013,,,, 2003 Aug 11 18:55:32:864 GMT -4 Engine
ESI [] PE-ESI Job-15000
[ProcessDefinitions/Services/Logging_Service/WriteLog_ESIMaster
]: ,98,,3,1,0,40016,,,,
これらの現象は通常、TIBCO BusinessWorks プロセスエンジンが起動時に Windchill ESI ビジネスロジックプロパティファイルを読み込めなかったことを示します。これらのプロパティファイルには、データマッピングで使用される相互参照やデフォルト値、ログ作成に使用されるテキストなどが含まれています。この問題には、以下のような複数の原因が考えられます。
1. プロパティファイルが <TIBCO_ホーム>\esi\bin ディレクトリに正しくインストールされていない。
2. FilesToRead_ORA.properties ファイルの Path 変数に無効な値が指定されている。Path 変数は、ファイルが格納されているディレクトリを指している必要があります。この値には、パス名の後にスラッシュを入力する必要があります。例: C:/tibco/esi/ (Windows) または /opt/tibco/esi/ (UNIX)
3. プロパティファイルのセキュリティ権限で TIBCO BusinessWorks プロセスエンジンの読み取りアクセス権限が許可されていない。
この問題を回避するには、以下の点を確認します。
1. FilesToRead_ORA.properties ファイルの Path 変数に無効な値が指定されている場合は、正しい値を入力して、ファイルを保存し、TIBCO BusinessWorks プロセスエンジンを再起動します。
2. プロパティファイルへのアクセス権限がない場合は、TIBCO BusinessWorks プロセスエンジンに必要なアクセス権限を付与します。展開時の Windchill ESI ビジネスロジックプロパティファイルの設定およびクラスパスの指定についての詳細は、Oracle Applications 環境での Windchill ESI の管理 を参照してください。
TIBCO BusinessWorks に、以下のいずれかのエラーが表示されます。
TIBCO BusinessWorks に、以下のいずれかのエラーが表示されます。
• ORA-01461 can bind a LONG value only for insert into a LONG column
• [DataDirect][ODBC Oracle driver]String data, right truncated.Error in parameter
これは、Windchill PDMLink で、Oracle Applications で許容される長さを超えるフィールドをマッピングしようとした場合に発生することがあります。この問題が最も発生しやすいフィールドは、変更通知番号および Reference Designator (参照指定子) です。
Windchill PDMLink を修正するか、業務プロセスを設定して、修正通知番号または Reference Designator フィールドの長さが 10 文字を超えないようにする必要があります。システム間でのフィールド長の違いに対応する方法の詳細については、Oracle Applications 環境での Windchill ESI の管理 を参照してください。
Apache/Tomcat 404 Web ブラウザのエラーにより、TIBCO Administrator が失敗します。
これは、サポートされていないバージョンの Web ブラウザを使用している場合に発生することがあります。
この問題を解決するには、Web ブラウザを Microsoft Internet Explorer バージョン 6.0 SP1 以上にアップグレードします。
Oracle Applications 用の TIBCO アダプタのログに、エラーメッセージが記録される
Oracle Applications 用の TIBCO アダプタのログに、次のようなエラーメッセージが記録されます。
2004 Mar 11 14:43:20:226 GMT -5
BOMConfiguration.BOMConfiguration Error [Adapter] AEADB-700071
Duplicate agent found on DEV01MACHINE.mydomain.mycompany.com
(132.253.82.60)2004 Mar 11 14:43:20:226 GMT -5
MasterConfiguration.MasterConfiguration Info [Adapter] AEADB-
700095 Terminating agent
これは、複数の開発者が同じサブネット上で同じアダプタ展開設定名を使用している場合に発生することがあります。アダプタ公開設定を区別するには、ドメインだけでは不十分です。
この問題を回避するには、すべてのアダプタ展開設定名がサブネット上で一意になるようにします。
TIBCO Administrator でアダプタインスタンスまたはプロセスエンジンを起動しても、ステータスが「Starting Up」のまま変わらない
TIBCO Administrator でアダプタインスタンスまたは処理エンジンを起動しても、ステータスは「Starting Up」のままで、「Started」に変わりません。
これは、Oracle Applications 用の TIBCO アダプタと TIBCO Runtime Agent (TRA) の既知の問題です。Windows システムではデフォルトで TIBCO サービスが自動的に開始されますが、場合によって正しい順序で起動されず、Administrator Server と TRA の間で適切に通信できないことがあります。
ステータスが「Starting Up」と表示されていても実際には正常に起動したかどうかをコンポーネントのログファイルで確認してください。ほとんどの場合は、正常に起動しています。正常に起動していない場合は、以下の手順を実行します。
1. TIBCO Administrator アプリケーションと実行中のすべての TIBCO コンポーネントおよびサービスをシャットダウンします。
2. 以下の順序で TIBCO サービスを手動で開始します。
a. TIBCO Administrator <バージョン> (ドメイン名)
b. TIBCO HAWK Agent (ドメイン名)
3. TIBCO Administrator アプリケーションを再起動し、コンポーネントを起動します。
TIBCO BusinessWorks プロセスエンジンログに複数の「Activity timed out」エラーが表示されている
TIBCO BusinessWorks プロセスエンジンログに複数の「Activity timed out」エラーが表示されているにもかかわらず、Windchill ESI では Enterprise Systems のトランザクションログのグラフィカルユーザーインタフェースに正常な実行結果がレポートされます。
これは正常な動作です。Windchill ESI は、特定のタイムアウトイベントを以降の Oracle Applications 照会に合わせて自動的に補正するため、処理は正常に続行されます。
特に対処する必要はありません。
「配布ターゲット」表-がカスタム部品のプロパティページに表示されない
ターゲットがデータベースに作成された後に「配布ターゲット」表が wt.wadm.FADProduct などのカスタム部品のプロパティページに表示されません。
これは、<Windchill>\codebase\netmarkets\jsp\tgt\distributionList.jsp ファイルのデフォルトバージョンが、カスタム部品の配布ターゲット表を表示するように設定されていない場合に発生することがあります。
wt.wadm.FADProduct などのカスタム部品に対して「配布ターゲット」表を有効にします。
1. <Windchill>\codebase\netmarkets\jsp\tgt\distributionList.jsp というファイルを開きます。
2. if ステートメントを次のようにカスタム部品タイプを追加して修正します。
if (oid.indexOf("wt.doc") != -1 ||
oid.indexOf("wt.epm") != -1 ||
oid.indexOf("wt.part") != -1 ||
oid.indexOf("com.ptc.windchill.mpml.processplan.MPMProcessPlan") != -1 ||
oid.indexOf("com.ptc.windchill.mpml.resource.MPMProcessMaterial") != -1 ||
oid.indexOf("com.ptc.windchill.mpml.resource.MPMTooling") != -1 ||
oid.indexOf("com.ptc.windchill.mpml.resource.MPMSkill") != -1 ||
oid.indexOf("wt.wadm.FADProducts") != -1)
3. ファイルを保存し、サーブレットエンジンを再起動します。
ほかの設定上の問題
EAR を手動で展開する場合は、次の設定を確認します。
• DataResponse キュー名には、ORAPTCPROD のような ESIOMAdapter/Datasource の値を追加する必要があります。
• Java Max Heap Size および Java Thread Stack Size の設定: それぞれ 512 MB および 512 KB より大きくする必要があります。
以上でアプリケーションを展開する準備が整いました。ただし、サービスはまだ起動しないでください。
EMS: JMS 管理ウィンドウで次のコマンドを実行して、JMS を設定します。<DataResponse> と <EAI ユーザー> は、適切な値で置き換えてください。たとえば、com.ptc.windchill.esi.DataResponse.ORAPTCPROD と ESISYS などです。
• create queue <DataResponse>
• setprop queue <DataResponse> secure
• grant queue <DataResponse> <EAI ユーザー> receive
• grant queue <DataResponse> <WC ESI ユーザー> send
• setprop factory QueueConnectionFactory url=tcp://<JMSServer>:7222
• commit
ここでサービスを起動します。
サービス起動時のエラー
以下を確認します。
• <TIBCO_ホーム>/tra/domain/<ドメイン名>/application/logs
サービス起動に関するログが生成されておらず、プロセス ID が "-1" になっている場合は、<Tibco_ホーム>/tra/domain/<ドメイン名>/application/<アプリケーション名> フォルダ内の対応する *.sh または *.cmd ファイルを実行してみます。これは、サービスを開始する前に対処すべき、依存性の不具合がある可能性を示します。
Windchill PDMLink からプロモーションリクエストをリリースすると、複数の「製造部門への引き渡し」ワークフローが作成される
この状況は、Windchill ESI の「プロモーションリクエストをパブリッシング」プリファレンスの値が「いいえ」に設定されている場合に発生します。プロモーションリクエストのリリース時に、RTM ワークフローが 1 つだけ作成されるようにするには、このプリファレンスを「はい」に設定してください。
|
|
Windchill ESI の「プロモーションリクエストをパブリッシング」を「いいえ」に設定している場合は、プロモーションリクエストをリリースすると、プロモーションリクエストに含まれるプロモート可能アイテムの数だけ RTM ワークフローが作成されます。
|
