AMQPプロトコルは、さまざまなアプリケーション間の堅牢で非同期のメッセージングをサポートするために確立されました。ABAPプラットフォームは、ABAPアプリケーション用のAMQPクライアントを実装するためのAPIを提供します。このようなAMQPクライアントを使用すると、ABAPアプリケーションは他のAMQPクライアントとポイントツーポイントまたはブローカーを介してメッセージを交換することができます。以下に、ブローカーを介したAMQPプロトコルを使用したアプリケーション間のメッセージ交換の概略例を示します。
-
交換は、さまざまなABAPアプリケーション間、およびABAPアプリケーションと非ABAPアプリケーション間で行うことができます。
- 各AMQPクライアントを使用して、1つの専用ブローカーへの接続を確立できます。この接続は、さまざまなブローカートピックのコンテンツを交換するために使用できます。同じアプリケーション内に実装された複数のAMQPクライアントがブローカーに接続されている場合があります。
- アプリケーションが1つ以上の追加のブローカーに接続する必要がある場合は、1つ以上の追加の対応するクライアントオブジェクトを作成する必要があります。各ブローカー接続は、アプリケーション内で少なくとも1つの対応するAMQPクライアントを要求します。
接続タイプ
次のAPC接続タイプが各AMQP接続でサポートされています。
- WebSockets：AMQP接続は、IETF標準RFC6455に従ってWebSocket接続の上に確立されます。
- TCPソケット：AMQP接続は、ネイティブTCP/IP接続を介して確立されます。
アプリケーションプログラマーの観点からは、使用されるAPC接続タイプは接続セットアップ中にのみ異なります。したがって、AMQPクライアントABAP APIでは、AMQPクライアントオブジェクトを作成するためのファクトリメソッドの対応する使用法によって、異なる接続タイプが決定されます。AMQP接続が確立されるとすぐに、APIは基盤となるAPC接続タイプに依存しません。
サービスの質
- せいぜい1回の配信：メッセージは最も手頃な価格で送信されます。
- 少なくとも1回の配信：送信されたメッセージには確認が必要です。
- 正確に1回の配信：送信されたメッセージには確認が必要です。受信者で保存されたメッセージの状態を破棄するには、重複を避けるために個別の確認応答が必要です。
メッセージが送信者によって決済されて送信されている場合、受信者の決済モードの値は無視されます。
ABAPアプリケーションサーバーは、QoSを最大1回および少なくとも1回のみサポートします。
イベント駆動型プログラミングモデル
AMQPクライアントの場合、APCクライアントの場合と同様のイベント駆動型プログラミングモデルが提供されます。アプリケーションは次のイベントを処理できます。
すべての通信ステップは同期点です。より正確には、AMQPフレーム（たとえば、、、、）を送信する各アクションと、OPEN各BEGINイベントの処理の終了（たとえばATTACH、、、）は同期点です。これの意味は：SENDON_MESSAGEON_SENDON_FLOW_CHANGE
- DBコミットがトリガーされます。
- 実行が中断され、後で再開される可能性があります（ABAPセッションのデタッチ/アタッチを含む）。
次の図は、AMQPクライアントの単純な相互作用モデルを示しています。接続設定は、WebSocket/TCPソケット接続設定とAMQP接続ハンドシェイクの2つのステップで構成されます。接続が正常にセットアップされると、イベントハンドラーON_OPENが実行されます。クライアントはAMQPセッションを開き、メッセージの送信用と受信用の2つのリンクを接続します。次に、クライアントはメッセージを送受信し、最後に接続を閉じます。、、、、、およびメソッドの確認応答は、関連OPENするイベントハンドラー、、、、、、およびによって処理されます。受信したメッセージは、BEGINATTACHSENDCLOSEON_OPENON_BEGINON_ATTACHON_SENDON_CLOSEON_MESSAGEハンドラ。一部のアクションにより、追加のアクションとイベントが発生する場合があります。たとえば、送信者リンクが接続された後、受信者は通常、送信者にクレジットを付与します。これにより、ON_FLOW_CHANGEイベントが発生します。接続のACLOSEは、すべてのAMQPリンクも切り離し、すべてのAMQPセッションを終了します。したがって、対応するイベントON_DETACHとON_ENDイベントが発生します。
QoSを使用してメッセージを送信する場合、最大1回、イベントハンドラーON_SENDがローカルで実行され、sendメソッドの処理が成功した直後に実行されます。
QoSが少なくとも1回の着信メッセージの場合、ABAPアプリケーションサーバは確認応答（AMQPディスポジションフレーム）をピアに送信する必要があります。これは、ON_MESSAGEハンドラーメソッドが正常に実行された後、サーバーインフラストラクチャによって自動的に実行されます。
着信メッセージと確認応答を処理するには、ABAPセッションがアイドル/待機状態である必要があります。この状態は、UIインタラクション（PBO / PAI）などの暗黙的に開始することも、ABAPWAITステートメントを使用して明示的に開始することもできます。イベントハンドラメソッドは、それぞれのABAPセッションがアイドル状態または待機中になるとすぐに実行されます。
上記のAMQPフレームの処理とは対照的に、接続キープアライブ用の空のAMQP転送フレームは、ABAPサーバインフラストラクチャによって完全に処理され、ABAPAMQPAPIに公開されません。ABAPサーバは、ABAPセッションを使用せずにこれらのフレームを送受信します。代わりに、それらはInternet Communication Manager（ICM）によってのみ処理されます。接続の維持の時間間隔は、接続が確立されたときにAMQP接続ごとに構成できます。
AMQPクライアント接続のライフサイクルは、AMQPクライアントオブジェクトにバインドされます。アプリケーションが到達不能になった場合（最後の参照がクリアされたため）、ABAPガベージコレクタはオブジェクトを破棄し、接続を閉じる可能性があります。さらに、他のABAPリソースと同様に、AMQPクライアント接続は埋め込みABAPセッションのライフサイクルにバインドされます。したがって、エラーやダンプなど、ABAPセッションの終了につながるアクションは、AMQP接続をすぐに閉じます。
