Conexão HTTP v2

Introdução

Uma conexão HTTP v2, criada usando o conector HTTP v2, estabelece acesso sobre o protocolo HTTP ou HTTPS a um serviço como uma API REST, API GraphQL ou formulário da web. Uma vez que uma conexão é configurada, é possível criar instâncias de atividades HTTP v2 associadas a essa conexão para serem usadas como fontes (para fornecer dados em uma operação) ou como alvos (para consumir dados em uma operação).

Criar ou editar uma conexão HTTP v2

Uma nova conexão HTTP v2 é criada usando o conector HTTP v2 a partir de uma dessas localizações:

• A aba Endpoints e conectores do projeto na paleta de componentes de design (veja Paleta de componentes de design).
• A página Endpoints Globais (veja Criar um endpoint global em Endpoints Globais).

Uma conexão HTTP v2 existente pode ser editada a partir dessas localizações:

• A aba Endpoints e conectores do projeto na paleta de componentes de design (veja Paleta de componentes de design).
• A aba Componentes do painel do projeto (veja Menu de ações de componentes em Aba Componentes do painel do projeto).
• A página Endpoints Globais (veja Editar um endpoint global em Endpoints Globais).

Configurar uma conexão HTTP v2

Cada elemento da interface do usuário da tela de configuração da conexão HTTP v2 é descrito abaixo.

• Nome da Conexão: Insira um nome para identificar a conexão. O nome deve ser único para cada conexão HTTP v2 e não deve conter barras / ou dois pontos :. Este nome também é usado para identificar o endpoint HTTP v2, que se refere tanto a uma conexão específica quanto às suas atividades.

• URL Base: Insira a URL base. A URL base é usada para testar a conexão. Se este campo é utilizado em tempo de execução depende de se o campo URL da Atividade HTTP de uma atividade HTTP v2 está preenchido:

  • Se uma URL parcial ou nenhuma URL for fornecida no campo URL da Atividade HTTP, então a URL utilizada em tempo de execução é concatenada a partir da URL Base e da URL da Atividade HTTP.

  • Se uma URL completa for fornecida no campo URL da Atividade HTTP, então a URL Base não é utilizada em tempo de execução.

• Autorização: Use o menu para selecionar o tipo de autenticação, resumido abaixo. A configuração de cada tipo de autenticação é descrita em tipos de autenticação de conexão HTTP v2.

  • Chave de API: Especifique um par chave-valor de API para enviar nos cabeçalhos ou parâmetros de consulta.

  • Assinatura AWS: Especifique um ID de chave de acesso AWS, chave de acesso secreta, região, serviço e token de sessão para enviar usando a Versão 2 da Assinatura da Amazon Web Services (AWS) nos cabeçalhos ou parâmetros de consulta.

• Autenticação Básica: Especifique um nome de usuário e uma senha para enviar nos cabeçalhos.

• Token Bearer: Especifique um token bearer para enviar nos cabeçalhos.

• Autenticação Digest: Especifique um nome de usuário, senha, realm, nonce, algoritmo, QOP, contagem de nonce, nonce do cliente e opaco para enviar nos cabeçalhos.

• Autenticação Hawk: Especifique um ID de autenticação Hawk, chave de autenticação, informações específicas do aplicativo, um ID de aplicativo e DLG para enviar nos cabeçalhos.

• Sem Autenticação: Selecione para acessar o serviço anonimamente sem autorização.

• OAuth 2.0: Especifique o tipo de concessão e forneça o endpoint do token OAuth, ID do cliente, segredo do cliente e escopo para enviar nos cabeçalhos ou no corpo da solicitação.

• Repetir: Funcional apenas ao usar um ambiente associado a um grupo de agentes privados, esta configuração é usada para repetir uma solicitação quando um endpoint HTTP v2 retorna um desses códigos de status: 500, 502, 503 ou 504.

  Esta configuração entra em vigor quando usada com agentes privados versão 10.34 ou posterior.

  Selecione a caixa de seleção Repetir para expandir opções de configuração adicionais:

  

  • Intervalo de Repetição (Segundos): Insira o número de segundos (máximo de 5 segundos) para aguardar entre o reenvio de uma solicitação para o endpoint HTTP v2.

  • Máximo de Repetições: Insira o número máximo de repetições (máximo de 5 repetições) que uma solicitação será reenviada para o endpoint HTTP v2. Se a solicitação ainda falhar após o número máximo de repetições, uma exceção com uma mensagem de erro será retornada no log da operação. Além disso, o agente privado registrará cada repetição no arquivo de log jitterbit.log.

Cada tentativa é tratada como parte da mesma execução da operação, onde apenas um único registro aparece no log da operação. Quaisquer ações de operação configuradas para executar operações subsequentes são acionadas com base no status final da operação após tentar até o número máximo de tentativas.

• Configurações Opcionais: Clique para expandir configurações opcionais adicionais:

  

  • Obter conteúdo da resposta em string base64: Selecione para retornar responseContent codificado em base64 das atividades HTTP v2.

  • Configurações de Proxy: Use o menu para selecionar as configurações de proxy, uma dessas opções:

    • Personalizado: As configurações de proxy são ativadas usando as entradas especificadas nos campos adicionais que se tornam disponíveis quando esta opção é selecionada. Esta opção ignora a configuração de proxy do agente privado se existir.

      

      • Host: Insira o nome do host do servidor proxy HTTP.
      • Porta: Insira a porta do servidor proxy HTTP.
      • Usuário: Insira o nome de usuário para autenticação do servidor proxy HTTP.
      • Senha: Insira a senha para autenticação do servidor proxy HTTP.
      • Domínio NTLM: Insira o domínio NTLM para autenticação do servidor proxy HTTP.
      • Permitir Certificados Não Verificados Usados pelo Proxy: Selecione para permitir que certificados não verificados sejam usados pelo servidor proxy HTTP.

    • Padrão: As configurações de proxy estão ativadas, usando a configuração de proxy do agente privado se existir. Se as configurações de proxy não forem especificadas na configuração do agente, então a configuração Padrão tem o mesmo resultado que a configuração Desativar.

    • Desativar: As configurações de proxy estão desativadas, ignorando a configuração de proxy do agente privado se existir.

  • Propriedades HTTP Avançadas: Se aplicável, defina estas opções avançadas:

    • Content-Type: Insira o tipo de conteúdo da estrutura de solicitação que é esperada pela API específica. Por exemplo, text/plain, application/json, application/x-www-form-urlencoded, etc. Se o método utilizado não aceitar dados estruturados, ou se a API não exigir que o tipo de conteúdo seja especificado, deixe este campo em branco. Este campo não é afetado pela configuração Enviar cabeçalhos de solicitação na execução da atividade.

      Alternativamente, o tipo de conteúdo pode ser especificado em outros campos de configuração da interface do usuário ou fornecido na transformação da solicitação. Se o tipo de conteúdo for especificado em vários locais, esta ordem de precedência é seguida:

      1. Um cabeçalho Content-Type fornecido na tabela Configurações Adicionais de uma atividade HTTP v2 substitui todos os campos abaixo.
      2. O campo bodyContentType especificado em uma transformação de solicitação substitui os campos restantes abaixo.
      3. Um cabeçalho Content-Type fornecido no nó headers da transformação de solicitação substitui os campos restantes abaixo.
      4. Um cabeçalho Content-Type fornecido no campo Cabeçalhos de Solicitação de uma atividade HTTP v2 substitui o campo restante abaixo.
      5. Um cabeçalho Content-Type fornecido no campo Cabeçalhos de Solicitação de uma conexão HTTP v2, se Enviar Cabeçalhos de Solicitação na Execução da Atividade estiver habilitado, tem a menor precedência.

      Nota

      Se um cabeçalho for definido em vários locais, cada instância do cabeçalho será adicionada à solicitação de uma atividade seguindo a ordem de precedência acima. Esta ordem é baseada em como os serviços normalmente lidam com cabeçalhos duplicados em uma solicitação.

    • Habilitar codificação de conteúdo: Selecione para enviar o cabeçalho Accept-Encoding com codificação Gzip. Este campo não é afetado pela configuração Enviar Cabeçalhos de Solicitação na Execução da Atividade.

      Alternativamente, este cabeçalho pode ser definido em outros campos de configuração da interface do usuário ou fornecido na transformação da solicitação. Se este cabeçalho for especificado em vários locais, esta ordem de precedência é seguida:

      1. Um cabeçalho Accept-Encoding fornecido no nó headers da transformação de solicitação substitui todos os campos abaixo.
      2. Um cabeçalho Accept-Encoding fornecido no campo Request Headers de uma atividade HTTP v2 substitui o restante do campo abaixo.
      3. Um cabeçalho Accept-Encoding fornecido no campo Request Headers de uma conexão HTTP v2, se Send Request Headers in Activity Execution estiver habilitado, tem a menor precedência.

      Nota

      Se um cabeçalho for definido em múltiplos locais, cada instância do cabeçalho será adicionada à solicitação de uma atividade seguindo a ordem de precedência acima. Esta ordem é baseada em como os serviços normalmente lidam com cabeçalhos duplicados em uma solicitação.

    • Habilitar codificação de transferência em partes: Selecione para enviar o cabeçalho Transfer-Encoding: chunked. Use esta opção se você estiver transferindo grandes conjuntos de dados. Este campo não é afetado pela configuração Send Request Headers in Activity Execution.

      Alternativamente, este cabeçalho pode ser definido em outros campos de configuração da interface do usuário ou fornecido na transformação de solicitação. Se este cabeçalho for especificado em múltiplos locais, esta ordem de precedência é seguida:

      1. Um cabeçalho Transfer-Encoding fornecido no nó headers da transformação de solicitação substitui todos os campos abaixo.
      2. Um cabeçalho Transfer-Encoding fornecido no campo Request Headers de uma atividade HTTP v2 substitui o restante do campo abaixo.
      3. Um cabeçalho Transfer-Encoding fornecido no campo Request Headers de uma conexão HTTP v2, se Send Request Headers in Activity Execution estiver habilitado, tem a menor precedência.

      Nota

      Se um cabeçalho for definido em múltiplos locais, cada instância do cabeçalho será adicionada à solicitação de uma atividade seguindo a ordem de precedência acima. Esta ordem é baseada em como os serviços normalmente lidam com cabeçalhos duplicados em uma solicitação.

    • Permitir cifras fracas: Esta opção não está funcional atualmente.

    • Manter conexão: Selecione para permitir que uma única conexão TCP permaneça aberta para múltiplas requisições e respostas HTTP.

    • Verificação de certificado SSL: Selecione para verificar o serviço validando o certificado SSL / TLS apresentado durante o processo de handshake.

    • Codificar URL da requisição: Selecione para codificar a URL da requisição.

    • Seguir redirecionamentos: Selecione para permitir que o conector redirecione com quaisquer redirecionamentos presentes na URL Base. Se a URL Base redirecionar e esta configuração não estiver selecionada, ocorrerá um erro ao testar a conexão e na primeira execução de uma operação. Quando esta opção é selecionada, o seguinte campo se torna visível:

      • Número máximo de redirecionamentos: Insira a quantidade de redirecionamentos que a conexão seguirá antes de retornar um erro.

    • Apenas aplicável ao usar HTTPS: Use o menu para alterar a seleção de Negociar (padrão) para uma versão específica do TLS, se necessário, selecionando entre TLSv1.0, TLSv1.1, TLSv1.2 ou TLSv1.3.

    • Cabeçalhos da Requisição: Defina cabeçalhos HTTP para a conexão. Clique no ícone de adicionar para adicionar um cabeçalho à tabela abaixo e insira um par chave-valor para cada parâmetro de requisição.

      Para salvar a linha, clique no ícone de enviar na coluna mais à direita.

      Para editar ou excluir uma única linha, passe o mouse sobre a coluna mais à direita e use o ícone de editar ou o ícone de excluir .

      Para excluir todas as linhas, clique em Limpar Tudo.

      Alternativamente, os cabeçalhos podem ser definidos em outros campos de configuração da interface do usuário ou fornecidos na transformação da requisição. Cabeçalhos que não compartilham uma chave são enviados cumulativamente, independentemente de onde são especificados.

      Se a mesma chave de cabeçalho for especificada em múltiplos lugares, esta ordem de precedência é seguida:

      1. Um cabeçalho fornecido no nó headers da transformação da requisição substitui todos os campos abaixo.
      2. Um cabeçalho fornecido no campo Cabeçalhos da Requisição de uma atividade HTTP v2 substitui o restante do campo abaixo.
      3. Um cabeçalho fornecido no campo Cabeçalhos da Requisição de uma conexão HTTP v2 (este campo), se Enviar Cabeçalhos da Requisição na Execução da Atividade estiver habilitado, tem a menor precedência.

      Nota

      Se um cabeçalho for definido em múltiplos locais, cada instância do cabeçalho será adicionada à solicitação de uma atividade seguindo a ordem de precedência acima. Essa ordem é baseada em como os serviços normalmente lidam com cabeçalhos duplicados em uma solicitação.

      Aviso

      Não defina manualmente cabeçalhos de solicitação Authorization em atividades HTTP v2 se a conexão HTTP v2 estiver configurada para enviar seus próprios cabeçalhos de solicitação Authorization dependendo do tipo de autenticação selecionado. Fazer isso resulta na terminação da operação e falha antes de alcançar o endpoint de destino e é registrado como um erro 400 Bad Request.

      Se a autenticação dinâmica for necessária no nível da atividade, defina o tipo de autenticação da conexão como No Auth e configure os cabeçalhos de solicitação Authorization da atividade conforme necessário.

      Importante

      Os campos na tabela Request Headers exibem o ícone de variável apenas no modo de edição. Para que os valores de variável desses campos sejam preenchidos em tempo de execução, a versão do agente deve ser pelo menos 10.75 / 11.13.

      Os campos na tabela Request Headers não suportam o uso de variáveis para passar JSON bruto. Se seu caso de uso não suportar a definição de JSON bruto nos campos diretamente, escape o conteúdo JSON antes de passá-lo com uma variável. Por exemplo, escapando {"success": "true"}; torna-se {\"success\": \"true\"};.

    • Enviar cabeçalhos de solicitação na execução da atividade: Selecione para passar cabeçalhos definidos em Request Headers para atividades HTTP v2. Consulte as ordens de precedência acima para determinar como os cabeçalhos definidos em uma conexão HTTP v2 interagem com cabeçalhos definidos em outros locais.

• Testar: Clique para verificar a conexão enviando uma solicitação HTTP GET usando a autorização configurada. Um teste é considerado bem-sucedido se qualquer código de status HTTP 2xx for retornado. Uma resposta 405 Method Not Allowed também é tratada como bem-sucedida. Quando a conexão é testada, a versão mais recente do conector é baixada pelo(s) agente(s) no grupo de agentes associado ao ambiente atual. Este conector suporta suspender o download da versão mais recente do conector usando a política de organização Desativar Atualização Automática do Conector.

• Salvar Alterações: Clique para salvar e fechar a configuração da conexão.

• Descartar Alterações: Após fazer alterações em uma configuração nova ou existente, clique para fechar a configuração sem salvar. Uma mensagem pede para você confirmar que deseja descartar as alterações.

• Excluir: Após abrir uma configuração de conexão existente, clique para excluir permanentemente a conexão do projeto e fechar a configuração (veja Dependências de componentes, exclusão e remoção). Uma mensagem pede para você confirmar que deseja excluir a conexão.

Próximos passos

Depois que uma conexão HTTP v2 foi criada, você coloca um tipo de atividade na tela de design para criar instâncias de atividade que serão usadas como fontes (para fornecer dados em uma operação) ou como alvos (para consumir dados em uma operação).

As ações do menu para uma conexão e seus tipos de atividade estão acessíveis no painel do projeto e na paleta de componentes de design. Para detalhes, veja Menus de ações em Fundamentos do conector.

Estes tipos de atividade estão disponíveis:

• PATCH: Aplica modificações parciais a um recurso existente em um serviço acessível pelo protocolo HTTP ou HTTPS e pode ser usado como fonte ou alvo em uma operação.

• HEAD: Recupera a linha de status e a seção de cabeçalho de um recurso em um serviço acessível pelo protocolo HTTP ou HTTPS e pode ser usado como fonte ou alvo em uma operação.

• POST: Cria um novo recurso em um serviço acessível pelo protocolo HTTP ou HTTPS e pode ser usado como fonte ou alvo em uma operação.

• GET: Recupera informações sobre um recurso em um serviço acessível pelo protocolo HTTP ou HTTPS e pode ser usado como fonte ou alvo em uma operação.

• OPTIONS: Recupera informações sobre as opções de comunicação para um recurso em um serviço acessível pelo protocolo HTTP ou HTTPS e pode ser usado como fonte ou alvo em uma operação.

• BULK: Envia várias solicitações para um serviço acessível pelo protocolo HTTP ou HTTPS e pode ser usado como fonte ou destino em uma operação.

• DELETE: Exclui um recurso em um serviço acessível pelo protocolo HTTP ou HTTPS e pode ser usado como fonte ou destino em uma operação.

• PUT: Substitui um recurso existente em um serviço acessível pelo protocolo HTTP ou HTTPS e pode ser usado como fonte ou destino em uma operação.