オープン SQL 命令 INSERT 、 UPDATE 、 MODIFY 、 DELETE を使用すると、複数のダイアログステップにまたがるデータベース変更をプログラミングすることができます。データベースコミットを明示的にプログラミングしていなくても、 Dynpro が処理されたあとで発生する暗黙的データベースコミットでデータベース LUW が終了されます。下図は代表的な Dynpro による一連の作業におけるそれぞれのデータベース LUW を示します。

この手順を使用する場合、前のダイアログステップのデータベース変更をロールバックすることはできません。したがって、これは個別ダイアログステップの間に論理的な関係のないプログラムのみに適しています。

しかし、通常の場合、個別ダイアログステップでのデータベース変更は他のダイアログステップでの変更に依存するので、すべて一緒に実行またはロールバックしなければなりません。これらの従属データベース変更は論理単位を形成し、以下でリストアップする連結手法を用いて１つのデータベース LUW にまとめることができます。

SAP LUW とは、ダイアログステップで構成され、変更が１つのデータベース LUW でデータベースに書き込まれる論理単位は、 SAP LUW と呼ばれます。データベース LUW の場合と異なり、 SAP LUW は複数のダイアログステップにまたがることができ、一連の異なるワークプロセスを使って実行することができます。 SAP LUW にデータベースの変更が含まれる場合は、それらを全部データベースに書き込むか、まったく書き込まないようにする必要があります。確実にこの処理を行うため、トランザクションが正常に終了したときにデータベースコミット、プログラムがエラーを検出するときにデータベースロールバックを行うようにしなければなりません。しかし、データベース LUW からのデータベースの変更はそのあとのデータベース LUW で取り消すことができないため、 SAP LUW に対するすべてのデータベース変更を１つのデータベース LUW で実行しなければなりません。データの完全性を維持するため、データベース変更をすべて SAP LUW の最終のデータベース LUW でグループ化しなければなりません。下図はこの原理を示します。

SAP LUW 内でのデータベース変更に対するグループ化の手法により、その場合でもデータベース変更を取り消すことができます。これはトランザクションを複数のワークプロセスはもちろん、複数の R/3 システムにも分散することができることも意味します。 SAP LUW 内でのデータベース変更のグループ化機能について、このあとでまとめます。

グループ化の最も簡単な形式は、アプリケーション全体を１つのダイアログステップで処理することです。この場合、システムはユーザ入力をチェックし、データベースを更新しますが、そのダイアログステップ自身ではデータベースコミットが発生しません。もちろん、これは複雑な業務プロセスには適していません。その代わりとして、 R/3 システムには以下のグループ化手法が含まれています。

CALL FUNCTION ... IN UPDATE TASK 命令を使用して汎用モジュールを呼び出すと、その汎用モジュールには特別な更新ワークプロセスを使用して実行フラグが立てられます。つまり、プログラムの代わりに汎用モジュールにデータベース変更のためのオープン SQL 命令を記述し、プログラム内で本来なら命令を取り込んでいるはずのポイントで汎用モジュールを呼び出すことができます。 IN UPDATE TASK オプションを使用して汎用モジュールを呼び出すと、その汎用モジュールとそのインタフェースパラメータがログエントリとして VBLOG という名称の特別なデータベーステーブルに格納されます。

プログラムが COMMIT WORK 命令まで達すると、汎用モジュールは更新ワークプロセスを使って実行されます。 COMMIT WORK プロセスのあと、ダイアログワークプロセスは自由にそれ以降のユーザ入力を受け取ることができます。トランザクションのダイアログ部は COMMIT WORK 命令で終了します。そのあと SAP LUW の更新部が始まり、それは更新ワークプロセスの責任になります。更新プロセスがデータベースの変更をすべてコミットするかロールバックした時点で、 SAP LUW が完了します。

更新に使用する汎用モジュールを登録する方法に関する追加情報が必要な場合は、 データベース更新用汎用モジュールの登録を参照してください。

更新の際にエラーが発生するのは例外的なケースだけです。なぜならば、 SAP LUW のダイアログ段階で不正エントリなどの論理エラーがすべてチェックされるからです。論理エラーが発生すると、プログラムは ROLLBACK WORK 命令を使用して更新を終了することができます。その後は汎用モジュールは呼び出されることがなく、ログエントリはテーブル VBLOG から削除されます。更新自体でのエラーは、通常はたとえばメモリ不足などの技術的なものです。技術的エラーが発生すると、更新ワークプロセスはデータベースロールバックを開始し、ログエントリが VBLOG に戻されます。そのあと、最初に VBLOG エントリを生成したダイアログのユーザに終了の詳細を含むメールが送信されます。このようなエラーはシステム管理者が修正しなければなりません。そのあと、返された VBLOG エントリを再度処理することができます。

更新管理に関する追加情報が必要な場合は、 更新管理を参照してください。

このようにデータベースの変更を SAP LUW の最後のデータベース LUW にグループ化するという手法により、データベースを非同期で更新し、ダイアログワークプロセスでの応答時間を短縮することができます。たとえば、更新をダイアログワークプロセスからまったく切り離し、リモートデータベースサーバで中央更新ワークプロセスを使用することができます。

命令 PERFORM ON COMMIT はダイアログワークプロセスにサブルーチンを呼び出します。しかし、これはシステムが次の COMMIT WORK 命令に達するまでは実行されません。この場合も、 ABAP 命令 COMMIT WORK が SAP LUW の終了を定義します。なぜならば、データベースの変更を行う PERFORM ON COMMIT で呼び出されるサブルーチンの命令はすべて該当するダイアログステップのデータベース LUW で実行されるからです。

このグループ化手法の CALL FUNCTION ... IN UPDATE TASK に対する利点は、更新データを別のテーブルに書き込む必要がないことからパフォーマンスが向上する点です。しかし、パラメータを PERFORM ... ON COMMIT 命令で引渡すことができない点がデメリットです。データはグローバル変数と ABAP メモリを使って引渡されます。この方法を使ってデータの受渡しを行う場合、データの不整合の危険がかなり高くなります。

CALL FUNCTION ... IN BACKGROUND TASK DESTINATION ... を使用して呼び出す汎用モジュールは、プログラムが次の COMMIT WORK 命令に（リモートファンクションコールを使って）達するときに、別の R/3 システムでバックグラウンド実行対象として登録されます。 COMMIT WORK のあと、ダイアログプロセスはこれらの汎用モジュールが実行されるのを待ちません（非同期更新）。このように登録される汎用モジュールは、すべて１つのデータベース LUW でまとめて実行されます。このような更新が便利なのは、たとえば、同じデータを複数のデータベースで更新する必要がある場合です。

詳細については、キーワード文書を参照してください。

RFC 処理の詳細については、 ベーシスサービス文書のリモート通信のセクションを参照してください。