システム負荷を適切に分散するために、宛先オプションを使用して任意のアプリケーションサーバまたは
R/3 システムのあらかじめ定義したアプリケーションサーバグループで、汎用モジュールを並列処理することができます。
並列処理は、非同期
RFC の特殊なバリアントを使用して実現されます。 ユーザ独自の並列処理アプリケーションに対して、適正なバリアント ( キーワード CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP) だけを使用することが重要です。 非同期 RFC の他のバリアントを使用すると、この正しいキーワードの組込み保護機能を回避されるため、システムに障害が発生する可能性があります。詳細は、以下のサブセクションで説明します。
並列処理の前提条件
並列処理を実行する前に、アプリケーションおよび
R/3 システムが以下の要件を満たしていることを確認してください。並行して実行するデータ処理タスクは、そのタスクの他のインスタンスから論理的に独立していなければなりません。
つまり、このタスクを実行するときには、並列処理される同一データセットの他のレコードを参照する必要がなく、並列処理の他の結果に依存しないことが必要です。 たとえば、連続処理する必要のあるデータや、あるデータ項目の処理が別の項目の処理に依存しているデータの場合には、並列処理は不適切です。データが特定の順序で並列処理されることや、または特定の結果が処理過程の任意の時点で使用できるようになるということは保証されません。
並列ジョブからタスクを処理するには、
R/3 システムのサーバに少なくとも 3 つのダイアログワークプロセスが必要です。 また、並列処理システムのワークロード基準を満たしていなければなりません。このワークロード基準とは、ディスパッチャキューの使用率は 10 % 未満であり、並列ジョブのタスクを処理するために少なくとも 1 つのダイアログワークプロセスが空いている必要があるという基準です。並列処理のための汎用モジュールおよび
ABAP キーワード以下の汎用モジュールおよび
ABAP キーワードを使用して、アプリケーションで並列処理を実現することができます。リソースが並列処理に使用できるかどうかを判別するために使用します。
以下の処理を行うことができます。
R/3
システムで汎用モジュールを並列実行するには、この ABAP キーワードを使用します。 通常は、このキーワードをループに入れ、処理すべきデータをいくつかの作業パケットに分割します。 処理するデータを内部テーブル ( EXPORT 、 TABLE 引数 ) の形式で受け渡すことができます。 このキーワードは、処理に指定された RFC サーバグループ内の使用可能なサーバに非同期 RFC コールをディスパッチすることによって、並列処理を実現します。CALL FUNCTION
を使用した RFC コールは、 DIALOG タイプのワークプロセスで処理されることに注意してください。 1 つのダイアログステップ ( デフォルトで 300 秒、システムプロファイルパラメータ rdisp/max_wprun_time ) の処理に対する DIALOG 制限は、 RFC コールにも適用されます。 コールの並列処理のためにデータを分割するときは、この制限を忘れないでください。キーワード
CALL FUNCTION の直後に呼び出して、並列処理タスクが実行されるサーバの名称を取得します。特定のサーバを並列処理タスクに使用しないようにします。
特定のサーバが並列処理に使用できないことを指定する場合は、 SPBT_GET_PP_DESTINATION とともに使用します ( たとえば、サーバが使用できなくなった場合の例外 COMMUNICATION FAILURE ) 。WAIT UNTIL <
論理式 >CALL FUNCTION
で登録した非同期の並列タスクがすべて戻るまで待機する場合に必要です。 通常、このキーワードは、順序に従ってバックグラウンド処理を行う場合に指定する必要があります。 CALL FUNCTION にオプション PERFORMING ON RETURN が含まれている場合にだけ使用できます。RECEIVE RESULTS FROM FUNCTION function
非同期
RFC の処理結果を受信する場合に必要です。 RECEIVE は、メッセージやリターンコードと同様に IMPORT パラメータおよび TABLE パラメータも取り込みます。並列処理におけるリソース管理
以下の宛先オプションを使用して
R/3 システムで汎用モジュール ( 非同期コール ) の並列処理を実行します。事前に定義されているアプリケーションサーバグループにおいて、次を実行します。
CALL FUNCTION RemoteFunction STARTING NEW TASK taskname
Destination
IN GROUP groupname現在使用できる有効なすべてのアプリケーションサーバにおいて、次を実行します。
CALL FUNCTION RemoteFunction STARTING NEW TASK Task
Destination
IN GROUP DEFAULTこのオプションを指定すると、まず、現在使用可能な
( ログインサーバと同等のすべてのサーバまたはアプリケーションサーバの ) リソース ( ワークプロセス ) の容量が確認されます。 各アプリケーションサーバで非同期コールの実行に使用できるリソースは、現行のシステム負荷によって異なります。アプリケーション開発者は、本稼動システム
( すなわち、顧客のシステム ) の RFC グループの可用性に関して責任があります。 RFC グループの更新方法の詳細については、 負荷分散のためのグループの宛先更新. を参照してください。使用可能なリソースの確認後に、使用可能なアプリケーションサーバで非同期コールが実行されます。
特定の時点でリソースが使用できない場合、例外ルーチン RESOURCE_FAILURE が 実行されます ( オプション Exceptions を参照 ) 。 非同期汎用モジュールコールの場合、この例外はアプリケーションプログラムで 処理されなければなりません。RFC
グループで使用可能なリソースの確認プロセスは以下のとおりです。まず、システムが該当するアプリケーションサーバのディスパッチャキューの長さを確認します。
この長さが全体の 10 % より長い場合、このサーバでは使用可能なリソースはありません。 全体の 10 % より短い場合、現在の空きダイアログプロセスの数から ( システムまたは管理プログラムへのログオンといった別の目的用の予約インスタンスとして ) 2 を引いた数のプロセスを使用することができます。 したがって RFC 並列処理を考慮すると、 1 つのアプリケーションサーバには、最低 3 つのダイアログプロセスが なければなりません。