ワークプロセス 

ワークプロセスは、R/3 アプリケーションの個別のダイアログステップを実行します。次の 2 つのセクションでは、まずワークプロセスの構造について説明し、次に R/3 システムのさまざまなタイプのワークプロセスについて説明します。

ワークプロセスの構造

ワークプロセスは、アプリケーションプログラムのダイアログステップを実行します。ワークプロセスは、アプリケーションサーバのコンポーネントです。次の図に、ワークプロセスのコンポーネントを示します。

各ワークプロセスには、2 つのソフトウェアプロセッサと1 つのデータベースインタフェースが組み込まれています。

Dynpro プロセッサ

R/3 アプリケーションプログラミングでは、ユーザインタラクションと処理ロジックは区別されています。プログラミングの観点では、ユーザインタラクションは Dynpro により制御されます。Dynpro は、実際の入力マスクだけでなく、制御ロジックによって構成されています。Dynpro 制御ロジックによってユーザインタラクションの大部分が制御されます。R/3 ベーシスシステムには、Dynpro 制御ロジックをプログラミングするための特殊言語が組み込まれています。Dynpro プロセッサは Dynpro 制御ロジックを実行します。Dynpro プロセッサは、ディスパッチャを介してワークプロセスと SAPgui 間の通信を継承し、制御ロジック内のモジュールを呼び出して、項目内容が Dynpro から制御ロジックに確実に転送されるようにします。

ABAP プロセッサ

アプリケーションプログラムの実際の処理ロジックは、SAP 独自のプログラム言語であるABAP によって作成されます。ABAP プロセッサはアプリケーションプログラムの処理ロジックを実行して、データベースインタフェースと通信します。Dynpro プロセッサは、次に処理する Dynpro 制御ロジック のモジュールを ABAP プロセッサに通知します。次の図に、アプリケーションプログラムの実行時における Dynpro プロセッサと ABAP プロセッサ間のインタラクションを示します。

データベースインタフェース

データベースインタフェースは以下のサービスを提供します。

ｷ        ワークプロセスとデータベース間の接続の設定および終了

ｷ        データベーステーブルへのアクセス

ｷ        R/3 リポジトリオブジェクト (ABAP プログラム、Dynpro など) へのアクセス

ｷ        カタログ情報 (ABAP ディクショナリ) へのアクセス

ｷ        トランザクションの管理 ( コミットおよびロールバックの処理)

ｷ        アプリケーションサーバでのテーブルバッファ管理

次の図に、データベースインタフェースの各コンポーネントを示します。

この図では、データベースへのアクセス方法として、オープン SQL およびネイティブSQL という 2 つの方法があることを示しています。

オープン SQL 命令は、ABAP に完全に統合された標準SQL のサブセットです。オープン SQL 命令を使用して、R/3 インストレーションが使用しているデータベースシステムに関係なく、データにアクセスすることができます。オープン SQL は標準 SQL のデータ操作言語 (DML) 部分で構成されています。つまり、(SELECT 命令による) データの読込と (INSERT 、UPDATE 、DELETE 命令による) データの変更を行うことができます。標準 SQL のデータ定義言語 (DDL) とデータ制御言語 (DCL) 部分のタスクは、R/3 システムで ABAP ディクショナリと権限システムによって実行されます。これらはデータベースに関係なく、統一機能を提供し、さまざまなデータベースシステムに用意されている機能以外にも、各種機能が組み込まれています。

オープン SQL は、他のABAP 構成との組合せによってデータベースアクセスの簡略化と高速化を実現できる点で、標準SQL よりもまさっています。また、アプリケーションサーバ上に特定のテーブルをバッファリングして、データベースへの過剰なアクセスを防ぐこともできます。その場合には、データベースインタフェースがバッファとデータベースを比較します。バッファは、現在のワークプロセスのワークメモリに一部保存され、アプリケーションサーバ上のすべてのワークプロセスの共有メモリに一部保存されます。R/3 システムが複数のアプリケーションサーバにまたがって分散されている場合、さまざまなバッファのデータは、一定の間隔でバッファ管理によって同期化されます。データベースをバッファリングする際に、バッファ内のデータが常に最新であるとは限らない点に注意してください。したがって、めったに変更されないデータのみに対してバッファを使用してください。

ネイティブ SQL は ABAP にゆるやかに統合されているため、それぞれのデータベースシステムのプログラミングインタフェースに組み込まれているすべての機能にアクセスすることができます。オープン SQL 命令とは異なり、ネイティブ SQL 命令は、チェックや変換が行われない代わりに、データベースシステムに直接送信されます。ネイティブ SQL を使用するプログラムは、対象となるデータベースシステムに固有のものです。R/3 アプリケーションに組み込まれるネイティブ SQL は最小限に抑えられています。実際に、ネイティブ SQL は ( たとえば、ABAP ディクショナリのテーブル定義の登録または変更などのために) 少数のベーシスコンポーネントのみで使われます。

図中のデータベース依存層は、データベースシステム間の相違をデータベースインタフェースのその他の部分から見えないようします。ベーシスシステムをインストールする際に、適切な層を選択してください。SQL は標準化されているため、命令構文の相違はごくわずかです。ただし、命令の意味と動作は完全に標準化されていないため、これらの相違は大きい場合があります。ネイティブ SQL を使用する場合、データベース依存層の機能は最小になります。

ワークプロセスのタイプ

すべてのワークプロセスには前述したコンポーネントが組み込まれていますが、ワークプロセスは異なるタイプに分類することもできます。ワークプロセスのタイプによって、アプリケーションサーバで実行するタスクの種類が決まります。特定の技術属性セットは指定されません。個別のタスクは、ディスパッチャによってワークプロセスに分散されます。

R/3 システムを起動する前に、使用するワークプロセスの数とタイプを決定してください。ディスパッチャはワークプロセスを開始して、それぞれのタイプに相当するタスクのみを割り当てます。したがって、アプリケーションサーバでのリソースの使用を最適化できるようにワークプロセスを分散させることが可能です。

次の図でもアプリケーションサーバの構造を示しますが、今回は、ワークプロセスの各種タイプが含まれています。

 

 

以下に、各種ワークプロセスについて簡単に説明します。この文書の他のセクションでは、アプリケーションサーバの個別コンポーネントと R/3 システムについて詳しく説明しています。 

ダイアログワークプロセス

ダイアログワークプロセスは、ダイアログステップを実行するために、有効なユーザからのリクエストを処理します。

更新ワークプロセス

更新ワークプロセスはデータベース更新リクエストを実行します。更新リクエストは SAP LUW の一部であり、バックグラウンドでの処理のためにデータベース LUW 内のダイアログから生じるデータベース操作をバンドルしたものです。

バックグラウンドワークプロセス

バックグラウンドワークプロセスは、ユーザインタラクションなしで実行可能なプログラムを処理します ( バックグラウンドジョブ) 。

エンキューワークプロセス

エンキューワークプロセスは、共有メモリ領域内のロックテーブルを管理します。ロックテーブルには R/3 システム用の論理データベースロックが含まれており、SAP LUW コンセプトの重要な部分を担っています。R/3 システムでは、ロックテーブルを 1 つだけ使用することができます。したがって、エンキューワークプロセスを組み込んだアプリケーションサーバも 1 つだけ使用できます。

スプールワークプロセス

スプールワークプロセスは順次依頼処理をプリンタまたはイメージストアに渡します。各アプリケーションサーバには、複数のスプールワークプロセスを組み込むことができます。

アプリケーションサーバによって提供されるサービスは、そのワークプロセスのタイプによって決まります。1 つのアプリケーションサーバには、複数の機能を持たせることができます。たとえば、アプリケーションサーバにダイアログワークプロセスとエンキューワークプロセスが組み込まれている場合は、ダイアログサーバとエンキューサーバの双方の機能を持つことができます。

システムの実行中に、システム管理機能を使用してワークプロセスをダイアログモードまたはバックグラウンドモードに切り替えることができます。たとえば、昼間はダイアログワークプロセスの方がバックグラウンドワークプロセスよりも多く、夜間はその逆の場合には、R/3 システムを昼間と夜間の操作で切り替えることができます。