参加
最後オンライン
最近の投稿
BASISに投稿されました 続きを読む

このトピックでは、NetWeaver ABAP Platformの変更管理システム(Change Management System,CMS)の仕組みを取り上げて説明します。 変更管理システムと移送管理システムを合わせて、CTS(Change Transport Systemo)と呼ばれています。

バージョン管理

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

バージョンの種類

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

開発データベース上のバージョン

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

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

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

バージョンデータベース上のバージョン

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

カテゴリ内容説明
““依頼がリリースされた時点で登録されたバージョン
Iインポート中に登録されたバージョン
Sシステム依頼 ( 修正または仮修正に取り込む前のバックアップコピー用など)により登録されたバージョン
U任意の時点で ( 中間バージョンとして) ユーザ依頼により登録されたバージョン。依頼がリリースされるとこれらのバージョンは削除され、“ “ バージョンと置換されます。

バージョンの登録

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

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

バージョンの照会、使用

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

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

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

依頼タイプ

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

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

依頼ステータス

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

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

タスク

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

  • 修正
  • 仮修正

依頼の作成

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

依頼へのオブジェクトの取り込み

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

  • 完全自動 
    変更は自動的に依頼に記録されます。 プログラムやテーブル構造などの変更はこのパターンに分類されます。
  • マニュアル
    オブジェクトを変更するトランザクションの一つの機能として動作します。 以下のようなオブジェクトはこのパターンに分類されます。
    • テーブルデータ SE16 データブラウザ画面で「テーブルエントリ→エントリ転送」機能を利用
    • 翻訳 SLXT
    • ロール PPFG
  • 完全マニュアル
    変更対象オブジェクトのオブジェクトディレクトリを指定、全てのオブジェクトはこの方法で依頼に記録することができます。
  • SE01 移送オーガナイザ
    以下の機能が含められています。
    • 依頼の登録、削除、マージ、属性変更、リリース及び一覧照会など
      オブジェクトの編集により、依頼を登録することもできます
    • タスクの登録、削除、属性変更、リリース及び一覧照会など
      オブジェクトの編集により、依頼にタスクを登録することもできます
    • オブジェクトの追加、削除、バージョンの照会など
      オブジェクトの編集により、自動的に追加されることがあります。
  • SE03 移送オーガナイザツール

BASISに投稿されました 続きを読む

このトピックでは、NetWeaver ABAP Platformの移送管理システム(Transport Management System,TMS)の仕組みを取り上げて説明します。

移送管理システムの構成

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

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

移送ドメイン

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

移送ドメインコントローラ

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

移送グループ

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

移送ディレクトリ

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

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

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

BASISに投稿されました 続きを読む

このトピックでは、NetWeaver ABAPリリース7.0 (SAP NetWeaver 2004s)以降から導入された新しいテクニックの拡張フレームワークを取り上げてそれぞれ説明します。

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

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

Enhacement Spot

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

Enhancement Implementaion

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

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による拡張仕掛けを作成

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

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

明示的Enhancement Optionによる拡張仕掛けを作成

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

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

BASISに投稿されました 続きを読む

主な手順

準備

オブジェクトキーの入手

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

オブジェクト修正

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

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

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

移送

BASISに投稿されました 続きを読む

カスタマ開発に利用できる標準機能の抜粋を以下の表で示します。 おもに以下のように分類することができます。

  • ABAPディクショナリ 
  • コーディング 
  • テスト 
  • バッチインプット 
  • JOB 
  • 分析 
  • 外部OSコマンド 
  • 帳票/レポート系 
Trcd機能目的
GRR3レポートペインタ照会レポートペインタを照会、テスト実行できる。(登録がGRR1,変更がGRR2)
SAAB有効化可能なブレークポイント関連性のあるプログラムのテストをまとめて実行するために定義できる。
SAMTABAP プログラム一括処理パッケージ(旧名称:開発クラス)の登録をすることができる
SCOVABAP カバレージアナライザ-
SCIコードインスペクタコーディング規約(独自設定可能)チェックや、代表的なパフォーマンスに問題がある記述方法などのチェックをすることができる
SCIIコードインスペクタ: インスペクションコードインスペクタを手っ取り早く使いたいときはコチラ
SE21パッケージビルダパッケージ(旧名称:開発クラス)の登録をすることができる
SE24クラスビルダ-
SE30実行時間分析分析ツール
SE33汎用モジュールビルダ-
SE37汎用モジュールビルダ-
SE38ABAPエディタ-
SE39ABAP画面分割エディタ--
SE41メニューペインタ-
SE43分野メニュー-
SE51スクリーンペインタ-
SE55拡張テーブル更新モジュール生成-
SE63翻訳未翻訳の部分や翻訳が間違っている場合、また独自のテキストに変更したい場合、翻訳機能を使用する。ただし、翻訳した後にサポートパッケージやnoteなどを適用した場合、標準の文字列に戻ってしまう場合もある。翻訳したテキストを移送したい場合、プログラム:RSLTEXPOから移送依頼を作成する(RSLTEXPOのウィザードを使用した場合、移送する対象のテキスト~移送依頼作成~エクスポートまで自動的におこなうので注意)
SE71フォームペインタSAPSCRIPTで帳票のフォームを作成できる。
SE80ABAPワークベンチプログラムIDに関係するオブジェクトをまとめて管理できる
SE81アプリケーション階層:照会-
SE84リポジトリ情報システム-
SE91メッセージ更新メッセージ更新 プログラムなどで使用/出力する定型メッセージを設定する。1つのメッセージクラスに1000個のメッセージが設定可能。
SE93トランザクション更新トランザクションコードを登録/変更することができる
SFPフォームビルダAdobe Acrobat(PDF)を使用したインタラクティブフォーム(Interactive forms )やPDF-Based Printを定義することができる。
SHD0トランザクション/画面バリアントトランザクションバリアントの管理
SHDBトランザクションレコーダ別名:バッチインプットレコーダ。トランザクションを実行する動作を記録し、バッチインプットセッションやプログラムを作ることができる。
SM35バッチインプット:セッション一覧記録したバッチインプットセクションを管理。実行/エラー照会など管理できる
SM35Pバッチインプット:ログ一覧-
smartformssmartforms-
SMATABAPプログラムセット処理関連性のあるプログラムのテストをまとめて実行することができる。拡張構文チェックなどをプログラムセット(条件を指定したグループ)でまとめてチェックすることができる
SNRO番号範囲オブジェクト更新番号範囲オブジェクトの定義をすることができる
SQVIクイックビューアSAPクエリの個人用。INNER JOINレベルまでのテーブル結合が可能。SAPクエリのサブセット版のような位置付け
S_ALR_87101287-ABAP言語コマンド検索のための統計プログラム分析
RPR_ABAP_SOURCE_SCANABAPレポートソーススキャン指定した文字列をプログラムから検索することができる
RSANAL00ABAPプログラム分析変数の型変換や変数一覧、サブルーチン、使用している汎用モジュールやインクルードプログラム、参照しているテーブルなどを分析してくれる。1行が72文字を超える行があるとショートダンプが発生するため、4.6より後に使えることはあまりないかも
RSABAPSC-バージョン管理: オブジェクト一覧によるリモート比較
RSVCAD11--

BASISに投稿されました 続きを読む

ABAPプログラムはリポジトリオブジェクトであり、リポジトリ情報システムに登録されます。

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

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

Dynpro画面を持つことができるのは、タイプ1、タイプ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 : サブルーチン

BASISに投稿されました 続きを読む

ABAPディクショナリは、データベーステーブルの他にアプリケーションの中に取り扱うデータも含め、SapECCシステムで使用されているすべてのデータ定義を一元的に管理するリポジトリです。 SAP標準だけでなく、ユーザ定義のデータ型もABAPディクショナリに登録されます。 ABAPディクショナリで管理されるオブジェクトタイプは大きく分けると、データ型定義、データベースオブジェクト及びツール関連の三つに分類することができます、その中に最も重要なのはそれぞれ以下のものがあります。

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

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

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

ドメイン

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

データエレメント

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

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

Noテーブル項目データエレメントドメイン技術タイプ
1VBRK(請求書:ヘッダデータ)VBELN(請求伝票)VBELN_VF(請求伝票)VBELN(販売管理伝票番号)CHAR(10)
2VBRP(請求伝票: 明細データ)VBELN(請求伝票)
3AUBEL(販売伝票)VBELN_VA (販売伝票)
4VBAK(販売伝票:ヘッダデータ)VBELN(販売伝票)

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

構造

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

テーブルデータ

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

テーブル

テーブルタイプ

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

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

  3. クラスタテーブル
    クラスタテーブルとは、例:「BSEG」会計伝票明細のようにテーブルクラスタに割り当てられたテーブルのことです。テーブルクラスタには、複数クラスタテーブルが割り当てられ、DB上は、テーブルクラスタにデータが登録されています。

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

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

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

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

出荷クラス

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

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

出荷クラス説明
Aアプリケーションテーブル (マスタ及びトランザクションデータ)
Cカスタマテーブル。データを更新するのはカスタマのみです。
L一時データ保管用テーブル
Gカスタマテーブル。SAP が新規データレコードを挿入する場合がありますが、既存データレコードは上書きまたは削除されません。カスタマ名称領域をテーブル TRESC で定義する必要があります
Eシステムテーブル。カスタマ入力のための独自の名称領域があります。カスタマ名称領域をテーブル TRESC で定義する必要があります
Sシステムテーブル。データ変更のステータスは、プログラム変更と同一です
Wシステムテーブル。データは独自の移送オブジェクト (たとえば、R3TR、PROG、R3TR TABL など) を使用して移送されます

技術設定

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

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

ビュー

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

索引

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

検索ヘルプ

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

ロックオブジェクト

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

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

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

BASISに投稿されました 続きを読む

リポジトリ情報システムには、プログラム、データベーステーブルの定義、共通データ型の定義などのすべての開発オブジェクトが含まれます。 このため、開発オブジェクトはリポジトリオブジェクトとも呼ばれます。 リポジトリオブジェクトはクライアントには依存しません。そのため、すべてのクライアントで照会と利用が可能です。

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

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

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

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

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

リポジトリオブジェクトの分類

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

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

オブジェクトディレクトリ

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

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

カテゴリ完全オブジェクトサブオブジェクト
総合DEVC(パッケージ)-
ABAPディクショナリTABL(テーブル)TABD(テーブル定義)
TABT(テーブルの技術属性)
TTYD(テーブルデータ型定義)
TTYX(テーブルデータ型定義のテキスト)
INDX(テーブル索引)
TABU(テーブル内容)-
VIEW(ビュー)VIED(ビュー定義)
VIET(ビュー技術属性)
DTEL(データエレメント)DTED(データエレメント定義)
DOMA(ドメイン)DOMD(ドメイン定義)
SHLP(検索ヘルプ)-
ENQU(ロックオブジェクト)ENQD(ロックオブジェクト定義)
プログラムPROG(プログラム)REPS(レポートソースプログラム)
REPT(レポートテキスト)
VARI(レポートプログラムのシステムバリアント)
VARX(レポートプログラムのアプリケーションバリアント)
FUGR(汎用グループ)FUGT(汎用グループテキスト)
FUNC(汎用モジュール)
CLAS(クラス)CLSD(クラス定義)
CINC(クラスインクルード)
CPRI(クラスプライベットヘッダ)
CPRO(クラス保護ヘッダ)
CPUB(クラスパブリックヘッダ)
METH(メソッド)
INTF(インタフェース)INTD(インタフェース)
STVI(トランザクションバリアント)-
SCVI(画面バリアント)-
ENHC(複合拡張実装)-
ENHO(拡張実装)-
ENHS(拡張スポット)-
WDYN(WebDynproコンポネント)WDYC(コントローラ)
WDYD(定義)
WDYV(ビュー)

BASISに投稿されました 続きを読む

このトピックでは、以下の特徴から、NetWeaver ABAP Platformのデータベース・テクノロジーを説明します。

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

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

出荷クラス主に格納されるデータ
システムテーブルプログラムといった開発オブジェク等
制御ロジックロジック制御情報等
カスタマイジングテーブルビジネス設定情報等
アプリケーションテーブルマスタやトランザクションといった業務データ等

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

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

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

クライアント番号用途
000SAP標準クライアント
001ドイツ版のカスタマイズサンプル
066アーリーウォッチ用クライアント

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

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

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

DB 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の終了に伴い、自動的に解放されます。

SAP LUW

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

SAP LUWの終了

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

SAP LUWの原子性

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

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

 

SAP LUWの単位

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

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

SAP LUWとDB LUW

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

一方、SAP LUWは論理的な単位を提供しています、SAP LUWにおける各更新依頼は、結局、DB LUWによりデータの変更をデータベースに反映しないといけないですが、そのDB LUWは新たに生成されるものではなく、更新依頼が実行されるワークプロセスの固有のDB LUWとなります。そのDB LUWで発行された別の即時DB更新がもしあれば、同時にコミットされます、なお、エラーが発生する場合も、一緒にロールバックされることになります。

BASISに投稿されました 続きを読む

このトピックでは、NetWeaver ABAP Platformのプレゼンテーション・テクノロジーを説明します。

ABAPプログラムの画面技術は、後からWEB対応のWebDynproも追加されましたが、従来からDynproを使ってきました。SapECCシステムで利用されている標準画面は、全てDynproで構成されています。 Dynpro画面はSapGUIウィンドウに表示されます。SapGUIは、SapECCシステムへのユーザインタフェースです。SapGUIはABAPアプリケーションサーバと通信し、ABAPアプリケーションからレスポンスされたプレゼンテーションを表示し、またユーザからの入力を処理し、そのアクションをABAPアプリケーションへリクエストします。

SapGUIウィンドウ

一般的な SapGUIウィンドウは以下のようなUIパーツから構成されます。

  • メニューバー
  • システム機能バー
  • 表題バー
  • アプリケーションバー
  • Dynpro領域
  • ステータスバー

下記の図でSapGUIウィンドウのレイアウト構成を示します。

Dynproの構成要素

Dynproは主に、Dynpro属性、画面レイアウト、エレメント一覧、PBO、PAIから構成されます。

  • Dynpro属性
    Dynproが持つ基本情報です。Dynpro番号、Dynproタイプ(標準・従属画面・ダイアログボックス・選択画面)、後続Dynproなどがあります。
  • 画面レイアウト
    画面のレイアウト情報です。各UIエレメントの位置やサイズを定義します。
  • エレメント一覧
    Dynproが持っている各UIエレメントの詳細です。
  • PBO
    Process Before Output、Dynpro画面が表示される前の処理を行う処理ブロックです。
  • PAI
    Process After Input、Dynpro画面が表示され、ユーザがアクションを行った後の処理を行う処理ブロックです。

NetWearver ABAP Platformは、ABAPアプリケーション内に独自のスプールリングおよび印刷システムを提供しています。これはすべての印刷機能への統一的なインタフェースとなっています。

プリンタとの接続形式

ABAPアプリケーションとプリンタの接続形式には以下の3つの方法があります。

  • アプリケーションサーバのローカル接続 (アクセス方法 L, C)
  • lpd hostを経由したリモート接続 (アクセス方法 U)
  • PC と SAPlpdを経由したリモート接続 (アクセス方法 U or P)

ABAPアプリケーションのスプール管理は「トランザクションコード:SPAD」から管理・定義が可能です。

印刷処理の流れ

SapECCにおける印刷は、以下のステップを使用します。 1.ユーザが生成された出力の印刷を要求すると、その要求はスプールシステムに送信されます。この処理は、スプール要求の生成と呼ばれます。 2.スプール要求は、プリンタと印刷形式の指定とともに、スプールデータベースに格納されます。 3.データを印刷するために、スプール・ワーク・プロセスが処理するスプール要求のための印刷要求が生成されます。 4.スプールワークプロセスは、印刷のためにデータを整形し、印刷要求をWindowsスプールシステムに渡します。 5.Windowsスプールシステムがプリンタキュー管理を引き継ぎ、データが適切な出力デバイスに渡され、印刷されるようにします。