Certificazione del connettore Data Factory

I proprietari dell'origine dati che sviluppano un connettore personalizzato per l'origine dati potrebbero voler distribuire il connettore personalizzato in modo più ampio agli utenti di Data Factory. Dopo aver creato, usato e convalidato un connettore personalizzato dagli utenti finali, il proprietario dell'origine dati può inviarlo per la certificazione Microsoft.

La certificazione di un connettore Data Factory rende il connettore disponibile pubblicamente, predefinito, Microsoft Fabric Data Factory e Microsoft Power BI nelle esperienze seguenti:

• Microsoft Fabric Dataflow Gen2
• Microsoft Power BI Dataflow Gen1
• Microsoft Power BI Datamart
• Modello semantico di Microsoft Power BI (nel servizio Power BI)
• Microsoft Power BI Desktop
• Gateway dati locale per Microsoft Fabric e Microsoft Power BI

I connettori certificati sono:

• Gestito dallo sviluppatore partner

• Supportato dallo sviluppatore partner

• Certificato da Microsoft

• Distribuito da Microsoft

Microsoft collabora con i partner per verificare che dispongano del supporto per la manutenzione, ma i problemi dei clienti con il connettore stesso vengono indirizzati allo sviluppatore partner.

Cenni preliminari sulla certificazione

Prerequisiti

Per garantire la migliore esperienza per i clienti, vengono considerati solo i connettori che soddisfano un set di prerequisiti per la certificazione:

• Il connettore deve essere per un prodotto pubblico.

• Il connettore deve essere considerato completo del codice per una versione di versione iniziale. Il programma consente iterazioni e aggiornamenti frequenti. Microsoft non offre assistenza tecnica o consulenza per lo sviluppo di connettori personalizzati. È consigliabile usare risorse pubbliche, ad esempio la documentazione dell'SDK e il repository di esempi. Se hai bisogno di ulteriore assistenza, possiamo condividere un elenco di noti consulenti per lo sviluppo di connettori personalizzati del settore di terze parti che potresti voler coinvolgere direttamente, separati da qualsiasi programma o partnership Microsoft. Microsoft non è affiliata a nessuno di questi consulenti e non è responsabile dell'uso dei propri servizi. Microsoft fornisce l'elenco per praticità e senza garanzie, raccomandazioni o garanzie. Per altre informazioni, contattare il contatto di certificazione Microsoft.

• Lo sviluppatore deve fornire una stima per l'utilizzo corrente e futuro.

• Il connettore deve essere già reso disponibile ai clienti direttamente per soddisfare le esigenze degli utenti o uno scenario aziendale. Questi criteri possono essere soddisfatti usando un programma di anteprima privata distribuendo il connettore completato direttamente agli utenti finali e alle organizzazioni. È consigliabile che gli sviluppatori di connettori usino un meccanismo di distribuzione automatica ed eseguano test interni dei propri connettori per scorrere i connettori in un gruppo controllato. Ogni utente o organizzazione deve essere in grado di fornire commenti e suggerimenti e convalidare la necessità aziendale del connettore e che il connettore funzioni correttamente per soddisfare i requisiti aziendali.

• Il connettore deve funzionare correttamente a un livello previsto di utilizzo da parte dei clienti.

• Deve essere presente un thread nel forum Idee sull'infrastruttura guidato dai clienti per indicare la richiesta di rendere il connettore disponibile pubblicamente in Data Factory e/o Power BI. Non esiste una soglia di engagement impostata. Tuttavia, maggiore è l'impegno, maggiore è la domanda evidenziata per il connettore.

Questi prerequisiti esistono per garantire che i connettori sottoposti a certificazione abbiano un cliente e un'azienda significativi devono essere usati per e supportare la post-certificazione.

Processi e sequenze temporali

I connettori certificati vengono rilasciati con versioni mensili di Power BI Desktop, quindi le scadenze per ogni versione funzionano da ogni data di rilascio di Power BI Desktop. La durata prevista del processo di certificazione dalla registrazione alla versione varia a seconda della qualità e della complessità dell'invio del connettore. Microsoft non fornisce garanzie specifiche sulla sequenza temporale per quanto riguarda la revisione e l'approvazione del connettore. Le scadenze rigide per ogni revisione del connettore sono descritte nei passaggi seguenti, ma Microsoft non garantisce la conformità a queste sequenze temporali.

• Registrazione: notifica della finalità per certificare il connettore personalizzato. Questa registrazione deve essere eseguita entro il 15 del mese, due mesi prima del rilascio di Power BI Desktop di destinazione.

  • Ad esempio, per la versione di Aprile di Power BI Desktop, la scadenza sarà il 15 febbraio.

• Invio: invio di file del connettore per la revisione di Microsoft. Questo invio deve verificarsi entro il primo mese prima del rilascio di Power BI Desktop di destinazione.

  • Ad esempio, per la versione di Aprile di Power BI Desktop, la scadenza sarà il 1° marzo.

• Revisione tecnica: finalizzazione dei file del connettore, passando la revisione e la certificazione Microsoft. Questa verifica deve verificarsi entro il 15 del mese prima del rilascio di Power BI Desktop di destinazione.

  • Ad esempio, per la versione di Aprile di Power BI Desktop, la scadenza sarà il 15 marzo.

A causa della complessità delle revisioni tecniche e dei potenziali ritardi, della riprogettazione e dei problemi di test, è consigliabile inviare in anticipo con un lungo lead time per il rilascio iniziale e la certificazione.

Requisiti di certificazione

Abbiamo un determinato set di requisiti per la certificazione. Microsoft riconosce che non tutti gli sviluppatori possono soddisfare questi requisiti e si spera di introdurre un set di funzionalità che gestirà le esigenze dello sviluppatore in breve ordine.

File di invio (artefatti)

Verificare che nell'invio siano inclusi i file di connettore seguenti:

• File connettore (con estensione mez)

  • Il file con estensione mez deve seguire gli standard di stile e deve essere denominato in modo analogo al nome del prodotto o del servizio. Non deve includere parole come "Fabric", "Power BI", "Connector" o "API".
  • Denominare il file con estensione mez: ProductName.mez

• File di Power BI Desktop (con estensione pbix) per i test

  • Per testare il connettore, è necessario un report di Power BI di esempio (con estensione pbix).
  • Il report deve includere almeno una query per testare ogni elemento nella tabella di spostamento.
  • Se non esiste uno schema impostato, ad esempio database, il report deve includere una query per ogni "tipo" di tabella che il connettore potrebbe gestire.

• Testare l'account nell'origine dati

  • L'account di test viene usato per testare e risolvere i problemi del connettore.
  • Fornire un account di test permanente, in modo da poter usare lo stesso account per certificare eventuali aggiornamenti futuri.

• Istruzioni di test

  • Fornire qualsiasi documentazione su come usare il connettore e testarne le funzionalità.

• Collegamenti a dipendenze esterne (ad esempio, driver ODBC)

Caratteristiche e stile

Il connettore deve seguire un set di regole di funzionalità e stile per soddisfare uno standard di usabilità coerente con altri connettori certificati.

• Il connettore DEVE:

  • Usare il formato del documento sezione.
  • Contiene un'intestazione o una struttura della versione sopra il documento di sezione.
  • Specificare i metadati della documentazione della funzione.
  • Disporre del gestore TestConnection.
  • Seguire le convenzioni di denominazione , ad esempio DataSourceKind.FunctionName. Non deve includere parole come "Fabric", "Power BI", "Connector" o "API".
  • Restituisce dati in formato tabulare, organizzati in tabelle con colonne, come per un'origine dati relazionale. I formati multidimensionali basati su cubi, dimensioni e misure non sono supportati.
  • Si comportano allo stesso modo in modalità Import e DirectQuery, restituendo risultati identici.
  • Impostare il flag Beta su True alla versione iniziale.

• Deve FunctionName avere senso per il dominio , ad esempio "Contenuto", "Tabelle", "Documento", "Database" e così via.

• Il connettore DEVE:

  • Hanno icone.
  • Specificare una tabella di spostamento.
  • Inserire le stringhe in un resources.resx file. Gli URL e i valori devono essere hardcoded nel codice del connettore e non devono essere inseriti nel resources.resx file.

Sicurezza

Esistono considerazioni di sicurezza specifiche che il connettore deve gestire.

• Se Extension.CurrentCredentials() viene usato:

  • L'utilizzo è obbligatorio? In tal caso, dove vengono inviate le credenziali?
  • È garantito che le richieste vengano effettuate tramite HTTPS?
    • È possibile usare la funzione helper di imposizione HTTPS.
  • Se le credenziali vengono inviate tramite Web.Contents() GET:
    • Può essere trasformato in post?
    • Se è necessario GET, il connettore DEVE usare il CredentialQueryString record nel Web.Contents() record delle opzioni per passare credenziali sensibili.

• Se vengono usate funzioni Diagnostics.*:

  • Convalidare ciò che viene tracciato; i dati non devono contenere informazioni personali o grandi quantità di dati non necessari.
  • Se è stata implementata una traccia significativa nello sviluppo, è necessario implementare una variabile o un flag di funzionalità che determina se la traccia deve essere attiva. Questa traccia deve essere disattivata prima dell'invio per la certificazione.

• Se Expression.Evaluate() viene usato:

  • Convalidare la provenienza dell'espressione e il relativo contenuto( ovvero, può costruire in modo dinamico le chiamate a Extension.CurrentCredentials()e così via).
  • Non Expression deve essere fornito dall'utente né accettare l'input dell'utente.
  • Non Expression deve essere dinamico, ovvero recuperato da una chiamata Web.

Registrazione per la certificazione

Se si è interessati a ottenere la certificazione del connettore personalizzato, assicurarsi che lo scenario e il connettore soddisfino i prerequisiti e i requisiti descritti in questo articolo. In caso contrario, si verificheranno ritardi nella certificazione perché il team richiede di risolvere eventuali problemi o incoerenze prima di procedere con la certificazione.

Assicurarsi che il connettore sia completo e sia stato testato sia nella creazione in Power BI Desktop che nell'aggiornamento e nell'utilizzo in servizio Power BI. Assicurarsi di aver testato l'aggiornamento end-to-end completo nel servizio Power BI usando un gateway dati locale.

Per iniziare, completare il modulo di registrazione e un contatto Microsoft verrà contattato per iniziare il processo.

Dopo la certificazione

Dopo aver certificato e rilasciato il connettore tramite Microsoft Fabric e le esperienze di Microsoft Power BI, è necessario eseguire alcune operazioni per assicurarsi di poter usare correttamente il connettore certificato disponibile pubblicamente disponibile per la produzione.

• L'utente e gli utenti finali devono usare la versione del connettore certificato inclusa negli ambienti prima della certificazione (ad esempio Power BI Desktop e Gateway dati) e rimuovere eventuali file mez o pqx esistenti (connettori personalizzati) usati prima della certificazione. In caso contrario, è possibile che il connettore personalizzato di test venga usato inavvertitamente da Power Query anziché dal connettore appena certificato.
• I connettori personalizzati devono essere usati solo per testare le nuove versioni del connettore.
• Quando si lavora con utenti finali e clienti, assicurarsi che comprendano la versione del connettore personalizzata usata nei test prima della certificazione deve essere rimossa al termine del test e la nuova versione del connettore certificato è disponibile.