アプリケーションサーバ 

R/3 プログラムはアプリケーションサーバ上で実行します。アプリケーションサーバは、R/3 システムの重要なコンポーネントの1 つです。以下の各セクションで、アプリケーションサーバについて詳しく説明します。

アプリケーションサーバの構造

R/3 システムのアプリケーション層は、アプリケーションサーバとメッセージサーバで構成されます。R/3 システムのアプリケーションプログラムはアプリケーションサーバ上で実行します。アプリケーションサーバは、プレゼンテーションコンポーネント、データベースと通信します。アプリケーションサーバ同士で通信する場合は、メッセージサーバを使用します。

次の図に、アプリケーションサーバの構造を示します。

次に、個別のコンポーネントについて説明します。

ワークプロセス

アプリケーションサーバには、アプリケーションを実行できるワークプロセスが組み込まれています。各ワークプロセスは、実行中のアプリケーションのコンテキストを格納しているメモリ領域にリンクしています。このコンテキストには、アプリケーションプログラムの最新データが含まれています。これは、各ダイアログステップで使用できなければなりません。さまざまなタイプのワークプロセスの追加情報は、この文書の後半に記載されています。

ディスパッチャ

各アプリケーションサーバにはディスパッチャが組み込まれています。ディスパッチャとは、ワークプロセスと、アプリケーションサーバにログオンしたユーザ間のリンクです。ディスパッチャは、ダイアログステップに対するリクエストを SAPgui から受け取って、それを空いているワークプロセスに転送します。同じ方法で、ダイアログステップの結果である画面出力を適切なユーザに返します。

ゲートウェイ

各アプリケーションサーバにはゲートウェイが組み込まれています。ゲートウェイは、R/3 通信プロトコル (RFC 、CPI/C) のインタフェースです。ゲートウェイは、同じ R/3 システム内の他のアプリケーションサーバと通信したり、他の R/3 システム、R/2 システム、または非 SAP システムと通信したりすることができます。

ここで説明するアプリケーションサーバの構造によって、R/3 システム全体のパフォーマンスとスケーラビリティが向上します。ワークプロセス数を一定させ、ダイアログステップをディスパッチすることで、メモリ使用が最適化されます。これは、特定のコンポーネントとワークプロセスのメモリ領域はアプリケーションに依存せず、再使用可能なためです。個々のワークプロセスは単独で動作するため、マルチプロセッサアーキテクチャに適しています。ディスパッチャがワークプロセスにタスクを分配する方法については、セクション ダイアログステップのディスパッチで詳しく説明します。

共有メモリ

アプリケーションサーバ上のすべてのワークプロセスは、共有メモリと呼ばれる共通のメインメモリ領域を使用して、コンテキストの保存や固定データのローカルバッファリングに対応しています。

すべてのワークプロセスが使用するリソース ( プログラムやテーブル内容など) は共有メモリに格納されています。R/3 システムのメモリ管理により、ワークプロセスは常に正しいコンテキスト、つまり、実行中のプログラムの現在の状態に関連するデータを確実にアドレス指定します。マッピングプロセスは、ダイアログステップに必要なコンテキストを共有メモリから関連ワークプロセスのアドレスに投入します。これによって、実際のコピー作業が最小限に抑えられます。

アプリケーションサーバの共有メモリ内でデータをローカルにバッファリングすることで、データベースの必須読取回数が減少します。したがって、アプリケーションプログラムのアクセス回数が大幅に減少します。バッファの使用を最適化するために、個別アプリケーション ( 財務会計、ロジスティクス、人事管理) を別々のアプリケーションサーバグループに集約することができます。

データベース接続

R/3 システムを起動すると、各アプリケーションサーバはワークプロセスをデータベース層に登録し、専用の単一チャネルを受け取ります。システムが実行している間、各ワークプロセスはデータベースシステム ( サーバ) のユーザ ( クライアント) になります。ワークプロセスの登録は、システムの実行中に変更することはできません。また、1 つのワークプロセスから別のワークプロセスにデータベースチャネルの割当を変更することもできません。このため、ワークプロセスは、 単一のデータベース作業論理単位 (LUW) 内でデータベースを変更できるだけです。データベース LUW は、分離不可能なデータベース操作の順序です。これは、以下に説明するプログラミングモデルにとって重要な意味を持っています。

ダイアログステップのディスパッチ

アプリケーションサーバにログオンするユーザ数が、使用可能なワークプロセス数を上回ることがよくあります。さらに、R/3 システムのアーキテクチャによる制限が設けられていません。その上、各ユーザは複数のアプリケーションを同時に実行することができます。ディスパッチャは、アプリケーションサーバ上のワークプロセス間ですべてのダイアログステップを分配するという重要なタスクを実行します。

次の図に、この仕組みを例をあげて示します。

...

       1.      ディスパッチャは、ユーザ 1 からダイアログステップ実行リクエストを受け取り、それを、たまたま空いているワークプロセス 1 に転送します。そのワークプロセスは、アプリケーションプログラムのコンテキスト ( 共有メモリに保存) をアドレス指定して、ダイアログステップを実行します。ワークプロセスは、再び空きになります。

       2.      ディスパッチャは、ユーザ 2 からダイアログステップ実行リクエストを受け取り、それを、再び空きになったワークプロセス 1 に転送します。そのワークプロセスは、ステップ 1 と同様にダイアログステップを実行します。

       3.      ワークプロセス 1 が稼動している間に、ディスパッチャはユーザ 1 から次のリクエストを受け取り、それを空いているワークプロセス 2 に転送します。

       4.      ワークプロセス 1 および 2 がそれぞれダイアログステップの処理を終了したあとで、ディスパッチャはユーザ 1 から別のリクエストを受け取り、それを再び空きになったワークプロセス 1 に転送します。

       5.      ワークプロセス 1 が稼動している間に、ディスパッチャはユーザ 2 から次のリクエストを受け取り、それを空いているワークプロセス 2 に転送します。

以上の例から、以下のことがわかります。

ｷ        プログラムからのダイアログステップは、実行のために 1 つのワークプロセスに割り当てられます。

ｷ        プログラムの個別ダイアログステップはそれぞれ異なるワークプロセスで実行できるため、新規ワークプロセスごとにプログラムコンテキストをアドレス指定する必要があります。

ｷ        1 つのワークプロセスで、複数のユーザからの異なるプログラムのダイアログステップを実行することができます。

この例では、ディスパッチャが、アプリケーションで連続ダイアログステップに同じワークプロセスができるだけ多く使われるように、リクエストをワークプロセスに分配しようとしていることは示されていません。ダイアログステップが実行されるたびにアドレス指定しなければならないプログラムコンテキストが保存されるため、これは効果的な処理方法です。

ディスパッチおよびプログラミングモデル

アプリケーション層とプレゼンテーション層を分離するために、アプリケーションプログラムをダイアログステップに分割する必要が生じました。この点と、ダイアログステップが個別のワークプロセスにディスパッチされるという事実は、プログラミングモデルにとって重要な意味を持っています。

前述したように、ワークプロセスは、単一のデータベース作業論理単位 (LUW) 内のみでデータベースを変更できます。データベース LUW は、分離不可能なデータベース操作の順序です。データベースの内容は、最初と最後で整合性が維持されていなければなりません。データベース LUW の最初と最後は、データベースシステムに対するコミットコマンド ( データベースコミット) によって定義されます。データベース LUW の動作中、つまり、2 つのデータベースコミットの間は、データベースシステム自身がデータベース内の整合性を保証します。つまり、データベースは、編集中にデータベースエントリをロックしたり、ステップがエラーを発生して強制終了した場合に旧データをリストアする ( ロールバック) などのタスクを継承します。

標準的な SAP アプリケーションプログラムは複数の画面と、それに対応するダイアログステップにわたって展開します。各画面でユーザが要求するデータベース変更によって、画面がすべて処理されたあとでデータベースの一貫性が確保されます。ただし、個別のダイアログステップは複数のワークプロセスで実行されます。また、1 つのワークプロセスは別のアプリケーションのダイアログステップを処理することができます。2 つ以上の独立したアプリケーションのダイアログステップがたまたま同じワークプロセスで処理された場合でも、それらのアプリケーションが同じデータベース LUW を使って稼動することはありません。

したがって、ワークプロセスはダイアログステップごとに異なるデータベース LUW を開かなければなりません。ワークプロセスは、データベース変更を行ったダイアログステップごとに、そのダイアログステップの終わりにコミットコマンド ( データベースコミット) をデータベースに送信します。これらのコミットコマンドは明示的にアプリケーションプログラムに書き込まれないため、暗黙のデータベースコミットと呼ばれます。

このような暗黙のデータベースコミットでは、データベース LUW を最大で 1 つのダイアログステップに対してのみ開いておくことができます。したがって、データベース負荷、整流化、デッドロックが大幅に削減されて、多数のユーザが同じシステムを使用できるようになります。

ただし、この方法 (1 ダイアログステップ = 1 データベース LUW) が、ダイアログステップの技術的な分配によってではなく、アプリケーションプログラムの論理フローに応じてコミットやロールバックを実行するよう要求することに関して、どのように調整できるかについて問題が発生します。相互に依存するデータベース更新リクエストによって、複数のダイアログステップにわたって展開される論理単位がプログラム内に設定されます。この論理単位に関連するデータベース変更は、一括処理され、一括して取消できなければなりません。

SAP プログラミングモデルには、データベース更新を論理単位に一括することのできるバンドル手法が組み込まれています。論理的に関連付けられたデータベース操作群をバンドルする R/3 アプリケーションプログラムのセクションを SAP LUW といいます。データベース LUW とは異なり、SAP LUW には、データベース更新を含め、1 つの論理単位内のダイアログステップがすべて含まれています。