Partilhar via

Certificação Data Factory Connector

  • Artigo

Nota

Este artigo descreve os requisitos e o processo para enviar um conector do Data Factory para certificação. Leia atentamente o artigo na íntegra 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 Microsoft.

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

  • Microsoft Fabric Dataflow 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:

  • Mantido pelo desenvolvedor parceiro

  • Suportado pelo desenvolvedor parceiro

  • Certificado pela Microsoft

  • Distribuído pela Microsoft

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

Nota

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 conector do Data Factory. Consulte a descrição geral do SDK do Power Query para saber mais sobre esta ferramenta.

Visão Geral da Certificação

Pré-requisitos

Para garantir a melhor experiência para nossos clientes, consideramos apenas conectores que atendam 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 conectores personalizados. Recomendamos o uso de recursos públicos, como nossa documentação do SDK e repositório de exemplos. Se você precisar de mais assistência, podemos compartilhar uma lista de consultores conhecidos de desenvolvimento de conectores personalizados do setor de 3ª parte que você pode querer contratar diretamente, separados 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 deles. A Microsoft fornece a lista para sua conveniência e sem quaisquer garantias, recomendações ou garantias. Para saber mais, entre em contato com seu contato de certificação da Microsoft.

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

  • O conector já deve estar disponível aos clientes diretamente 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 auto-distribuição e executem testes internos de seus próprios conectores para iterar sobre seus conectores sob um grupo controlado. Cada usuário ou organização deve ser capaz de fornecer feedback e validação de que há uma necessidade comercial para o conector e que o conector está funcionando com êxito para atender aos seus requisitos de negócios.

  • 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 tornar o conector disponível publicamente no Data Factory e/ou Power BI. Não há um limite definido de engajamento. No entanto, quanto mais engajamento, mais forte será a demanda evidenciada pelo conector.

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

Processo e Prazos

Os conectores certificados são lançados com versões mensais do Power BI Desktop, portanto, os prazos para cada versão funcionam de volta a partir de cada data de lançamento do Power BI Desktop. A duração esperada do processo de certificação, desde o registo até à libertação, varia em função da qualidade e complexidade da apresentação do conector. A Microsoft não fornece nenhuma garantia de cronograma específica em relação a qualquer revisão e aprovação do conector. Os prazos rígidos para cada revisão do conector são descritos nas etapas a seguir, mas a Microsoft não garante a adesão a esses cronogramas.

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

    • Por exemplo, para a versão de abril do Power BI Desktop, o prazo seria 15 de fevereiro.

  • Submissão: envio de ficheiros de conector para revisão da Microsoft. Esse envio deve ocorrer até o primeiro dia do mês antes da versão de destino do Power BI desktop.

    • Por exemplo, para a versão de abril do Power BI Desktop, o prazo seria 1º de março.

  • Revisão técnica: finalização dos arquivos do conector, passando pela revisão e certificação da Microsoft. Essa revisão deve ocorrer até o dia 15 do mês anterior à versão de destino do Power BI Desktop.

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

Devido à complexidade das revisões técnicas e possíveis atrasos, rearquitetura e problemas de teste, é altamente recomendável enviar com antecedência e um longo prazo para a versão inicial e certificação.

Requisitos de certificação

Temos um certo conjunto de requisitos para a certificação. Reconhecemos que nem todos os desenvolvedores podem atender a esses requisitos, e esperamos introduzir um conjunto de recursos que atenda às necessidades dos desenvolvedores em pouco tempo.

Arquivos de envio (artefatos)

Certifique-se de que os seguintes arquivos de conector estejam incluídos no seu envio:

  • Arquivo do conector (.mez)

    • O arquivo .mez deve seguir padrões de estilo e ter um nome 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 do Power BI Desktop (.pbix) para teste

    • Necessitamos de um exemplo de relatório do Power BI (.pbix) para testar o seu conector.
    • O relatório deve incluir pelo menos uma consulta para testar cada item na 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 possa manipular.

  • Testar a conta para sua fonte de dados

    • Usamos a conta de teste para testar e solucionar problemas do seu conector.
    • Forneça uma conta de teste que seja 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)

Características 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:

    • Use o formato de documento da seção.
    • Conter um cabeçalho/adorno da versão acima do documento da seção.
    • Forneça metadados de documentação da função.
    • Tenha o manipulador TestConnection.
    • Siga 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 para uma fonte de dados relacional. Não há suporte para formatos multidimensionais baseados em cubos, dimensões e medidas.
    • Comporte-se da mesma forma no modo Import e DirectQuery, retornando resultados idênticos.
    • Tenha 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:

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

Segurança

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

  • Se Extension.CurrentCredentials() for utilizado:

    • O uso é obrigatório? Em caso afirmativo, para onde são enviadas as credenciais?
    • É garantido que os pedidos sejam feitos através de HTTPS?
      • Você pode usar a função auxiliar de imposição HTTPS.
    • Se as credenciais forem enviadas usando Web.Contents() via GET:
      • Pode ser transformado num POST?
      • Se GET for necessário, o conector DEVE usar o CredentialQueryString registro no Web.Contents() registro de opções para passar credenciais confidenciais.

  • Se as funções Diagnostics.* forem usadas:

    • Validar o que está a ser rastreado; os dados não devem conter PII ou grandes quantidades de dados desnecessários.
    • Se você implementou um rastreamento significativo no desenvolvimento, deverá implementar um sinalizador de variável ou recurso que determine se o rastreamento deve estar ativado. Esse rastreamento deve ser desativado antes do envio para certificação.

  • Se Expression.Evaluate() for utilizado:

    • 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 a entrada do usuário.
    • O Expression não deve ser dinâmico (ou seja, recuperado de uma chamada web).

Registo para Certificação

Se você estiver interessado em obter a certificação de seu conector personalizado, certifique-se de que seu cenário e conector atendam aos pré-requisitos e requisitos descritos neste artigo. Se não o fizer, haverá atrasos na certificação, uma vez que a nossa equipa exige que corrija quaisquer problemas ou inconsistências antes de avançar com a certificação.

Verifique se o conector está com o código completo e foi testado tanto na criação no Power BI Desktop quanto na atualização e consumo no serviço do Power BI. Certifique-se de ter testado 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 um contato 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 das 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 publicamente disponível 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 não o fizer, poderá resultar na utilização inadvertida do conector personalizado de teste pelo Power Query em vez do conector recém-certificado.
  • 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 que o teste for concluído e a nova versão do conector certificado estiver disponível.