使用する
BAPIに対する後続のSAP変更を自動的に有効化することが重要な場合は常に、得意先拡張コンセプトを使用する必要がありますが、これらのSAP変更が得意先拡張に影響を与えることはありません。
実装に関する考慮事項
これらの2つの要件を満たすには、BAPIパラメーターを変更しないことが重要です。代わりに、得意先拡張がコンテナでBAPIに渡され、BAPI汎用モジュール内で処理することができます。したがって、拡張される可能性のあるすべてのBAPIについて、次の最小限の予防措置を講じる必要があります。
-
BAPIインターフェースで拡張パラメーターを作成する
問題のBAPIの要件に応じて、BAPI開発者は、BAPI汎用モジュールのインタフェースでデータインポート用の1つの拡張パラメータ（ ExtensionIn）および/またはデータエクスポート用の1つの拡張パラメータ（ ExtensionOut ）を作成します。これらの拡張パラメータは、すべての得意先拡張がBAPIに渡されるコンテナとして機能します。拡張パラメータは常にBAPIPAREX構造に基づいています。
データは1つのテーブルに転送されます。このテーブルの個々のエントリの形式は、構造BAPIPAREXによって決定されます。この構造には、複数のデータ入力フィールド（VALUEPART1、VALUEPART2、…）と、顧客によって作成されたヘルプ構造の名前のフィールド（STRUCTURE）が含まれています。データはエントリごとにフィールドに書き込まれるため、データを解釈するにはヘルプ構造が必要です。BAPIテーブル拡張は、顧客が追加のフィールドを使用してSAPデータベーステーブルを拡張する場合に特に適しています。BAPIテーブル拡張は、SAPまたは得意先のいずれかによって作成されている可能性があります。ヘルプ構造またはBAPIテーブル拡張の例については、カスタマ拡張に関する以下の文書を参照してください。既存のSAPデータベーステーブルに基づくBAPIの拡張、追加の顧客データベーステーブルを含めることによるBAPIの拡張、およびデータベースレベルではないインポートデータを使用したBAPIの拡張。
-
ビジネスアドイン（BadIs）
各BAPI汎用モジュールには、アプリケーションによって提供される出口に加えて、2つの追加のBAdIが含まれている必要があります。最初のBAdIは、顧客がBAPIに転送されるすべてのデータをチェックできるようにする必要があります。特に、 ExtensionInパラメーターの内容は、その内容がBAPIでさらに処理される前にチェックする必要があります。2番目のBAdIは、顧客が追加の処理アクティビティ（追加のテーブルへの書き込み、追加の値の読み取り、追加の基準によるデータの選択など）を実行できる場合に常に提供されます。顧客がBAPIのエクスポートパラメータを拡張した場合は、2番目のBAdIを使用してExtensionOutパラメータを入力する必要があります。
特徴
詳細には、BAPIのカスタマ拡張コンセプトは、以下のタイプの拡張をサポートしています。
-
既存のSAPデータベーステーブルに基づくBAPIの拡張得意先は、基礎となるSAPデータベーステーブルに含まれているが、提供されているBAPIインタフェースには含まれていないBAPIの値を考慮することができます。2つの異なるアプリケーションを区別します。
-
SAPテーブルへの得意先項目の追加この場合、得意先は、BAPIによって使用されるSAPテーブルに追加の得意先項目を追加しています。結果として、拡張コンセプトでは、これらの追加の値をBAPIに渡したり、BAPIで処理したり、BAPIによって返されたりできるようにする必要があります。
このタイプのBAPI拡張では、別の概念が必要です。これは、顧客がAPPENDまたはINCLUDEを使用してデータベーステーブルを拡張できる場合でも、互換性の理由から、関連するBAPI構造でAPPEND手法が禁止されているためです。
-
既存のデータベースフィールドの使用SAP開発者が基礎となるデータベーステーブルのすべてのテーブルフィールドをBAPIインタフェースに追加しなかった場合、得意先はこれらのフィールドを後でBAPIに追加することができます。
-
-
追加の顧客データベーステーブルを含めることによるBAPIの拡張拡張の概念により、顧客はBAPIで独自のテーブルを処理することもできます。
-
データベースレベルに影響を与えないインポートデータを使用したBAPIの拡張データベーステーブルに影響を与える値を使用したBAPIの拡張に加えて、顧客は実行時にのみ必要な値をBAPIに渡すこともできます。
