SAP R / 3 Archi構造
編集チーム
⚡ スマートサマリー
SAP R / 3 Archiアーキテクチャは、プレゼンテーション、アプリケーション、データベースの責任を分離する 3 層のクライアント サーバー設計です。この記事では、各層、ABAP と Java コンポーネントスタック、ディスパッチャ駆動のログオンプロセス、および理由 SAP この階層型モデルを選択しました。
SAP R / 3 Archi構造はほぼすべての古典作品の基盤となっている SAP ERP の導入。以下のセクションでは、3 つの層がどのように相互作用し、ABAP と ERP がどのように連携するかを説明します。 Java スタックは、ディスパッチャとメッセージサーバー、およびデータベース間で処理を分割します。
何ですか SAP R/3ですか?
SAP R/3は、 3層アーキテクチャ 3つの独立した層から構成される：
- プレゼンテーション
- 用途
- データベース
- R の略 リアルタイム 処理。
- 3 は、 3層 建築様式。
ユーザーのPC（フロントエンド）： ユーザーはアクセスします SAP システムスルー SAP GUIまたはWebブラウザを使用します。ユーザーのマシンにはフロントエンドクライアントのみがインストールされ、アプリケーションサーバーとデータベースサーバーは専用ハードウェア上で別々に動作します。
アプリケーションサーバー: アプリケーションサーバーはビジネスロジックを実行します。ワークロードは複数のアプリケーションサーバーに分散されるため、負荷が高い場合でもユーザーはより迅速に応答を受け取ることができます。これらのサーバーは通常、ユーザーのワークステーションではなく、リモートインフラストラクチャ上で稼働します。
データベースサーバー: データベースサーバーは、 SQL ABAP によって生成されたクエリと Java アプリケーション。データベースとアプリケーションサービスは、容量要件に応じて、同じマシン上で実行することも、別々の物理ホスト上で実行することもできます。
どして SAP R/3は3層アーキテクチャを採用していますか？
プレゼンテーション、ビジネスロジック、ストレージを3つの独立した階層に分離することで、 SAP R/3は、単層または二層設計に比べて4つの実用的な利点があります。
- 独立した拡張性： 各レイヤーは個別にスケーリング可能です。データベースハードウェアに手を加えることなくアプリケーションサーバーを追加することで、ビジネスロジックのボトルネックを解消できます。
- ワークロードの分散: メッセージサーバーは、受信セッションをアプリケーションサーバー間で負荷分散することで、いずれかのサーバーが単一の競合ポイントとなることを防ぎます。
- データベース保護: エンドユーザーはデータベースに直接接続することはありません。すべての読み取りおよび書き込み操作は、アプリケーションサーバーのワークプロセスを経由し、認証チェック、ロック、トランザクションログ記録が標準化されます。
- Upgrade 柔軟性: その SAP GUI フロントエンドは進化する可能性がある (デスクトップ、ブラウザ、またはモバイル クライアントを介して) SAPアプリケーションやデータベースのコードを変更することなく、UI5）を利用できます。
この分離によって SAP 複数のデータベースバックエンドをサポートするため（以下を含む） SAP HANA, Oracle, IBM Db2、そして Microsoft SQL Server ―同じアプリケーションコードベースの下で。
SAP R/2対 SAP R/3: Archiテクトロジーが進化
SAP R/2はメインフレーム上で動作し、ユーザー端末がデータベースと直接通信する2層アーキテクチャを採用していました。1992年に発売されたR/3は、クライアントとデータベースの間に専用のアプリケーション層を挿入しました。この2つを並べて比較すると次のようになります。
| 側面 | SAP R / 2 | SAP R / 3 |
|---|---|---|
| Archi構造 | 2層構造（メインフレーム＋端末） | 3層構造（プレゼンテーション層＋アプリケーション層＋データベース層） |
| Hardware | 集中型メインフレーム | 分散型Unix / Windows / Linuxサーバー |
| 拡張性 | 垂直方向のみ（大型メインフレーム） | 水平方向（アプリケーションサーバーの追加） |
| データベースアクセス | ユーザーセッションから直接 | アプリケーションサーバーのワークプロセスによって媒介される |
| プログラミングモデル | ABAP/4のみ | ABAPと Java 並んで |
残りのセクションでは、R/3の3つのレイヤーそれぞれについて詳しく説明します。
異なる理解 SAP 層
図1：3つの SAP R/3レイヤーと、それらの間を流れるトラフィック。
プレゼンテーション層
その プレゼンテーション層 を構成するソフトウェアコンポーネントが含まれています SAP GUIとは、R/3システムのグラフィカルなフロントエンドのことです。システムとユーザー間のインターフェースとして機能し、データの入力と表示を直感的に行えるレイアウトを提供します。
このレイヤーはユーザー入力をアプリケーションサーバーに転送し、応答として受信したデータをレンダリングします。 SAP GUIが実行されている間は、そのセッションの間、R/3システム内のユーザーの端末セッションにリンクされたままになります。
アプリケーション層
その アプリケーション層 1 つ以上のアプリケーション サーバーと メッセージサーバー各アプリケーションサーバーは、R/3のビジネスロジックを実行する一連のサービスを実行します。理論的には単一のアプリケーションサーバーで十分ですが、実際には容量と冗長性を確保するために、サービスは複数のサーバーに分散されます。
メッセージサーバーはアプリケーションサーバー間の通信を調整します。リクエストを転送し、 tracksアプリケーションサーバーグループを生成し、ユーザーがログオンした際に現在の負荷に基づいて適切なサーバーを割り当てます。これが水平スケーリングを可能にする仕組みです。
データベースレイヤー
その データベースレイヤー R/3システムで使用されるすべてのデータを格納する中央データベースシステムが設置されています。データベーススタックは、データベース管理システム（DBMS）とデータベース自体の2つのコンポーネントで構成されています。 SAP 独自のDBMSを搭載し、 SAP HANAまた、主要な商用データベースもすべてサポートしています（Oracle, IBM Db2、 Microsoft SQL Server).
すべての R/3 データ (カスタマイズ設定、アプリケーション コード、画面定義、メニュー、関数モジュール、ランタイム データ) はこのデータベースに格納されます。プログラム コードと設計オブジェクトは、 R/3リポジトリこれらの「リポジトリオブジェクト」は、ABAPワークベンチがシステム間で読み書きおよび転送する対象です。
のコンポーネントを理解する SAP R/3 3層 Archi構造
図2：ABAP + Java 2つのスタックがどのようにインフラストラクチャを共有しているかを示すシステムアーキテクチャ。
モダン SAP NetWeaverインスタンスはABAPと Java スタック。以下のコンポーネントは、各スタックがゲートウェイ、ICM、およびJCOブリッジを共有してスタック間の通信を行いながら、独自のディスパッチ処理をどのように行うかを示しています。
| 成分 | スタック | 職種 |
|---|---|---|
| メッセージサーバー（ABAP） | ABAP | 分散ディスパッチャー間の通信を調整します。 ABAPシステム そして、インスタンス間で負荷を分散します。 |
| ディスパッチャーキュー | ABAP | Buffer 作業プロセスが空くまで、受信したリクエストを保留します。 |
| 発車係 | ABAP | キューからリクエストを取り出し、それぞれを適切なワークプロセスタイプに割り当てます。 |
| ABAPワークプロセス | ABAP | R/3アプリケーションでダイアログステップを実行します。タイプには、ダイアログ、更新、バックグラウンド、スプール、エンキューなどがあります。 |
| ゲートウェイ | 共有 | 通信を可能にする SAP システム間およびシステム間 SAP およびRFCを介した外部システム。 |
| メモリパイプ | 共有 | インターネット通信マネージャ（ICM）とABAPワークプロセス間でデータを転送します。 |
| メッセージサーバー（Java) | Java | 座標 Java ディスパッチャとサーバー プロセス。内部での通信を可能にする。 Java ランタイムクラスタ。 |
| エンキューサーバー | Java | 論理ロックを管理します Java サーバープロセス内で実行されるアプリケーションコード。 |
| 中央サービス | Java | 特別 Java ロックとプロセス間メッセージングを処理するクラスタインスタンス。「インスタンス」とは、リソース（メモリ、ワークプロセスなど）のグループのことです。 |
| Java 発車係 | Java | クライアントからのリクエストを受け取り、転送します。 Java サーバープロセス。 |
| SDM | Java | ソフトウェア展開マネージャー — J2EE コンポーネントをインストールします Java スタック。 |
| Java サーバープロセス | Java | マルチスレッド処理を用いて、多数のリクエストを同時に処理する。 |
| ICM | 共有 | インターネット通信マネージャー — HTTP、HTTPS、SMTP トラフィックを有効にします。 SAP ブラウザからアクセスできます。 |
| JCO | ブリッジ | Java コネクタ — 通信を処理します Java ディスパッチャとABAPディスパッチャは、両方のスタックが並行して実行される場合に使用されます。 |
図3：ABAPワークプロセスのカテゴリ（ダイアログ、更新、バックグラウンド、スプール、エンキュー）。
方法 SAP ログオンプロセスは機能しますか?
図4：ユーザーログオンのステップバイステップフロー SAP R/3ディスパッチャおよびワークプロセス層。
ステップ1） ユーザーがクリックすると SAP からのシステム SAP GUI; リクエストは転送されます ディスパッチャ.
ステップ2） リクエストは リクエストキューディスパッチャーは 先入先出 ルールを適用し、リクエストを次に利用可能な作業プロセスに割り当てます。
ステップ3） 適切なタイプのワークプロセスが割り当てられます。ログオンするユーザーにはダイアログワークプロセスが、バックグラウンドレポートにはバックグラウンドワークプロセスが、UPDATE文には更新ワークプロセスが割り当てられます。ワークプロセスの種類は、実行されるアクションによって決まります。
ステップ4） ダイアログ作業プロセスが割り当てられると、ユーザーの権限と現在の設定は 転がり込んできた ワークプロセスがユーザーのデータに対して動作できるように、共有メモリに渡されます。ダイアログステップが終了すると、そのデータは共有メモリに渡されます。 ロールアウト 次のユーザーのためにメモリを解放する。「ダイアログステップ」とは、トランザクション内で画面間を移動することを指します。
ステップ5） 作業プロセスはまずバッファ内で要求されたデータを探します。そこでデータを見つけることは、 ヒット また、データベースとの往復通信を回避し、応答時間を改善します。見つからない場合は、 ミス そしてデータベースの読み取り。高いヒット/ミス比率は、 SAP パフォーマンス。
ステップ6） 残りのデータはデータベースから照会され、結合された結果が返送されます。 SAP ディスパッチャを介したGUI。
ステップ7） ユーザーのセッションデータは、最終的に共有メモリから削除されます。 ロールアウトメモリ領域を解放して、次のリクエストに備えます。
リクエストの発生元がどこであっても、ユーザーとのやり取りごとに同じディスパッチャ → キュー → ワークプロセス → バッファ → ロールアウトのサイクルが繰り返されます。 SAP GUI、ICM経由のブラウザ、またはゲートウェイ経由の外部システム。
