Esplorazione dei connettori personalizzati certificati

Completato

Per rendere disponibile un connettore personalizzato a tutti gli utenti in App per la logica, Power Automate e Power Apps come connettore certificato, occorre inviare il connettore a Microsoft per la certificazione. Microsoft esamina il connettore e, se quest'ultimo soddisfa i criteri di certificazione, lo approva per la pubblicazione. Dopo la pubblicazione, il connettore viene incluso nell'elenco completo dei connettori disponibili pubblicamente.

Questa unità esamina ogni passaggio del processo di certificazione, inclusi alcuni passaggi generali. Questi stessi passaggi si applicano anche agli aggiornamenti successivi, che tuttavia potrebbero essere notevolmente più rapidi a seconda dell'ambito dell'aggiornamento.

Pianificazione

Il primo passaggio del processo di certificazione è la pianificazione, in cui si inizia a ideare l'aspetto del connettore. La creazione di un connettore usato anche da altri utenti prevede infatti una certa pianificazione.

Il primo passaggio nel processo di pianificazione consiste nel verificare che non esista già un connettore. Se così fosse, è opportuno considerare di contribuire al connettore esistente proponendo delle modifiche, poiché Microsoft non certifica più connettori per la stessa API.

È utile tenere presenti alcuni fattori chiave per la pianificazione, ad esempio:

  • Identificare i trigger e le azioni disponibili inizialmente. Non è necessario coprire il 100% dell'API, ma il set iniziale di trigger e azioni dovrebbe essere efficace. Se la versione iniziale risulta troppo limitata, gli utenti possono notare l'assenza di funzionalità per gli scenari comuni. È opportuno scrivere o disegnare uno o più flussi di lavoro che è possibile creare in Power Automate con il connettore. Questo approccio consente di scegliere le API da includere nel connettore.

  • Individuare le eventuali modifiche da apportare all'API per supportare i trigger o ottimizzare in altro modo l'uso del connettore.

  • Valutare come verrà gestita l'autenticazione e quali interventi di adattamento sono necessari per allineare il meccanismo di autenticazione attuale dell'API e le funzionalità supportate dei connettori personalizzati.

  • Valutare come fornire una chiave agli utenti che vogliono usare il connettore, se l'API richiede una chiave API.

  • Esaminare i modelli di criteri per determinare se l'implementazione dei modelli possa migliorare l'usabilità del connettore.

  • Esaminare le estensioni OpenAPI per verificarne l'applicabilità. Ad esempio, i connettori certificati in genere implementano la connessione di test. Inoltre, l'uso di estensioni con valori dinamici può essere utile se si hanno parametri con elenchi di valori tra cui scegliere.

Per i nuovi connettori non è necessario attendere il termine della fase di sviluppo per registrarsi per la certificazione. Per altre informazioni, vedere la documentazione relativa al processo di certificazione per editori verificati o al processo di certificazione per editori indipendenti. Prevedere di ricevere una comunicazione da un rappresentante Microsoft che faciliterà la comprensione del connettore personalizzato, illustrerà i progressi nello sviluppo e assisterà nel processo di certificazione.

La parte più importante della pianificazione in relazione agli aggiornamenti a un connettore certificato è quella di evitare di interrompere le attività degli utenti esistenti. Questo argomento verrà trattato in modo più dettagliato in un'unità successiva.

Sviluppo

L'obiettivo principale della fase di sviluppo consiste nella preparazione dell'API e nella definizione del connettore personalizzato per poterlo inviare. Prima di procedere al passaggio successivo, è necessario assicurarsi che la definizione del connettore personalizzato sia stata ripulita e includa tutti i nomi corretti per la pubblicazione.

Creazione di un connettore open source

L'unità introduttiva ha fornito una panoramica generale su come creare un connettore open source. In questo processo, i connettori certificati di editori verificati vanno inseriti nella cartella certified-connectors, mentre i connettori di editori indipendenti nella cartella independent-publisher-connectors. Prima di inviare una richiesta pull, completare le attività seguenti:

  • Modificare i file del connettore per aggiungere i metadati specifici richiesti. I file del connettore devono contenere metadati specifici che descrivono il connettore e il suo servizio finale.

  • Eseguire il comando paconn validate sul connettore scaricato e risolvere gli errori.

Per eseguire la convalida, usare il seguente comando:

paconn validate --api-def [Location of apiDefinition.swagger.json]

Dopo aver superato la convalida, è possibile inviare la richiesta pull al ramo dev del repository GitHub. Questa azione avvia un processo automatizzato che esegue la convalida iniziale della richiesta pull e verifica la presenza di un accordo di contributo valido. Una volta completata, la convalida automatica viene automaticamente assegnata a Microsoft per la revisione iniziale. Se i revisori rilevano problemi da correggere, inseriscono commenti sulla richiesta pull. I problemi devono poi essere risolti prima di inviare di nuovo la richiesta pull. Al termine della revisione, il revisore esegue il merge della richiesta pull nel repository.

Invio da editore indipendente

Se si sta pubblicando un connettore in qualità di editore indipendente, i passaggi successivi sono:

  1. Inviare gli artefatti del connettore alla richiesta pull creata al momento della proposta del connettore.

  2. Compilare l'elenco di controllo nel modello di richiesta pull.

  3. Rimuovere "Proposta -" dal titolo della richiesta pull.

Un tecnico di certificazione Microsoft fornisce un feedback entro 1-2 settimane dalla richiesta iniziale. Se il feedback richiede un aggiornamento al connettore, è necessario inviare un aggiornamento alla richiesta pull.

Invio da editore verificato

Il passaggio successivo consiste nell'inviare il connettore per la certificazione in Microsoft Power Platform ISV Studio quando il contatto Microsoft lo richiede. ISV Studio è un portale per la gestione dei passaggi restanti del processo di certificazione che determina l'integrità del connettore dopo la distribuzione.

Per l'invio del connettore a ISV Studio per la certificazione, tenere pronto quanto segue:

  • Informazioni sui test del connettore, ad esempio una chiave API, altri dettagli di autenticazione o qualsiasi suggerimento sull'utilizzo del connettore da parte del tester.

  • Un file Intro.md con le informazioni da includere nella documentazione pubblica per il connettore. Nella documentazione sull'invio a ISV Studio è disponibile un modello.

Man mano che la certificazione avanza, si riceveranno aggiornamenti nel portale e un messaggio e-mail dal contatto principale. Se si verificano problemi, è necessario risolverli prima di proseguire il processo di certificazione. Una volta superata la certificazione, il connettore dovrà essere distribuito nell'area "Anteprima" per essere sottoposto a test.

Test

Il processo di certificazione prevede che il connettore venga distribuito nell'area "Anteprima" per essere sottoposto a test. È il momento di verificare che il connettore distribuito funzioni correttamente prima di essere distribuito in tutte le aree del mondo. Assicurarsi di testare tutte le funzionalità del connettore in Power Apps, Power Automate e App per la logica.

Per altre informazioni, vedere Istruzioni per il test del connettore nella certificazione.

Distribuzione

Al termine del test, il connettore viene distribuito in tutte le aree pubbliche. La durata prevista del processo va da 7 a 10 giorni lavorativi, perché Microsoft esegue la distribuzione incrementale nelle aree di tutto il mondo. Si riceve una notifica per ogni area di distribuzione.

Supporto

Ora che il connettore è stato rilasciato pubblicamente, è possibile monitorarne le prestazioni da ISV Studio se si tratta di un connettore di editore verificato. Verificare che il personale di supporto sappia come usare il connettore con Power Apps o Power Automate per aiutare gli utenti che riscontrano problemi.