権限とは、システムのユーザに、ある範囲のことを正当に行うことができるものとして与えられている能力、またその能力が及ぶ範囲のことです。

ユーザに付与される権限には、以下の情報が定められます。

• 対象
  権限でアクセス可能な対象(リソースや処理など)を定義します。
• 範囲
  対象に対してアクセス可能な範囲を定義します。例えば、対象がファイルなら、読み取りができるかどうか、書き込めるかどうか、アクセスされる範囲を制御できます。
• 期間
  権限の有効期間を指定します。

権限制御とは、システムが、各ユーザに対して、事前に付与された権限に従って、処理の実行やアクセスの範囲を制御することです。

権限制御は、通常、OSやデータベース、アプリケーションなど各分野でそれぞれ実施されます。

• OS
  アプリケーション、サービス、ファイルといったリソースのアクセス権限をユーザ・グループ毎に制御します。
• データベース
  テーブル、ビューといったデータベースオブジェクト単位で、ユーザ・グループ毎にデータの照会、更新、作成、削除の権限を制御します。
• アプリケーション
  アプリケーション側で必要に応じてビジネスレベルの権限制御を行います。

データベース側では、テーブルレベルのアクセス制御が仕組みに組み込まれているのは普通ですが、テーブルをさらに行レベルのアクセス制御をかけることは通常サポートされません。

例えば、各支店の売上データが格納されたテーブルがあるとします。各支店の従業員が所属支店のデータしか参照できないというセキュリティ要件はよくあるものですが、データベース側でカーバできないため、アプリケーション側で何らかの対応をしなければなりません。

NetWeaver ABAPは、アプリケーションレベルで独自の権限仕組みを導入ことにより、上記のビジネス要件に統合化したソリューションを提供します。

NetWeaver ABAPの権限制御を利用することにより、以下の機能を実現することができます。

• ユーザ(グループ)毎に各機能の実行可否を制御
  例えば、経理部の人を購買システムの機能を実行できないように権限制御をかけることができます。
• ユーザ(グループ)毎にアクセスデータ範囲を制御
  例として取り上げられた支店毎の制御をかけることができます。

NetWeaver ABAPの権限制御は以下の特徴があります。

• できることの積み上げ
  できることのみを定義でき、できないことの定義はできません。これはシンプルという利点もありますが、膨大になりがち、管理が大変になるというデメリットがあります。
• 言語レベルでサポート
  権限チェックするためのコマンド(authority-check) がABAP言語に組み込まれています。

Netweaver ABAPの権限コンセプトの構成要素は開発局面と運用局面に分けて整理することができます。

• 開発局面
  プログラムを実装する際に、機能のセキュリティ要件を元に、実行時にどうな権限チェックをかけないといけないかを設計して、そのロジックをプログラムに組み込んでおく必要があります。　
  このような権限チェックの内容と方法を定義するのは権限オブジェクトという構成要素になります。
  権限オブジェクトはコア要素であり、システムにより一元管理されます。
• 運用局面
  システムを構築する際に、 運用要件を元に、システムの利用者がどんな人いるか、どういうふうに権限をわけないといけないかを設計しておく必要があります。
  このような権限割当の単位を定義するのは権限プロファイルという構成要素になります。
  権限プロファイルに関連機能の権限オブジェクトの権限値が含められますので、機能にどんな権限オブジェクトがあるかを把握しておかなければなりません。
  ECC標準機能ではすでに数千の権限オブジェクトが組み込まれていますので、権限オブジェクトの把握は相当大変な作業になると想像できます。

権限オブジェクトとは、権限制御でチェックしなければならない項目及びチェック方法を示す要素です。 権限オブジェクトの上位要素としては権限クラス、下位要素としては権限項目があります。

• 権限クラス
  権限クラスは、権限オブジェクトの論理的な組合せで、たとえばアプリケーション(財務会計、人事管理など) に対応します。
• 権限項目
  権限項目は、権限オブジェクトに構成する項目です。ABAPディクショナリで保存されたデータエレメントﾄに接続されています。

権限オブジェクトは、AND で結合された項目を 10 個までグループﾟ化します。

権限オブジェクトが事前にプログラムロジックに組み込まれており、実行時に 実行可能なアクション(データの照会や登録、変更など)及び処理可能なデータの範囲を制御します。

権限とは、権限オブジェクトの定義、すなわち、権限オブジェクトの各権限項目の許容値を組合せたものです。 権限により、権限オブジェクト項目値のセットにもとづいて、ECCシステムで特定のアクティビティを実行することができます。 権限を使用することで、権限オブジェクトの項目に対して任意の数の指定値または値範囲を項目に対して指定することができます。また、すべての値を許可したり、空の項目を許容値として許可したりすることもできます。 権限を変更すると、その権限を含む権限プロファイルを持つすべてのユーザが影響を受けます。

権限プロファイルとは、権限の集合で、ユーザにまとめて権限を割り当てる単位です。権限プロファイルは下記3種類があります。

• 生成済権限プロファイル　
  生成済権限プロファイルは、ロールからロールの権限データで自動生成される権限プロファイルです。
• マニュアル権限プロファイル
  マニュアル権限プロファイルとは、 ロールを使わずに明示的に作成される権限プロファイルです
• 複合プロファイル
  複合プロファイルには、任意の数の権限プロファイルが含まれます。

以下の図で権限コンセプトを構成する各要素の関係を示します。

ロールは厳密的に権限コンセプトの構成要素ではないですが、内部的に生成済権限プロファイルを自動生成するため、権限プロファイルとして利用することができます。 さらに、ロールはユーザメニュ構成を定義する単位にもなりますので、実際のシステム運用ではロールを利用してユーザの権限を管理するはほとんどです。

リポジトリオブジェクトは変更履歴に対してバージョン管理ができます。

バージョンは開発データベース(リポジトリ)上のバージョンとバージョンデータベース上の履歴バージョンと2種類と大別されます。

開発データベース上では、MAXで「有効」と「修正」と2バージョンが存在います。

• 有効バージョン
  有効バージョンは現在のSAP環境に有効になっているバージョンというもので、端末に問わず、プログラムを実行する際に、このバージョンが利用されます。
• 修正バージョン
  修正バージョンは現在修正中のステータスが格納されます。

有効化すると、修正バージョンのステータスを持って有効バージョンが上書きされると同時に、修正バージョンが削除されます。 有効化した後に、再修正が発生しない限り、開発データベースに有効バージョンのみで、修正バージョンが存在しない状態になります。 修正バージョンでもすべてのユーザに見えます。

バージョンデータベース上のバージョンは以下のようなものがあります。

バージョンの登録はシステムによる自動登録とユーザによるマニュアル登録の2種類があります。

• システムによる自動登録
  バージョン管理の目的はリポジトリオブジェクトのすべての変更履歴を記録することです。 そのため以下のようなタイミングで自動的にバージョンが登録されます。
  • リポジトリオブジェクトが変更される前
    変更されたそれぞれのオブジェクトが変更依頼に入力された時点 バージョン管理の最新バージョンが有効でなければ、このオブジェクトのバージョンは、オブジェクトが変更される前にバージョン管理に保存されます。 このようなバックアップバージョンはバージョン概要に「 S 」 または 「 I 」で示されます。
  • 変更依頼のリリース時
    変更されたオブジェクトのある変更依頼をリリースすると、バージョンが登録されます。 依頼番号は関連バージョンのバージョン概要に表示されます。
• ユーザによるマニュアル登録
  自動的に登録されたバージョン以外にも、任意の時点で仮バージョンを登録することもできます。 それには、リポジトリオブジェクト更新トランザクションの バージョン登録機能を使用します。 また、これらの仮バージョンを使用して、仮バージョンが有効化された後でもオブジェクトの前バージョンを復元することもできます。 依頼がリリースされると、仮バージョンは削除され、その時点で有効なバージョンと置換されます。

バージョン管理機能は、オブジェクトナビゲータ ( SE80 )、移送オーガナイザ(SE01)といったトランザクションに組み込まれており、それを利用して下記のようなことができます。

• バージョンの一覧表示
• 指定バージョンの内容表示
• 指定された二つバージョンの比較

ローカルオブジェクトは変更履歴が取られない以外に、リポジトリオブジェクトの変更は全て変更依頼に記録されます。 変更依頼は依頼と略称することができ、必ずしも移送依頼に限ることがありません。

依頼は依頼タイプによって下記のように分類することができます。

• ローカル変更依頼
  ローカル変更依頼のリリースは、移送ファイルが作成されないため、移送は不可能です。
• 移送可能変更依頼(ワークベンチ依頼)
  リポジトリオブジェクトを変更すると、ワークベンチ依頼を指定するためのクエリウィンドウが表示されます。変更依頼にオブジェクトを割り当てている場合は、変更のみを保存することができます。　
  通常、ワークベンチ依頼とそのタスクは、全クライアントのリポジトリオブジェクトとカスタマイジングへの変更の記録に使用されます。ただし、クライアント依存カスタマイジングを取り込むこともできます。
  リポジトリオブジェクトへの変更を移送するかどうかは、そのオブジェクトのパッケージの現行 SAP システムからの移送ルートが定義されているかどうかによって決まります。このシステム設定から、変更依頼が移送可能か、また変更依頼がどの対象システムに移送されるかが自動的に判断されます。
• 移送可能変更依頼(カスタマイジング依頼)
  カスタマイジング依頼では、1クライアント(依頼のソースクライアント) で行われたクライアント依存のカスタマイジング設定が記録されます。
  クライアントのカスタマイジング作業での変更の自動記録は、クライアントごとに クライアント制御を使用して有効化または無効化することができます。自動記録が有効な場合は、カスタマイジング設定を変更するとクエリウィンドウが表示され、カスタマイジング依頼を指定するように要求されます。
  カスタマイジング依頼が移送されるかどうかは、ワークベンチ変更依頼と同様に、入力されるオブジェクトには 依存しません。 SAP システム ( 拡張移送制御を使用する場合はクライアント) のカスタマイジング依頼は、システム設定に応じてすべて移送可能またはすべてローカルになります。変更依頼が移送可能かどうか、移送可能な場合はどの対象システムに移動するかは、 標準移送レイヤ によって自動的に判断されます。ただし、この設定はマニュアルで変更できます。

修正可能かどうか、リリース済みかどうかによって、依頼ステータスが下記の二つに分けられます。

• 修正可能(未リリース)
• リリース済(修正不可)

タスクは依頼の下位要素であり、ユーザ名で表されます。 タスクタイプは下記の二つがあります。

• 修正
• 仮修正

SE01で移送オーガナイザで新たな移送依頼を登録することができます。 なお、プログラム改修などの場合、既存の依頼を選択や新たな依頼を作成するウィザードが提示される場合もあります。

依頼へのオブジェクトの取り込みは以下のようなパターンがあります。

• 完全自動　
  変更は自動的に依頼に記録されます。 プログラムやテーブル構造などの変更はこのパターンに分類されます。
• マニュアル
  オブジェクトを変更するトランザクションの一つの機能として動作します。 以下のようなオブジェクトはこのパターンに分類されます。
  • テーブルデータ SE16 データブラウザ画面で「テーブルエントリ→エントリ転送」機能を利用
  • 翻訳 SLXT
  • ロール PPFG
• 完全マニュアル
  変更対象オブジェクトのオブジェクトディレクトリを指定、全てのオブジェクトはこの方法で依頼に記録することができます。

• SE01 移送オーガナイザ
  以下の機能が含められています。
  • 依頼の登録、削除、マージ、属性変更、リリース及び一覧照会など
    オブジェクトの編集により、依頼を登録することもできます
  • タスクの登録、削除、属性変更、リリース及び一覧照会など
    オブジェクトの編集により、依頼にタスクを登録することもできます
  • オブジェクトの追加、削除、バージョンの照会など
    オブジェクトの編集により、自動的に追加されることがあります。
• SE03 移送オーガナイザツール

以下の図で、移送管理システムのモデル構成を示します。

このモデルでは、3階層ランドスケープが一つのドメインと二つの移送グループで構成されます。次にその構成要素をそれぞれ取り上げて詳しく説明します。

移送ドメイン(transport domain)は、移送を一元管理するすべてのABAPシステムで構成されます。移送ドメイン内では、すべてのシステムに一意のシステムIDを設定し、これらのシステムから1つのシステムのみが移送ドメインコントローラとして指定されます。 デフォルトの移送ドメイン名は DOMAIN_<SID> (<SID> はドメインコントローラのシステムID) で設定されます。 また、移送ドメインには、１つ以上の移送グループが含まれます。

移送ドメインコントローラ(transport domain controller)は、移送ルートや RFC 接続の設定など、移送ドメイン全体に関する設定を管理します。 通常は、本稼動システムまたは品質保証システムをドメインコントローラとして設定します。ドメインコントローラのシステム負荷は小さく、負荷が増えるのは TMS 設定変更時のわずかな時間だけです。 ドメインコントローラとしての役割をもつ ABAPシステムが稼動していないと、TMS 設定を変更することはできません。

移送グループとは、共通移送ディレクトリを共有する１つ以上のシステムで構成されるものです。

移送ディレクトリとは、移送データのファイルを保管するために移送グループで使用する共通ディレクトリのことです。 移送グループはこのディレクトリを使用して、すべてのエクスポートとインポートし、すべての移送はこのディレクトリで実行する必要があります。

移送ディレクトリのモデルサブディレクトリ構成は以下にようになります。 共通移送ディレクトリのサブディレクトリ

• bin
  tpとTMSの設定ファイル
• buffer
  各システムの移送バッファ
• data
  エクスポートされたデータ
• cofiles
  コマンドファイルまたは移送依頼情報ファイル
• log
  移送ログ、トレースファイル、統計。
• tmp
  一時データとログファイル
• actlog
  全タスクと全依頼のアクションログ
• sapnames
  各SAPユーザの移送依頼に属する情報
• EPS
  SAPサポートパッケージのダウンロードディレクトリ

移送ルート(Transport Route)は、ランドスケープを構成するSAPシステム（「開発システム」「検証システム」「本稼働システム」）間の移送順序を指定したものです。移送ルートは、コンソリデーションルートまたはデリバリルートのいずれかのタイプです。

標準的な3 システムランドスケープの移送ルートは以下のとおりです。

• コンソリデーションルート
  コンソリデーションルートは、開発システムと品質保証システムを接続します。。 自動的に作成される移送レイヤの名称は、Z<SID> (<SID> は開発システムのシステム ID)となります。
• デリバリルートは
  デリバリルートは、品質保証システムと本稼動システムの間に作成されます。

開発システムでは、コンソリデーションルートに対応する (標準) 移送レイヤとリンクしているパッケージのオブジェクトに変更を加えた場合、その変更は変更依頼に記録され、品質保証システムを経て本稼動システムに移送されます。

SAP社が提供するオブジェクト（＝標準オブジェクトと呼ぶ）への変更は、変更依頼に「仮修正」属性のタスクとして記録されます。この場合、移送レイヤとして“SAP”を使用することを除いて、他のオブジェクトの場合と同じ方法で移送することができます。

移送レイヤは、リポジトリオブジェクトの開発/変更を実施するシステムおよび、該当オブジェクトの移送先システム（品質保証システムや本運用システムなど）を定義します。

リポジトリオブジェクトは特定の「パッケージ」に属し、「パッケージ」に「移送レイヤ」が割り当てられます。

同じABAPシステムで開発され、同じ移送ルートで移送された開発プロジェクトは、すべてまとめられて 1 つの移送レイヤ となります。

各リポジトリオブジェクトのオブジェクトタイプには、以下のようなさまざまな移送属性があります。

リポジトリオブジェクトおよびクライアント非依存カスタマイジングオブジェクトがあります。

各リポジトリオブジェクトには、 オブジェクト・ディレクトリ・エントリがあります。移送属性もその中に登録されます。

オブジェクトを登録する時に、パッケージを指定するように要求されます。パッケージは移送レイヤに割り当てられます。 TMSで、現在のシステムからのコンソリデーションルートが移送レイヤに定義されていると、オブジェクトは移送可能な変更依頼のタスクに記録されます。 TMSで、現在のシステムからのコンソリデーションルートが移送レイヤに定義されていない場合、オブジェクトは ローカルな変更依頼に属するタスクに記録されます。

変更依頼が移送可能な場合、依頼の対象はオブジェクトのコンソリデーション対象と同じです。

オブジェクトのマスタシステムは、そのオブジェクトが登録されたオリジナルシステムであり、開発と修正のためのオブジェクトの編集もこのシステムで行います。

オブジェクトは、1 つのシステムにのみオリジナルが存在します。 SAPから提供されたオブジェクト の場合は、オリジナルのシステムはSAP側に保存されています。カスタマシステムにおけるSAP標準のオブジェクトはすべてコピーとなります。この原則は、開発システム、およびそれに続くすべてのシステムにも適用されます。

独自のアプリケーションを作成する場合には、作成するオブジェクトは、その開発システムに存在するものがオリジナルになります。 開発したものを変更依頼に割り当てる場合には、タイプを開発/修正となります。 この依頼によって、開発システムから次のシステムへオブジェクトが移送されます。

オリジナルに対して変更を加えることを修正といいます。 これらの変更は、タスクのタイプが開発/修正である変更依頼に記録されます。 コピー(オリジナルシステム以外のオブジェクト) に対して変更を加えると、その変更は、 仮修正のタスクに記録されます。 SAP オブジェクトに対する仮修正は、モディフィケーションと呼ば れます。

カスタマイジングオブジェクトのみです。

クライアント依存のカスタマイジングオブジェクトは、 カスタマイジング依頼に属するタスクに記録されます。 TMSで、現在のシステムからのコンソリデーションルートが現在のシステムまたはクライアントの標準移送レイヤに定義されている場合、オブジェクトは 移送可能なカスタマイジング依頼に属するタスクに記録されます。

TMSで、現在のシステムからのコンソリデーションルートがシステムまたは現在のクライアントの標準移送レイヤに定義されていない場合、オブジェクトは移送対象のないカスタマイジング依頼のタスクに記録されます。

NetWeaver ABAP Platformにおける変更はすべて依頼/タスクにより管理されます。変更が移送可能な場合に、依頼は変更の移送(リリース)単位となります。タスクは依頼よりも下位レベルに位置し、依頼のなかではユーザ名で表されます。

前述の移送管理システムのモデル構成を例として移送の流れを説明します。

1. 開発機DEVで依頼をリリース
   依頼の各タスクがリリースされたら、依頼自体もリリース可能になります。
   依頼がリリースされたら、移送分が移送ディレクトリにExportされます。
2. 品証機QTSTに移送をインポート
3. 移送を移送グループ１の移送ディレクトリから移送グループ2の移送ディレクトリにコピー
4. 品証機QAS2に移送をインポート
5. 本番機PRODに移送をインポート

• STMS 移送管理システム
  移送管理システム機能には以下の機能が含められています。
  • 移送ドメインにおけるSAPシステムの役割の定義
  • 移送ルートの設定
  • 移送ツールプログラム(tp)のパラメータプロファイルの設定
  • 移送ドメイン内のすべてのSAPシステムのインポートキューの表示
  • 品質保証システム（QA）の品質保証／承認手続の定義
  • インポートキューにある移送依頼のインポートのスケジュール
  • 共通移送ディレクトリを使用しない、システム間の移送の実行
• SE01 移送オーガナイザ(拡張ビュー)
  移送オーガナイザも変更オーガナイザもこの一つのトランザクションに統合されています。
• SE03 移送オーガナイザツール

拡張フレームワーク(Enhancement Framework)とは、、従来の拡張テクニック(カスタマExitやクラシックBAdiなど)をオブジェクト指向の手法で改良したフレームワークです。 拡張フレームワークでサポートされる拡張仕組は、「BAdiによるオブジェクトプラグイン」と「Enhancement Optionによるソースコードプラグイン」に大別します。 ここのBAdiは従来のクラシックBAdiと区別して、新規BAdiと呼ばれます。クラシックBAdiから新規BAdiに自動的に変換することができます。

拡張フレームワークを構成しているコンポーネントには下記のようなものがあります。 •Enhacement Spot •Enhancement Implementaion •Enhancement Option

Enhacement Spotは、拡張が実装できる位置を管理します。 オブジェクトプラグインとしてのEnhacement Spotは明示的に作成しなければならないほか、ソースコードプラグインとしてのEnhacement Spotは、Enhancement Optionを作成する際に一緒に作成されます。 オブジェクトプラグインEnhacement Spotの例ソースコードプラグインEnhacement Spotの例

Enhancement Implementaionは、拡張実装を表します。オブジェクトプラグインとしてのBAdiによる拡張実装と、ソースコードプラグインとしてのEnhancement Optionによる拡張実装とも含められます。

ソースコードプラグイン を記述する位置はEnhancement Option によって管理されています。 Enhancement Option には、「ソース中の位置」「拡張タイプ(動的/静的、Point/Section)」などの属性があります。

Enhancement Option には、明示的なものと暗黙的なものがあります。 暗黙的なものとは、すべてのリポジトリオブジェクトにあらかじめ組み込まれたもので、Enhancement Spot を必要としません。 明示的なものとは、開発者が独自に作成するもので、Enhacement Point文やEnhancement Section文などを使用し、明示的に作成位置を指定します。 Enhancement Point は「挿入型」の拡張で、指定した行位置に拡張コードが挿入されます。 Enhancement Section は「置換型」の拡張で、指定した行範囲のコードが拡張コードで置換されます。

拡張をサポートさせるには、拡張できるようにさせたいソースコードに事前に拡張の仕掛けを組み込む必要があります。 拡張フレームワークには以下三つの拡張方法が用意されています。

1. BAdiによる拡張
2. 明示的Enhancement　Optionによる拡張
3. 暗黙的Enhancement　Optionによる拡張

「暗黙的Enhancement　Optionによる拡張」は、サブルーチンや、汎用モジュールといったリポジトリオブジェクトのソース実装の開始及び終了の場所に全て予め組み込まれていますので、個別定義する必要がありません。

以下の手順で、BADIによる拡張仕掛けを作成することができます。

1. クラスビルダでBAdi用インタフェースを作成
2. Enhancement　Spotを作成
   SE80を利用します　
3. Enhancement　Spot　Defineを作成
   SE80を利用します
   Create BAdiを選択し、先ほど作成済のBAdi用インタフェースを指定
4. 拡張するソースコードにGET BADI、CALL　BADIを実装

以下の手順で、明示的Enhancement　Optionによる拡張仕掛けを作成することができます。

1. 拡張するソースコードにEnhancement-Point文又はEnhancement-Sectionを記述
2. 保存してウィザードに従いEnhancement　Optionを作成
   Enhancement　Optionを管理するEnhancement　Spotも同時に作成

オブジェクトキーの入手

対象となるオブジェクトの修正にはオブジェクトキーと呼ばれる特殊な キーワードが必要となります。

SE37やSE38、SE11などを利用して、オブジェクトを修正します。

次のようにオブジェクトキー要求があります。

このとき表示されるオブジェクト名を OSS で登録し、その結果取得された アクセスキーを入力します。 これはシステム（インストール）が異なると同じバージョンでも値が変わり ますので、毎回取得する必要があります。 また確認メッセージが表示されます。

外部リンク

• SAPソフトウェア変更登録 (SSCR) キーの登録(PDF)-SAP Help Portal

ABAPプログラムは以下のタイプがあります。

• タイプ1：レポートプログラム(公式では実行可能プログラムと呼ばれている)
• タイプM：ダイアログプログラム(公式ではモジュールプールと呼ばれている)
• タイプF：汎用グループ、汎用モジュールのコンテナとして、汎用モジュールを実装できる唯一のプログラムタイプ
• タイプK：クラスプール、クラス定義のコンテナ
• タイプJ：インタフェースプール、インタフェース定義のコンテナ
• タイプS：サブルーチンプール、サブルーチン用のコードコンテナ
• タイプT：タイププール、型定義のコンテナ
• タイプI：インクルードプログラム

Dynpro画面を持つことができるのは、タイプ１、タイプM、タイプFの三つのみです。

プログラムタイプによってプログラムの基本的な技術属性が決まるため、プログラム作成時にタイプを設定する必要があります。

ABAPプログラムは直接実行可能プログラムと直接実行不可能プログラムに分類されます。Windowsアプリケーション開発の世界でこれに相当するのはEXEとDLLの分類になります。

ABAPプログラムを直接実行するには、二つの方法があります。

• トランザクションコードによる実行　
  トランザクションコードにより実行可能なプログラムは、レポートプログラム(TYPE 1)、ダイアログプログラム(TYPE M)、汎用グループ(TYPE F)があります。
  プログラムでは、CALL TRANSACTION やLEAVE TO TRANSACTIONといった命令を使ってトランザクションを起動することができます。
• プログラム名による実行
  SA38又はSE38でプログラム名により実行可能なプログラムは、レポートプログラム(TYPE 1)のみになります。バックグランドでも実行できるのもこのタイプのみです。
  プログラムでは、SUBMIT命令を使ってレポートプログラムを起動することができます。

直接実行可能プログラムはアプリケーションプログラムとも呼ばれます。

直接実行不可能プログラムは、プログラミングでしか呼び出されることができません。タイプによって呼び出す命令はそれぞれです。

• CALL FUNCTION : 汎用モジュール
• CALL METHOD　 : クラスのメソッド　
• PERFORM : サブルーチン

• データ型定義：オブジェクトのデータ定義はABAPディクショナリにのみ存在する
  • ドメイン
  • データエレメント
  • 構造
  • テーブルデータ
• データベースオブジェクト：オブジェクトのデータ定義は基盤となるデータベースにも自動登録される
  • テーブル
  • ビュー
  • 索引
• ツール関連： Dynpro 項目の編集に使用されるツールも提供
  • 検索ヘルプ
  • ロックオブジェクト

ABAPディクショナリオブジェクトは、ABAPプログラムから参照できます。実行時にABAPプログラムがロードされる際に、動的にABAPディクショナリオブジェクトの定義を展開されます。

以下にて各オブジェクトタイプをそれぞれ説明します。

ドメインは項目の技術属性を定義するものであり、項目のデータ型と長さを指定することで項目の値範囲を記述します。 例として、「性別」のドメインの定義を次に示します。

• 参考サイト：SAP Portal Help--ドメイン

データエレメントは意味属性であり、同じ意味を持つデータ項目は同じデータエレメントに割り当てるべきです。

下記の例を利用して、データ項目、データエレメント、ドメインの関連関係を説明します。

上記のテーブルに示された四つのデータ項目とも10文字の伝票番号であるため、同じドメインのVBELNを割り当てられます。但し同じ伝票番号といっても、請求伝票の伝票番号と受注伝票の伝票番号と二種類があるため、データエレメントは二つに分かれることになります。同じデータエレメントのデータ項目であれば結合検索できます。

• 参考サイト：SAP Portal Help--データエレメント

構造は複数のコンポーネント(項目)で構成されます。構造を構成するコンポーネント(項目)は、基本データ型の他に別の構造やテーブルデータ型を参照することができます。

• 参考サイト：SAP Portal Help--構造

テーブルデータ型は、ABAPにおける内部テーブルをグローバルで定義します。

• 参考サイト：SAP Portal Help--テーブルデータ

ABAPディクショナリのテーブルには、3種類のテーブルタイプが存在します。

1. 透過テーブル
   例：「VBRK」KNA1(得意先マスタ)など、殆どのテーブルです。
   透過テーブルは名前の通り、ABAPディクショナリと同じ構造で、DBテーブルが登録されています。
2. プールテーブル
   例：「Annn」条件マスタや「T001T」カスタマイズテーブルなどなど、テーブルプールに割り当てられたテーブルのことです。テーブルプールには、複数プールテーブルが格納され、DB上は、テーブルプールにデータが登録されています。
   複数のプールテーブルのデータが、どのようにテーブルプールに登録されているかというとプールテーブルの1行1行が、それぞれテーブルプールの1行となっていて、内部結合ではなく、単純に複数のテーブルがまとまっているだけです。
   
   
3. クラスタテーブル
   クラスタテーブルとは、例：「BSEG」会計伝票明細のようにテーブルクラスタに割り当てられたテーブルのことです。テーブルクラスタには、複数クラスタテーブルが割り当てられ、DB上は、テーブルクラスタにデータが登録されています。
   
   

クラスタテーブルとプールテーブルは、透過テーブルと違って以下の特徴が存在します。

• NativeSQLでは使用できません。
• Select文で、外部結合・内部結合できません。
• キー項目以外の項目は、ほとんどが文字列結合された状態で1項目に登録されています。
• 上記理由により、キー以外の項目を抽出条件とするとパフォーマンス悪化の要因になります。

クラスタテーブルかプールテーブルかによって、プライマリキーがかさなっている複数テーブルが存在する場合、そのデータの登録方法は異なります。

• クラスタテーブル　
  プライマリキーで内部結合された状態で複数テーブルがまとまって登録されています。
• プールテーブル　
  プライマリキーで内部結合せず単純に複数テーブルがまとまって登録されています。

テーブルには出荷クラス属性をもっております。出荷クラスは、インストールやアップグレード、クライアントコピー、およびカスタマシステム間移送の際に、テーブルデータの移送を制御します。出荷クラスは、拡張テーブル更新でも使用されます。

以下の出荷クラスがあります。

ABAPディクショナリに透過テーブルを定義する際、技術設定を更新する必要があります。

• データクラス
  データクラスは、テーブルを格納するデータベースの物理領域 (ORACLE では表領域と呼ばれます) を論理的に定義したものです。データクラスを正しく選択すれば、テーブルを ABAPディクショナリで有効化したときに、そのテーブルがデータベースの正しい領域に自動的に登録されます。
  データクラスには、マスタデータ、トランザクションデータ、組織データ、およびシステムデータなどがあります。さらに、カスタマデータクラス (USER、USER1) と呼ばれるデータクラスもあります。これは、カスタマ開発に使用されます。データベースに特別な保管域を割り当てる必要があります。
  • マスタデータ　
    マスタデータは、ほとんど変更されることのないデータです。マスタデータの例としては、名称、住所、および電話番号など、住所のデータが挙げられます。
  • トランザクションデータ　
    トランザクションデータは、頻繁に変更されるデータです。たとえば、倉庫の在庫品目は購買発注が登録されるたびに変更されるデータです。
  • 組織データ
    組織データは、システムの導入時にカスタマイジングで定義され、その後はほとんど変更されることのないデータです。たとえば、国コードなどです。
  • システムデータ
    システムデータは、SapECCシステム自体が必要とするデータです。たとえば、プログラムソースなどです。
• 􀂄バッファリング
  テーブルのレコードをバッファに入れるかを定義します。
• サイズカテゴリ　
  テーブルの予想レコード数はいくつかを定義します。
• ログ記録　
  データレコードへの変更ログを記録するかを定義します。

• 参考サイト：SAP Portal Help--テーブル

ビューとは、1つ以上の実テーブル表から任意のデータを選択し、それらをカスタマイズして表した仮想テーブルのことです。

• 参考サイト：SAP Portal Help--ビュー

索引は、いくつかの項目に縮小されたデータベースのコピーということができます。索引を使用すると、特定の検索条件を満たすデータレコードをテーブルから検索することができます。

• 参考サイト：SAP Portal Help--索引

検索ヘルプは、入力ヘルプ (F4 ヘルプ) を定義するための ABAPディクショナリオブジェクトです。

• 参考サイト：SAP Portal Help--検索ヘルプ

DBトランザクションレベルの排他制御はデータベース管理システムが用意していますが、それとは別に、SapECCは、独自のロックオブジェクトに基づいてアプリケーションレベルの排他制御を実現しています。

ロックオブジェクトにはロックするテーブルとロックするレコードのキー項目情報が定義され、ロックオブジェクトを有効にすると、汎用モジュールENQUEUE_<ロックオブジェクト名>とDEQUEUE_<ロックオブジェクト名>がロックを設定 / 解除するためにその定義から生成されます。

ロック設定汎用モジュールから掛けられたロックの情報はロックテーブルに格納されます。ロックテーブルは、エンキューサーバのメインメモリに存在するテーブルであり、システム内の現在のロックを記録します。ロック設定汎用モジュールでロックを掛けようとする前に、まずロックテーブルを参照して同じロックが既に存在する場合、エラー終了したり、待ち状態にしたりすることによって、排他制御の仕組みを実現します。

• 参考サイト：SAP Portal Help--ロックオブジェクト

リポジトリに格納される全ての開発オブジェクトは、アプリケーションコンポーネント→パッケージ→開発オブジェクトというカテゴリ構造で管理されます。

アプリケーションコンポーネントはアプリケーション階層にツリー構造で表示されます。SE81でアプリケーション階層を照会することができます。

上記の図から馴染みのSDやMMなどのアプリケーションコンポーネント名称を読み取ることができます。アプリケーションコンポーネントは公式名称ですが、実際には別名の「モジュール」のほうがよく使用されています。

パッケージはリポジトリオブジェクトをカテゴリ化で管理できるようにする仕組みです。SE21(パッケージビルダ)でパッケージを照会又は定義することができます。 パッケージとは、意味的に関連する開発オブジェクトのコンテナであり、以前の開発クラスにかわったものです。1つのパッケージに、異なる開発オブジェクト(プログラム、テーブル、Dynpro、汎用モジュール、クラスなど)を含めることができます。。パッケージの特徴は、プロパティのネスト、インタフェース、可視性、およびアクセス管理にあります。。 パッケージはパッケージビルダ(トランザクションSPAK)を使用して作成および管理される。また、オブジェクト変更の記録と移送は、パッケージへの割当を使用する移送/修正システム(CTS)によっても管理されます。 以下の図でパッケージMBを例として取り上げます。

リポジトリオブジェクトはSE84(リポジトリ情報システム)で検索できます。

リポジトリオブジェクトは主に以下のような大分類があります。

• ビジネスオブジェクト
• ABAPディクショナリ
• プログラム
• クラス
• WebDynpro

オブジェクトディレクトリは、全てのリポジトリオブジェクトに基本属性情報を管理します。

リポジトリ情報システムに格納される各リポジトリオブジェクトはその種類の抜粋を下記の表で示します。

• ビジネスロジックもデータベース化
• クライアントによる論理分割
• ダイアログを跨る作業論理単位

NetWearver ABAP Platformでは、ビジネスデータのみではなく、ビジネスロジックが反映されたアプリケーション及びパラメータ設定情報そのものもデータベースで統合的に管理されます。 NetWearver ABAP Platformのデータベースにおけるテーブルは、出荷クラスによって以下のように分類されます。

SapECCシステムはクライアントによって論理的に分けられます。 実体となる1つのシステム上に、自由に複数のクライアントを定義できて、仮想的に複数のシステムが存在しているかのように扱うことができるのです。 各クライアントには、独自のデータ環境があり、すなわち、クライアントごとに独自のアプリケーションデータと殆どの設定データがあります。 あるクライアントに属するデータは、他のクライアントのユーザからアクセスできないような仕組みになっています。この仕組みを実現するためには、以下のような仕掛けが掛けられています

• クライアント依存テーブルに全てクライアント番号を第1PKとして持たせる
• OpenSQLによるDBアクセス処理で対象クライアント制御条件を裏で自動的に付加する

クライアントは3桁の数字で識別されます、インストール時のデフォルトクライアントは以下の通りです。

普通の意味では、アプリケーションの動作のうち、「ある意味を持った一連の処理のまとまり」のことをトランザクションといいます。そして、トランザクション制御とはこの一つのトランザクション内でデータの整合性が保たれるようにすることです。

SapECCでは、正式的な名称として、この「ある意味を持った一連の処理のまとまり」を「トランザクション」ではなく、「作業論理単位(Logical Unit of Work、略するとLUW)」と呼んでいます。関連がありますが、SapECCの「トランザクション」は、トランザクションコードを使用して開始するアプリケーションプログラムのことと定義されています。

SapECCでは、DBMSが実装済のトランザクション制御の他に、業務レベルの作業論理単位制御をサポートしています。この二つの制御は、それぞれDB LUWとSAP LUWに呼ばれます。

DB LUW は、データが常に整合性を持つようにするために、OracleやMSSQLなどのDBMS(データベース管理システム)が使用するメカニズムです。DBMS側では、一般的にこのDB LUWを「トランザクション」と呼びます。

SAPのDB LUWは、以下のように動作します。

• DB LUWは一つのワークプロセスの中に完結しなければなりません
• ワークプロセスが正常又は異常終了する際に、コミットされていないDB更新に対して、暗黙的なデータベースコミット又はロールバックを行います
• プログラムが汎用モジュールDB_COMMITを呼び出して明示的にデータベースコミットを行うことができます。
• プログラムがSAP LUWの命令（COMMIT WORK、ROLLBACK WORK）を呼び出してSAP LUWを終了する同時に、DB LUWも終了します。
• 開始されるときや、前のDB LUW がコミット又はロールバックで終了するときに、新しいDB LUWが開始されます。
• DB LUW内で実行されるDB変更はでDBロックを起こします、そのDBロックはLUWの終了に伴い、自動的に解放されます。

DB LUWはデータベースに対して分割できない連続したデータ上の操作であり、完全に終了するか、まったく実行しないかのいずれかにする必要があります。SAP LUWは、システムに対して分割できない業務処理であり、その業務処理全体を完了するか、あるいはまったく実行しないかのいずれかにする必要があります。SAP-LUW は通常、複数のダイアログステップや複数のDB LUW に及ぶことがあります。 同じSAP LUW で発生したDBデータ変更要求は、全て最後にデータベースに反映されることになります。

SAP LUWは、DB LUWのように暗黙的に終了することがありません。「COMMIT WORK」や「ROLLBACK　WORK」命令を発行して、明示的に終了させる必要があります。

一つのSAP LUWの中の各更新は複数のダイアログステップに跨って発行されることがよくありますが、発行時に即時に実行されるとすれば、別々のDB LUWのDBデータ操作になりますので、作業単位としての原子性が完全に崩れてしまうことになります。

NetWeaverABAPでは、それらの更新を即時実行せずに、「更新依頼」オブジェクトを登録しておきます。「commit work」命令でSAP LUWがコミットされる際に、登録された「更新依頼」を一つのDB LUWで実行することにより、作業単位としての原子性を維持します。

SAP LUW毎に、違う更新キーが割り当てられます、更新依頼はその更新キーと一緒に更新キューに登録されますので、それにより同じSAP LUWのものかどうかを判断できます。

アプリケーションプログラム( TYPE 1、TYPE M)はそれぞれ別のSAP LUWをもっています。但し、トランザクション(機能)ではなく、「ダイアログモジュール」として起動される場合は、呼び出し元のSAP　LUWで実行されることになります。

NetWeaverABAPではワークプロセスごとに、固定DB接続1 つが割り当てられています。そのDB接続でDB LUWが実行されますので、ワークプロセスは常に一つのDB LUWと結び付いております。