BOPFでは、代替キーを使用してビジネスオブジェクトのノードインスタンスを識別します。
代替キーは、人間が読み取れるキーの値を提供し、名前が示すように、ノードインスタンスの技術的な読み取り不可能なUUIDの代わりに使用されます。代替キーは、対応する従属ノードインスタンスを一意に識別するノードの属性または属性のセットによって定義されます。
例1
顧客の請求書アプリケーションは、単一の請求書ごとに人間が読める形式の請求書番号（1〜100.000）で識別する必要があると想定します。対応する請求書ノードインスタンス0050562501281DDF97848577AF34366Cのキーは、明らかにこの要件を満たしていません。したがって、ノードインスタンスを識別することを目的としたノードの属性INVOICE_NUMBERは、構造化されていない一意の代替キーを完全に表します。コンシューマーは、特定の請求書番号（たとえば、4711）を使用してノードインスタンスのテクニカルキーを照会できます。
例2
現在のトランザクション中に顧客の請求書インスタンスが作成されたとすると、クエリを使用してこのインスタンスのキーを検索することはできません。ただし、このような場合は、代わりに代替キーを使用できます。クエリとは異なり、代替キー呼び出しは、データベースにまだコミットされていないBOデータに対して実行できます。
代替キーの分類
代替キーは次のように分類できます。
構造化および非構造化
代替キーは、同じノードの単一の属性（非構造化代替キー）または複数のノード属性（構造化代替キー）に関連付けることができます。
代替キー
独自性
代替キーは、それらの値の一意性に従って分類することもできます。
- 一意：この分類により、代替キーの値が一意であることが保証されます（たとえば、請求書番号4711の請求書ルートノードインスタンスは1つだけです）。
- 属性が初期でない場合に一意：この分類により、値が初期でない（nullでない）場合に代替キーの値が一意になります。これの意味は：
- 非構造化代替キーの場合：初期ではない各代替キー値は常に一意ですが、初期代替キーもいくつか存在する可能性があります。
- 構造化された代替キーの場合：すべてのフィールドが（初期以外の）値で埋められている場合、代替キーの値は一意です。
- 一意ではない：この分類により、複数のノードインスタンスが同一の代替キー値を持つことができます。
代替キーの取得
クエリと同様に、代替キーは、コンシューマがビジネスオブジェクトノードインスタンスを検索するための最初のアクセスポイントを提供します。クエリとは異なり、トランザクションイメージで代替キー呼び出しを実行できます
次のメソッド呼び出しは、内部コンシューマーが（たとえば、アクション実装内から）代替キーを取得するために使用できます。
/ BOBF / IF_FRW_READ-> CONVERT_ALTERN_KEY（）
次のメソッド呼び出しでは、トランザクションサービスマネージャが使用されます。これは、外部コンシューマーによってトリガーされる可能性があります。たとえば、REPORTまたはUIコンポーネントによってトリガーされます。
/ BOBF / IF_TRA_SERVICE_MANAGER-> CONVERT_ALTERN_KEY（）
