使用する
汎用モジュールをプログラミングするときは、BAPI固有の要件の範囲を満たす必要があります。
トランザクションモデルの要件
-
BAPIは「COMMITWORK」コマンドを実行してはなりません。
理由：呼び出し元がトランザクションを制御する必要があります。複数のBAPIを1つのLUW内で組み合わせることができる必要があります。詳細については、BAPIを開発するためのトランザクションモデルを参照してください。
次のコマンドは使用しないでください。
-
コールトランザクション
-
レポートを送信
-
レポートを送信して返品する
-
-
データベースの変更は、更新によってのみ行うことができます。
理由：RFCは暗黙的なデータベースコミットを実行します。
-
グローバルメモリを使用して値を転送しないでください。
理由：これにより、副作用が回避され、機能のカプセル化がサポートされます。
-
BAPIが呼び出された後にCOMMITWORKが実行されない場合は、設定されているロックを削除する必要があります。
-
SAP内部ロックによって保護されていないすべてのテーブルは、デッドロックを防ぐために常に同じ順序で更新する必要があります。
BAPIのリモート機能の要件
-
BAPIは画面出力を生成してはなりません。これは、リスト、クエリ、およびダイアログボックスを作成してはならないことを意味します。これは、BAPI自体と、BAPIによって間接的に呼び出される可能性のあるすべての汎用モジュールに当てはまります。
理由：外部クライアントが画面の出力に応答できません。最悪の場合、クライアントプログラムの接続が切断される可能性があります。
-
必要に応じて、すべてのBAPIが独自の権限チェックを実行できる必要があります。特に入力ヘルプには、権限チェックが含まれている必要があります。
エラー処理要件
-
BAPIでは例外は使用されません。代わりに、すべてのエラーメッセージは、標準化されたパラメータReturnで呼び出し元のプログラムに報告されます。
-
BAPIによってプログラムが終了してはなりません。関連するメッセージ（メッセージタイプA、終了メッセージ）は、returnパラメーターでのみ返されます。プログラムでは、タイプE（エラーメッセージ）およびA（終了メッセージ）のメッセージを直接表示することは許可されていません。
-
ここでは、エラー処理が通常の汎用モジュールよりも重要な役割を果たします。
-
使用されるエラー番号の意味は変更しないでください。
-
エラーメッセージは、外部アプリケーションのユーザーが理解できる必要があります。たとえば、テーブル名を含めることはできません。
-
エラーメッセージは、エラーの原因がビジネス（コンテンツ）に関連するものなのか、インポートデータの欠落によるものなのかを指定する必要があります。
-
性能要件
-
BAPIはうまく機能する必要があります。次のガイドラインに従う必要があります。
-
転送されるデータの量を最小限に抑えるために、完全なWHERE条件のみを使用してください。
-
不要なデータベースアクセスは避けてください。
-
ARRAYを使用してください。
-
ロックの粒度は、オブジェクトモデルのインスタンスの粒度に対応している必要があります。
-
実行時にプログラムを生成しないでください。
-
-
BAPIのベースとなる汎用モジュールには、RFCを使用して外部プログラムからアクセスすることができます。このため、BAPIをプログラミングするときは、次の追加のガイドラインに従う必要があります。
-
大量のデータの処理
一括データは、SAPGUIをフロントエンドとして使用するABAPプログラムと、VisualBasicなどの外部開発プラットフォームで開発されたプログラムでは異なる方法で処理されます。SAPシステムで大量のデータ（たとえば、多数のエントリを含むリスト）が読み込まれる場合、データの大部分はアプリケーションサーバに残ります。実際に表示されるデータのみがフロントエンドに送信されます。対照的に、Visual Basicでプログラミングしている場合、すべてのデータはアプリケーションサーバーからクライアントシステムに送信されます。これにより、ネットワークの負荷とクライアントシステムに必要なメモリの量が増加します。BAPIが大量のデータを読み取らなければならない状況をカバーする必要があります。たとえば、最初のnのみがデータレコードが読み取られます。または、BAPIは、データ量が特定の制限を超えており、新しい選択を行う必要があることを示すメッセージを呼び出し側プログラムに返すことができます。
-
データベースロックの期間を短縮するために、データベースロックに個別に番号を割り当てないでください。代わりに、バッファを利用してください。番号をバッファに読み取り、バッファから直接番号を割り当てます。
-
COMMIT WORKコマンドのできるだけ近くでデータベースを更新することにより、ロック期間を最小限に抑えることができます。これにより、データベースロックの期間が短縮され、他のプロセスがブロックされるリスクが軽減されます。
-
変更されたデータレコードの（部分的な）キーの具体性が低いほど、データレコードが複数のBAPIによってアクセスされ、レコードがロックされる可能性が高くなります。たとえば、プラントレベルで統計を実行すると、BAPIのパフォーマンスに悪影響がありますが、プラントと材料に基づく統計では、適用されるBAPIが少なくなるため、ロックが少なくなります。
-
以前のデータベースCOMMIT（コミットされた読み取り）に依存する読み取りトランザクションの使用を最小限に抑えます。これらの読み取りトランザクションは、更新トランザクションのCOMMITWORKコマンドが処理されるまで待機する必要があります。
-
-
書き込みが有効なBAPIメソッドは、変更または新しく作成されたインスタンスの整合性を確保するために、必要なすべての整合性チェックを行う必要があります。
-
入力が予期されていないテーブルに対してリフレッシュを実行する必要があります。
-
getおよびsetパラメーターは使用しないでください。
理由：これにより、副作用が回避され、機能のカプセル化がサポートされます。
-
BAPIは、カスタマイジング設定から独立している必要があります。特に、カスタマイジングに関連する値は変更できません。
-
顧客拡張の概念の一部として、顧客がBAPI機能を拡張できるように、ビジネスアドイン（BadI）を含める必要があります。
各BAPI汎用モジュールには、アプリケーションによって提供される出口に加えて、2つの追加のBAdIが含まれている必要があります。
最初のBAdIは、顧客がBAPIに転送されるすべてのデータをチェックできるようにする必要があります。特に、テーブル拡張に書き込まれる前に、 ExtensionInパラメーターの内容を確認してください。2番目のBAdIは、顧客が拡張（追加のテーブルの作成など）を行えるように提供されています。顧客がBAPIのエクスポートパラメータを拡張した場合は、2番目のBAdIを使用してExtensionOutパラメータを入力する必要があります。
関連項目： BAPIの得意先拡張。
参照：ビジネスアドイン。
