WebSphere Message Broker バージョン 8.0.0.5 オペレーティング・システム: AIX、HP-Itanium、Linux、Solaris、Windows、z/OS

製品の最新バージョンについては、IBM Integration Bus バージョン 9.0 をご覧ください。

SAP アダプターのスケーラビリティーとパフォーマンス

SAP からの同期呼び出しの処理時に遅延がないように、アダプター上のリスナーの数とメッセージ・フローの追加インスタンスの数を構成して、パフォーマンスを改善できます。

SAP インバウンド・アダプターは、SAP から同期呼び出しを受け取ります。 このアダプターは、「リスナーの数」というプロパティーを持っています。このプロパティーは、SAP プログラム ID を listen する特定の数のスレッドを持つようにアダプターを構成することにより、同時呼び出しの最大数を制御します。 リスナーはこれらの呼び出しの入力パラメーターを処理のために SAPInput ノードに送信し、出力パラメーターは SAPReply ノードに送信されます。

リスナーは、SAP から呼び出しを受け取ると、SAPInput ノードを含むメッセージ・フロー・インスタンスが使用可能になるまで処理をブロックします。 メッセージ・フロー・インスタンスが使用可能になり、インポート・パラメーターの処理を開始すると、エクスポート・パラメーターを含むメッセージが SAPReply ノードに伝搬されるまで、リスナーは処理を再度ブロックします。

SAPInput ノードがメッセージを送信してから SAPReply ノードが応答メッセージを受け取るまでの間の経過時間の長さは、メッセージ・フロー上の追加のインスタンス・プロパティーの影響を受ける可能性があります。 処理が遅延しないようにするには、リスナーの最大数と、SAPInput および SAPReply ノードを含むメッセージ・フローの追加インスタンスの数を調整してください。 メッセージ・フロー・レベルまたは SAPInput ノード自体で、追加のインスタンス数を構成できます。

制約事項

リスナーの数は、SAP の構成によって制限されます。 SAP トランザクション SMQS では、RFC 宛先ごとに最大接続数プロパティーを表示したり変更したりできます。 構成するリスナーの数が接続の最大数より多い場合、無効になります。

メッセージ・フローのインスタンスを追加するごとに、フロー内のノードのタイプに応じて、フロー内の各ノードによって余分のリソースが使用されます。

シナリオ

以下の図は、基本的なシナリオを示しています。リスナーの数とメッセージ・フローの追加のインスタンス数は同じです。この場合、シナリオは 3 つのリスナーと 3 つのメッセージ・フロー・インスタンスで構成されています。
この図は、以下のステップを説明します。
  1. SAP は 3 つの呼び出しを行い、これをそれぞれ 1 つのリスナーが受け取ります。
  2. 各リスナーは、メッセージ・フローの 3 つのインスタンスのうち 1 つにある SAPInput ノードに、各呼び出しの入力パラメーターを送信します。
  3. 各メッセージ・フロー・インスタンスは、そのメッセージをターゲット・アプリケーションに送信します。
  4. ターゲット・アプリケーションは、メッセージを処理し、応答をメッセージ・フロー・インスタンスに返します。
  5. 各メッセージ・フロー・インスタンス内の SAPReply ノードは、元の呼び出しを受信したリスナーに応答メッセージを送信します。
  6. 各リスナーは、応答メッセージを該当する SAP プログラムに返します。
上記の例に図示されているように、SAPReply ノードは、SAPInput ノードと同一のメッセージ・フロー内でも構いません。 しかし、下記のシナリオでは、SAPReply ノードは SAPInput ノードとは違うフロー内にあります。 SAPReply ノードは、SAPInput ノードと同一の実行グループ中にデプロイしなければなりません。
  1. SAP は 3 つの呼び出しを行い、これをそれぞれ異なるリスナーが受け取ります。
  2. 各リスナーは、SAPInput ノードを含むメッセージ・フローに、各呼び出しの入力パラメーターを送信します。
  3. メッセージ・フローは、ターゲット・アプリケーションのキューにメッセージを入れます。
  4. ターゲット・アプリケーションはキューからメッセージを取得し、それを処理します。
  5. ターゲット・アプリケーションはメッセージをキューに入れます。
  6. SAPReply ノードを含む 2 番目のメッセージ・フローはキューからメッセージを取得し、それを処理します。
  7. SAPReply ノードは応答メッセージを該当するリスナーに送信します。
  8. 各リスナーは、応答メッセージを該当する SAP プログラムに返します。
このシナリオでは、メッセージ・フローの待ち時間は、シナリオ全体の所要時間と比較して短くなります。 したがって、このメッセージ・フローの追加インスタンスの構成数を少なくして、SAPInput ノードを含むメッセージ・フローで使用されるリソースを制限できます。 メッセージ・フローはインポート・パラメーターを処理のために短時間で伝搬するので、この例のように、メッセージ・フローの 1 つのインスタンスを多数のリスナーが利用できます。
以下のシナリオも考えられます。
  • 単一のメッセージ・フローに SAPReply ノードが 1 つ含まれていますが、複数の SAPInput ノードへの応答に使用されます。 メッセージが SAPReply ノードに伝搬された後で、リスナーは応答を SAP に送り返すので、SAP からの別の呼び出しを受け取ることができます。 しかし、メッセージ・フローの現行インスタンスは、SAPReply ノードの下流のノードを依然として処理中です。 この場合は、SAPReply ノードを含むメッセージ・フローのインスタンスの数を増やします。
  • SAPReply ノードへの伝搬後に、メッセージ・フロー内の他のノードが余分の処理を実行します。 この場合は、SAPReply ノードが入っているメッセージ・フローが SAPInput ノードの入っているものと同じであっても、そのフローのインスタンスの数を増やしてください。

    このシナリオは、データの整合性に関して望ましくない影響を及ぼす可能性があります。 SAPReply ノードの後で例外が発生すると、メッセージ・フローによって更新されるリソース (データベース表や WebSphere® MQ キューなど) は、ロールバックされる可能性があります。 しかし、応答は既に SAP に送り返されているので、ロールバックできません。この動作が適切でない場合は、SAPReply ノードが確実にメッセージ・フロー内の最終ノードになるようにして、データの整合性を改善できます。

SAP アダプターを調整する方法の詳細は、スケーラビリティーとパフォーマンスのための SAP アダプターの調整を参照してください。

特記事項 | 商標 | ダウンロード | ライブラリー | サポート | フィードバック

Copyright IBM Corporation 1999, 2014Copyright IBM Corporation 1999, 2014.

        
        最終更新:
        
        最終更新: 2015-02-28 17:48:32


概念トピック概念トピック | バージョン 8.0.0.5 | bc22040_