このセクションでは、メッセージ・フローを開発する際に生じる可能性のある共通問題のいくつかについて概説します。 このセクションには、以下の問題を処理するためのアドバイスが含まれます。
ご自分が UDN の作成者ではない場合、これらのファイルを削除することができます。 作成者またはベンダーは、 これらの UDN の 5.0 バージョンを Eclipse 機能およびプラグインの形式で提供する必要があります。 プラグインには、アイコン、翻訳、パレット定義、InfoPop、ヘルプなどが含まれているはずです。
詳しくは、エディターのプリファレンスおよびローカライズ設定を参照してください。
/flow2/schema1/SAMPLE.conxmi cannot be loaded. The following error was reported: schema1/SAMPLE.conxmi
渡された参照はコンテンツ・アシスタンスおよび ESQL の妥当性検査をサポートしているため、 これは効果的です。 メッセージ・タイプ・コンテンツ・プロパティー open、 または open defined は妥当性検査で使用されません。 また、前提事項はこのプロパティーが closed であることです。
ESQL エディター・プリファレンスにより、メッセージ参照のミスマッチを無視すること、 またはそれらを警告またはエラーとして報告することを選択します。 デフォルトでは、このタイプの問題は警告として報告されるため、 メッセージ・フローを依然としてデプロイすることができます。
このエラーによって、メッセージは failure ターミナルに送信されます。
MQInput ノードの failure ターミナルを out ターミナルではなく、連続するノードに誤って接続した可能性があります。 out ターミナルは、3 つのターミナルのうちのトップではなく、真ん中のターミナルです。未接続の out ターミナルに送信されたメッセージは廃棄されます。
MQInput ノードの failure ターミナルが、たとえば、MQOutput ノードと接続している場合には、これらのメッセージは現れません。
あるノードと他のノードの failure ターミナルとの接続は、すべてのエラー処理を扱えるようにメッセージ・フローを設計したことを示します。 failure ターミナルと MQOutput ノードを接続した場合、メッセージ・フローは発生するエラーを無視します。
詳しくは、トレースの使用を参照してください。
このアクションは、メッセージが送信されるすべてのノードから、そしてこれらのノードからのみユーザー・トレース・エントリーを生成します。
分散プラットフォームでは、mqsireadlog コマンドを使用してトレース・エントリーを検索したり、mqsiformatlog コマンドを使用してそれらをフォーマットすることができます。また、フォーマットされたレコードを表示して、メッセージ・フローによってメッセージのパスをチェックすることができます。これらのコマンドの詳細については、コマンドを参照してください。
z/OS の場合、COMPONENTPDS にあるジョブ BIPJLOG を編集および送信して、mqsireadlog および mqsiformatlog を実行してトレースを処理してください。ユーティリティー・コマンドの詳細については、z/OS ユーティリティー・ジョブを参照してください。
メッセージをメッセージ・フローに再度送信してください。 Debug レベルのトレースによって、メッセージがその経路を取る理由についてさらに詳細な情報を入手できます。また、これによって、メッセージ・フローが実行するアクションの理由を判別することができます。
問題を解決した後、トレースを必ずオフにしてください。そうしない場合、パフォーマンスに悪影響を与える場合があります。
一般に:
メッセージ・フローが、障害ではないものの出力キュー (または他の持続的なストア) で終わらないパスを持っている場合、メッセージ・フローは失敗しておらず、メッセージはバックアウトされません。また、代わりの宛先 (たとえば、catch ターミナル、送達不能キュー、またはキューのバックアウト・キュー) にも書き込まれません。
SQL0954C Not enough storage is available in the application heap to process the statement.z/OS では、HY014 の SQLSTATE は SQL コード -99999 で戻される可能性があります。 これは、DataFlowEngine プロセスが、 準備済み SQL ステートメントが処理する DB2 z/OS 処理限界の 254 ハンドルに達したことを表します。
パフォーマンス上の理由で、ステートメントが準備された後、 ステートメントおよびハンドルはキャッシュ内に保管され、 SQLPrepare 関数への呼び出し回数を削減します。 ステートメントがすでにキャッシュ内にある場合、ステートメント・ハンドルが戻され、 新規の結合パラメーターで再実行できるようにされます。
ステートメント・ストリングを使用して、キャッシュ検索を実行します。 各メッセージごとに多少異なる、ハードコーディングされた SQL ストリングを使用すると、 ステートメントはキャッシュ内に見つからず、SQLPrepare 関数は常に実行されます (また、 新規の ODBC カーソルがオープンされます)。 PASSTHRU ステートメントを使用する場合、パラメーターを実行時に結合したまま、 同じ準備済み SQL ステートメントを処理するメッセージごとに使用できるように、 パラメーター・マーカーを使用してください。 この方法は、データベース・リソースに関してより効率的であり、 繰り返し実行されるステートメントに関してもより高速になります。
しかし、パラメーター・マーカーを常に使用できるわけではありません。 また、実行時に SQLステートメント・ストリングを動的に作成したいと思うかもしれません。 これによって、多数の固有 SQL ステートメントがキャッシュされる可能性があります。 これらのステートメントは一般的に大きくないため、キャッシュ自体はそれほど大きくなりません。 しかし、少ないメモリー割り振りが多数あると、メモリーのフラグメント化が生じる可能性があります。
任意の与えられたメッセージ・フローに対して、 標準的なノードでは約 2 KB のスレッド・スタック・スペースが必要です。 デフォルトでは、UNIX プラットフォームの単一メッセージ・フロー内では約 500 ノード、Windows プラットフォームでは 1000 ノードの限度があります。 この限度は、各ノード内で実行されている処理のタイプによって、 大きかったり小さかったりする可能性があります。
この環境変数設定はブローカーに適用されるため、 MQSI_THREAD_STACK_SIZE は、 DataFlowEngine プロセス内で作成される各スレッドごとに使用されます。 実行グループに割り当てられる多数のメッセージ・フローがあり、 大きな MQSI_THREAD_STACK_SIZE を設定すると、 DataFlowEngine プロセスはスタック用の大量のストレージを必要とします。
500 ノードのメッセージ・フローというのは到達しそうにないほど大きな限度と思われますが、メッセージ・フロー内にループを置くか、 または適切な出力ターミナルをフロー内で先行するノードの入力ターミナルに接続すると、 このような多数のノードを実行することになります。 メッセージ内で繰り返しレコードを処理する場合に、これを選択することもできます。ループバックは、残りのレコードを調べる filter ノードや、 処理されたレコード数をカウントする compute ノードによって制御されます。 フローは、見た目には少数のノードで構成されています。しかし、ループの各反復ごとに、 ループ内のノードは順次配列内の新規ノードとして実行されます。このため、ループの反復数で乗算されたループ内のノード数は限度の 500 ノードに達する可能性があります。
このために、ハードワイヤード・ループを使用して MQSI_THREAD_STACK_SIZEを大きくすることはしないでください。 たとえば、メッセージ・フローをループして繰り返しレコードを処理する必要がある場合、 ESQL PROPAGATE ステートメントを使用します。 これによって、compute ノード内でループを実行することができ、 compute ノード内の伝搬呼び出しが実行される地点に戻る前に、 メッセージ・フローの残りを駆動できるようになります。 さらに、フローの残りに渡す必要があるのは、 一度に 1 つの繰り返しレコードのみです。 処理が伝搬している Compute ノードに戻ると、以前のセットの出力ツリー用のストレージは解放されます。 スタック使用の観点から、メッセージ・フローは PROPAGATE 呼び出しが発行された地点に 巻き戻されるため、スタックの蓄積はありません。 スタック上では、現行ループの反復は一度に 1 つだけです。
Video_Test#FCMComposite_1_1 ComIbmMQInputNode , Video_Test.VIDEO_XML_IN
JITC_COMPILEOPT=SKIP{org/eclipse/ui/views/tasklist/TaskListContentProvider}{resourceChanged}
WebSphere MQ Everyplace メッセージ内に含まれているデータを解析または変更する必要がある場合には、MQeMbMsgObject を使用してください。これらは、標準の WebSphere MQ メッセージとの並列性を備えています。相関 ID といったフィールドを設定できます。また、WebSphere Business Integration Message Broker パーサーを使用して解析可能なフィールドがあります。
注意 |
商標 |
ダウンロード |
ライブラリー |
技術サポート |
フィードバック
![]() ![]() |
au16530_ |