La référence de AWS Partner Central l'API a été restructurée. Pour plus d'informations sur les opérations d'API prises en charge, consultez la référence des AWS Partner Central API.

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisation des demandes de prestations

Une demande de prestation modélise la demande d'un partenaire pour un avantage spécifique. Il saisit toutes les informations nécessaires pour évaluer et traiter la demande en fonction des conditions spécifiques à la prestation. Le cycle de vie des demandes de prestations passe par plusieurs étapes, de la création du brouillon à l'approbation finale ou au rejet.

Création de demandes de prestations

Les partenaires lancent le processus de demande de prestations en créant une demande de prestations à l'aide de l'action CreateBenefitApplication API. Lors de sa création, la demande entre en PENDING_SUBMISSION statut, ce qui permet aux partenaires de préparer des informations complètes avant de les soumettre pour examen.

Lors de la création d'une demande de prestations, les partenaires doivent fournir :

Les partenaires peuvent éventuellement fournir :

L'CreateBenefitApplicationAPI effectue une validation souple, en vérifiant uniquement les types de champs et les modèles de base. La validation complète de la logique métier a lieu lors de la soumission, ce qui permet aux partenaires de sauvegarder les demandes incomplètes et de revenir plus tard pour les compléter.

Bonne pratique : Les partenaires doivent utiliser le schéma de demande de prestations de GetBenefit pour comprendre exactement quelles informations sont requises avant de créer une demande. Cela réduit le risque d'échec de la soumission en raison de données manquantes ou non valides.

Mise à jour des demandes de prestations

Les partenaires peuvent modifier les projets de demandes de prestations à l'aide de UpdateBenefitApplication l'action API. Cela permet aux partenaires d'affiner les informations, d'ajouter de la documentation ou de corriger des erreurs avant la soumission.

Lors de la mise à jour d'une demande de prestations, les partenaires doivent fournir :

Les partenaires doivent soumettre l'objet complet de la demande de prestations, même si seuls des champs spécifiques sont modifiés. La meilleure pratique consiste à d'abord récupérer les derniers détails de l'application à l'aide deGetBenefitApplication, à modifier les champs nécessaires, puis à envoyer la charge utile complète mise à jour àUpdateBenefitApplication.

Verrouillage optimiste : le champ de révision garantit que les mises à jour ne sont appliquées que si l'application n'a pas changé depuis sa dernière récupération. Si la révision ne correspond pas à la valeur actuelle de la base de données, la mise à jour est rejetée avec une erreur de conflit. Cela empêche les partenaires de remplacer accidentellement les modifications apportées par d'autres processus ou systèmes.

Les mises à jour ne peuvent être effectuées que lorsque l'application est en cours PENDING_SUBMISSION de traitement. Une fois soumises, les candidatures entrent dans le processus d'évaluation et ne peuvent plus être mises à jour via cette API.

Associer des ressources aux demandes de prestations

Les partenaires peuvent associer les demandes de prestations à des ressources associées à l'aide de l'action AssociateBenefitApplicationResource API. Cela crée des liens précieux entre les avantages et le contexte commercial dans lequel ils sont utilisés.

Les types de ressources pris en charge incluent :

L'association de ressources ne peut avoir lieu qu'avant la soumission. Une fois qu'une demande de prestations est soumise (changement de statutIN_REVIEW), aucune autre association n'est autorisée. Les partenaires peuvent associer jusqu'à 10 ressources à chaque demande de prestation.

Pour dissocier une ressource, les partenaires utilisent l'action d'DisassociateBenefitApplicationResourceAPI. Tout comme l'association, la dissociation ne peut se produire que dans le PENDING_SUBMISSION statut.

Soumission des demandes de prestations

Lorsqu'une demande de prestations est complète et prête à être AWS examinée, les partenaires la soumettent à l'aide de l'action SubmitBenefitApplication API. La soumission déclenche une transition d'état de PENDING_SUBMISSION à IN_REVIEW et lance le flux de travail d'approbation spécifique à l'avantage.

Lors de la soumission, l'API effectue une validation complète, notamment :

Si la validation échoue, l'API renvoie un message contenant ValidationException des codes d'erreur détaillés et des messages indiquant quels champs doivent être corrigés. Les partenaires doivent résoudre ces problèmes UpdateBenefitApplication avant de tenter à nouveau de soumettre.

Exigence en matière de traitement des dossiers : Les demandes de prestations ne peuvent pas être soumises si les fichiers joints sont toujours en cours PENDING de traitement. Les partenaires doivent attendre la fin du traitement du dossier (changement de statutSUCCEEDED) avant de le soumettre. Si le traitement des fichiers échoue (statutFAILED), les partenaires doivent télécharger les versions corrigées.

Après une soumission réussie :

Les partenaires peuvent suivre la progression de la soumission en récupérant la demande et en surveillant le champ Étape, qui indique l'étape d'approbation en cours (par exemple, « Approbation commerciale », « Approbation technique », « Approbation financière »).

Gestion des candidatures soumises

Une fois soumises, les partenaires disposent d'options limitées pour gérer les demandes de prestations, mais l'API propose des actions spécifiques pour les scénarios courants.

Rappel des demandes de prestations

Si un partenaire découvre une erreur ou doit apporter des modifications après la soumission, il peut rappeler l'application à l'aide de l'action de l'RecallBenefitApplicationAPI. Recall fait revenir la demande à son PENDING_SUBMISSION statut, ce qui permet des mises à jour et une nouvelle soumission.

Lors du rappel d'une demande, les partenaires doivent fournir :

Le champ Motif permet une meilleure traçabilité et aide à AWS comprendre les problèmes courants à l'origine des rappels, ce qui permettra d'apporter des améliorations futures au processus de demande de prestations.

Après le rappel, les partenaires peuvent l'utiliser UpdateBenefitApplication pour apporter les modifications nécessaires, puis les soumettre à nouveau SubmitBenefitApplication lorsqu'ils sont prêts.

Modification des demandes de prestations

Pour les corrections mineures après la soumission, les partenaires peuvent utiliser l'action de l'AmendBenefitApplicationAPI pour mettre à jour des champs spécifiques sans rappeler l'intégralité de l'application. Cela est particulièrement utile lorsque les AWS réviseurs demandent des éclaircissements ou des corrections au cours du processus de révision.

Les modifications utilisent une Patch-style approche JSON dans laquelle les partenaires spécifient :

Les partenaires peuvent soumettre jusqu'à 10 modifications en un seul appel d'API. Chaque modification doit inclure un numéro de révision mis à jour pour un verrouillage optimiste.

Les modifications doivent être utilisées pour les corrections mineures. En cas de modifications importantes, les partenaires doivent RecallBenefitApplication renvoyer la demande au statut d'ébauche pour des mises à jour complètes.

Annulation des demandes de prestations

Si un partenaire n'a plus besoin d'un avantage ou souhaite retirer sa candidature, il peut l'annuler à l'aide de l'action CancelBenefitApplication API. L'annulation fait passer la demande au CANCELED statut, mettant fin définitivement au processus de candidature.

Lors de l'annulation d'une candidature, les partenaires doivent fournir :

Une fois annulées, les applications ne peuvent pas être réactivées. Si le partenaire décide ultérieurement qu'il a besoin de la prestation, il doit créer une nouvelle demande de prestation.

Les raisons courantes d'annulation sont les suivantes :

Affichage des détails de la demande de prestations

Les partenaires peuvent récupérer des informations complètes sur une demande de prestations à l'aide de l'action GetBenefitApplication API. Cela fournit une vue complète de l'application, y compris :

Métadonnées de l'application :

Informations sur le statut :

Contenu de l'application :

Informations d'audit :

Les codes de motif de statut sont particulièrement utiles lorsqu'une demande est en cours de ACTION_REQUIRED traitement. Ces codes fournissent des conseils spécifiques et pratiques sur les points que les partenaires doivent prendre en compte pour que la demande soit traitée.

Liste des demandes de prestations

Les partenaires peuvent consulter toutes leurs demandes d'avantages à l'aide de l'action de l'ListBenefitApplicationsAPI. Cela renvoie une liste paginée de résumés d'applications avec de puissantes fonctionnalités de filtrage.

Les partenaires peuvent filtrer les candidatures selon les critères suivants :

La réponse à la liste comprend des informations récapitulatives essentielles telles que :

Les partenaires peuvent configurer le tri des résultats à l'aide du paramètre Sort, avec des options permettant de trier par date de création, statut, programme ou identifiant de prestation dans l'ordre croissant ou décroissant.

Création de tableaux de bord : l'ListBenefitApplicationsAPI est conçue pour faciliter la création de tableaux de bord pour les partenaires. En filtrant et en triant les applications, les partenaires peuvent créer des vues telles que :