Requisitos do conector de parceiro

Leia a Visão geral da publicação para entender os benefícios e o nível de comprometimento exigido para publicar um conector. Para publicar um conector de parceiro, seu conector precisa atender a todos os requisitos descritos abaixo.

Apps Script

Antes de enviar o conector para revisão, faça o seguinte no Apps Script:

  1. Conceda acesso para visualização do seu projeto do Apps Script a:
  2. Crie uma implantação chamada Production e atualize a Production implantação para a versão do código que você pretende publicar.
  3. Confirme que você atualizou a implantação Production para a versão do código que quer revisar.
  4. Confirme se o arquivo de manifesto está visível no Apps Script. À esquerda, clique em Configurações do projeto . Selecione a caixa de seleção Mostrar arquivo de manifesto "appsscript.json" no editor.

Manifesto

Inclua o seguinte no manifesto do conector e confirme se o projeto do Apps Script está configurado para mostrar o arquivo de manifesto appsscript.json no editor.

Consulte a referência do manifesto do conector da comunidade para mais informações.

dataStudio

  1. description deve fornecer informações e instruções para que os usuários tenham um conhecimento básico sobre o conector e como usar lo. Os conectores com descrições vagas e incompletas são rejeitados.
  2. addOnUrl É recomendável manter como uma página hospedada dedicada sobre seu conector, preferencialmente hospedada no seu próprio domínio. A página precisa incluir o seguinte:
    • Uma Política de Privacidade e Termos de Uso ou um link para esse conteúdo, no mesmo domínio do addOnUrl.
    • Detalhes que o usuário precisa saber para usar seu conector.
    • O link de inscrição, se uma conta for necessária para usar seu conector.
    • Conteúdo hospedado, de preferência, no seu domínio. Não é permitido hospedar conteúdo em https://sites.google.com/.
    • Veja exemplos de páginas de parceiros existentes: Funnel, Supermetrics, CallRail.
  3. supportUrl precisa ser uma página hospedada para receber suporte para seu conector. Ele não pode ser um link de e-mail ou mailto.
  4. logoUrl deve direcionar para uma imagem estática hospedada sob seu controle. Não é possível usar imagens veiculadas por serviços do Google em domínios como *.gstatic.com, *.ggpht.com, *.google.com, *.googleusercontent.com. O uso do Google Cloud Storage para veicular imagens do domínio *.googleapis.com é aceitável e é uma opção de hospedagem recomendada.
    • Os conectores com ícones animados são rejeitados. Use imagens estáticas.
    • É recomendável usar uma imagem de pelo menos 48 x 48 pixels.
    • Evite imagens somente de texto que sejam difíceis de ler quando reduzidas para 48 x 48 pixels.
  5. Preencha a sources propriedade com todas as fontes conectadas ao seu conector. Consulte a referência Fontes no manifesto para mais detalhes.
    • Para ver a lista de fontes, consulte o repositório de registro de dados. Se a fonte à qual você está se conectando não existir no repositório, envie uma solicitação de pull ao repositório de registro de dados para adicionar a fonte. Caso as fontes do seu manifesto não existam no repositório, seu conector será reprovado no processo de revisão.
    • Estes são metadados adicionais do conector que serão indexados para o recurso de pesquisa da galeria. Seu conector será exibido nos resultados da pesquisa quando os usuários pesquisarem uma fonte específica na galeria.
  6. Forneça valores para shortDescription, authType, feeType, privacyPolicyUrl, e termsOfServiceUrl.
  7. name precisa representar diretamente a finalidade do conector. Um nome claro ajuda os usuários a determinar se o conector atende às necessidades deles. Evite usar a palavra conector no nome, já que os usuários já sabem que estão procurando um conector.
    • Não inclua caracteres especiais ou não visíveis com a intenção de chamar a atenção ou alterar a posição do conector.
  8. Não use nomes abreviados para o Data Studio em nenhum lugar do manifesto (por exemplo, GDS, DS etc.).
  9. Os emojis não são permitidos em nenhum campo de manifesto (description, shortDescription, name etc.). No geral, não inclua caracteres especiais ou não visíveis com a intenção de chamar a atenção para o conector.
  10. Caso seu conector tenha um esquema fixo, crie um modelo de relatório para ele e adicione-o ao manifesto. Ative a opção Compartilhamento por link para o relatório.

urlFetchWhitelist

  1. Limite o número de endpoints chamados por UrlFetchApp àqueles absolutamente necessários para a funcionalidade do conector. Adicione a propriedade urlFetchWhitelist ao nível raiz do seu manifesto. Veja a referência de urlFetchWhitelist para mais informações.
    • Inclua todos os endpoints usados com o serviço UrlFetchApp.
    • Se o conector não buscar recursos usando o serviço UrlFetchApp, defina urlFetchWhitelist como uma lista vazia [].
    • Se o conector não se conectar a um conjunto de endpoints fixos ou o prefixo do endpoint variar, omita a propriedade urlFetchWhitelist e forneça detalhes no campo de formulário Exceção para urlFetchWhitelist ao enviar a solicitação de revisão.

oauthScopes

  1. Defina escopos OAuth explícitos no manifesto. Os conectores sem escopos OAuth explícitos são rejeitados.

Conector

  1. Se o usuário precisar de uma conta para usar o conector, inclua instruções para a criação dela na description ou no link addOnUrl.
  2. Seu conector não pode estar incompleto ou em fase Beta. É necessário publicar um conector completo e funcional. Você sempre pode atualizar seu conector, mas a implantação de produção liberada para os usuários deve ser testada e o recurso precisa estar completo.
  3. Crie mensagens de erro claras e acionáveis para exibição aos usuários no caso de um erro interno do conector. Isso inclui os casos em que um usuário insere uma entrada inválida/em branco na configuração.
  4. As informações dos campos shortDescription e description e dos links addOnUrl e supportUrl, bem como da página OAuth (caso aplicável), precisam seguir os padrões de ortografia e gramática.
  5. shortDescription não pode conter URLs.
  6. Use métodos de autenticação fornecidos por getAuthType(). Não solicite credenciais com getConfig().
  7. Conclua o processo de verificação do cliente OAuth. Isso é obrigatório para todos os conectores, independentemente do método de autenticação em getAuthType(). O processo de verificação é diferente da revisão do conector e é gerenciado por uma equipe separada, não pelo Data Studio. Para mais informações, consulte as perguntas frequentes sobre a verificação da API OAuth. Se o processo de verificação do cliente OAuth não for concluído, seu conector será rejeitado.
    • Durante o processo de verificação do OAuth, adicione os escopos do OAuth necessários do seu conector como parte da configuração da tela de permissão OAuth. Se você não incluir todos eles, o processo de verificação do OAuth poderá ser aprovado, mas seu conector ainda mostrará a tela Aplicativo não verificado. Isso fará com que o processo de verificação do conector de parceiro falhe.
      Autorize e teste seu conector usando uma nova conta após concluir o processo de verificação do OAuth para que a tela Aplicativo não verificado não seja exibida aos usuários.
  8. Verifique se você está em conformidade com os Termos de Serviço das galerias do Data Studio (remetente).

Quando você cumprir todos os requisitos, clique no botão a seguir para solicitar uma revisão do conector:

Publicar um conector de parceiro