【SAP技術者向け】トランザクションレコーダ（Tr:SHDB）でデータ入力を効率化する

トランザクションレコーダ（Tr:SHDB）では、SAP GUI上で操作した画面の動きをBDCデータとして記録することができる。
Tr:SHDBで記録した特定の入力パターンをBDCデータという構造として記録しておくことで、大量のデータ入力を行いたい場合などに、画面の動きを自動化してデータ入力を効率化することができる。

SAPでは、主にGUIを通じた繰返しデータ入力のことを指して「バッチインプット」という。

バッチインプットの仕組みを用いてSAPのデータ入力を効率化するツールをいくつかの会社が提供しているが、それらも画面の動きを記録したデータ構造（BDCデータ）を用いることを基本の枠組みとしている。

今回は、トランザクションレコーダ（Tr:SHDB）を用いた画面操作の記録方法、およびBDCデータの構造がどのようなものか、そしてバッチインプットへの活用方法について解説する。

トランザクションレコーダ（Tr:SHDB）でデータ入力を効率化

トランザクションレコーダ（Tr:SHDB）でデータ入力を効率化

Tr:SHDB実行手順

Tr:SHDBは以下の手順で実行し、トランザクションレコードを記録できる。

SHDB実行手順：
1．Tr:SHDBを実行する。
2．「新規記録」ボタンを押下
3．トランザクションレコード名を指定する。
4．実行対象のトランザクションコードを指定する。
5．トランザクションが呼び出されるので、記録したい画面の動きを手動で操作する。
6．手動で操作した内容が記録される。
7．手動記録内容を必要に応じて編集する。

トランザクションレコードはBDCデータ構造（後述）として記録される。
実行したトランザクションコード、どの画面でどの項目を入力し、どのようなコマンド（ボタン押下）をしたのかというのが、画面毎に記録される。

・補足：記録したトランザクションレコードの確認/編集方法
Tr:SHDBを実行した時の第一画面で、これまで記録を取ったレコード名が一覧で表示される。
必要に応じ照会・変更からBDCデータを編集する。

BDCデータの解説

以下はトランザクションレコーダーでBDCデータ構造として記録されたもの。
「原価センタ登録（Tr:KS01）を実行し、第一画面と第二画面の各項目に値を入力し、第二画面にて保存ボタンを押した」という操作を行った場合のレコードを例示している。

各部分に分解して解説する。

トランザクションコード

第1行目には実行対象のトランザクションが記載されている。
トランザクションコードが記載される場合、開始コードは「T」が設定される。

Dynpro画面

プログラムIDとDynpro番号により、どの画面上での操作であるかを示している。
この該当画面下で、どのような項目入力を行ったか、どのようなコマンドを入れたかがBDCデータとして表現される。

OKCODE

該当画面でどのようなボタン押下（ユーザコマンド）を行ったかを表す。
ユーザコマンドには全てコマンドのIDが割り当たっている。

コマンド例
・/00　Enterボタンの押下に対応するコマンド
・/BU　保存ボタンの押下に対応するコマンド
・/BACK　戻るボタンの押下に対応するコマンド

画面によってボタンの意味合いが変わる場合やボタンが存在しない場合もあるので、同じコマンドでも常に同じ動作であるとは限らない点に留意する必要がある。

今回の例では「/00」のコマンド実行で、原価センタ登録の第二画面に遷移する。
（項目値をすべて入力してから当該コマンドが実行される）

カーソル位置（フォーカス）

カーソル位置（フォーカス）をどこの項目に置くか指定する。
この場合はCSKSZ-KOKR（事業領域）にフォーカスが当たる。

実際にバッチインプットを組む際に「BDC_CURSOR」はあまり使わない。
Tr:SHDBで記録を取っても削ることが多い。

項目及び項目値

「項目名」の欄に「構造名-項目名」が記録され、「項目値」の欄に各項目に入力した値が記録される。

今回の例では、原価センタ登録の第一画面で指定する原価センタコードや有効開始終了日を入力するBDCデータとなっている。

バッチインプットの解説

BDCデータの使い方

BDCデータをTr:SHDBで取得した後、いくつかの方法で活用することができる。

①トランザクションレコードをバッチインプットツールのデータ入力のひな形に用いる
どの会社が提供しているツールを使用するかにもよるが、トランザクションレコード名をツールにインポートして入力ひな形のようにすることができる。
「項目値」の部分を変数化・マッピングし、エクセルで投入データを作成し、ツールにエクセルを読ませることで、所定画面の所定項目に次々と繰返しデータ投入をしてくれるというのが基本的な仕組み。

②ABAPプログラムでBDCデータを組む
プログラム中でBDCデータを組んで、CALL_TRANSACTIONに引き渡すという使い方ができる。
内部テーブルとして「BDCDATA」型を宣言し、そこに上述したような画面や項目値の指定を入れていく。
この場合は、プログラム実行の都度BDCデータを組むので、Tr:SHDBでレコードを取る必要は無いのだが、画面の動きの検証のために設計段階ではほぼ必ず動かすと思われる。

バッチインプット実行モード

組んだBDCデータを流す際に、バッチインプットの実行モードを指定できる。
主に3つのモードを使う。

実行モード
A：GUI画面を呼び出し、オンラインでバッチインプットを実行する。バックグラウンドではないので注意。
E：エラーがあった場合のみ、GUI画面を呼び出す。
N：すべてバックグラウンドで処理する。

オンラインのみで実行される前提のアドオンであれば「A」または「E」を指定しても良いが、基本的には「N」により実行する。
バッチインプット実行中のエラーで、エラー箇所が分からない場合、デバッグモードで「A」に切り替えて実行してみるケースはある。

コミット後続行フラグ

地味に重要なのが「コミット後続行フラグ」。
バッチインプットは通常、大量のマスタや伝票を投入したり上書きするために使用する。
同一オブジェクトを繰返し更新する場合、前回更新時のDBレコードロックが外れる前に同じオブジェクトを更新しようとすると、ロック状態によるエラーが発生する。（バッチインプットではありがちなエラー）
コミット後続行フラグを入れることで、更新とロックの解除を待ってから次のデータ投入に移るという動作にすることができ、ロックエラーを防止できる。

「Dynpro XXX に項目 YYY が存在しません」エラーの場合

BDCデータは主に、予め画面の動きを指定して繰返し動作させる場合に使用する。
しかし、場合によっては想定外のGUI動作をする場合があり、BDCデータに指定した以外の画面に遷移したり、項目が非活性になったりすることがある。

こうした場合に「Dynpro XXX に項目 YYY が存在しません」といったエラーが出る。

入力したパラメータ値の問題であったり、画面項目周りのカスタマイズ変更やEXIT変更があったり、あるいは単にバッチインプットの検証不足だったりが要因となる。

バッチインプットのメリット

上記のように組んだバッチインプット処理をバックグラウンドで動作させると、裏でGUIが動いて画面の動きに即したデータ入力を行う。GUIを介するので若干動作は遅いものの、バックグラウンドであれば描画処理等を省略するので、十分な速度は確保される。
RPAを用いた業務効率化もトレンドだが、GUIの中で完結する処理ならバッチインプットの方が速い。
また、画面の動きに即しているので（BAPIなどに渡す構造よりも）分かりやすいというメリットもある。