Certificação do conector do Data Factory

Observação

Este artigo descreve os requisitos e o processo para enviar um conector do Data Factory para certificação. Leia todo o texto com atenção antes de iniciar o processo de certificação.

Os proprietários de fontes de dados que desenvolvem um conector personalizado para sua fonte de dados podem querer distribuir seu conector personalizado de forma mais ampla para os usuários do Data Factory. Depois que um conector personalizado é criado, usado e validado pelos usuários finais, o proprietário da fonte de dados pode enviá-lo para certificação da Microsoft.

A certificação de um conector do Data Factory disponibiliza o conector publicamente, pronto para uso, no Microsoft Fabric Data Factory e no Microsoft Power BI nas seguintes experiências:

  • Fluxo de dados do Microsoft Fabric Gen2
  • Fluxo de dados do Microsoft Power BI Gen1
  • Microsoft Power BI Datamart
  • Modelo semântico do Microsoft Power BI (no serviço do Power BI)
  • Microsoft Power BI Desktop
  • Gateway de dados local para Microsoft Fabric e Microsoft Power BI

Os conectores certificados são:

  • mantidos pelo desenvolvedor do parceiro;

  • têm suporte do desenvolvedor parceiro;

  • certificados pela Microsoft;

  • distribuídos pela Microsoft.

Trabalhamos com parceiros para tentar garantir que eles tenham suporte na manutenção, mas os problemas do cliente com o próprio conector são direcionados ao desenvolvedor parceiro.

Observação

Hoje, você pode aproveitar o SDK do Power Query para criar um conector que pode ser certificado por meio do programa de certificação de conectores do Data Factory. Acesse a visão geral do SDK do Power Query para saber mais sobre essa ferramenta.

Visão geral da certificação

Pré-requisitos

Para garantir a melhor experiência para nossos clientes, consideramos apenas os conectores que atendem a um conjunto de pré-requisitos para certificação:

  • O conector deve ser para um produto público.

  • O conector deve ser considerado code-complete para uma versão de lançamento inicial. O programa permite iterações e atualizações frequentes. A Microsoft não oferece assistência técnica ou consultoria de desenvolvimento de conector personalizado. Recomendamos usar recursos públicos, como nossa documentação do SDK e nosso repositório de amostras. Se você precisar de mais assistência, podemos compartilhar uma lista de consultores de desenvolvimento de conectores personalizados do setor de terceiros conhecidos que você pode querer envolver diretamente, separadamente de qualquer programa ou parceria da Microsoft. A Microsoft não é afiliada a nenhum desses consultores e não é responsável pelo uso dos serviços que eles oferecem. A Microsoft fornece a lista para sua comodidade e sem quaisquer garantias ou recomendações. Para saber mais, entre em contato com seu contato de certificação da Microsoft.

  • O desenvolvedor deve fornecer uma estimativa para uso atual e futuro.

  • O conector já deve estar disponível diretamente para os clientes para atender a uma necessidade do usuário ou cenário de negócios. Esses critérios podem ser atendidos usando um programa de Visualização Privada distribuindo o conector concluído diretamente para usuários finais e organizações. Sugerimos que os desenvolvedores de conectores usem um mecanismo de autodistribuição e executem testes internos de seus próprios conectores para iterar em seus conectores em um grupo controlado. Cada usuário ou organização deve ser capaz de fornecer comentários e validação de que há uma necessidade comercial para o conector e que o conector está funcionando para atender aos seus requisitos comerciais.

  • O conector deve estar funcionando com êxito em um nível previsto de uso pelos clientes.

  • Deve haver um thread no fórum Fabric Ideas orientado pelos clientes para indicar a demanda para disponibilizar o conector publicamente no Data Factory e/ou no Power BI. Não há um limite definido de participação. No entanto, quanto mais participação, mais forte será a demanda evidenciada pelo conector.

Esses pré-requisitos existem para garantir que os conectores em processo de certificação tenham necessidades significativas de clientes e negócios para serem usados e suportados após a certificação.

Processos e linhas do tempo

Os conectores certificados são lançados com versões mensais do Power BI Desktop; portanto, os prazos para cada versão contam a partir de cada data de lançamento do Power BI Desktop. A duração esperada do processo de certificação, desde o registro até a liberação, varia dependendo da qualidade e da complexidade do envio do conector. A Microsoft não fornece nenhuma garantia de prazos específicos em relação a qualquer revisão e aprovação de conectores. Os prazos para cada revisão de conector estão descritos nas etapas a seguir, mas a Microsoft não garante o cumprimento desses prazos.

  • Registro: notificação da intenção de certificar seu conector personalizado. Esse registro deve ocorrer até o dia 15 do mês, dois meses antes do lançamento da versão pretendida do Power BI Desktop.

    • Por exemplo, para a versão de abril do Power BI Desktop, a data limite seria 15 de fevereiro.
  • Envio: envio dos arquivos do conector para análise da Microsoft. Esse envio deve ocorrer até o primeiro dia do mês antes do lançamento do Power BI Desktop em questão.

    • Por exemplo, para a versão de abril do Power BI Desktop, a data limite seria 1º de março.
  • Análise técnica: finalização dos arquivos do conector, aprovação na análise e certificação da Microsoft. Isso deve ocorrer até o dia 15 do mês, dois meses antes da versão pretendida do Power BI Desktop.

    • Por exemplo, para a versão de abril do Power BI Desktop, a data limite seria 15 de março.

Devido à complexidade das análises técnicas e possíveis atrasos, rearquitetura e problemas de teste, é altamente recomendável enviar antecipadamente com um longo tempo de execução para a versão inicial e a certificação.

Requisitos de certificação

Temos um determinado conjunto de requisitos para certificação. Reconhecemos que nem todos os desenvolvedores podem atender a esses requisitos e esperamos introduzir um conjunto de recursos que lidará com as necessidades do desenvolvedor em breve.

Arquivos de envio (artefatos)

Verifique se os seguintes arquivos de conector estão incluídos em seu envio:

  • Arquivo conector (.mez)

    • O arquivo .mez deve seguir padrões de estilo e ser nomeado de forma semelhante ao nome do produto ou serviço. Ele não deve incluir palavras como "Malha", "Power BI", "Conector" ou "API".
    • Nomeie o arquivo .mez: ProductName.mez
  • Arquivo Power BI Desktop (.pbix) para teste

    • Precisamos de um relatório de exemplo do Power BI (.pbix) para testar o conector.
    • O relatório deve incluir pelo menos uma consulta para testar cada item em sua tabela de navegação.
    • Se não houver um esquema definido (por exemplo, bancos de dados), o relatório precisará incluir uma consulta para cada "tipo" de tabela que o conector pode manipular.
  • Conta de teste para sua fonte de dados

    • Nós usamos a conta de teste para testar e solucionar problemas do conector.
    • Forneça uma conta de teste persistente, para que possamos usar a mesma conta para certificar quaisquer atualizações futuras.
  • Instruções de teste

    • Forneça qualquer documentação sobre como usar o conector e testar sua funcionalidade.
  • Links para dependências externas (por exemplo, drivers ODBC)

Recursos e estilo

O conector deve seguir um conjunto de regras de recurso e estilo para atender a um padrão de usabilidade consistente com outros conectores certificados.

  • O conector DEVE:

    • Usar o formato do documento da Seção.
    • Conter um cabeçalho/adorno de versão acima do documento da seção.
    • Ter metadados da documentação da função.
    • Ter o manipulador TestConnection.
    • Seguir as convenções de nomenclatura (por exemplo, DataSourceKind.FunctionName). Ele não deve incluir palavras como "Malha", "Power BI", "Conector" ou "API".
    • Retornar dados em formato tabular, organizados em tabelas com colunas, como uma fonte de dados relacional. Não há compatibilidade com formatos multidimensionais baseados em cubos, dimensões e medidas.
    • Comporte-se da mesma forma no modo Import e DirectQuery, retornando resultados idênticos.
    • Ter o sinalizador Beta definido como True na versão inicial.
  • O FunctionName deve fazer sentido para o domínio (por exemplo, "Conteúdo", "Tabelas", "Documento", "Bancos de Dados" e assim por diante).

  • O conector DEVE:

    • Ter ícones.
    • Ter uma tabela de navegação.
    • Colocar cadeias de caracteres em um arquivo resources.resx. URLs e valores devem ser codificados no código do conector e não serem colocados no arquivo resources.resx.

Segurança

Há considerações de segurança específicas que o conector deve tratar.

  • Se Extension.CurrentCredentials() for usado:

    • O uso é necessário? Nesse caso, para onde as credenciais são enviadas?
    • Há alguma garantia de que as solicitações foram feitas por HTTPS?
    • Se as credenciais forem enviadas usando Web.Contents() via GET:
      • Pode ser transformado em POST?
      • Se GET for necessário, o conector DEVERÁ usar o registro CredentialQueryString no registro de opções Web.Contents() para passar credenciais confidenciais.
  • Se as funções Diagnostics.* forem usadas:

    • Valide o que está sendo rastreado; os dados não devem conter PII nem grandes quantidades de dados desnecessários.
    • Se você implementou um rastreamento significativo no desenvolvimento, implemente uma variável ou sinalizador de recurso que determina se o rastreamento deve estar ativado. Esse rastreamento deve ser desativado antes do envio para certificação.
  • Se Expression.Evaluate() for usado:

    • Valide de onde a expressão está vindo e o que ela é (ou seja, pode construir dinamicamente chamadas para Extension.CurrentCredentials()e assim por diante).
    • O Expression não deve ser fornecido pelo usuário nem receber entrada de usuário.
    • O Expression não deve ser dinâmico (ou seja, recuperado de uma chamada da web).

Registrar-se para certificação

Se você tiver interesse em buscar a certificação do conector personalizado, verifique se seu cenário e conector atendem aos pré-requisitos e requisitos descritos neste artigo. Não fazer isso causará atrasos na certificação, pois nossa equipe exigirá que você corrija quaisquer problemas ou inconsistências antes de avançar.

Verifique se o conector está com código concluído e foi testado na criação no Power BI Desktop e na atualização e no consumo no serviço do Power BI. Verifique se você testou a atualização completa de ponta a ponta no Serviço do Power BI usando um gateway de dados local.

Para começar, preencha nosso formulário de registro e uma pessoa da Microsoft entrará em contato para iniciar o processo.

Após a certificação

Depois que o conector for certificado e lançado por meio de experiências do Microsoft Fabric e do Microsoft Power BI, há algumas coisas que você deve fazer para garantir que possa usar corretamente o conector certificado disponível publicamente implantado em produção.

  • Você e os usuários finais devem usar a versão do conector certificado incluída em ambientes anteriores à certificação (como o Power BI Desktop e o Gateway de Dados) e remover todos os arquivos .mez ou .pqx existentes (conectores personalizados) usados antes da certificação. Se isso não for feito, o conector personalizado de teste poderá ser usado pelo Power Query inadvertidamente em vez do conector recém-certificado.
  • Os conectores personalizados só devem ser usados para testar novas versões do conector.
  • Ao trabalhar com usuários finais e clientes, certifique-se de que eles entendam que a versão do conector personalizado usada nos testes antes da certificação deve ser removida depois da conclusão do teste e da nova versão do conector certificado estar disponível.