CData SAP Gateway Drivers:バッチ処理でのトランザクション制御概要

by 浦邊信太郎 | May 13, 2026 | Last Updated: May 13, 2026

CData SAP Gateway Drivers:バッチ処理でのトランザクション制御概要

概要

CData SAP Gateway Driversは、SAP OData サービスに対して SQL ライクなインターフェースで INSERT / UPDATE / DELETE 操作を行える強力なドライバーです。その中でも「バッチ処理」は複数レコードを効率よく更新する際に欠かせない機能です。本記事では、標準 JDBC の PreparedStatement.addBatch() / executeBatch() API を軸に、バッチ処理の動作仕様・エラー時の挙動・返り値の取得方法を体系的に解説します。

バッチ処理の基本動作

JDBC バッチ API による処理方式

CData SAP Gateway JDBC Driver では、標準 JDBC の PreparedStatement.addBatch() / executeBatch() を使ってバッチ処理を行います。addBatch() で複数の SQL 文をキューに積み、executeBatch() を呼び出すとキュー内のすべての操作が SAP Gateway の $batch エンドポイントへまとめて送信されます。

String connectionStr = "jdbc:sapgateway:Url=https://your-sap-host/sap/opu/odata/sap/GWSAMPLE_BASIC;"
    + "User=SAPUser;Password=SAPPassword;";

Connection conn = DriverManager.getConnection(connectionStr);
String sql = "UPDATE SalesOrderSet SET Note = ? WHERE SalesOrderId = ?";
PreparedStatement pstmt = conn.prepareStatement(sql);

// 複数レコードを addBatch でキューに積む
pstmt.setString(1, "Updated note A");
pstmt.setString(2, "0500000001");
pstmt.addBatch();

pstmt.setString(1, "Updated note B");
pstmt.setString(2, "0500000002");
pstmt.addBatch();

pstmt.setString(1, "Updated note C");
pstmt.setString(2, "0500000003");
pstmt.addBatch();

// executeBatch() を呼び出した時点で SAP Gateway へバッチ送信
int[] updateCounts = pstmt.executeBatch();

pstmt.close();
conn.close();

executeBatch() の戻り値は各 SQL 文の更新件数を格納した int[] 配列です。ただし、後述のとおり ノーコードツールを経由する場合はこの配列を直接参照できないため、LastResultInfo#TEMP テーブルで代替します。

$batch リクエストと Changeset の2層構造

executeBatch() を呼び出すと、ドライバーは SAP Gateway の $batch エンドポイントに対して HTTP POST を発行します。ここで混乱しやすいのが「$batch リクエスト(HTTP リクエスト単位)」と「Changeset(その中のトランザクション単位)」という2つの概念です。$batch リクエストはいわば「封筒」です。その中に Changeset と呼ばれる小さな封筒が入っており、1つの Changeset が1つのトランザクション単位(全成功 or 全ロールバック)になります。個々の INSERT / UPDATE / DELETE 操作は、この Changeset の中に入ります。

2つのプロパティがそれぞれ異なる粒度を制御します。

  • BatchSize:1つの $batch リクエストに含める操作の総件数を指定する。100件を BatchSize=10 で処理すると、10件ずつ10回の $batch リクエストが送信される。

  • EnableAtomicBatchOperations:$batch リクエスト内の操作を何件ずつ Changeset にまとめるかを決める。false(デフォルト)なら1件ずつ個別の Changeset、true なら $batch リクエスト内の全件を1つの Changeset としてまとめる。

CData SAP Gateway Drivers:バッチ処理でのトランザクション制御概要

BatchSize プロパティによる分割送信

BatchSize の設定

API の呼び出し方式

1

1 レコードごとに個別の API リクエストを発行(バッチなし)

N(N > 1)

N 件をまとめて1回の $batch リクエストとして送信

例えば 100 件を BatchSize = 10 で処理すると、10件ずつ10回の $batch リクエストが SAP Gateway に送信されます。

エラー発生時の挙動制御

エラー発生時の動作は、以下の 2 つの「隠しプロパティ」の組み合わせで詳細に制御できます。

関連プロパティ

EnableAtomicBatchOperations

複数レコードの更新を 1 つのバッチリクエストとしてアトミックに処理するかどうかを指定します。

  • true:指定の BatchSize 単位でまとめてバッチ送信。同一バッチ内でエラーが発生すると、そのバッチ全体がロールバックされます。

  • false(デフォルト):1 行ずつ独立した処理単位として扱われます。ある行のエラーが他の行に影響しません。

参考ドキュメント:EnableAtomicBatchOperations

ContinueOnError

バッチ処理中にエラーが発生した際、処理を継続するか中断するかを指定します。

  • true:エラーが発生したバッチをロールバックして次のバッチに進みます。

  • false:エラーが発生したバッチをロールバックして全体の処理を中断します。

参考ドキュメント:ContinueOnError

プロパティの組み合わせパターン

EnableAtomicBatchOperations

ContinueOnError

動作

false(デフォルト)

任意

各行が独立して処理。他の行への影響なし

true

true

バッチ単位でロールバック。エラー後も次のバッチを継続処理

true

false

バッチ単位でロールバック。エラー発生時点で全体処理を中断

注意: これらは「隠しプロパティ」のため、ツールのプロパティ一覧には通常表示されません。ドライバーの接続文字列に指定する場合はOtherプロパティを用い、Other="EnableAtomicBatchOperations=true;ContinueOnError=true"のように設定する必要があります。

返り値の確認

バッチ処理後に以下のクエリを実行することで、個々の行の処理結果(正常・エラーを含む)を確認できます。

SELECT * FROM LastResultInfo#TEMP;

このテーブルから取得できる主な情報:

  • 対象 API / テーブル情報

  • エラー項目(どの列でエラーが発生したか)

  • エラー内容(原因メッセージ)

  • エラーコード(SAP OData API が返すコード)

注意: LastResultInfo#TEMP テーブルのスキーマは事前定義されていません。実行前にメタデータを確認するか、SELECT * で全カラムを取得してください。また、このテーブルは次のデータ更新操作の際にクリアされ再作成されます。

認識の整理

よくある誤解を含めて、CData SAP Gateway Driver のバッチ処理に関する仕様を以下にまとめます。

認識

正確な仕様

基本は逐次コミットでトランザクション非対応

EnableAtomicBatchOperations を使用することでバッチ単位のトランザクション制御が可能。ただし、SAP OData API の仕様に依存します。

エラー発生時は後続処理が停止する

ContinueOnError で制御可能。true に設定すれば後続バッチの処理を継続できます。

処理件数は取得可能

LastResultInfo#TEMP テーブルで成功した行をカウントすることで間接的に取得可能です。

まとめ

CData SAP Gateway Driver のバッチ処理は、BatchSizeEnableAtomicBatchOperationsContinueOnError の 3 つのプロパティを組み合わせることで、さまざまなトランザクション要件に対応できます。エラー処理後の詳細情報は LastResultInfo#TEMP テーブルから取得できるため、フロー設計時には必ずバッチ処理後に結果確認ステップを組み込むことをお勧めします。

さらに詳しい情報は、CData 公式ドキュメントや SAP OData バッチ処理の仕様も参考にしてください。

関連リンク