AWS パートナーセントラル API リファレンスが再構築されました。サポートされている API オペレーションの詳細については、 [AWS パートナーセントラル API リファレンス](https://docs.aws.amazon.com/partner-central/latest/APIReference/Welcome.html)を参照してください。
翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# メリットアプリケーションの使用
メリットアプリケーションは、特定のメリットに対するパートナーのリクエストをモデル化します。メリット固有の条件に従ってリクエストを評価および処理するために必要なすべての情報をキャプチャします。利点アプリケーションのライフサイクルは、ドラフトの作成から最終的な承認または拒否まで、複数の状態を経ます。
## メリットアプリケーションの作成
パートナーは、 `CreateBenefitApplication` API アクションを使用してメリットアプリケーションを作成することで、メリットリクエストプロセスを開始します。作成時にアプリケーションは `PENDING_SUBMISSION` ステータスになり、パートナーはレビューのために送信する前に完全な情報を準備することができます。
メリットアプリケーションを作成する場合、パートナーは以下を提供する必要があります。
+ **メリット識別子** - リクエストされているメリットの ID または ARN
+ **フルフィルメントタイプ** - パートナーがメリットを期待する方法 (`CREDITS`、`CASH`、`DISCOUNT`、`ACCESS``RECOGNITION`、、または `RESOURCE`)
+ **メリットアプリケーションの詳細** - メリットのリクエストスキーマで定義されたメリット固有の情報を含む JSON ドキュメント
+ **クライアントトークン **- 重複した送信を防ぐための一意のべき等性トークン
パートナーはオプションで以下を提供できます。
+ **名前と説明** - アプリケーションの人間が読み取れる識別子
+ **パートナー連絡先** - この特典リクエストを管理するユーザーの連絡先情報 (最大 1 件の連絡先)
+ **ファイル添付ファイル** - プロジェクトプラン、SOWs、コスト証明、顧客満足度調査などのサポートドキュメント (最大 10 ファイル)
+ **関連リソース** - 関連する機会または既存のメリット配分へのリンク (最大 10 リソース)
+ **タグ** - リソースの整理と追跡のためのキーと値のペア (最大 200 タグ)
`CreateBenefitApplication` API はソフト検証を実行し、基本的なフィールドタイプとパターンのみをチェックします。完全なビジネスロジックの検証は送信中に行われるため、パートナーは不完全なアプリケーションを保存し、後で戻って完了できます。
**ベストプラクティス:** パートナーは の特典リクエストスキーマを使用して`GetBenefit`、アプリケーションを作成する前に必要な情報を正確に理解する必要があります。これにより、データの欠落や無効なデータによる送信失敗の可能性が低くなります。
## メリットアプリケーションの更新
パートナーは、 `UpdateBenefitApplication` API アクションを使用して、ドラフトメリットアプリケーションを変更できます。これにより、パートナーは送信前に情報を絞り込んだり、ドキュメントを追加したり、エラーを修正したりできます。
メリットアプリケーションを更新する場合、パートナーは以下を提供する必要があります。
+ **識別子** - 更新するメリットアプリケーションの ID または ARN
+ **リビジョン** - オプティミスティックロックの現在のリビジョン番号
+ **利点アプリケーションの詳細** - 完全に更新された JSON ドキュメント
特定のフィールドのみが変更されていても、パートナーは完全なメリットアプリケーションオブジェクトを送信する必要があります。ベストプラクティスは、まず を使用して最新のアプリケーションの詳細を取得し`GetBenefitApplication`、必要なフィールドを変更してから、更新されたペイロード全体を に送信することです`UpdateBenefitApplication`。
**オプティミスティックロック:** リビジョンフィールドは、アプリケーションが最後に取得されてから変更されていない場合にのみ更新が適用されるようにします。リビジョンが現在のデータベース値と一致しない場合、更新は競合エラーで拒否されます。これにより、パートナーが他のプロセスやシステムによって行われた変更を誤って上書きすることを防ぎます。
更新は、アプリケーションが `PENDING_SUBMISSION`ステータスの場合にのみ実行できます。送信されると、アプリケーションはレビュープロセスに入り、この API を通じて更新できなくなります。
## リソースとメリットアプリケーションの関連付け
パートナーは、 `AssociateBenefitApplicationResource` API アクションを使用して、メリットアプリケーションを関連リソースにリンクできます。これにより、利点とそれらが使用されているビジネスコンテキストとの間に貴重なつながりが生まれます。
サポートされているリソースタイプは以下のとおりです。
+ **機会** - メリットアプリケーションを の特定の顧客機会にリンクします。これは、MAP 資金やカスタマーエンゲージメントに関連する POC クレジットなどの機会固有の利点に特に役立ちます。
+ **BENEFIT\_ALLOCATION** - 既存のメリット配分へのリンク。パートナーがメリットを連鎖させたり、以前のメリットがどのように活用されているかを示すことができます。
リソースの関連付けは、送信前にのみ行うことができます。メリットアプリケーションが送信されると (ステータスが に変更されると`IN_REVIEW`)、それ以上の関連付けは許可されません。パートナーは、各利点アプリケーションに最大 10 個のリソースを関連付けることができます。
リソースの関連付けを解除するには、パートナーは `DisassociateBenefitApplicationResource` API アクションを使用します。関連付けと同様に、関連付け解除は `PENDING_SUBMISSION`ステータスでのみ実行できます。
**重要**
パートナーは、メリットアプリケーションにアクセスし、関連付けられている特定のリソースを読み取るための適切なアクセス許可を持っている必要があります。API は、関連付けオペレーション中にこれらのアクセス許可を検証します。
## メリットアプリケーションの送信
メリットアプリケーションが完了し、AWSレビューの準備ができると、パートナーは `SubmitBenefitApplication` API アクションを使用してそれを送信します。送信により、 から `PENDING_SUBMISSION` への状態遷移がトリガー`IN_REVIEW`され、利点固有の承認ワークフローが開始されます。
送信時に、API は以下を含む包括的な検証を実行します。
+ **必須フィールドの検証** - 利点アプリケーションの詳細のすべての必須フィールドが存在することを確認します
+ **フィールド形式の検証** - フィールド値が予想されるパターンとデータ型と一致することを確認します
+ **ビジネスルールの検証** - 利点固有のビジネスロジックと制約を適用します
+ **リソースの検証** - 関連するすべてのリソースが有効でアクセス可能であることを確認します
+ **ファイル検証** - すべてのファイルアタッチメントが正常に処理を完了したことを確認します
検証が失敗した場合、API は修正が必要なフィールドを示す詳細なエラーコードとメッセージを含む ValidationException を返します。パートナーは、送信を再試行`UpdateBenefitApplication`する前に、 を使用してこれらの問題に対処する必要があります。
**ファイル処理要件:** アタッチされたファイルがステータスのままの場合、メリットアプリケーションを送信できません`PENDING`。パートナーは、ファイル処理が完了する (ステータスが に変更される`SUCCEEDED`) のを待ってから送信する必要があります。ファイルの処理に失敗した場合 (ステータス `FAILED`)、パートナーは修正されたバージョンをアップロードする必要があります。
送信が成功した後:
+ アプリケーションのステータスが に変わります。 `IN_REVIEW`
+ 特典所有者のチームに新しい送信が通知されます。
+ パートナーは標準更新 APIs
+ アプリケーションは、ビジネス承認、技術承認、財務承認の各段階を含む、定義された承認ワークフローに入ります。
パートナーは、アプリケーションを取得し、現在の承認ステージ (「ビジネス承認」、「技術承認」、「財務承認」など) を示すステージフィールドをモニタリングすることで、送信の進行状況を追跡できます。
## 送信済みアプリケーションの管理
送信後、パートナーには利点アプリケーションを管理するためのオプションが限られていますが、API は一般的なシナリオに対して特定のアクションを提供します。
### メリットアプリケーションの呼び出し
パートナーがエラーを検出した場合、または送信後に変更を加える必要がある場合は、 `RecallBenefitApplication` API アクションを使用してアプリケーションを呼び出すことができます。リコールはアプリケーションを `PENDING_SUBMISSION`ステータスに移行し、更新と再送信を可能にします。
アプリケーションを呼び出す場合、パートナーは以下を提供する必要があります。
+ **識別子** - リコールするメリットアプリケーションの ID または ARN
+ **理由** - リコールに関するオプションの説明 (最大 1000 文字)
理由フィールドを使用すると、トレーサビリティが向上し、リコールにつながる一般的な問題AWSを理解し、メリットアプリケーションプロセスの今後の改善に役立てることができます。
リコール後、パートナーは `UpdateBenefitApplication`を使用して必要な変更を行い、準備`SubmitBenefitApplication`ができたら を使用して再送信できます。
**重要**
リコールは通常、早期レビュー段階でのみ使用できます。後の承認段階に進んだアプリケーションや承認されたアプリケーションは、リコールの対象とならない場合があります。
### メリットアプリケーションの修正
送信後の軽微な修正の場合、パートナーは `AmendBenefitApplication` API アクションを使用して、アプリケーション全体を呼び出すことなく特定のフィールドを更新できます。これは、AWSレビュープロセス中にレビュアーが明確化または修正をリクエストする場合に特に便利です。
修正では、パートナーが以下を指定する JSON パッチ形式のアプローチを使用します。
+ **パス** - 更新するフィールドを識別する JSONPath 式 (例: `$.CreditDisbursementDetails.AwsAccountIdForCredits`)
+ **値** - フィールドの新しい値
+ **オペレーション** - 実行するオペレーション (現在`REPLACE`は のみサポートされています)
パートナーは、1 回の API コールで最大 10 件の修正を送信できます。各修正には、オプティミスティックロック用に更新されたリビジョン番号を含める必要があります。
軽微な修正には修正を使用する必要があります。大幅な変更を行う場合は、 `RecallBenefitApplication`を使用してアプリケーションをドラフトステータスに戻し、包括的な更新を行う必要があります。
### メリットアプリケーションのキャンセル
パートナーに利点がなくなった場合、またはアプリケーションの取り消しを希望する場合は、 `CancelBenefitApplication` API アクションを使用してキャンセルできます。キャンセルすると、アプリケーションは `CANCELED` ステータスに移行し、アプリケーションプロセスが完全に終了します。
アプリケーションをキャンセルする場合、パートナーは以下を提供する必要があります。
+ **識別子** - キャンセルする特典アプリケーションの ID または ARN
+ **理由** - キャンセルのオプションの説明 (最大 1000 文字)
キャンセルされると、アプリケーションを再アクティブ化することはできません。パートナーが後でメリットが必要と判断した場合は、新しいメリットアプリケーションを作成する必要があります。
キャンセルの一般的な理由は次のとおりです。
+ 顧客の機会が失われた、または遅延した
+ パートナー容量の制約が変更されました
+ ビジネスの優先順位の移行
+ 意図した目的にメリットが不要になった
## メリットアプリケーションの詳細の表示
パートナーは、 `GetBenefitApplication` API アクションを使用してメリットアプリケーションに関する完全な情報を取得できます。これにより、以下を含むアプリケーションの包括的なビューが提供されます。
**アプリケーションメタデータ:**
+ 一意の識別子 (ID) と Amazon リソースネーム (ARN)
+ 関連するメリット識別子
+ アプリケーション名と説明
+ 現在のステータス (`PENDING_SUBMISSION`、`IN_REVIEW`、`ACTION_REQUIRED`、`APPROVED`、`REJECTED`、または `CANCELED`)
+ 現在の処理ステージ
**ステータス情報:**
+ ステータスの理由 - 現在のステータスの人間が読み取れる説明
+ ステータス理由コード - 特定の問題または要件を示す構造化コード (「Checklist Incomplete」、「Project Plan Missing」、「Design Win Missing」など)
**アプリケーションコンテンツ:**
+ 完全なメリットアプリケーションの詳細 JSON ドキュメント
+ パートナーの連絡先情報
+ 処理ステータスの添付ファイル
+ 関連付けられたリソース (機会または割り当て)
+ リソースタグ
**監査情報:**
+ 作成タイムスタンプ
+ 最終変更タイムスタンプ
+ 現在のリビジョン番号
ステータス理由コードは、アプリケーションが `ACTION_REQUIRED`ステータスの場合に特に役立ちます。これらのコードは、アプリケーションを進めるためにパートナーが対処する必要があることに関する具体的で実用的なガイダンスを提供します。
## メリットアプリケーションの一覧表示
パートナーは、 `ListBenefitApplications` API アクションを使用してすべての利点アプリケーションを表示できます。これにより、強力なフィルタリング機能を備えたアプリケーション概要のページ分割されたリストが返されます。
パートナーは、次の方法でアプリケーションをフィルタリングできます。
+ **プログラム** - 特定のプログラム (MAP、MDF、サンドボックス、POC など) のアプリケーションを表示します。
+ **フルフィルメントタイプ** - 配信方法 (`CREDITS`、`CASH`、 `ACCESS`など) でフィルタリングする
+ **メリット識別子** - 特定のメリットのアプリケーションを表示する
+ **ステータス** - アプリケーションステータス (`PENDING_SUBMISSION`、`IN_REVIEW`、、`REJECTED`、`CANCELED`) でフィルタリング`APPROVED`します。
+ **ステージ** - 承認ステージ (ビジネス承認、技術承認、財務承認) でフィルタリングする
+ **関連付けられたリソース ARNs** - 特定の機会または割り当てにリンクされたアプリケーションを検索する
リストレスポンスには、次のような重要な概要情報が含まれます。
+ アプリケーション ID、ARN、および名前
+ 関連付けられた利点 ID
+ プログラムとフルフィルメントタイプ
+ 現在のステータスとステージ
+ 作成と変更のタイムスタンプ
+ 関連リソース
+ 現在のリビジョン番号
+ 特典アプリケーションの詳細から選択されたフィールド (特典所有者が定義)
パートナーは、Sort パラメータを使用して結果のソートを設定できます。これには、作成日、ステータス、プログラム、または利点識別子で昇順または降順でソートするオプションがあります。
**ダッシュボードの構築:** `ListBenefitApplications` API は、パートナーダッシュボードの作成をサポートするように設計されています。アプリケーションをフィルタリングおよびソートすることで、パートナーは次のようなビューを構築できます。
+ アクションが必要なアプリケーション (`ACTION_REQUIRED` ステータス)
+ 最近送信されたアプリケーション (作成日、`IN_REVIEW`ステータスでソート)
+ 割り当て保留中の承認済みアプリケーション (`APPROVED` ステータス)
+ プログラムによるアプリケーション (特定のプログラムでフィルタリング)