並列処理の実現 
一部の
R/3
レポートは夜間での処理だけでは時間が足りなくなってきています。特に大量のデータを処理するカスタマでは、
(
品目計画実行などの
)
バックグラウンド処理システムで定期的に
R/3
レポートを実行する場合、非常に時間のかかることがあります。ダイアログユーザが複数のタイムゾーンにまたがっている場合は特に、このようなジョブを
“
夜間
”
に完了させることは難しくなります。リリース
3.1G
では、
R/3
に
“
短い夜
”
のもたらす問題の解決策として並列処理バックグラウンドジョブが用意されています。実行時間が長い
R/3
レポートは並列処理で実行できるようになり、
R/3
システムの使用可能なダイアログワークプロセスに小分けして作業を行い、その後結果を終了後まとめることができます。
並列処理はバックグラウンド処理システム自体ではなく、
ABAP
レポートと
ABAP
プログラムで実行されます。つまり、ジョブステップで実行されるレポートが並列処理用にプログラムされている場合に限り、ジョブは並列で処理されます。このようなレポートは対話式で開始される場合でも並列処理が可能です。
並列処理は非同期
RFC
の特殊バリアントを使用して実行されます。ユーザ独自の並列処理アプリケーションに対して適切なバリアントの
CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP
キーワードだけを使用することが重要です。非同期
RFC
のその他のバリアントを使用すると、正しいキーワードに組み込まれた保護機能が働かず、システムに障害が発生することになります。
汎用モジュールと
ABAP
キーワード
並列処理はバックグラウンドで実行されるアプリケーションレポートで実行されます。以下の汎用モジュールと
ABAP
キーワードを使用してユーザ独自のバックグラウンドアプリケーションで並列処理を実行できます。
SPBT_INITIALIZE:
並列処理用資源の利用可能度を判定する場合にオプションで使用します。
以下の操作を実行できます。
- 指定した並列処理グループが正確がどうかのチェック。
ユーザデータで処理予定のデータのパケットのより効率的なサイズを決定するための、利用可能なワークプロセス数の調査。
引数を持つ、
ABAP
キーワードの
CALL FUNCTION <
関数
> STARTING NEW TASK <
タスク名
>:
このキーワードを使用して
R/3
システムに並列で汎用モジュールコールを実行させることができます。一般に、このキーワードは、処理されるデータをワークパケット単位に分割するループに記述します。処理予定のデータは内部テーブル形式
(EXPORT, TABLE
引数
)
で渡すことができます。キーワードはこの処理用に指定されている
RFC
サーバグループで利用可能なサーバに非同期
RFC
コールをディスパッチすることにより、並列処理を実行します。
CALL FUNCTION
を用いた
RFC
コールは
DIALOG
タイプのワークプロセスで処理されることに注意してください。
1
つのダイアログステップの処理に関する
DIALOG
制限
(
デフォルトでは
300
秒、システムプロファイルパラメータ
rdisp/max_wprun_time)
は
RFC
コールにも適用されます。データを並列処理コール用に分割する際は、この制限に注意してください。
汎用モジュール
SPBT_GET_PP_DESTINATION: CALL FUNCTION
キーワードのすぐ後にコールし、並列処理を実行するサーバ名を取得します。指定はオプションです。
汎用モジュール
SPBT_DO_NOT_USE_SERVER:
並列処理タスクの処理において特定サーバを以降使用しないようにします。特定サーバを並列処理にある時点以降利用しない場合
(
サーバが利用不能になった場合の
COMMUNICATION FAILURE
例外など
)
に
SPBT_GET_PP_DESTINATION
と組み合わせて使用します。指定はオプションです。
キーワード
WAIT: CALL FUNCTION
を用いて登録されるすべての非同期並列タスクの戻りを待機する場合は必須です。これは、順番にバックグラウンド処理を行うには通常必要とされます。
CALL FUNCTION
に
PERFORMING ON RETURN
が追加されている場合にのみ使用することもできます。
キーワード
RECEIVE:
非同期
RFC
の処理結果を受け取る場合は必須です。
RECEIVE
は、メッセージおよびリターンコードと同様に、
IMPORT
パラメータと
TABLE
パラメータも検索します。
前提条件
並列処理を実行する前に、バックグラウンド処理アプリケーションと
R/3
システムが以下の要件を満たしていることを確認してください。
:
並列で実行される予定のデータ処理タスクはタスクの他のインスタンスからは論理的に独立していなければなりません。つまり、そのタスクは同様に並列で処理される同一データセットからの他のレコードの参照なしで実行され、タスクは並列操作のその他の結果に依存しないということです。たとえば、並列処理は順次処理しなければならないデータや、
1
データ項目の処理がデータの他の項目の処理に依存するような場合には不向きです。
この定義は、並列処理における特定順序でのデータ処理、処理の所定ポイントでの特定結果の利用を保証するものではありません。
の要件も満たす必要があります。
(CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP
キーワードのオンライン文書も参照してください。
)
コールする汎用モジュールは外部からコール可能としてマークを付けておかなければなりません。この属性は汎用モジュール定義
(
トランザクション
SE37)
の
リモートファンクションコール項目で指定されます。
コールされた汎用モジュールには、宛先
“BACK”
のファンクションコールを含むことはできません。
非同期
RFC
コールを行った後は、呼出元プログラムを新しい内部セッションに変更しないでください。つまり、レポートで
CALL FUNCTION STARTING NEW TASK
を使用した後は
SUBMIT
または
CALL TRANSACTION
を使用しないでください。
CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP
キーワードを使用して外部プログラムを開始することはできません。
R/3
システム間のコールでは、両システムともにリリース
3.0A
以降のバージョンである必要があります。
システムのリソース
:
並列ジョブからタスクを処理するには、
R/3
システムのサーバには最低でも
3
つのダイアログワークプロセスが必要です。これはまた、以下の並列処理システムのワークロード基準を満たす必要があります。つまり、ディスパッチャキューは
10%
以下で、並列ジョブからのタスク処理用に最低でも
1
つのダイアログワークプロセスが空いていなければなりません。
RFC
サーバグループを使用した資源管理
並列処理システムには、
R/3
システムの資源すべてが並列ジョブに使用されてしまい、他のジョブや他のユーザに性能低下の問題をもたらすような事態を発生させないための、安全機能が組み込まれています。
このような組み込まれた安全機能だけでなく、
RFC
サーバグループでの資源の共有を最適化することもできます。並列処理のコンテキストでは、グループにより、特定プログラムを並列で実行するために使用される
R/3
アプリケーションサーバ群が指定されます。デフォルト
(DESTINATION IN GROUP DEFAULT
を追加した
CALL FUNCTION STARTING NEW TASK)
では、このグループは資源基準を満たすすべてのサーバになります。また独自の制限を設けたグループを登録することもできます。トランザクション
RZ12 (
ツール
→
管理
→
管理
→
ネットワーク
→
RFC
宛先、次に
RFC
→
RFC
グループ
)
を使用して、グループを表示したり、更新することができます。
SPBT_INITIALIZE
汎用モジュール
(
使用される場合
)
と
ABAP CALL FUNCTION STARTING NEW TASK
キーワードの両方に、使用予定のグループを指定する必要があります。
1
つの並列
ABAP
レポートあるいはプログラム
(
ジョブステップ
)
には
1
つのグループしか指定できません。
メッセージと例外
コールする汎用モジュールでは、
MESSAGE
キーワードではなく、エラーレポート用の例外を使用します。非同期
RFC
では例外処理の制御はすべてユーザが行います。汎用モジュールにより生成された例外を
CALL FUNCTION
キーワードの予約済の
SYSTEM_FAILURE
と
COMMUNICATIONS_FAILURE
例外に追加するだけです。これによって並列プログラミングタスクを起動するプログラムの例外を処理できるようになります。
権限
システムプロファイルパラメータの
auth/rfc_authority_check
が設定されると
(
値
1)
、バックグラウンドジョブの権限を持つユーザが必要な
RFC
権限を持つかどうかが、
CALL FUNCTION
キーワードで自動的にチェックされます。
RFC
権限オブジェクトは
RFC
アクセス時の
S_RFC
権限チェックです。権限チェックでは汎用モジュールグループ別に汎用モジュールにアクセスします。つまり、ユーザに特定グループに属する汎用モジュールを実行する権利があるかどうかがチェックされます。
汎用モジュール
AUTHORITY_CHECK_RFC
を使用してユーザの
RFC
権限をテストできます。この汎用モジュールは、指定したグループに対する権限をユーザが持っている場合には
RC = 0
を返します。汎用モジュールは権限チェックが実際に実行されるかどうかをチェックしません。
サンプルプログラム
:
並列ジョブ
このサンプルプログラムは対話式で、あるいはバックグラウンド処理システムで開始された場合に、並列で実行するレポートを登録する方法を示しています。これは、
ABAP CALL FUNCTION STARTING NEW TASK
文書のオンライン文書をベースとしています。
プログラム構造
SPBT_INITIALIZE:
データの宣言後、レポートは
SPBT_INITIALIZE
汎用モジュールをコールします。このコールにより、プログラムは並列処理グループが有効であることと、資源が利用できることを確認します。このコールはオプションです。汎用モジュールをコールしない場合は、
R/3
システム自体が
SPBT_INITIALIZE
をコールして
RFC
サーバグループを初期化します。
汎用モジュールは利用可能なワークプロセス数を返すので、コールは処理対象となるワークパケットのサイズの決定に使用できます。たとえば、
10
個のワークプロセスを利用できる場合は、データを
10
個のパケットに分割して処理します。ただし、ジョブ用に予約されているサーバグループで作業をしている場合を除き、空きワークプロセス数がコール時とプログラムによるワークパケットの送出時までの間に変わらないという保証はありません。
また、処理予定のレコードごとに並列処理コールを行うデータを用いて実行することも当然可能です。この場合、ワークパケットサイズの最適化は行われません。
CALL FUNCTION...Loop:
レポートの中心は
DO
ループで、ここで並列で処理される汎用モジュール
(CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP)
がコールされます。この例のループは単純なカウントダウンメカニズムで制御されます。本稼動レポートでは、すべてのデータが
CALL FUNCTION
で処理を行うために送信されるまでループを繰り返してください。
わかりやすく説明するため、この例のループではデータが不要な汎用モジュール
(RFC_SYSTEM_INFO)
をコールします。本稼動レポートには、処理対象のレコードあるいはレコードグループを選択するロジックをインクルードします。これらのレコードを内部テーブルにパッケージ化し、
CALL FUNCTION STARTING NEW TASK
の追加
EXPORTING
または
TABLES
機能を使用して並列処理コールにインクルードします。
リカバリに備えて、本稼動プログラムには処理の進捗ログを記録するロジックもインクルードしてください。万が一プログラムが処理途中で異常終了した場合は、どのデータが処理済で、どのデータをレポートで再処理すべきかをユーザが判断できなければなりません。最も単純な形式の場合、このロジックは並列処理用にディスパッチされたデータを最も簡単な形式で記録し、データの単位ごとに処理が完了したものと判断するようなものになります。
タスク管理
: CALL FUNCTION
からのリターンコードが
0 SY-SUBRC)
の場合、並列処理タスクが正常にディスパッチされたことを示します。ここで重要になるのは、ジョブが並列処理タスクの動きを正確に記録しているかどうかです。タスク管理は以下の
2
つの割当を管理します。
CALL FUNCTION
タスクごとの固有のタスク名の生成
CALL FUNCTION
で指定したタスク名を使用して並列処理タスクを識別します。タスクからの戻りを正確に識別できるように、ディスパッチするタスクがそれぞれ固有の名称を持つようにしなければなりません。
(
ダイアログワークプロセス
)
が一時的に使用されている場合、すべての資源が使用可能になるまで待機。次の「
CURRENTLY_NO_RESOURCES_AVAIL
例外の処理」を参照してください。
- 全タスクの完了を判断。全タスクが完了しなければプログラムを終了できません。詳細については、後述の「ジョブの完了待機」を参照してください。
例では、タスク管理はタスク名でカウンタを増数し、ディスパッチされたタスクのテーブルを更新します。
SPBT_GET_PP_DESTINATION
を使用して、どこで並列タスクが処理されているかを特定する機能がオプションで用意されています。
RESOURCE_FAILURE
例外の処理
:
並列処理タスクがディスパッチされるごとに、
R/3
システムは以降のタスクの処理に利用できる資源数
(
ダイアログワークプロセス数
)
をカウントダウンします。このカウントは、並列処理タスクが完了すると再び増加し、プログラムに返されます。
並列処理タスクの完了までに時間がかかる場合は、並列処理資源が一時的に不足する場合があります。この場合には、
CALL FUNCTION
は例外
RESOURCE_FAILURE
を返します。つまり、プログラムで使用している
RFC
グループのすべてのダイアログワークプロセスが使用中ということです。
プログラムは、資源が利用可能になるまで待機し、エラーとなった
CALL FUNCTION
を再度実行する必要があります。サンプルプログラムでは、単純で合理的なフェイルセーフ待機メカニズムを使用します。このプログラムは並列処理タスクが返され、資源を解放するまで待機します。
WAIT
は
1
秒の初期タイムアウトの指定も行います。
CALL FUNCTION
が再びエラーになると、タイムアウト時間を延長して
WAIT
が繰り返されます。並列タスクの完了に時間がかかると予測される場合は、タイムアウトの時間を長く設定できます。適当な回数反復した後でこの繰り返しを終了するためのコードも追加してください。受信応答
: CALL FUNCTION
キーワードは各並列処理タスクが完了するたびに
FORM
ルーチン
RETURN_INFO
の処理を開始します。この
FORM
ルーチンは
RECEIVE
キーワードを使用して並列処理の結果を取得します。この場合、
RFC_SYSTEM_INFO
からの
RFCSI_EXPORT
構造の内容が内部構造
INFO
に設定されます。
RECEIVE
は非同期実行
RFC
汎用モジュールの
IMPORTING
と
TABLE
から戻されたデータを収集する必要があります。
例
:
レポートが一覧を生成すると仮定します。
RETURN_INFO
や
RECEIVE
のような
FORM
ルーチンを使用して並列処理タスクが生成した一覧エントリを収集します。すべての並列タスクからデータが戻された後、レポートはソートを行うか、あるいは提示前に必要な一覧エントリの処理を継続します。
ジョブ完了の待機
:
タスク管理の一部として、ジョブはすべての並列処理タスクが完了するまで待機しなければなりません。サンプルプログラムはこのために
WAIT
キーワードを使用し、並列処理タスク数が登録済タスク数と一致するまで待機します。この
WAIT
とは関係なく、
RETURN_INFO FORM
ルーチンが開始されます。
WAIT
条件が正確に評価できるように、
RETURN_INFO
は完了済並列処理タスク数を記録します。
データ宣言
*
DATA: GROUP LIKE RZLLITAB-CLASSNAME VALUE ' ',
"
並列処理グループ
"SPACE =
グループデフォルト
(
すべての
"
サーバ
)
WP_AVAILABLE TYPE I, "
並列処理で利用可能な
"
ダイアログワークプロセス数
"(
空きワークプロセス数
)
WP_TOTAL TYPE I, "
グループ内の合計
"
ダイアログワークプロセス数
MSG(80) VALUE SPACE, "
リモート
RFC
例外が発生した場合の
"
エラーメッセージ用コンテナ
INFO LIKE RFCSI, C, "
メッセージテキスト
JOBS TYPE I VALUE 10, "
並列ジョブ数
SND_JOBS TYPE I VALUE 1, "
処理用に送られるワークパケット
RCV_JOBS TYPE I VALUE 1, "
受信したワークパケット応答数
EXCP_FLAG(1) TYPE C, " RESOURCE_FAILURE
発生数
TASKNAME(4) TYPE N VALUE '0001', "
タスク名並列処理作業単位名
)
BEGIN OF TASKLIST OCCURS 10, "
タスク管理
TASKNAME(4) TYPE C,
RFCDEST LIKE RFCSI-RFCDEST,
RFCHOST LIKE RFCSI-RFCHOST,
END OF TASKLIST.
*
* SBPT_INITIALIZE
へのオプションコールにより並列処理の実行対象グループをチェック。
*
ワークパケットのサイズを最適化する際にも使用される。
* work / WP_AVAILABLE).
*
CALL FUNCTION 'SPBT_INITIALIZE'
EXPORTING
GROUP_NAME = GROUP
"
チェック対象グループ名
IMPORTING
MAX_PBT_WPS = WP_TOTAL
"
並列処理用にグループ内で利用可能な
"
ダイアログワークプロセス数の合計
FREE_PBT_WPS = WP_AVAILABLE
"
この時点で並列処理用にグループ内で
"
利用可能なダイアログワークプロセス数
EXCEPTIONS
INVALID_GROUP_NAME = 1
"
不正グループ名
; RFC
"
グループが定義されていない
トランザクション
" RZ12
を参照。
INTERNAL_ERROR = 2
"R/3
システムエラー
;
"
診断情報用
"
システムログを参照
(
トランザクション
SM21)
。
PBT_ENV_ALREADY_INITIALIZED = 3
"
汎用モジュールは一度だけコール可能。
"
並列処理を開始する前に
"
コールしなければ
R/3
により自動的に
"
コールされる。
CURRENTLY_NO_RESOURCES_AVAIL = 4
"
グループのダイアログワークプロセスは
"
利用不可。すべて使用中あるいはサーバの負荷が
"
高すぎる。
NO_PBT_RESOURCES_FOUND = 5
"
グループ内のサーバは定義されている
"2
つのワークプロセスの基準を満たさない。
CANT_INIT_DIFFERENT_PBT_GROUPS = 6
"
すでに
1
グループを初期化済にもかかわらず、
"
別のグループを初期化しようとしている。
OTHERS = 7..
CASE SY-SUBRC.
WHEN 0.
"
正常終了。ワークパケットのサイズ最適化の設定を
"
オプションで実行。
WHEN 1.
"
グループ名が存在しないためレポートは中止。
MESSAGE E836."
グループが定義されていません。
”
WHEN 2.
"
システムエラー。エラー分析のため処理を中止してシステムログをチェック。
WHEN 3.
"
プログラミングエラー。プログラムを停止して修正。
MESSAGE E833."PBT
環境はすでに初期化済です。
WHEN 4.
"
資源なし
:
これは一時的な障害の場合があります。しばらく
"
休止してコールを繰り返してみてください。あるいは、
"RFC
グループ管理をチェックし、グループが
"
要件に従って定義されているか確認してください。
MESSAGE E837."
すべてのサーバが現在使用中。
”
WHEN 5.
"
サーバ、ネットワーク、操作モードをチェック。
”
WHEN 6.
*
並列処理を実行
CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP
を使用して
*
この作業を実行する汎用モジュールをコールします。処理対象のレコードごとにコールを行うか、
*
レコードをワークパケットに分割します。いずれの場合にも、
CALL FUNCTION
キーワード
* (EXPORT, TABLES
引数
)
に内部テーブルとして
*
レコードセットを指定してください。
DO.
CALL FUNCTION 'RFC_SYSTEM_INFO' "
並列で実行される汎用モジュール
STARTING NEW TASK TASKNAME "
この
RFC
コールを識別するための名称
DESTINATION IN GROUP group "
並列処理に使用される
"
サーバグループの名称
"
グループ名を
"
トランザクション
RZ12
に
"
表示されるとおりに正確に入力
(
すべて大文字
)
。特定
ABAP
プログラムの
1
つのグループ名だけを使用することも可能。
PERFORMING RETURN_INFO ON END OF TASK
"
この書式は、
RFC
コールが完了すると
"
コールされます。これは、
"IMPORT
と
TABLES
パラメータを
" RECEIVE
を使用して
"
コールした汎用モジュールから収集します。
EXCEPTIONS
COMMUNICATION_FAILURE = 1 MESSAGE msg
"
宛先のサーバに到達できないか、または
"
通信が中断。
MESSAGE msg
によって
"
この例外で返されるメッセージ
" (
コールされた
FM
からの
"
たとえば
E
または
A
メッセージ
)
を取得。
"
例外
1
または
2
の後では、
"
プログラムを中止せずに、
" SPBT_GET_PP_DESTINATION
と
" SPBT_DO_NOT_USE_SERVER
を使用して
"
このサーバを以降の並列処理対象から除外できます。
"
次に別のサーバを使用してこのコールの処理を再び実行することができます。
SYSTEM_FAILURE = 2 MESSAGE msg
"
プログラムエラーまたは
"
その他の内部
R/3
エラー。
MESSAGE msg
を使用すると
"
この例外の発生で返された
"
すべてのメッセージを取得可能。
RESOURCE_FAILURE = 3. "
現在すべてのワークプロセスが利用不可能。
"
この例外は必ずプログラムで処理する必要があります。
YOUR_EXCEPTIONS = X. "
コールされた汎用モジュールにより
"
生成された例外をここに追加。
例外は
"
ユーザに返されるため、ユーザ側で対応可能。
CASE SY-SUBRC.
WHEN 0.
"
非同期
RFC
タスクの管理
"
タスク名を保存
...
TASKLIST-TASKNAME = TASKNAME.
"... RFC
コールを実行しているサーバ名を取得。
CALL FUNCTION 'SPBT_GET_PP_DESTINATION'
EXPORTING
RFCDEST = TASKLIST-RFCDEST
EXCEPTIONS
OTHERS = 1.
APPEND TASKLIST.
WRITE: / 'Started task: ', TASKLIST-TASKNAME COLOR 2.
TASKNAME = TASKNAME + 1.
SND_JOBS = SND_JOBS + 1.
"
ループ終了のタイミングを決定するメカニズム。ここでは、
"
並列処理タスク数の単純なカウンタ
"
本稼動時には、処理対象データのディスパッチ終了時に
"
ループを終了します。
JOBS = JOBS - 1. "
既存ジョブ数
IF JOBS = 0.
EXIT."
ジョブ処理終了
ENDIF.
WHEN 1 OR 2.
"
通信障害とシステム障害を処理。プログラムは
"
これらの例外を捕捉し、バックグラウンド処理ジョブを回復可能な状態で終了
"
させる必要があります。
"
推奨
:
ジョブが未処理データを用いて再起動可能なように、
"RFC
タスクが開始されたとき、および処理が戻されたときに
"
処理済になっているデータを記録する。
WRITE msg.
"
このプログラムでの並列処理タスクでこれ以降使用されない
"
ようにサーバを除去。
"
今コールしたサーバ名を取得
...
CALL FUNCTION 'SPBT_GET_PP_DESTINATION'
EXPORTING
RFCDEST = TASKLIST-RFCDEST
EXCEPTIONS
OTHERS = 1.
"
次にこれを利用可能なサーバ一覧から削除する。
CALL FUNCTION 'SPBT_DO_NOT_USE_SERVER'
IMPORTING
SERVERNAME = TASKLIST-RFCDEST
EXCEPTIONS
INVALID_SERVER_NAME = 1
NO_MORE_RESOURCES_LEFT = 2
"
グループにサーバが残っていない。
PBT_ENV_NOT_INITIALIZED_YET = 3
OTHERS = 4.
WHEN 3.
"
現在のところ、利用可能な資源
(
ダイアログワークプロセス
)
なし。
この例外を処理し、処理が続行されるまで、
"
あるいは処理続行を妨害する障害があることがわかるまで、
"
待機して
CALL FUNCTION
を繰り返す。
MESSAGE I837."
すべてのサーバが現在使用中。
"
非同期
RFC
コールへの応答待ち。各応答では
"
ダイアログワークプロセスを再び利用可能にする必要があります。
IF EMPFNAME = SPACE.
EXCP_FLAG = 'X'.
"
最初の
RESOURCE_FAILURE
処理試行。すべての
"RFC
コールから処理が戻されるまで、または最高
1
秒間待機。
"
次に
CALL FUNCTION
を繰り返す。
WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '1' SECONDS.
ELSE.
" 2
回目の
RESOURCE_FAILURE
処理試行。
WAIT UNTIL RCV_JOBS >= SND_JOBS UP TO '5' SECONDS.
"WAIT
からの
SY-SUBRC 0
は応答が返されたことを示す。
"
そのため、資源の問題は作業負荷のために一時的に発生したものと思われる。ゼロ以外の
RC
は
"
完了していない
RFC
コールが存在し、障害のある可能性があることを示します。
IF SY-SUBRC = 0.
CLEAR EXCP_FLAG.
ELSE."
応答なし
"
無限ループ処理
ENDIF.
ENDIF.
ENDCASE.
ENDDO.
...
*
*
ジョブ終了待機
:
すべての
RFC
タスクからの応答。
ｓ
*
残りの非同期応答を受信
WAIT UNTIL RCV_JOBS >= SND_JOBS.
LOOP AT TASKLIST.
WRITE:/ 'Received task:', TASKLIST-TASKNAME COLOR 1,
30 'Destination: ', TASKLIST-RFCDEST COLOR 1.
ENDLOOP.
...
*
*
このルーチンは
RFC
コールが完了し、返されたときに開始されます。このルーチンは
RECEIVE
を使用し、
RFC
汎用モジュールから、
* IMPORT
と
TABLE
のデータを収集します。
*
* WRITE
キーワードは非同期
RFC
ではサポートされないことに注意してください。一覧を生成する必要がある場合は、
RFC
汎用モジュールは
*
内部テーブルに一覧データを戻します。これにより、
*
このデータを収集し、処理の最後に一覧を出力できます。
*
FORM RETURN_INFO USING TASKNAME.
DATA: INFO_RFCDEST LIKE TASKLIST-RFCDEST.
RECEIVE RESULTS FROM FUNCTION 'RFC_SYSTEM_INFO'
IMPORTING RFCSI_EXPORT = INFO
EXCEPTIONS
COMMUNICATION_FAILURE = 1
SYSTEM_FAILURE = 2.
RCV_JOBS = RCV_JOBS + 1. "
データ受信
IF SY-SUBRC NE 0.
*
通信障害とシステム障害の処理
...
ELSE.
READ TABLE TASKLIST WITH KEY TASKNAME = TASKNAME.
IF SY-SUBRC = 0. "
データ登録
TASKLIST-RFCHOST = INFO_RFCHOST.
MODIFY TASKLIST INDEX SY-TABIX.
ENDIF.
ENDIF.
...
ENDFORM