【SAPアドオン開発】アップロード機能で必要な処理etc

SAP,SEの日常SAP,PP,MM,アップロード,Fiori,ABAP

SAPの導入では、CSVやTSVといったテキストファイルをアップロードしてデータを登録/更新/削除できるようにしたいという要望を受けます。

そこで今回は、アップロード機能についてお話しします。

スポンサーリンク

アップロード機能が欲しいと言われる理由

SAPではマスタや伝票の登録/更新は、各項目を1つ1つ入力するのが基本です。しかしながら、ユーザの業務では数十個のデータ、時には100を超えるデータを1回で登録したり更新したりする場合があります。
数十個のデータをSAPの機能に合わせて1つ1つ手入力するのは、ユーザにとって大変な手間になります。

そのため、アップロード機能は業務上の手間を削減したいという目的で作られることが多いです。
例)品目マスタアップロード、発注アップロード等

また、アップロードするファイルを作成する方法として、「Excelにデータをまとめておくから、そこからコピペして簡単に作れるようにしたい」という要望もあったりします。

アップロード機能の実現方法

アップロード機能を実現するには主に以下の方法を採用することになるかと思います。
※各方法の詳細はここでは割愛します。

①バッチインプット
 Tr-Cd:SHDB(トランザクションレコーダ)を使用してデータ入力の画面上の操作を記録しておきます(記録したデータをBDCデータと言います)。BCDデータを基にデータの繰返し入力を可能にします。

② ABAPでのアドオン開発
 SAP GUI上で動作するアドオン機能をABAPで開発します。

③ Fiori
 FioriはSAP S/4HANAから使用することが出来るものです。詳細は割愛しますが、SAPをGoogle ChromeなどのWebブラウザから使用するようにしたものと思ってください。開発にはABAPに加えて、HTML/CSS/JavaScriptといったWeb系の技術が必要になります。

ユーザの利便性を考慮すると②または③の方法を採用し、対話型のアプリケーションを開発するのが良いかと思います(Fioriを採用しているのであれば③、Fioriを採用していなければ②)

以降、機能の概要をお話ししますが上記②または③を採用することを前提に解説します。

機能の概要

アップロード機能がどのようなものになるかを解説します。ここで解説するのはあくまで一例ですので、ユーザによって画面のレイアウトや仕様は異なりますが、基本的にはこれから解説するような仕様はユーザの利便性なども考慮すると必要になるかと思います。

画面構成

アップロード機能の画面構成としては以下のようなものになることが多いでしょう。
① アップロード画面
 アップロードファイルのパスを指定する欄、ファイルの形式と文字コードを選択するラジオボックス、実行ボタンというシンプルな画面レイアウトです。

(例)アップロード画面

② 処理結果画面
 処理した件数、成功した件数、失敗した件数を出力する画面です。エラー詳細画面に遷移できるように開発します。

(例)処理結果画面

③ エラー詳細画面
 エラーメッセージを出力する画面です。エラーメッセージの他に行数を出力して、アップロードファイルのどの行でエラーが発生したのかを分かるようにします。

(例)エラー詳細画面

ファイルレイアウト

アップロードファイルのレイアウトは基本的に1行1明細となります。また、必要な項目は以下のようなものになるかと思います。

・登録区分
 Iを指定したら登録、Uを指定したら更新、Dを指定したら削除というように、値によって処理方法を変えることが出来る項目です。

・マスタやトランザクションのキー項目 + 必須入力項目 + その他項目
 キー項目はチェック処理やデータの存在チェックなどに使用するため、必ず用意しておきます。
 また、マスタや伝票を登録する際に必ず入力が必要な項目も用意しておきます。
 そして、その他の項目として、業務上アップロードファイルに必要な項目をユーザと相談して用意します(拡張項目はここに含まれるイメージ)。

 購買発注伝票を例にすると、
 ・キー項目:購買伝票番号、明細
 ・必須項目:伝票タイプ、仕入先、会社コード、購買組織、購買グループ、プラント、品目コード、購買発注数量、納入期日 etc
 ・その他項目:拡張項目など

履歴管理のためのアドオンテーブル

アップロード機能では履歴管理を目的としてアドオンテーブルを作成することが多いです。
テーブルに保持する項目としては以下のような項目があります。
・機能IDやプログラムID等
・処理ステータス(Sだと成功、Eだと失敗等)
・アップロードファイルのデータ内容
・登録者/登録日時、更新者/更新日時
・エラーメッセージ
など

チェック仕様

データを更新するので当然ですが、入力内容に誤りがないか等のチェックを行います。以下のようなチェックは大体必要になると考えて良いでしょう

①ファイルの項目数チェック
 アップロードされたファイルの項目数が、想定した項目数と合っているかを確認します。

②必須チェック
 必須項目に値が設定されているかをチェックします。

③書式チェック
 データが定められた書式で設定されているかをチェックします。

 例えば、日付項目でyyyy/mm/ddの書式しか許容していないのに、yyyymmddでアップロードされたらエラーにするという感じです。

④データの存在チェック
 マスタの登録では、品目コードや仕入先コードなどのキー項目が同じデータを重複して登録することは不可となります。そのため、登録前にすでに登録されていないかを確認します。

 また、更新や削除を行う場合、対象のデータが無ければ処理を行えません。そのため、更新や削除処理の前にデータをSQLで抽出し、対象のデータが存在することを確認します。存在しなければ、次のデータの処理に移ったりします。

上記は代表的なチェック処理ですが、扱うデータによって他にもチェック処理を実装することがあります。

例えば、購買発注を登録するアップロード機能だと、伝票タイプが対象のものか
ユーザによって他のチェック処理も入ることがありますので要件を詰めていく中で確認していく必要があります。

チェックNGの場合の対応方法

入力データに不備がありチェックNGとなった場合には、主に以下2つの対応方法が考えられます

①チェックNGのデータがあったら、次のデータのチェックを行う。チェックNGのデータはエラーメッセージを出力する。チェックOKのデータは処理を継続し登録や更新を行う。

②チェックNGのデータがあったら、他のデータのチェックは行わずエラーメッセージを出力して処理を終了する。

個人的には①が好みですが、ユーザから「②で良いよ」と言われる方もいらっしゃったり、①と②を使い分けたりすることもあるので要件を詰めていく中で確認する必要があります。

データ処理

一通りチェックが終わったらデータの登録/更新/削除処理を行います。ABAPの場合には、BAPIを使用したりしてデータ処理を行います。

もし、エラーが発生した場合にはチェックNGの場合と同様に、以下のような方法が代表的かと思います。
①エラーが発生したらエラーメッセージを出力し、次のデータの処理を行う。
②エラーが発生したらエラーメッセージを出力し、処理を終了する。残りののデータの処理は行わない。

また、エラーへの対処方法の1つとして、リトライ回数を設ける方法もあります。
データ処理が正常に完了するまで最大で3回まで繰り返すというものです。(回数はその都度検討が必要)
このとき、リトライ時間というものも設けます。エラーが発生したらすぐに再度処理をするのではなく、1秒経過したら再処理を行うというものです。

リトライ回数を3回/リトライ時間を1秒とした場合、処理の流れは以下のようなイメージになります。

アップロード機能の処理の流れ

ここまでの内容を簡単にまとめると以下のような処理の流れになります。(あくまで一例)

まとめ

ファイルアップロード機能について解説しました。
実際の開発ではユーザの業務に合わせて必要な項目やチェックが変わってくるので、要件をしっかりと詰めておくことが大切になります。

スポンサーリンク