MQTT接続ごとに次のAPC接続タイプがサポートされています。
- WebSockets：MQTT接続は、IETF標準RFC6455に従ってWebSocket接続の上に確立されます。
- TCPソケット：MQTT接続は、ネイティブTCP/IP接続を介して確立されます。
アプリケーションプログラマーの観点からは、使用されるAPC接続タイプは接続セットアップ中にのみ異なります。したがって、MQTTクライアントABAP APIでは、MQTTクライアントオブジェクトを作成するためのファクトリメソッドの対応する使用法によって、異なる接続タイプが決定されます。
MQTTプロトコルは、メッセージを公開するための3つのサービス品質（QoS）レベルを定義します。
- QoS 0（「最大で1回の配信」）：メッセージは最も手頃な価格で公開されます。
- QoS 1（「少なくとも1回の配信」）：メッセージの公開には確認応答が必要です。
- QoS 2（「正確に1回の配信」）：メッセージの公開には確認応答が必要です。保存されたメッセージの状態を破棄するには、重複を避けるために個別の確認応答が必要です。
ABAPアプリケーションサーバーは、QoS0とQoS1のみをサポートします。
メッセージングの場合、APIは基盤となるAPC接続タイプに依存しません。MQTTクライアントの場合、APCクライアントの場合と同様のイベント駆動型プログラミングモデルが提供されます。アプリケーションは次のイベントを処理できます。
すべての通信ステップ（たとえば、メッセージの公開、ON_MESSAGEイベント）は「同期点」です。これの意味は：
- DBコミットがトリガーされます。
- 実行が中断され、後で再開される可能性があります（ABAPセッションのデタッチ/アタッチを含む）。
次の図は、MQTTクライアントの単純な相互作用モデルを示しています。接続設定は、WebSocket/TCPソケット接続設定とMQTT接続ハンドシェイクの2つのステップで構成されます。接続が正常にセットアップされると、イベントハンドラーON_CONNECTが実行されます。クライアントは、特定のトピックをサブスクライブおよびサブスクライブ解除し、メッセージを公開および受信し、最後にサーバーから切断します。、、、およびメソッドの確認応答は、PUBLISH関連するイベントハンドラー、、、、およびによって処理されます。受信したメッセージはハンドラーによって処理されます。SUBSCRIBEUNSUBSCRIBEDISCONNECTON_PUBLISHON_SUBSCRIBEON_UNSUBSCRIBEON_ DISCONNECTON_MESSAGE
QoS 1の着信メッセージの場合、ABAPアプリケーションサーバは確認応答パケット（MQTT PUBACK）をブローカに送信する必要があります。ON_MESSAGEこれは、ハンドラーメソッドが正常に実行された後、サーバーインフラストラクチャによって自動的に実行されます。
着信メッセージと確認応答を処理するには、ABAPセッションがアイドル/待機状態である必要があります。この状態は、UIインタラクション（PBO / PAI）などの暗黙的に開始することも、ABAPWAITステートメントを使用して明示的に開始することもできます。イベントハンドラメソッドは、それぞれのABAPセッションがアイドル状態または待機中になるとすぐに実行されます。
上記のMQTTパケットの処理とは対照的に、接続キープアライブのパケット、つまりMQTTPINGREQとMQTTPINGRESPは、ABAPサーバーインフラストラクチャによって完全に処理されます。これらのMQTTパケットは、ABAPMQTTAPIに公開されません。ABAPサーバーは、ABAPセッションを使用せずに、これらのパケットを送受信します。代わりに、それらはInternet Communication Manager（ICM）によってのみ処理されます。接続キープアライブの時間間隔は、接続が確立されたときにMQTT接続ごとに構成できます。
MQTTクライアント接続のライフサイクルは、MQTTクライアントオブジェクトにバインドされています。アプリケーションが到達不能になった場合（最後の参照がクリアされたため）、ABAPガベージコレクタはオブジェクトを破棄し、接続を閉じる可能性があります。さらに、他のABAPリソースと同様に、MQTTクライアント接続は埋め込みABAPセッションのライフサイクルにバインドされます。したがって、エラーやダンプなど、ABAPセッションの終了につながるアクションは、MQTT接続をすぐに閉じます。
