ABAP/ROLLBACK WORK
データベースへの更新をなかったことにする命令で、COMMI WORKと対になる命令。 要は、「巻き戻し」ですな。
概要 †
データベースの更新は、実はSQL命令単体では「確定」せず、DB更新→コミットでニコイチとなる。
ここで更新命令後、ROLLBACK WORK命令を発行することにより処理を「なかったこと」に出来る。
用法 †
ヘッダと明細のあるアドオンテーブルの更新など、ニコイチの処理の片方が失敗した場合など。
サンプル †
IF ( SY-SUBRC <> 0 ). ROLLBACK WORK. ENDIF.
その他 †
暗黙的COMMITに注意 †
確定したり戻したりしたい場合でも、Dynproの切り替えやMESSAGE命令でもコミットが走ることとなる。
そのため、下記のコードは意味が無かったり意図したとおりに動作しないので注意。
IF ( SY-SUBRC <> 0 ). MESSAGE Exxx(ZZxx). ROLLBACK WORK. ENDIF.
ちなみに、一般的にバッチインプットでなくBAPIを使えと言われる理由の一つに、この命令が利用できるか否かがあり、前者は標準の画面で標準の流れに沿っているが故MESSAGE命令が発行されるため、ニコイチの処理ができないことが挙げられる。
暗黙的COMMITやROLLBACKは便利だし「わかっている人」にとってはワザワザ書かなくてもいいじゃんという話なのだが、導入中に仕様変更をする人や稼動後メンテする人も「わかっている人」とは限らないため、基本的には明示的に書いた方が書き手の意思が伝わってよいかと思う。
BAPI_TRANSACTION_ROLLBACKについて †
実は、ROLLBACK WORKの発行の後にBUFFER_REFRESH_ALLという汎用モジュールを呼び出しているだけだったりする。 BUFFER_REFRESH_ALLの中では、
LOOP AT GT_DELETEFUNCTIONS INTO WA_DELETEFUNCTION. CALL FUNCTION WA_DELETEFUNCTION-NAME_OF_FUNCTION. ENDLOOP REFRESH GT_DELETEFUNCTIONS.
というソース。 内部処理で「○○の場合は、ROLLBACKのために××という汎用モジュールを呼び出す」という思想。 本当はこれは設計者の領分であるはずなのに、SAPは裏側で勝手にやってくれるので便利極まりない。
よほど更新対象が限定されている或いは標準ロジックに任せたくない繊細なケアが必要である等の事情がなければ、BAPIを使ってしまってよい気がする。
コメントはありません。 Comments/ABAP/ROLLBACK WORK
