手順
オブジェクトの宛先はそれぞれ、1つの実行宛先または一連の実行宛先を表します。宛先オブジェクトは、クラスのクラスメソッドを使用して要求できますCL_BGRFC_DESTINATION_OUTBOUNDアウトバウンドキューとクラスの場合CL_BGRFC_DESTINATION_INBOUNDインバウンドキュー用。アウトバウンドキューの宛先は、トランザクションSM59で更新され、アウトバウンドbgRFCタイプtおよびタイプqの実行宛先を表す必要があります。インバウンドキューの宛先は、トランザクションSBGRFCCONFで更新する必要があります。宛先が有効でない場合、例外CX_BGRFC_INVALID_DESTINATIONは生産された。
未登録の宛先には常に「古い」というフラグが立てられるため、アウトバウンドキューにまだ登録されていない宛先を自動的に登録することが非常に重要でした。この未登録の宛先が誤って新しいAPIで埋められた場合、自動登録の場合、システムが以前と同じように動作する前に、宛先を最初に「古い」に切り替える必要があります。宛先の切り替えは、特にこの宛先へのキューがすでにいっぱいになっている場合、または宛先がすでに内部モードで使用されている場合、重要な操作です。この場合、新しいbgRFCタイプtおよびタイプqを有効化して、新しいRFCプロトコルを使用することができます。
宛先NONEおよびSPACEはサポートされていません。内部モード内の実行先ごとに正確に1つのオブジェクトが作成されます。つまり、宛先は実行先ごとにシングルトンです。
インターフェイスIF_BGRFC_DESTINATION_OUTBOUNDとIF_BGRFC_DESTINATION_INBOUND新しいバックグラウンドユニットを要求するために必要なメソッドへのアクセスを有効にします。基礎となるクラスはt/qRFCの使用には関係がなく、完全を期すために次のUML図にのみ示されています。
結果
タイプqのqRFCユニットとタイプtのbgRFCユニットの違いは、必要なサービス品質（QoS）です。bgRFCタイプqの場合、サービス品質は1回だけ（EOIO）であり、タイプtの場合、サービス品質は1回だけ（EO）です。bgRFCタイプqユニットのシーケンスを保証し、同時に独立ユニットを並列化できるようにするために、依存関係はキューを使用して実装されます。bgRFCタイプtユニットはキューに属していないため、常に並行して処理できます。
