ABAPの基礎知識　更新系　その４ - 肩書「シニアコンサルタント」のつぶやき

さて、今までの話は基本的に画面の遷移の話で、それを我慢すれば、
それなりに工数が削減される、というお話であった。
今回から先は、それよりもっと本質的なのだが、プログラム組んだことのない
純粋コンサルタントの皆さんには、なんのこっちゃらわからない話・・・
コミットのタイミング/ロックのON・OFF/更新のシリアライズなどの話である。

上記の話は、ほんとに、SEの人にとっては超当たり前の話なのだが、
マジでコンサルティングファームの皆さんだとかは、ピンとこない話なのである。
今回はまず、コミットのタイミングというヤツから話をしたい。
これは、他の２つの問題とは違い、どちらかというと、局所的なプログラム作法である。

一般的に、追加の項目をアドオンテーブルに作って、それを標準伝票と同期をとって
更新させようと思ったら、
・UserEXITでなんとかしてしまう
・アドオンで画面を作り、標準伝票の登録→アドオンテーブルの登録という順で更新する
の、二つの方法がある。
前者のほうは、かなり自由度が低い。そもそもUserEXIT自体が存在しない・・・などの
問題があるため、勢い２番目の方法をとる方向になる。
前回までのシリーズで、画面の構成自体での工数削減はできるのだが、ここに落とし穴がある。
このパターンは、必ずリカバリ画面を作る必要があるのだ。

要するに、UserEXITを使った項目の追加は、不自由ながら、データベースのコミットの
タイミングは、必ず１回で済むのである。
ところが、後者の場合、
・標準伝票の登録　（ここでコミット）　→　・アドオンテーブルの登録　（コミット）
と、２回データベースの更新タイミングがある。
通常は、この２つはちゃんと流れてくれるのだが、例えば、トラブルがあり、
サーバーを再起動するハメになったとしよう。
すると、タイミングによっては、１回目のコミットだけが発生し、アドオンテーブルの
書き込みができていない、中途半端な伝票が発生している可能性があるのである。
また、R/3は、リソースが逼迫すると、「昼休みにはログオフしてください」という、
意味のわからないメッセージを全部の画面で表示し始める。
このときが要注意である。
このメッセージが流れ始めると、プログラムでどうコーディングしていようが、
コミットが発行されると、それを検知して割り込みがかかり、プログラムの途中でも、
上記のナゾのメッセージをだして終わってしまうのである。
結果、標準伝票だけが登録されている不整合データが量産されるのである。
（そーいや、この事象も「仕様」だっていう回答だったなあ・・・）

このような状況に対応するためには、当然プログラム設計段階で、
・更新準備用アドオンテーブルに、値を全部書いて、一旦コミット
・標準伝票を登録する。
　その際、どこかに、上記準備用テーブルとのリンクがとれる項目を用意しておく。
　exp.伝票ヘッダテキストに、キーを書いておく
・更新準備用アドオンテーブルに、標準伝票更新済みステータスを書き込む
・アドオンテーブルを更新し、コミットする。
・更新準備用アドオンテーブルのエントリを削除する
という仕掛けを用意しておかなければならないのである。
なにかあったときには、更新準備用アドオンテーブルのエントリがないかを調べ、
エントリがあった場合は、どこからリランをするのかを、
ステータスと実際の伝票・アドオンテーブルの更新状況を勘案し決定する、
リラン用のプログラムが必要なのである。
当然、このリランが容易にできるように、標準画面の更新と、アドオンテーブルの更新は、
個別のプログラムもしくは汎用モジュールとして切り出しておく・・・
などなどの、こまやかなテクニックがいるわけである。

ということで、多重コミットを要件にする場合には、飛躍的に工数がかかる。
UserEXITの調査も確かに工数がかかるし、他システムとのインターフェイスを前提にした
更新系プログラムでは、回避不能の場合も多々あるのであるが、
できるだけ回避を模索するべし、なのである。
もし、回避できない場合は、上記のようなテクニックを駆使し、
リランを保障する仕掛けをバッチリ用意することを忘れてはならない。
もちろん、それができるように、見積もり工数も多めに積んで置くことも必要なのである。