アプリケーションサーバABAP（AS ABAP）は、APC接続（WebSocketまたはTCPソケット）のメッセージを受信すると、（着信）メッセージを処理するためのABAPセッションを作成します。APC接続を受け入れると、ABAPセッションはこの接続にリンクされなくなります。代わりに、AS ABAPは、接続のピアからメッセージを受信するときに、（タイプAPCの）新しいABAPセッションを毎回作成します。AS ABAPは、APC接続を受け入れたセッションに対応する属性を使用してこのセッションを確立します（たとえば、同じクライアントで同じユーザーIDを使用）。
さらに、受け入れセッションからの一部の情報には引き続きアクセスできます（HTTPアップグレードリクエストなど）。作成されると、ASABAPはこのセッションのON_MESSAGEイベントをトリガします。
このイベントを処理した後、ABAPセッションは削除されます。つまり、次のことを意味します。
- APC接続の着信メッセージは、異なるABAPセッション内で並行して処理されます。
- RFCと同様に、APC要求は、特定の優先度とレート（つまり、並列要求の最大数）を使用してダイアログワークプロセス（DIA）で処理されます。
- メッセージの順序が保持される保証はありません。
- 1つのABAPセッション内のメッセージ処理中にエラーが発生した場合、他のセッションに影響を与えることはありません。
- ピアが接続を閉じる場合：
- ON_CLOSEイベントが作成され、新しいABAPセッションによって処理されます。
- すでに受信したすべてのメッセージが処理されます。これは、ON_CLOSEイベントと並行して発生する可能性があります。
- データの送信はできなくなりました。
次の図は、APCステートレスサーバーアプリケーションの単純な相互作用モデルを示しています。各着信メッセージは、専用のABAPセッションで処理されます。
セッションプーリング
パフォーマンスを向上させるために、ASABAPはABAPセッションをプールすることができます。これの意味は：
- ABAPセッションを削除する代わりに、「クリーンアップ」されてAPC接続固有のセッションプールに入れられます。
- メッセージを受信すると、プールされたABAPセッションが使用可能であれば使用されます。そうでない場合は、新しいABAPセッションが作成されます。
メッセージが以前にプールされたセッションで処理されるか、新しいABAPセッションで処理されるかに応じて、メッセージはアプリケーションに対して透過的であり、プログラムロジックに影響を与えません。
