L' Centrale Partner AWS API Reference è stato ristrutturato. Per ulteriori informazioni sulle operazioni API supportate, consulta l'[Centrale Partner AWS API Reference.](https://docs.aws.amazon.com/partner-central/latest/APIReference/Welcome.html)
Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Lavorare con Benefit Applications
Un'applicazione Benefit modella la richiesta di un partner per un vantaggio specifico. Acquisisce tutte le informazioni necessarie per valutare ed elaborare la richiesta in base alle condizioni specifiche del beneficio. Il ciclo di vita della richiesta di benefit procede attraverso più fasi, dalla creazione della bozza all'approvazione o al rifiuto finali.
## Creazione di applicazioni Benefit
I partner avviano il processo di richiesta dei benefit creando una richiesta di benefit utilizzando l'azione `CreateBenefitApplication` API. Al momento della creazione, la domanda passa `PENDING_SUBMISSION` allo stato attuale, che consente ai partner di preparare informazioni complete prima di inviarle per la revisione.
Quando creano una domanda di benefit, i partner devono fornire:
+ **Identificatore del vantaggio**: l'ID o l'ARN del vantaggio richiesto
+ **Tipi di adempimento**: in che modo il partner prevede di ricevere il vantaggio (`CREDITS`,,,`CASH`, `DISCOUNT` o) `ACCESS` `RECOGNITION` `RESOURCE`
+ **Dettagli sulla richiesta del benefit**: un documento JSON contenente informazioni specifiche sui vantaggi, come definito dallo schema di richiesta del benefit
+ **Client Token: un token** di idempotenza unico per prevenire invii duplicati
I partner possono fornire facoltativamente:
+ **Nome e descrizione**: Human-readable identificatori dell'applicazione
+ **Contatti per i partner**: informazioni di contatto della persona che gestisce questa richiesta di benefit (massimo 1 contatto)
+ **File allegati**: documentazione di supporto come piani di progetto, SOW, prove dei costi o sondaggi sulla soddisfazione dei clienti (massimo 10 file)
+ **Risorse associate**: collegamenti alle opportunità correlate o alle allocazioni di vantaggi esistenti (massimo 10 risorse)
+ **Tag**: Key-value coppie per l'organizzazione e il monitoraggio delle risorse (massimo 200 tag)
L'`CreateBenefitApplication`API esegue la convalida software, controllando solo i tipi e i modelli di campo di base. La convalida completa della logica aziendale avviene durante l'invio, consentendo ai partner di salvare le candidature incomplete e di ritornare in un secondo momento per completarle.
**Best practice:** i partner devono utilizzare lo schema di richiesta dei vantaggi `GetBenefit` per comprendere esattamente quali informazioni sono necessarie prima di creare una domanda. Ciò riduce la probabilità di errori di invio dovuti a dati mancanti o non validi.
## Aggiornamento delle applicazioni Benefit
I partner possono modificare le bozze di richiesta di benefit utilizzando l'azione `UpdateBenefitApplication` API. Ciò consente ai partner di perfezionare le informazioni, aggiungere documentazione o correggere gli errori prima dell'invio.
Quando aggiornano una domanda di benefit, i partner devono fornire:
+ **Identificatore**: l'ID o l'ARN della domanda di benefit da aggiornare
+ **Revisione**: il numero di revisione corrente per il blocco ottimistico
+ **Dettagli dell'applicazione Benefit**: il documento JSON completo e aggiornato
I partner devono presentare l'oggetto completo della domanda di benefit, anche se vengono modificati solo campi specifici. La migliore pratica consiste nel recuperare innanzitutto i dettagli più recenti della domanda utilizzando`GetBenefitApplication`, modificare i campi necessari, quindi inviare il payload aggiornato completo a. `UpdateBenefitApplication`
**Blocco ottimistico:** il campo di revisione garantisce che gli aggiornamenti vengano applicati solo se l'applicazione non è stata modificata dall'ultima volta che è stata recuperata. Se la revisione non corrisponde al valore corrente del database, l'aggiornamento viene rifiutato con un errore di conflitto. Ciò impedisce ai partner di sovrascrivere accidentalmente le modifiche apportate da altri processi o sistemi.
Gli aggiornamenti possono essere eseguiti solo mentre l'applicazione è in `PENDING_SUBMISSION` stato. Una volta inviate, le candidature entrano nel processo di revisione e non possono più essere aggiornate tramite questa API.
## Associazione delle risorse alle applicazioni Benefit
I partner possono collegare le applicazioni relative ai benefit alle risorse correlate utilizzando l'azione `AssociateBenefitApplicationResource` API. Ciò crea connessioni preziose tra i vantaggi e il contesto aziendale in cui vengono utilizzati.
I tipi di risorsa supportati includono:
+ **OPPORTUNITÀ**: collega la richiesta di benefit a una specifica opportunità per il cliente in. Ciò è particolarmente utile per vantaggi specifici legati alle opportunità, come i finanziamenti MAP o i crediti POC legati al coinvolgimento dei clienti.
+ **BENEFIT\_ALLOCATION - Collegamento alle allocazioni** di benefit esistenti, per consentire ai partner di concatenare i vantaggi o dimostrare come vengono sfruttati i vantaggi precedenti
L'associazione delle risorse può avvenire solo prima dell'invio. Una volta inviata la domanda di sussidio (lo stato cambia in`IN_REVIEW`), non sono consentite ulteriori associazioni. I partner possono associare fino a 10 risorse a ciascuna domanda di benefit.
Per dissociare una risorsa, i partner utilizzano l'azione `DisassociateBenefitApplicationResource` API. Come l'associazione, la dissociazione può avvenire solo a `PENDING_SUBMISSION` livello di status.
**Importante**
I partner devono disporre delle autorizzazioni appropriate per accedere alla domanda di benefit e leggere la risorsa specifica associata. L'API convalida queste autorizzazioni durante l'operazione di associazione.
## Invio delle domande di indennità
Quando una richiesta di benefit è completa e pronta per essere AWS esaminata, i partner la inviano utilizzando l'azione `SubmitBenefitApplication` API. L'invio attiva una transizione di stato da `PENDING_SUBMISSION` a `IN_REVIEW` e avvia il flusso di lavoro di approvazione specifico per i vantaggi.
Al momento dell'invio, l'API esegue una convalida completa, tra cui:
+ **Convalida dei campi obbligatori**: garantisce la presenza di tutti i campi obbligatori nei dettagli della richiesta di benefit
+ **Convalida del formato dei campi**: verifica che i valori dei campi corrispondano ai modelli e ai tipi di dati previsti
+ **Convalida delle regole aziendali**: applica la logica e i vincoli aziendali specifici dei vantaggi
+ **Convalida delle risorse**: conferma che tutte le risorse associate sono valide e accessibili
+ **Convalida dei file**: verifica che l'elaborazione di tutti i file allegati sia stata completata correttamente
Se la convalida fallisce, l'API restituisce un messaggio ValidationException con codici di errore dettagliati e messaggi che indicano quali campi richiedono una correzione. I partner devono risolvere questi problemi utilizzando `UpdateBenefitApplication` prima di tentare nuovamente l'invio.
**Requisito di elaborazione dei file:** le domande di indennità non possono essere inviate se i file allegati sono ancora presenti`PENDING`. I partner devono attendere il completamento dell'elaborazione dei file (modifica dello stato`SUCCEEDED`) prima dell'invio. Se l'elaborazione dei file fallisce (stato`FAILED`), i partner devono caricare le versioni corrette.
Dopo l'invio avvenuto con successo:
+ Lo stato della domanda cambia in `IN_REVIEW`
+ Il team del titolare del benefit riceve una notifica della nuova presentazione
+ I partner non possono più modificare i dettagli dell'applicazione tramite API di aggiornamento standard
+ L'applicazione entra in un flusso di lavoro di approvazione definito che può includere fasi di approvazione aziendale, approvazione tecnica e approvazione finanziaria
I partner possono monitorare lo stato di avanzamento dell'invio recuperando l'applicazione e monitorando il campo Stage, che indica la fase di approvazione corrente (ad esempio, «Approvazione aziendale», «Approvazione tecnica», «Approvazione finanziaria»).
## Gestione delle candidature inviate
Una volta inviate, i partner dispongono di opzioni limitate per la gestione delle richieste di benefit, ma l'API fornisce azioni specifiche per scenari comuni.
### Richiamo delle applicazioni Benefit
Se un partner rileva un errore o deve apportare modifiche dopo l'invio, può richiamare l'applicazione utilizzando l'azione API. `RecallBenefitApplication` Recall ripristina `PENDING_SUBMISSION` lo stato dell'applicazione, consentendone gli aggiornamenti e il reinvio.
Quando richiamano una domanda, i partner devono fornire:
+ **Identificatore**: l'ID o l'ARN della richiesta di benefit da richiamare
+ **Motivo**: una spiegazione facoltativa per il richiamo (massimo 1000 caratteri)
Il campo del motivo consente una migliore tracciabilità e aiuta a AWS comprendere i problemi comuni che portano ai richiami, fornendo informazioni per i futuri miglioramenti del processo di richiesta dei vantaggi.
Dopo il richiamo, i partner possono utilizzarlo `UpdateBenefitApplication` per apportare le modifiche necessarie e inviarlo nuovamente quando sono pronti. `SubmitBenefitApplication`
**Importante**
Il richiamo è in genere disponibile solo durante le fasi iniziali di revisione. Le domande che sono passate a fasi di approvazione successive o che sono state approvate potrebbero non essere richiamabili.
### Modifica delle domande di indennità
Per correzioni minori dopo l'invio, i partner possono utilizzare l'azione `AmendBenefitApplication` API per aggiornare campi specifici senza richiamare l'intera applicazione. Ciò è particolarmente utile quando AWS i revisori richiedono chiarimenti o correzioni durante il processo di revisione.
Gli emendamenti utilizzano un approccio JSON Patch-style in cui i partner specificano:
+ **Path**: un'espressione JSONPath che identifica il campo da aggiornare (ad esempio,) `$.CreditDisbursementDetails.AwsAccountIdForCredits`
+ **Valore**: il nuovo valore per il campo
+ **Operazione**: l'operazione da eseguire (attualmente `REPLACE` è supportata solo)
I partner possono inviare fino a 10 modifiche in una singola chiamata API. Ogni modifica deve includere un numero di revisione aggiornato per un blocco ottimistico.
Gli emendamenti devono essere utilizzati per correzioni minori. In caso di modifiche sostanziali, i partner dovrebbero `RecallBenefitApplication` riportare l'applicazione allo stato di bozza per aggiornamenti completi.
### Annullamento delle richieste di benefit
Se un partner non ha più bisogno di un vantaggio o desidera ritirare la propria candidatura, può annullarla utilizzando l'azione `CancelBenefitApplication` API. L'annullamento fa passare la domanda allo `CANCELED` stato attuale, terminando definitivamente il processo di candidatura.
Quando annullano una candidatura, i partner devono fornire:
+ **Identificatore**: l'ID o l'ARN della richiesta di indennità da annullare
+ **Motivo**: una spiegazione facoltativa per l'annullamento (massimo 1000 caratteri)
Una volta annullate, le applicazioni non possono essere riattivate. Se in un secondo momento il partner decide di aver bisogno del vantaggio, deve creare una nuova richiesta di benefit.
I motivi più comuni di annullamento includono:
+ L'opportunità offerta dal cliente è stata persa o è stata ritardata
+ I vincoli di capacità dei partner sono cambiati
+ Le priorità aziendali sono cambiate
+ I vantaggi non sono più necessari per lo scopo previsto
## Visualizzazione dei dettagli della domanda Benefit
I partner possono recuperare informazioni complete su una richiesta di benefit utilizzando l'azione `GetBenefitApplication` API. Ciò fornisce una visione completa dell'applicazione, tra cui:
**Metadati dell'applicazione:**
+ Identificatore univoco (ID) e Amazon Resource Name (ARN)
+ Identificatore del benefit associato
+ Nome e descrizione dell'applicazione
+ Stato attuale (`PENDING_SUBMISSION`,`IN_REVIEW`,`ACTION_REQUIRED`,`APPROVED`,`REJECTED`, o`CANCELED`)
+ Fase di elaborazione attuale
**Informazioni sullo stato:**
+ Motivo dello stato: Human-readable spiegazione dello stato attuale
+ Codici dei motivi dello stato: codici strutturati che indicano problemi o requisiti specifici (ad esempio, «Elenco di controllo incompleto», «Piano di progetto mancante», «Design Win Missing»)
**Contenuto della domanda:**
+ Documento JSON completo con dettagli sulla richiesta dei vantaggi
+ Informazioni di contatto per i partner
+ Allegati di file con stato di elaborazione
+ Risorse associate (opportunità o allocazioni)
+ Tag delle risorse
**Informazioni sull'audit:**
+ Timestamp di creazione
+ Data e ora dell'ultima modifica
+ Numero di revisione corrente
I codici motivazionali dello stato sono particolarmente utili quando una domanda è in corso`ACTION_REQUIRED`. Questi codici forniscono indicazioni specifiche e attuabili su ciò che i partner devono affrontare per procedere con la richiesta.
## Elenco delle domande di benefit
I partner possono visualizzare tutte le loro applicazioni di benefit utilizzando l'azione `ListBenefitApplications` API. Ciò restituisce un elenco impaginato di riepiloghi delle applicazioni con potenti funzionalità di filtraggio.
I partner possono filtrare le applicazioni in base a:
+ **Programma**: visualizza le applicazioni per programmi specifici (MAP, MDF, Sandbox, POC, ecc.)
+ **Tipo di evasione: filtra** per metodo di consegna (`CREDITS`,, `CASH` ecc.) `ACCESS`
+ **Identificatore del vantaggio**: visualizza le candidature relative a un vantaggio specifico
+ **Stato**: filtra per stato dell'applicazione (`PENDING_SUBMISSION`,`IN_REVIEW`,, `APPROVED``REJECTED`,`CANCELED`)
+ **Fase**: filtra per fase di approvazione (approvazione aziendale, approvazione tecnica, approvazione finanziaria)
+ **ARN di risorse associate**: trova applicazioni collegate a opportunità o allocazioni specifiche
La risposta all'elenco include informazioni di riepilogo essenziali come:
+ ID, ARN e nome dell'applicazione
+ ID del benefit associato
+ Programmi e tipi di adempimento
+ Stato e fase attuali
+ Timestamp di creazione e modifica
+ Risorse associate
+ Numero di revisione corrente
+ Campi selezionati dai dettagli della domanda di benefit (come definito dal titolare del benefit)
I partner possono configurare l'ordinamento dei risultati utilizzando il parametro Sort, con opzioni di ordinamento per data di creazione, stato, programma o identificatore del benefit in ordine crescente o decrescente.
**Creazione di dashboard:** l'`ListBenefitApplications`API è progettata per supportare la creazione di dashboard per i partner. Filtrando e ordinando le applicazioni, i partner possono creare visualizzazioni come:
+ Applicazioni che richiedono un'azione (`ACTION_REQUIRED`stato)
+ Candidature inviate di recente (ordinate per data di creazione, `IN_REVIEW` stato)
+ Domande approvate in attesa di assegnazione (stato) `APPROVED`
+ Applicazioni per programma (filtrate per programmi specifici)