Buffering with Write BAPIs

使用する
統合
前提条件
特徴
活動

使用する

それぞれ独自のデータを定義する必要がある外部システムを節約するには、事前定義されたバッファリングメカニズムをすべての書き込みBAPI（つまり、データを作成および変更するBAPI）に実装する必要があります。

SAP内部使用の場合、これはリリース4.6A以降に開発されたBAPIに特に関係があります。以前のリリースでBAPIのバッファを実装する場合は、最初にBFAAGの同僚に連絡する必要があります。

BAPIの場合、標準のSAPシステムメカニズムを使用してアプリケーションデータをバッファリングできます。BAPIによって登録または変更されるデータは、更新バッファに登録されず、最初にBAPI汎用モジュールグループのバッファに収集されます。次に、バッファ全体が指定された時間に更新されます。

これには次の利点があります。

システム全体のパフォーマンスの向上。

個々の操作の更新は遅れており、すべて一緒に更新できます。「アレイ挿入」などの手法により、システムのパフォーマンスが向上します。バッファリングを使用しない場合は、各変更を個別に更新する必要があります。
アプリケーションインスタンスへのいくつかの変更

最初の変更で、データがデータベースからバッファに読み込まれ、変更がバッファで行われます。次の変更で、システムはデータがすでにバッファーに存在することを認識し、バッファーにも変更を加えます。バッファリングを使用しない場合、2番目の変更を行う前に、最初の変更を更新する必要があります。
データの大量転送に使用

バッファリング付きのBAPIは、アプリケーションリンク有効化（ALE）を介してシステム間で大量のデータが交換される状況で特に適しています。

バッファリングメカニズムにより、アプリケーションインスタンスをALEレイヤーで個別に処理しながら、インスタンスを一緒に更新することができます。SaveReplicaMultiple（）などの複数のBAPIとは異なり、このプロシージャでは個々のインスタンスのエラー処理が可能です。

統合

リリース4.0以降で使用されているコミットなしのBAPIのトランザクションモデルは、次の利点に基づいて拡張できます。

1つの論理作業単位（LUW）内で、1つのインスタンスに対して複数の変更または詳細な変更を実行できます。
（1つ以上のインスタンスに対する）すべての変更は、 BAPI BapiService.TransactionCommit（）によって一緒に更新されます。

この図は、バッファリングなしのBAPIのトランザクションモデルを示しています。

この図は、バッファリングを使用したBAPIのトランザクションモデルを示しています。

前提条件

BAPIのバッファリングメカニズムは暗黙的である必要があります。つまり、呼び出し元はバッファリングを制御する必要はありません。呼び出し側プログラムは、たとえば、バッファリング付きのCreate（）またはChange（）BAPIを使用できる必要があります。また、バッファリングなしでBAPIを使用できる必要があります。バッファはSAPシステムで暗黙的に更新されます。

ビジネスオブジェクトタイプにバッファリングが実装されている場合、このビジネスオブジェクトタイプのすべての書き込みBAPIもバッファリングを使用して実装する必要があります。

バッファリングを使用した書き込みBAPIがビジネスオブジェクトタイプに実装されている場合、これはこのオブジェクトタイプの読み取りBAPIに影響します。以下の「アクティビティ」セクションの情報を参照してください。

特徴

バッファリングを使用するBAPIの場合、標準のガイドラインに加えて、以下に説明する以下の実装手順と特性が必要です。

バッファの内容を更新するための汎用モジュール

バッファリングを使用するBAPIは、バッファ内のインスタンスを作成または変更することしかできないため、バッファの内容の最終更新を実行するために1つ以上の汎用モジュールを提供する必要があります。これらの更新モジュールは、バッファーの内容全体を更新プログラムに転送します。

これらの汎用モジュールは、バッファも使用されるシステムでのみ使用されるため、BAPIとして実装しないでください。

これらの汎用モジュールの命名規則は次のとおりです。<ビジネスオブジェクト名>_SAVEBUFFER。

更新モジュールには例外を定義しないでください。例外は、エラー処理が不可能になるプログラムの最後まで実行されないためです（以下の特殊な特性を参照）。

バッファの内容を削除するための汎用モジュール

トランザクションの開始時にバッファが空であることを確認するには、バッファの内容を削除する汎用モジュールを提供する必要があります。この削除汎用モジュールは、バッファーの内容全体を削除し、インスタンスのロックをすべて削除します。この汎用モジュールは、バッファも使用されるシステムでのみ使用されるため、BAPIとして実装しないでください。

この汎用モジュールの命名規則は、<ビジネスオブジェクト名>_CLEARBUFFERです。

削除モジュールは、エラー処理が不可能になるトランザクションの終了まで実行されないため、例外を定義することはできません（以下の特殊な特性を参照）。

特徴

バッファリングを使用するBAPIには、特別な特性が必要です。たとえば、呼び出し元はバッファ内のデータを再処理できないため、これらのBAPIはエラーを処理できる必要があります。データは暗黙的にバッファリングされるため、呼び出し元には管理BAPIは提供されません。

バッファの内容の一貫性

バッファリングのあるBAPIは、更新を除くすべての処理ステップを実行する必要があります。バッファで作成または変更されたすべてのインスタンスの整合性は、アプリケーションによって保証される必要があります。

これは次のことを意味します。

バッファ内で実行できるのは、整合性が保証された状態で更新できる操作のみです。更新モジュール自体は整合性チェックを実行できません。
番号の割り当てやアプリケーションブロックの作成など、更新前に必要な他のすべての手順は、更新モジュールを呼び出す前に実行する必要があります。
一貫して更新できない操作の場合、アクションを実行できません。このような場合、エラー状況はBAPIReturnパラメーターで報告する必要があります。

更新モジュールの呼び出し

バッファ操作が正常に実行された後、コマンドを使用します

コミット時に<ルーチン>を実行する

フォームルーチン<ルーチン>を呼び出し、次に更新モジュールを呼び出します。

更新モジュールは、コマンドを使用して呼び出す必要があります

CALL<ビジネスオブジェクト名>_SAVEBUFFERIN UPDATE TASK

更新プログラムで実行にフラグを立てます。

コマンドPERFORM<routine>ONCOMMITに「ONCOMMIT」を追加することにより、更新はすぐには実行されず、次のCOMMITWORKで実行されます。このようにして、任意の数のBAPI呼び出しをまとめて収集できます。BAPI BapiService.TransactionCommit（）を介して実行される最後のCOMMIT WORKコマンドは、フォームルーチンと各更新モジュールを1回だけ実行します。このため、このフォームルーチンでも汎用モジュールでもエラー処理を実行することはできません。

削除モジュールのサブスクライブ

各LUWの開始時に、バッファーは空である必要があります。以前のLUWで更新された、バッファに存在する可能性のあるインスタンスは、ブロックされなくなり、データベース内のバージョンよりも古い可能性があります。このインスタンスが再度更新されると、不整合が発生します。

各LUWの最後に、削除モジュールを呼び出してバッファーの内容を削除する必要があります。これは、BAPIのBapiService.TransactionCommit（）およびBapiService.TransactionRollback（）によってのみ実行できます。これらのBAPIに必要な情報を提供するには、バッファリングを使用するBAPIは、BAPI BapiService.TransactionCommit（）またはBapiService.TransactionRollback（）の削除モジュールをサブスクライブする必要があります。

削除モジュールは、中央汎用モジュールBUFFER_SUBSCRIBE_FOR_REFRESHを呼び出すことによってサブスクライブされます。これにより、パラメータNAME_OF_DELETEFUNCに削除モジュールの名前が含まれている必要があります。

COMMITWORKまたはROLLBACKWORKコマンドはありません

バッファリングのあるBAPIは、COMMITWORKまたはROLLBACKWORKコマンドを実行してはなりません。

ドキュメンテーション

バッファリングを使用する各BAPIは、そのように明示的に文書化する必要があります。

活動

バッファリングを使用してBAPIを書き込み、同じビジネスオブジェクトのBAPIを読み取ります

読み取られたインスタンスのバッファリングなし

バッファリング付きの書き込みBAPIが同じビジネス・オブジェクト・タイプに実装されている場合、読み取りBAPIは同じビジネス・オブジェクト・タイプのバッファーを使用できません。これにより、データベースから読み取ったデータを保管できるため、それ以上のデータベース・アクセスを回避できます。

インポートされたデータはロックされていないため、バッファ内の対応するデータは時間の経過とともに古くなります。データベース内のデータは、このデータがバッファー内にない場合にのみ読み取ることができるため、後続の読み取り操作は最初にバッファーにアクセスし、古くなっている可能性のあるデータを読み取ります。

バッファインスタンスは「実際の」インスタンスです

バッファへの書き込みBAPIによって作成または変更されたすべてのインスタンスは一貫しています。これらは、同じLUW内でさらに処理するために、他の変更BAPIで使用できます。

一貫した動作を保証するために、すべての読み取りBAPIは、有効なインスタンスとして、バッファにあり、まだデータベースにない既存のインスタンスを処理する必要があります。読み取りBAPIは、最初にバッファー内のインスタンスの読み取りを試み、インスタンスがバッファー内に見つからない場合にのみデータベースの検索を開始するように実装する必要があります。

したがって、バッファインスタンスは「実際の」インスタンスです。たとえば、BAPI ExistenceCheck（）は、バッファ内のインスタンスの存在も検索する必要があります。

読み取りBAPIの文書化

対応する書き込みメソッドのバッファリングを処理する各読み取りBAPIを文書化する必要があります。