インフリー技術情報発信ブログ

フィールドシンボル 使ってみよう その３

さて、今回もフィールドシンボルを使ったソースコードの紹介です。

今回は、在庫履歴テーブルを基に、12か月分を横1行に並ぶように、値を編集するロジックです。

これには、「ASSIGN COMPONENT (変数) OF STRUCTURE （構造） TO （フィールドシンボル).」の命令を使用します。

（変数）には、フィールドシンボルに割り当てる（構造）の項目位置（左から何番目か）または項目IDを定義します。

（構造）には、フィールドシンボルに割り当てる構造そのものを設定します。

（フィールドシンボル）は、当然、割当先のフィールドシンボルです。

下記、ソースコードには、方法1と方法2で（変数）への値の設定方法を現しています。

どちらも結果は同じになります。

REPORT  zxxxxxxxxx.

* 品目マスタ保管場所セグメント: 履歴
TYPES: BEGIN OF typ_mardh,
         matnr TYPE mardh-matnr,
         lfmon TYPE mardh-lfmon,
         labst TYPE mardh-labst,
       END OF typ_mardh.

DATA: it_mardh TYPE STANDARD TABLE OF typ_mardh.
DATA: w_lfmon  TYPE mardh-lfmon.

TYPES: BEGIN OF typ_month,
         labst01 TYPE mardh-labst,
         labst02 TYPE mardh-labst,
         labst03 TYPE mardh-labst,
         labst04 TYPE mardh-labst,
         labst05 TYPE mardh-labst,
         labst06 TYPE mardh-labst,
         labst07 TYPE mardh-labst,
         labst08 TYPE mardh-labst,
         labst09 TYPE mardh-labst,
         labst10 TYPE mardh-labst,
         labst11 TYPE mardh-labst,
         labst12 TYPE mardh-labst,
        END OF typ_month.

DATA: st_month TYPE typ_month.
DATA: w_fld    TYPE dd03l-fieldname.

DATA: w_index  TYPE i.

FIELD-SYMBOLS <f_st> TYPE typ_mardh.
FIELD-SYMBOLS <f_itm>.

PARAMETERS p_matnr TYPE mard-matnr OBLIGATORY.
PARAMETERS p_werks TYPE mard-werks OBLIGATORY.
PARAMETERS p_lgort TYPE mard-lgort OBLIGATORY.

SELECT matnr lfmon labst
  FROM mardh
  INTO TABLE it_mardh
 WHERE matnr = p_matnr
   AND werks = p_werks
   AND lgort = p_lgort.

CHECK sy-subrc = 0.

* 方法1
DO 12 TIMES.

  ADD 1 TO w_index.
  w_lfmon = w_index.

  READ TABLE it_mardh ASSIGNING <f_st>
                      WITH KEY lfmon = w_lfmon.
  CHECK sy-subrc = 0.

  ASSIGN COMPONENT w_index OF STRUCTURE st_month TO <f_itm>.
  CHECK sy-subrc = 0.

  <f_itm> = <f_st>-labst.

ENDDO.

CLEAR: w_lfmon, st_month.
* 方法2
DO 12 TIMES.

  ADD 1 TO w_lfmon.

  READ TABLE it_mardh ASSIGNING <f_st>
                      WITH KEY lfmon = w_lfmon.
  CHECK sy-subrc = 0.

  CONCATENATE 'LABST' w_lfmon INTO w_fld.

  ASSIGN COMPONENT w_fld OF STRUCTURE st_month TO <f_itm>.
  CHECK sy-subrc = 0.

  <f_itm> = <f_st>-labst.

ENDDO.

フィールドシンボルのソースコード紹介は、今回で終了です。

さてさて、次回のテーマは・・・これから考えます

フィールドシンボル 使ってみよう その２

今回も、フィールドシンボルの使用例のご紹介です。

今回の使用例は、テーブルのデータを一括して抽出して、一覧表示する機能です。

選択画面で指定されたテーブルIDを基に、内部テーブル定義しフィールドシンボルに割り当てています。

フィールドシンボルを使ってみたいけど、よくわからないな。という方は、

ぜひ、前回と今回の使用例を使って、プログラムを組んで、デバッグしてみてください。

使用例：

Report XXXX.

DATA: REF_TAB   TYPE REF TO DATA.   "参照変数

FIELD-SYMBOLS: <TAB> TYPE TABLE.    "対象データ取得用内部テーブル

FIELD-SYMBOLS: <ST>.                "内部テーブルヘッダ

PARAMETERS: P_TABNM   TYPE DD03L-TABNAME   OBLIGATORY.

* Main Proc

START-OF-SELECTION.

*  内部テーブル定義

  CREATE DATA REF_TAB TYPE TABLE OF (P_TABNM).

  ASSIGN REF_TAB->* TO <TAB>.

* 対象データを取得

  SELECT *

    INTO CORRESPONDING FIELDS OF TABLE <TAB>

    FROM (P_TABNM).

* 取得したデータを一覧表示

  LOOP AT <TAB> ASSIGNING <ST>.

   WRITE / <ST>.

  ENDLOOP.

フィールドシンボル 使ってみよう その１

さて、今回は、フィールドシンボルの使用例です。

個人的にですが、私はABAPプログラムを組む際は、レンジテーブルを多用するタイプです。

好みがあるので、あまり使わない人もいるかも知れませんが、やっぱり便利さに負けて、

いつも使ってしまいます。

と、いうことで！今回はレンジテーブルに条件を追加するサブルーチンの紹介です。

レンジテーブルは、常に「Sign」「Option」「Low」「High」の4項目しかありません。

しかし、定義するときに、参照する項目が変わると、「Low」「High」の属性が応じて

変わってしまうので、レンジテーブルを多用する私にとっては、複数のレンジテーブル、

それぞれにレコードを追加するロジックを書くだけで、結構な量のStep数になってしまいかねません。

そこで！以下のようなサブルーチンを使って、処理を共通化させています。

どれだけ、有効化は、さだかではありませんが・・・

*----------------------------------------------------------------------*

*       レンジテーブルの編集

*----------------------------------------------------------------------*

*      -->U_SIGN     SIGN

*      -->U_OPTION   OPTION

*      -->U_LOW      LOW

*      -->U_HIGH     HIGH

*      <--LT_TABLE   レンジテーブル

*----------------------------------------------------------------------*

FORM EDIT_RANGE_TABLE  USING    U_SIGN

                                U_OPTION

                                U_LOW

                                U_HIGH

                       CHANGING LT_TABLE TYPE TABLE.

  DATA: L_RNG_HD    TYPE REF TO DATA, "参照

        L_CTR_ITEM  TYPE I.           "項目カウント

  FIELD-SYMBOLS: <LS_HD>,           "ヘッダ

                 <LS_ITM>.          "項目

* レンジテーブルの構造を参照したデータオブジェクトを作成

  CREATE DATA L_RNG_HD LIKE LINE OF LT_TABLE.

* データオブジェクト(内部テーブルのヘッダ領域)をフィールドシンボルに割り当て

  ASSIGN L_RNG_HD->* TO <LS_HD>.

* ヘッダ領域の項目分繰り返す（レンジテーブルは、絶対4項目なので4回固定）

* ループしない方法でも記述することは可能

  DO 4 TIMES.

    ADD 1 TO L_CTR_ITEM.

*   ヘッダ領域の項目を左から順にフィールドシンボルに割り当てる

    ASSIGN COMPONENT L_CTR_ITEM OF STRUCTURE <LS_HD> TO <LS_ITM>.

    CASE L_CTR_ITEM.

      WHEN 1. "Sign

        MOVE U_SIGN   TO <LS_ITM>.

      WHEN 2. "Option

        MOVE U_OPTION TO <LS_ITM>.

      WHEN 3. "Low

        MOVE U_LOW    TO <LS_ITM>.

      WHEN 4. "High

        MOVE U_HIGH   TO <LS_ITM>.

    ENDCASE.

  ENDDO.

* レンジテーブルにレコードを追加

  APPEND <LS_HD> TO LT_TABLE.

ENDFORM.                    " EDIT_RANGE_TABLE

興味があれば、使ってみてください。

フィールドシンボル

前回、フィールドシンボルが登場したので、

今回からはフィールドシンボルについて、数回書いていこうかと思います。

フィールドシンボルとは、物理的なメモリを占有せずに、任意の変数（単一変数、構造、内部テーブルなど）に

割り当てる(Assign)ことで、任意の変数を指し示すことができます。

たとえば。。。。

Data w_a Type C.

Field-Symbols: <FS>.

Assign w_a To <FS>.

 <FS> = 'X'.

write: / <FS>,

/ w_a.

上記の処理結果は、以下のようにABAP一覧が表示されます。

　X

　X

フィールドシンボル<FS>は、変数w_aが割り当てられているため、

<FS>の値を変化させると、w_aへも同様の変更が適用されるのです。

フィールドシンボルの属性は、指定することが可能ですが、

指定しない場合は、割り当てられた変数の属性を継承します。

次回は、フィールドシンボルを利用した私がよく使うロジックを紹介したいと思います。

内部テーブル 3

今回も、内部テーブルについてです。

 

次回からは、別の話題にしたいと思います。

 

前回、内部テーブルのレコードを操作するためには、

『基本的』に作業領域に読み込み→値を編集→内部テーブルへ

反映のステップが必要です。と書き込みましたが、

 

内部テーブルのあるレコードを更新する場合に、限って

「作業領域に読み込み→値を編集」のステップで、

値を更新する方法があります。

 

それには、フィールドシンボルを使います。

フィールドシンボルとは、C言語でいうポインタのようなもので、

内部テーブルのあるレコードを直接参照することが可能になります。

 

例）Data: itab Type Standard Table of mara.

　　Field-symbols: <fs> type mara.

   Select *

      Into Table itab

    From mara.

　　Loop At itab assigning <fs>.

          <fs>-zitem = ‘X’.

    Endloop.

 

前回の「データベースから取得した内部テーブルの値を更新」を

フィールドシンボルを使った場合のソースです。

 

内部テーブルのレコード件数が、300件弱くらいまでは、

ほどんど「Modify命令」を使う場合とパフォーマンスは

変わらないらしいですが、それ以上の件数になると

フィールドシンボルを使ったほうがパフォーマンスが

よいらしいので、お試しあれ。

内部テーブル 2

今回も内部テーブルについてです。

　内部テーブルのレコードの追加・更新・読み込みには、決まった方法があります。

●     データベースから取得したレコードをまとめて格納

Ø         Select文で取得したレコードを直接格納

　

例）Data: itab Type Standard Table of mara.

                         Select *

                            Into Table itab

                            From mara.

 

●     内部テーブルのレコードを読み込む

Ø         Read 命令による1レコード読み込み

²        必ず作業領域を使用する

例）Data: itab Type Standard Table of mara.

　　Data: ist  Like line of itab.

                        Select *

                            Into Table itab

                            From mara.

              Read Table itab Into ist index 1.

Ø         Loop命令による順次読み込み

²        必ず作業領域を使用する

例）Data: itab Type Standard Table of mara.

　　Data: ist  Like line of itab.

                        Select *

                            Into Table itab

                            From mara.

　　Loop At itab Into ist.

      （処理）

       Endloop.

 

●     データベースから取得した1レコードを最終行に追加

Ø         Append命令で追加

²        必ず作業領域（ヘッダ）が必要

例）Data: itab Type Standard Table of mara.

                       Data: ist  Like line of itab.

Select *

                             Into ist

                            From mara.

                         Where Matnr = ‘a’

       Appned ist to itab.

 

●     データベースから取得した内部テーブルの値を更新

Ø         Modify 命令で更新

²        必ず作業領域を使用する

例）Data: itab Type Standard Table of mara.

　　Data: ist  Like line of itab.

                        Select *

                            Into Table itab

                            From mara.

　　Loop At itab Into ist.

          ist-zitem = ‘X’.

         Modify Table itab From ist.

       Endloop.

 

内部テーブルのレコード操作の基本は、以上です。

例 からわかるとおり、内部テーブルのレコードを操作するためには、基本的に、

作業領域に読み込み→値を編集→内部テーブルに反映のステップが必要です。

内部テーブル 1

今回は、内部テーブルについてです。

内部テーブルとは、プログラム内にて宣言するデータの一時保持用テーブルです。

Select命令でDBから取得したデータを一括して保持することが可能で、
ABAPプログラムは、この内部テーブルを中心にプログラムを
組み上げて行くといっても過言ではないほど、利用されます。

内部テーブルの宣言は・・・
DATA　itab TYPE (STANDARD) TABLE OF mara.

これで、「mara」という標準テーブルと同じ構造の内部テーブル「itab」が
使用可能になります。

「mara」の部分は、ディクショナリに登録されているテーブル、構造や
命令「Types」で宣言したローカル構造を指定します。

(STANDARD) の部分は、内部テーブルのタイプを示します。
タイプは３つあります。
Standard：スタンダードテーブル
　省略した場合は、スタンダードテーブルになります。
　個人的には、必ず明示するようにしています

Sorted：ソートテーブル
　内部テーブルの宣言と同時に、キー指定が必要です。
　キーは非一意も可能です。
　指定したキーで常に昇順ソートされてデータが保持されます。

Hashed：ハッシュテーブル
　内部テーブルの宣言と同時に、キー指定が必要です。
　キーは一意でなければなりません。
　ハッシュ関数によるランダムアクセスが可能になります。

通常、スタンダードテーブルが利用されることが多いですが、
ソートテーブルやハッシュテーブルを意識して使ってみるのも
面白いと思います。

OpenSQL

SAPは、様々なプラットフォーム上で稼動することが出来ます。
このプラットフォームの相違を吸収しているのが「ABAP VM」や
「OpenSQLアーキテクチャ」です。

今回は、OpenSQLのご紹介です。

OpenSQLとは、DBシステムに左右されずに同一の構文で、
SQLを発行することができます。
ABAP内ではSQLが発行されると、BASIS層のDBインターフェースを通じて、
個々のDBシステム用のSQL(NativeSQL)に変換されて処理が行われます。

　・OpenSQL 例）Select文

   　SELECT （抽出項目）
       INTO  (変数）
       FROM  (抽出テーブル）
     [WHERE    （条件）]
     [GROUP BY （項目）]
     [HAVING   （条件）]
     [ORDER BY （項目）].

OpenSQLの構文は、上記をご覧いただくとわかる通り、
特に特別な構文はほとんどありません。

ただし、「GROUP BY」や「[HAVING」「ORDER BY」は、
あまり使用されない傾向にあります。
「ORDER BY」については、ABAPのヘルプに、
データを抽出した後、ソート(Sort命令)を使用したほうが
パフォーマンスがよくなると記載されているくらいです。

このため、ABAPにおけるSQLは、単純にデータを抽出するのみで、
集計やソート、データのマージなどは、ABAPで行われることが
多いです。

ABAPのOpenSQLでは、内部テーブルを使用した構文が
特徴的だと思いますが、これは内部テーブルの話題の際に
触れたいと思います。

汎用モジュール

今回は、「汎用モジュール」について、紹介したいと思います。

汎用モジュールとは・・・・
　ある機能の塊を別プログラムから、呼び出せるようになっていて、
別の言語では、関数とかメソッドが近いかと思います。
　主に、共通機能をカプセル化したり、SAP外部からSAPに接続して、
処理を行いたいときとかに、開発対象となります。

汎用モジュールは、上記のとおり、一種の関数ですから、
当然、引数と戻り値が存在します。これらは、パラメータと呼ばれ、
4種類のパラメータが存在します。

1. Importパラメータ
　　　　・・・　引数です。別のプログラムから、汎用モジュールへ値を
　　　　　　　引き渡す際に使われます。
　　　　　　　構造体や、内部テーブルを用いて、1つのパラメータで、
　　　　　　　複数の値を引き渡すことが可能です。

2. Exportパラメータ
　　　　・・・　戻り値です。別のプログラムが、汎用モジュールから
　　　　　　　値を受け取る際に使われます。
　　　　　　　Imporｔパラメータと同様に、構造体や、内部テーブルを
　　　　　　　用いて、1つのパラメータで、複数の値を引き渡すことが可能です。

3. Tableパラメータ
　　　　・・・　引数としても、戻り値としても利用可能です。
　　　　　　　内部テーブルを用いてのみ、値の受け渡しが可能です。

4. Changingパラメータ
　　　　・・・　引数としても、戻り値としても利用可能です。
　　　　　　　Imporｔパラメータと同様に、構造体や、内部テーブルを
　　　　　　 用いて、1つのパラメータで、複数の値を引き渡すことが可能です。

最近のABAPでは、TableパラメータとChangingパラメータの
使用が、推奨されていません。TableパラメータとChangingパラメータを持つ、
汎用モジュールを作成しようとすると、警告がでて、「無効になった」と告げられます。
このため、基本的に、Importパラメータで値を引き渡し、Exportパラメータで
値を受け取ることになります。

　汎用モジュールに実装可能な処理に制限はなく、SAP標準データの更新、
アドオンテーブルの更新やDynproなど、組み込むことが可能である。

汎用モジュールの簡単な紹介は、ここまで。
では、また次回。。。

Dynpro

今回は、「Dynpro」について、紹介したいと思います。

 

Dynproとは・・・・

 Dynamic Programimg の略です。

　日本語に訳すと、動的プログラミング。

　動的・・ですが、みなさんが創造するような「動的」ではなく！

　画面の動作を制御するプログラムのことを示しています。

 

Dynproを構成するオブジェクトは・・・・

・ 画面

・ 制御ロジック

・ GUIステータス

・ GUI表題

 

　画面

　画面です。画面は、主に以下のオブジェクトを

　自由に配置して、ユーザインタフェースを構築します。

・　テキスト

・　入出力項目

・　ラジオボタン

・　チェックボックス

・　ボックス

・　テーブルコントロール

・　タブスリップコントロール

 

　制御ロジック

　　　画面の入力値のチェックや、出力値のセット、

　　　項目属性の変更や各種ボタンを押されたときの処理を

　　　記述します。

　　　大きく2つに分類されます。

　　　・PBO：　Process Before Output

　　　　　画面表示前の処理を指します。ここで、画面への値の

　　　　　出力や、属性変更等行います。

　　　・PAI：　Process After Input

　　　　　　画面入力後の処理を指します。ここでは、入力された

　　　　　　値のチェックや、ボタン毎の処理、例えば保存やスクロール　

　　　　　　など、を行います。

 

 　GUIステータス

 　　画面上部に表示するツールバーやメニューを定義します。

　　　ツールバーは、標準ツールバーとアプリケーションツールバーの

　　　2種類存在し、アプリケーションツールバーには、ある程度

　　　自由にカスタマイズできます。

 

 　GUI表題

　　　 画面タイトルです。PBOで、設定します。

 

以上、Dynproについて、簡単なご紹介でした。

では、また次回。。。