その他の問題の特定
このセクションでは、前述のカテゴリに当てはまらない分野に関する一般的な問題とその原因について説明します。一般的な問題のリストは次のとおりです。これらのリンクをクリックすると、発生した問題に関する情報に直接アクセスできます。問題が以下のリストにない場合、または指示どおりに対策を講じても問題を完全に解決できない場合は、システム管理者に連絡してください。
プロセスアーカイブを開始するときに、Tibco BusinessWorks Designer で「Cannot create Transport」および「Process Definition Load」のエラーが発生する
BusinessWorks を設定するには、以下の手順に従います。
1. 次のファイルをバックアップします。
<<TibcoHome>>/designer/<<version>>/bin/designer.tra
2. テキストエディタで次のファイルを開きます。
<<TibcoHome>>/designer/<<version>>/bin/designer.tra
3. 次の文字列をサーチします。
tibco.env.CUSTOM_CP_EXT
4. 見つかった文字列を次の文字列で置換します。
tibco.env.CUSTOM_CP_EXT %RV_HOME%/lib/tibrvj.jar:%RV_HOME%/lib:%RV_HOME%/lib/64:
 |
パスにその他のフォルダが含まれている場合もあります。これらのエントリは、文字列を置換する際に変更しないようにしてください。
|
5. 次の文字列をサーチします。
tibco.env.CUSTOM_LIB_PATH
6. 見つかった文字列を次の文字列で置換します。
tibco.env.CUSTOM_LIB_PATH %RV_HOME%/lib:%RV_HOME%/lib/64:
|
|
パスにその他のフォルダが含まれている場合もあります。これらのエントリは、文字列を置換する際に変更しないようにしてください。
|
7. designer.tra を保存して閉じます。
8. TIBCO Designer を開いて、プロセスアーカイブを開始します。
Windchill Enterprise Systems のトランザクションログに以下の SAP メッセージのいずれかが表示される
「No unit of measure found in ISO code __ in field BASE_UOM_ISO」
または
「The field MARA-MEINS/BAPI_MARA-BASE_UOM(_ISO) is defined as a required field; it does not contain an entry」
以下の原因が考えられます。
• 相互参照ルックアップファイルに正しい値がない。
• Windchill のデフォルトの測定単位がないか、無効である。
• 必要な ISO コードでなく SAP 固有の測定単位コードが使用された。
Windchill ESI がアダプタタイムアウトメッセージを返す
• アダプタの設定が間違っている。
• ESITarget が無効である。
• アダプタのインスタンスが動作していない。
• SAP アプリケーションサーバーが利用できない状態にある。
• アダプタと SAP 間で十分な接続を使用できない。
• 入ってくるメッセージの量がアダプタの処理能力を超えている。
|
|
この問題を解決するには、Windchill ESI 管理者の支援が必要になる場合があります。
|
Windchill PDMLink が EMS キューを購読できない
以下の原因が考えられます。
• Windchill ESI サービスが正常にインストールされていない。
• EMS サーバーが機能していない。
• Windchill メソッドサーバーと EMS サーバーの間でネットワークエラーが発生した。
• Windchill Adapter EMS の設定が間違っている。
• Windchill ESI のプリファレンスが、1 つ以上の間違った EMS キュー名、EMS キューユーザー、または EMS キューパスワードを指定している。
|
|
この問題を解決するには、Windchill ESI 管理者の支援が必要になる場合があります。
|
PostResult () メソッドでエラーが表示される
以下の原因が考えられます。
• パブリッシングするデータに問題がある。
• 1 つ以上の必要な TIBCO コンポーネントがオフラインになっている。
• Windchill ESI サービスが、JMS キューの読み取りや書き込みをできない (#ESISAPTroubleOther/WCPDMLinkCannotSubscribeEMSQueueと原因は同じです)。
• Windchill PDMLink においてデータベースエラーが発生した。
• Windchill ESI ミドルウェアのプログラミングエラーによって、PostResult RPC リクエストが正しくフォーマットされなかった。
|
|
この問題を解決するには、Windchill ESI 管理者の支援が必要になる場合があります。
|
パブリッシングしたオブジェクトに配布ターゲットが割り当てられていない
以下の原因が考えられます。
• 配布ターゲットを割り当てる前にオブジェクトをパブリッシングしようとした。
• すべての配布ターゲット割当を除去した後にオブジェクトをパブリッシングしようとした。
前回のパブリッシング以降、変更されていない
以下の原因が考えられます。
• Windchill ESI の「作業版数をチェック」プリファレンスが「いいえ」に設定されており、パブリッシングするオブジェクトの作業版数だけが変更されている。
• 前回のパブリッシング以降、データが変更されなかった。
• オブジェクトに関連付けられているすべての配布ターゲットに対してオブジェクトがすでに正常にパブリッシングされている。
• 新しい配布ターゲット割当をオブジェクトに追加した後、すでにパブリッシングされているそのオブジェクトをパブリッシングしようとした。
TIBCO BusinessWorks EMS や Windchill、またはいずれのシステムにも接続できない
以下の原因が考えられます。
• EMS サーバーが正しく設定されていないことが原因と考えられます。EMS サーバーの名前を「localhost」と指定すると、そのサーバーは、動作しているマシン上でのみ認識されます。ほかのマシンからは JMS サーバーに接続できません。EMS サーバー「localhost」に接続するように設定されているアプリケーションは、アプリケーションが配置されている同じマシン上で動作している EMS サーバーを検出しようとし、サーバーを検出できないとエラーを返します。サーバー名にマシン名を指定すると、ほかのマシンから EMS サーバーに接続できます。
この問題を解決するには、以下の手順に従います。
• factories.conf ファイルの QueueConnectionFactory に関連付けられた url プロパティを tcp://<マシン名>:7222 に設定します。
ここで <マシン名> は EMS サーバーが動作するマシンです。
• ESI をどこで実行しているかに応じて、BW Engine、TIBCO Designer、または TIBCO Administrator で、グローバル変数 ESIJMS\JNDIContextURL を = tibjmsnaming://<EMS サーバーが実行されているマシン名>::7222 に設定します。
|
|
この EMS サーバーがどこにあるかは無関係です。Windchill と同じマシンでも、ミドルウェアエンジンと同じマシンでも、まったく異なるマシンでも構いません。上記の値が正しく設定されている限り (また、マシンが同じネットワーク上にある限り)、Windchill PDMLink およびミドルウェアは適切な EMS サーバーに接続できます。
|
どのマシンおよびユーザーが EMS サーバーに接続しているかを調べるには、EMS 管理ツールで以下のコマンドを指定します。
>show connections
どのマシンからどのユーザーが接続しているかが表示されます。詳細については、TIBCO Enterprise for EMS のドキュメンテーションを参照してください。
TIBCO アダプタが ESI トランザクションでタイムアウトになる
• ERP への接続が切断された後に TIBCO アダプタがタイムアウトする場合は、接続のステータスを確認し、アダプタを再起動します。これはアダプタログを参照すると確認できます。
• 「TIBCO Administrator GUI」 > 「Application Management」 > 「<アプリケーション名>」 > 「Configuration」 > 「Process Archive.par」 > 「TIBCO BusinessWorks Process Configurations」 > 「ProcessDefinitions/DataProcessing/JMS_ESIEvent_TransactionRelease_End_PD」で bwengine の最大ジョブとフロー制限の設定を確認します。これはユーザー環境で実施した負荷テストに基づいてゼロ以外の有限の値にする必要があります。
• ERP との接続が切断されていないのに TIBCO アダプタがタイムアウトを起こすようになった場合は、「TIBCO Administrator GUI」 > 「Application Management」 > 「<アプリケーション名>」 > 「Configuration」 > 「ESISAPAdapterConfiguration.aar」 > 「Advanced」 > 「adr3.maxconnections value」を確認します。これは bwengine の最大ジョブの設定と同じ値にする必要があります。
ESI レスポンスメタ情報ファイルに関連したエラーメッセージが表示される
「新規配布ターゲット」または「配布ターゲットを編集」ウィンドウで「完了」をクリックすると、ESI レスポンスメタ情報ファイルに関するエラーメッセージが表示されます。
この原因は、配布ターゲットの「ESI レスポンスメタ情報のファイルパス」属性に指定した値に以下のような問題があるためです。
• ファイルのパスが存在していない。
• ファイルの内容が土台となるスキーマに従っていない (標準では、スキーマは ESIResponseMetaInformation.xsd ファイルに定義されています)。
• ファイルの内容が無効である。たとえば、ファイル内の MapInformation 要素が存在しない Map 要素を参照している。ファイルの内容が無効であると見なされる理由はほかにもいろいろあります。
• ファイル内の少なくとも 1 つの Map 要素に関連付けられた ID 属性がすでにその Map 要素と同一でない別の Map 要素で使用されている。これは、たとえば (作成中または編集中の) 配布ターゲットが特定の ESI レスポンスメタ情報ファイルを指すようにして、グローバル属性を追加できるようにその部品の Map 要素を修正したのに、ID 属性が ESIPart という値のままであり、別の配布ターゲットがデフォルトで提供されている ESI レスポンスメタ情報ファイルをすでに指している場合に発生します。
JMS トランスポートによってアダプタが起動に失敗する
TIBCO Runtime Agent 5.6 および TIBCO Runtime Agent 5.6.1 のインストール後、トランスポートとして Enterprise Message Service を使用した TIBCO アダプタプロジェクトが TIBCO Designer から起動しない。以下のエラーメッセージが表示されます。
Code = AESDKC-0156,Category = JmsComm, Severity = errorRole, Description = could not open JMS shared library jms.
この問題を解決するには、以下の手順に従います。
• Windows の場合: バックアップを作成した後、libeay32.dll と ssleay32.dll を <TIBCO_HOME>/adapters/sdk/version/<lib> から削除します。
• UNIX の場合: openssl ライブラリ libssl と libcrypto を TIBCO_HOME/adapters/sdk/version/lib ディレクトリから削除します。
アダプタが起動に失敗し、TIBCO Administrator でステータスが「起動中」のままになる
アダプタプロセスのプロセス ID が "-1" になっている場合は、アダプタ起動時にエラーが発生しています。このエラーは一般にライブラリに依存します。
既知のエラーは以下のとおりです。
• Error while loading shared libraries: librfccm.so: wrong ELF class: ELFCLASS64
このエラーは 64 ビット版 SAPJCo ライブラリを使用している場合に発生することがあります。Windows X64 や Linux ia64 のような特定のプラットフォームでは、SAP アダプタは 32 ビットアプリケーションです。32 ビット版ライブラリを使用すれば問題は解決します。
• Error while loading shared libraries: librfccm.so: wrong ELF class: ELFCLASS32
このエラーは 32 ビット版 SAPJCo ライブラリを使用している場合に発生することがあります。HPUX IA64 や Solaris SPARC のような特定のプラットフォームでは、SAP アダプタは 64 ビットアプリケーションです。64 ビット版ライブラリを使用すれば問題は解決します。
以下のライブラリでも同様の問題が発生しています。
• libresolv.so.2 sunw_2.2.2
• libstdc++-libc6.2-2.so.3
• libstdc++.so.5
以下を確認します。
• 正しい互換性パッケージがインストールされていること。これによって依存関係が解決されます。
• Java の環境変数が設定されている場合は、互換性のあるバージョンであることを確認してください。TIBCO アプリケーションは JRE 1.5 および 1.6 もインストールします。すでに設定した Java 設定を削除して、TIBCO アプリケーションに適切な Java 変数を設定させることができます。
• HPUX および Solaris マシンにおいては、SAP アダプタは 64 ビットアプリケーションのため、Java 変数がすでに設定されている場合はクラスパスに 64 ビット版 Java ライブラリが含まれていることを確認してください。
Coyote コネクタが起動されない
ESIOthers/WSHost 変数と ESIOthers/WSPort 変数を確認します。
エンタープライズトランザクションログでパブリッシングの状態が "保留中" のままである
以下の原因が考えられます。
• JMS サーバー tcp://<JMSServer>:7222 への接続に失敗した。
これは JMSServer が到達不可能である場合、または、ホスト名が正しい IP アドレスに解決されない場合に発生します。tibjms.jar ファイルのバージョンが正しくない場合にもこの問題は発生します。この問題を解決するには、Windchill サーバーの tibjms.jar ファイルで、TIBCO サーバー上の正しいバージョンの JMS を使用していることを確認します。
1. Windchill サーバーからコマンドウィンドウを開きます。
2. Windchill メソッドサーバーログに記録された文字列をそのまま正確に使用して、ping <JMSServer> を実行します。
3. ping リクエストが失敗する場合は、ping <JMSServer_IP> を実行します。
4. ping リクエストが成功した場合は、表示された IP アドレスを使用します。または、次の項目を %Windir%\System32\drivers\etc\hosts ファイルに追加します: <JMSServer_IP> <JMSServer>
5. ping リクエストが失敗し続ける場合は、ネットワーク管理者に連絡してください。
• DataResponse キューへの接続に失敗した。
これが問題の原因であることを確認するには、JMS サーバーに接続して、DataResponse キューが作成されており、WCESI ユーザーが DataResponse キューに対する送信権限を持つことを確認します。DataResponse キュー名の前にアスタリスク (*) が表示されている場合は、一時キューであるため、キューを作成する必要があります。この問題は、EAR を手動で展開した場合に発生することがあります。この問題を解決するには、JMS 管理ウィンドウで以下のコマンドを実行します。
1. Create queue <DataResponse>
2. Setprop queue <DataResponse> secure
3. Grant queue <DataResponse> <EAIUser> receive
4. Grant queue <DataResponse> <WCESIUser> send
5. Setprop factory QueueConnectionFactory url=tcp://<JMSServer>:7222
6. Commit
• プロセスアーカイブが同じ DataResponse キューに接続されていない。
JMS 管理ウィンドウを開いて、DataResponse キューがプロセスアーカイブによって購読されていることを確認します。手動展開時には、しばしばこの手順が省略されてエラーの要因となります。DataResponse キューが購読されていない場合、「TIBCO Administrator」 > 「Application Management」 > 「Application Name」 > 「Configuration」 > 「Deployment Name」 > 「Advanced」 > 「ESIJMS/DataResponseQueue」の順に移動して、DataResponseQueue の値を確認します。
• 1 人の WCESI ユーザーだけが EMS サーバーに接続されている。TIBCO EMS 管理ツールの「Show connections」で確認します。
• ClientID (BW-ESIMaster_JMSConnection-queue-<アプリケーション名>-Process_Archive) を持つ ESISYS 接続の数は、設定した ERP インスタンスの数と等しいはずです。そうでない場合、プロセスアーカイブを実行する追加のインスタンスが ESI 応答メッセージを消費している可能性があります。TIBCO EMS 管理ツールの「Show connections」で ESISYS 接続の数を確認します。
• すべての接続が現在のテストスイートの TIBCO または Windchill サーバーからであり、以前のテストスイートまたは不明のマシンからの接続がないことを確認します。そうでない場合、プロセスアーカイブを実行する追加のインスタンスが ESI 応答メッセージを消費している可能性があります。TIBCO EMS 管理ツールの「Show connections」で ESISYS 接続の数を確認します。TIBCO EMS 管理ツールの「Show connections」で確認します。
• Windchill とプロセスアーカイブが同じ JMS キューに接続されている。TIBCO EMS 管理ツールの「Show queues」で確認します。
• com.ptc.windchill.esi.Result キューの受信者が 1 つしかない。TIBCO EMS 管理ツールの「Show queues」で確認します。
• キューにメッセージが残っている。TIBCO EMS 管理ツールの「Show queues」で確認します。
• 配布ターゲットの作成時に Client 属性と System ID 属性に指定した値が、所定の SAP インスタンスで MICU の実行時に指定した該当する値と一致していません。この場合、Windchill ESI サービスが ESI 応答メッセージを存在しない EMS キューに格納しようとするため、ESI トランザクションの状態が保留中のままになります。
JAX-M パーサーまたは XML パーサーが ResultResponse XML スキーマを使用したメッセージの構文解析に失敗する
次のエラーメッセージが表示されます。
2,,2,2,1,20021,Windchill sent an invalid ResultResponse message. JAX-M Parser or XML Parser failed to parse message using ResultResponse XML schema. See Windchill logs for details,,,,,Job-1 Error in [ProcessDefinitions/Services/WCResult_Service.process/RepeatUntilTrue_SendAllResults/RepeatOnError_Result_ResultResponse/Java_ParseESIResultResponse]While executing [invoke] encountered [com.ptc.windchill.esi.ext.ESISoapException]: [Unable to create envelope from given source: at com.ptc.windchill.esi.ext.SoapResponseFinder.getResult(SoapResponseFinder.java:216)]
この問題は、JRE 6 に付属する Java ライブラリで発生します。JRE 1.5 および JRE 1.6.0.18 では発生していません。
「入力データが無効です」というメッセージがエンタープライズトランザクションログに表示される
このエラーは、"Invoke an adapter request response service" アクティビティにおいて、スキーマ検証での失敗があったことを示します。processArchive ログには、詳細な説明とスタックトレースが記録されます。ログには、スキーマ不一致の理由が的確に示されます。例:
validation error: data "xs:string('Hinge, Right Hand, Male, Removable, 0.187 Dia Pin, SS')" length must be at most xs:int('40') CHARACTERs ({com.tibco.xml.validation}SIMPLE_E_LENGTH_TOO_LONG) at /aeRequestInputType[1]/{http://www.tibco.com/xmlns/ae2xsd/2002/05/ae/700/basic/functionModules}__caret_request_caret_BAPI__MATERIAL__SAVEREPLICA_caret_BAPI__MATERIAL__SAVEREPLICA[1]/MATERIALDESCRIPTION[1]/item[2]/MATL__DESC[1]com.tibco.xml.validation.exception.k: data "xs:string('Hinge, Right Hand, Male, Removable, 0.187 Dia Pin, SS')" length must be at most xs:int('40') CHARACTERs
エンタープライズトランザクションログでトランザクションの状態が "保留中" のままである
以下の原因が考えられます。
• ESI サービスが EMS サーバーの DataResponse キューに ESIResponse を書き込めない。これを確認するには、「Info*Engine 管理」 > 「プロパティエディタ」> 「コア JMS プロパティ」に移動して、JMS BASE URI が正しいことを確認します。次にメソッドサーバーログを参照して、DataResponse キューの購読に成功していることを確認します。
• JMS サーバー (tcp://<JMSServer>:7222) への接続に失敗した。この問題を解決するには、Windchill サーバーの tibjms.jar ファイルが、TIBCO サーバー上の正しいバージョンの JMS から取得されていることを確認します。
• JMSServer が到達不可能である。または、ホスト名が IP アドレスに解決されない。これは tibjms.jar ファイルのバージョンが正しくないことが原因です。これを確認するには、以下の手順に従います。
a. Windchill サーバーからコマンドウィンドウを開きます。
b. Windchill メソッドサーバーログに記録された文字列をそのまま正確に使用して、ping <JMSServer> を実行します。
c. ping リクエストが失敗する場合は、ping <JMSServer_IP> を実行します。
d. ping リクエストが成功した場合は、表示された IP アドレスを使用します。または、次の項目を %Windir%\System32\drivers\etc\hosts ファイルに追加します: <JMSServer_IP> <JMSServer>
e. ping リクエストが失敗し続ける場合は、ネットワーク管理者に連絡してください。
• DataResponse キューへの接続に失敗した。
これが問題の原因であることを確認するには、JMS サーバーに接続して、DataResponse キューが作成されており、WCESI ユーザーが DataResponse キューに対する送信権限を持つことを確認します。DataResponse キュー名の前にアスタリスク (*) が表示されている場合は、一時キューであるため、キューを作成する必要があります。この問題は、EAR を手動で展開した場合に発生することがあります。この問題を解決するには、JMS 管理ウィンドウで以下のコマンドを実行します。
1. Create queue <DataResponse>
2. Setprop queue <DataResponse> secure
3. Grant queue <DataResponse> <EAIUser> receive
4. Grant queue <DataResponse> <WCESIUser> send
5. Setprop factory QueueConnectionFactory url=tcp://<JMSServer>:7222
6. Commit
• プロセスアーカイブが同じ DataResponse キューに接続されていない。
JMS 管理ウィンドウを開いて、DataResponse キューがプロセスアーカイブによって購読されていることを確認します。手動展開時には、しばしばこの手順が省略されてエラーの要因となります。DataResponse キューが購読されているかどうかは、「TIBCO Administrator」 > 「Application Management」 > 「Application Name」 > 「Configuration」 > 「Deployment Name」 > 「Advanced」 > 「ESIJMS/DataResponseQueue」の順に移動して、DataResponseQueue を確認します。
EMS サーバーを手動で起動した後に、EMS サーバーの設定が消滅する
EMS バージョン 5.1.4 で EMS サーバーの起動コマンドが変更されました。EMS バージョン 4.x では起動コマンドは「./tibemsd」でした。EMS バージョン 5.1.4 では、「/tibemsd64 -config ../tibco/cfgmgmt/ems/data/tibemsd.conf」です。このコマンドは相対パスを使用するため、<TIBCO_HOME>\ems\5.1\bin から起動する必要があります。
この問題を解決するには、「./tibemsd」というコマンドで開始したプロセスを停止して、次の正しいコマンドを使用して EMS サーバーを起動します。
"./tibemsd64 -config ../tibco/cfgmgmt/ems/data/tibemsd.conf
SAP インスタンスの TIBCO アダプタが動作を停止して、エラーステータスが表示される
この問題はアダプタのスタックオーバーフローエラーによって発生します。TIBCO のサポート部門はこれを既知の問題として認識しており、解決策はパラメータ adr3.stacksize の値を適切に増やすことです。サポートによるテストでは 524288 (512 KB) で成功しています。
この問題は現在、HPUX v3 マシンだけで発生します。
adr3.stacksize の値を増やすには、「TIBCO Administrator GUI」 > 「Application Management」 > 「<アプリケーション名>」 > 「Configuration」 > 「ESISAPAdapterConfiguration.aar」 > 「Advanced」を使用します。
プロモーションリクエストによってビジネスオブジェクトのセットをプロモートすると、それらの各オブジェクトについて RTM ワークフローが作成される。
これは、「プロモーションリクエストをパブリッシング」プリファレンスの値が「いいえ」の場合に起きます。プロモーションリクエスト内のオブジェクトが 1 つの RTM ワークフローでパブリッシングされるようにするには、このプリファレンスを「はい」に設定します。
1 つ以上のビジネスオブジェクトをプロモートしたときに生成される ESI 応答ファイルに ID 以外のプロモーションリクエストの情報が含まれない。
これは正常な動作です。プロモーションリクエストのほかの属性を別の XML 要素として ESI 応答とともに送信するには、ESI 応答メタ情報ファイルを適切に設定します。