SAP用語
SAP LUWとは？論理作業単位とCOMMIT WORKの実務
SAP LUW（論理作業単位）の意味、データベースLUWとの違い、COMMIT WORK・ROLLBACK WORKの使い分け、更新タスクやRFC連携での確認ポイントを実務向けに解説します。
SAP LUWとは
SAP LUWは、業務上ひとまとまりとして扱う処理単位です。LUWはLogical Unit of Workの略で、日本語では論理作業単位と呼びます。たとえば受注登録で、伝票ヘッダ、明細、価格、在庫や会計連携に関係する更新を一連の処理として確定させる場合、そのまとまりがSAP LUWです。
論理作業単位（LUW）を理解すると、画面上では登録が完了したように見えるのにデータベースへ確定されていない、途中でエラーが発生したのに一部だけ残っている、といった事象を切り分けやすくなります。SAP LUWでは、処理の開始、ロック、更新処理、確定または取消しという流れを確認します。
SAPの運用では、次の三つを区別して考えると整理しやすくなります。
- SAP LUW：業務処理として一貫性を保つ論理的な単位
- データベースLUW：データベースがコミットまたはロールバックする単位
- 画面上のトランザクション：利用者が開始して終了する操作単位
これらは常に同じ範囲になるとは限りません。ABAPプログラムの処理、更新タスク、RFC、非同期連携がどこで区切られるかによって、実際の境界が変わります。
SAP LUWとデータベースLUWの違い
データベースLUWは、データベースに対する変更を確定または取り消す技術的な単位です。一方、SAP LUWは、業務処理の整合性を維持するためのアプリケーション側の単位です。SAP LUWの中で複数のデータベースLUWが発生することもあります。
典型的なダイアログ処理では、利用者の入力を受けてABAPプログラムがデータを処理し、必要な更新を登録します。その後、処理の区切りでコミットが実行されると、データベースへの変更が確定します。更新処理を別の更新ワークプロセスへ渡す設計では、画面処理とデータベース更新の実行タイミングが異なるため、監視時には更新要求の状態も確認します。
SAP LUWの整合性を支える要素には、次のようなものがあります。
| 要素 | 役割 |
|---|---|
| エンキュー | 同じ業務データへの同時更新を調整する |
| 更新タスク | データベース更新を更新処理として実行する |
| COMMIT WORK | LUW内の更新を確定する境界を作る |
| ROLLBACK WORK | 未確定の変更を取り消す |
| 更新ログ・アプリケーションログ | 処理結果や失敗原因を追跡する |
ロックを取得しただけでは、業務データが確定したことにはなりません。コミット後にロックが解放される設計が多いため、処理の完了を判断するときは、ロックの有無だけでなく、更新結果とコミット結果を確認します。
SAPの用語全体を確認したい場合は、SAP用語集：モジュールと基本用語も参照してください。LUWはFI、MM、SD、EWMなど複数の業務領域にまたがって登場するため、個別モジュールの機能名だけで判断しないことが重要です。
COMMIT WORKの役割
ABAPでCOMMIT WORKを実行すると、現在のSAP LUWに含まれる更新処理を確定する境界が作られます。更新タスクとして登録された処理も、このコミットを契機に実行対象になります。外部システムへ結果を返す場合は、呼び出し元が確認できる時点と、データベース更新が確定する時点を分けて設計します。
更新完了を待ってから後続処理へ進めたい場合は、状況に応じて次の形式を使います。
COMMIT WORK AND WAIT.
AND WAITを付けると、更新処理の完了を待ってからプログラムの次の処理へ進みます。ただし、待機時間が長くなる可能性があるため、大量データ処理や高負荷時間帯では、更新処理の量、タイムアウト、ワークプロセスの使用状況を確認します。
COMMIT WORKは、単なる保存ボタンの代替ではありません。コミットを実行すると、同じSAP LUW内でまだ取り消したい変更まで確定する可能性があります。呼び出したAPIやBAPIが内部でコミットする設計かどうかも、連携処理では事前に確認します。
外部プログラムからBAPIを呼び出す場合、BAPIの処理結果を確認した後に、呼び出し側でコミットを明示する構成があります。その場合は、BAPIの戻りメッセージを確認してからBAPI_TRANSACTION_COMMITを呼び出し、失敗時には確定処理へ進めないようにします。実際の確定方法は、対象BAPIと連携方式の設計に合わせます。
ROLLBACK WORKで処理を取り消す
ROLLBACK WORKは、現在のSAP LUWでまだ確定していない変更を取り消すために使用します。入力チェック、権限確認、マスタ存在確認、外部連携結果の確認など、確定前に失敗を検出した場合に、後続のコミットを止めてロールバックへ進む設計にします。
IF lv_error = abap_true.
ROLLBACK WORK.
RETURN.
ENDIF.
COMMIT WORK AND WAIT.
エラー処理では、ロールバック後に利用者へ返すメッセージと、運用担当者が追跡できるログを分けて記録します。ロールバックが実行された場合でも、外部システムへの送信、ファイル出力、メール送信など、データベース外で実行済みの処理まで自動的に戻るとは限りません。そのため、外部副作用を伴う処理では、再実行キー、送信状態、冪等性を設計に含めます。
失敗時に一部のデータだけが残る場合は、次の順番で確認します。
- どの処理で
COMMIT WORKが実行されたか - 呼び出したBAPI、汎用モジュール、更新タスクが内部で確定していないか
- 更新要求が正常、エラー、未処理のどの状態か
- 外部RFCやファイル処理がデータベース更新の外側で実行されていないか
- 再実行によって二重登録が起きない設計になっているか
更新タスクとSAP LUW
更新タスクは、ダイアログ処理で受け付けた変更を、更新処理としてデータベースへ反映する仕組みです。ABAPでは、更新用の汎用モジュールをCALL FUNCTION ... IN UPDATE TASKで登録し、後続のコミットを契機に実行します。
CALL FUNCTION 'Z_UPDATE_DOCUMENT' IN UPDATE TASK
EXPORTING
iv_document = lv_document.
COMMIT WORK AND WAIT.
更新タスクのエラーは、画面処理を実行したワークプロセスのログだけでは判断できない場合があります。更新要求の状態、更新処理のエラー情報、アプリケーションログ、関連する業務伝票を組み合わせて確認します。更新要求が失敗している場合は、同じ処理を無条件に再実行せず、既存伝票やロック、外部送信の有無を確認してから復旧手順を選びます。
V1更新とV2更新を使う設計では、業務上必須の更新と、統計・集計など後続性の高い更新で完了タイミングが異なることがあります。業務伝票が作成済みでも、関連集計や統計情報が後から更新される構成はあります。監視では、画面処理の終了だけを成功条件にせず、必要な更新要求が完了していることまで確認します。
RFCとSAP LUWの境界
RFCを使う連携では、呼び出し元と呼び出し先が同じSAP LUWとして動くとは限りません。同期RFCで処理結果を受け取っても、呼び出し先の更新が確定済みとは限らないため、連携仕様にコミット責任を明記します。
トランザクションRFCでは、呼び出しをトランザクション単位で扱い、通信障害時の再実行や一貫性を考慮できます。キューを利用する連携では、処理順序、キュー停止、再処理の条件を監視対象に含めます。RFCの接続先や呼び出し方式を確認するときは、RFCとは？リモート・ファンクション・コールの基礎も役立ちます。
RFC連携で特に確認する項目は次のとおりです。
- コミットを呼び出し元と呼び出し先のどちらが担当するか
- 戻りメッセージをどの時点で成功と判定するか
- 通信再試行時に二重登録を防げるか
- トランザクションIDや外部キーで処理を追跡できるか
- エラー時にキュー、更新要求、アプリケーションログを確認できるか
連携対象がIDocの場合は、受信・送信ステータスと、後続の業務伝票更新を分けて確認します。IDocの基本的な流れは、SAP IDocとは？連携処理とステータスの見方で整理しています。
SAP LUWのトラブルシューティング
「登録完了」と表示されたのに検索結果へ出ない場合は、まずコミットの有無と更新要求の状態を確認します。画面処理が正常終了していても、更新タスクが後続処理として失敗している可能性があります。業務伝票番号が発行されている場合は、伝票のヘッダ、明細、ステータス、関連ログを同じ時刻範囲で照合します。
ロックが残っている場合は、次の観点で確認します。
- 処理を実行したユーザーのセッションが残っていないか
- ダイアログ処理が異常終了していないか
- 更新タスクがエラーで停止していないか
- バッチやRFCが同じ業務データを処理していないか
- ロックを強制解除する前に、実行中の処理がないことを確認したか
一部だけ登録された場合は、コミット境界を時系列で追跡します。ABAPソースのCOMMIT WORK、BAPIのコミット仕様、更新タスクの登録箇所、RFCやファイル送信の実行順を並べると、SAP LUWの範囲を特定しやすくなります。
運用記録には、実行ユーザー、実行時刻、会社コードやプラントなどの業務キー、伝票番号、外部トランザクションID、更新要求の結果、エラーメッセージを残します。これらをそろえると、同じ処理を安全に再実行できるか判断しやすくなります。
SAP LUWを設計・運用するときの要点
SAP LUWは、単にCOMMIT WORKを書く場所だけで決まるものではありません。業務上どこまでを一つの成功単位とするか、失敗時に何を戻すか、外部システムへいつ通知するかを先に決め、その設計に合わせてコミット境界を置きます。
実装では、一つの処理の中に無関係な業務更新を詰め込みすぎないことが重要です。LUWが大きすぎるとロック保持時間、メモリ使用量、更新待ち時間が増えます。反対に細かくコミットしすぎると、途中失敗時に業務処理全体を戻せなくなります。
運用では、次のチェックを標準化します。
- 成功条件をデータベース更新の完了まで定義する
- コミット担当をインターフェース仕様に明記する
- 更新タスクとRFCキューを監視対象にする
- 再実行時の重複登録を防ぐキーを用意する
- ロック解除や再処理の前に実行中処理を確認する
- 伝票、ログ、外部IDを相互に追跡できるようにする
SAPの移送や開発物の管理では、業務データを確定するSAP LUWと、変更をシステム間で移すトランスポートの単位を分けて考えます。変更管理の用語は、SAPトランスポートリクエストとは？移送単位と運用の基本で確認できます。