ABAPプッシュチャネル（APC）のアーキテクチャは、イベント駆動型プログラミングモデルを提供し、WebSocketまたはTCPソケット接続を使用して全二重通信を可能にします。
接続タイプ
ABAPプッシュチャネル（APC）テクノロジは、次の2つのAPC接続タイプをサポートします。
- WebSockets：IETF標準RFC6455に準拠したWebSocketプロトコルが通信に使用されます。
- TCPソケット：ネイティブTCP/IPパケットが通信に使用されます。
プログラミングモデル
これらの接続タイプを使用すると、さまざまなネットワーク層で通信を確立できます。どちらも全二重通信を提供します。このため、プログラミングモデルの観点からは類似しており、アプリケーション開発者に類似したAPIを提供できます。
両方のAPC接続タイプについて、Webブラウザーで使用可能なW3CWebSocketAPIに類似したイベント駆動型プログラミングモデルが確立されています。次のイベントは、アプリケーションで処理できます。
すべての通信ステップ（データの送信、ON_MESSAGEイベントなど）は「同期点」です。これの意味は：
- データベースのコミットがトリガーされます。
- 実行が中断され、後で再開される可能性があります（ABAPセッションのデタッチ/アタッチを含む）。
APC接続および対応するABAPセッションは、AS ABAPのリソース管理に統合されています（たとえば、エラー時の自動クリーンアップおよび接続またはセッションの削除）。
ステートフル通信とステートレス通信
接続タイプに関係なく、APCはさまざまな通信およびアプリケーションシナリオをサポートします。これらは、AS ABAP（クライアントまたはサーバー）の通信の役割と、アプリケーションのセッション処理が異なります。
クライアントとサーバーの役割の違いは、確立されたAPC接続の方向のみを指します。接続が受け入れられた後、メッセージを両方向に送信できます（全二重通信）。
AS ABAPがサーバとして機能する場合、APCアプリケーションは、受信したすべてのメッセージを同じABAPセッションで処理するか（ステートフル）、受信した各メッセージを新しいABAPセッションで処理する（ステートレス）ことができます。クライアントとして機能する場合、確立された接続は、作成中のABAPセッションにリンクされます（ステートフルAPCサーバーと同様）。さらに、APCは、作成中のABAPセッションからクライアント接続を切り離すサービスを提供します。そうすることで、各着信メッセージは、作成中のABAPセッションではなく、いわゆるAPCデタッチドクライアント（ステートレスまたはステートフル）のABAPセッションで処理されます。これにより、次のシナリオが発生します。
すべてのシナリオは、WebSocketとTCPソケットの両方でサポートされています。ただし、接続タイプに応じて、追加の機能と制限があります。
