Chamar endereços HTTP ou HTTPS externos nos Fluxos de Trabalho do Azure Logic Apps

Aplica-se a: Aplicativos Lógicos do Azure (Consumo + Standard)

Alguns cenários podem exigir que você crie um fluxo de trabalho de aplicativo lógico que envia solicitações de saída para pontos de extremidade em outros serviços ou sistemas por HTTP ou HTTPS. Por exemplo, suponha que você queira monitorar um endpoint de serviço para seu site verificando esse endpoint num horário específico. Quando um evento específico acontece naquele endpoint, como o seu site ficando fora do ar, esse evento dispara seu fluxo de trabalho e executa as ações nesse fluxo de trabalho.

Este guia mostra como usar o gatilho HTTP e a ação HTTP para que seu fluxo de trabalho possa enviar chamadas de saída para outros serviços e sistemas, por exemplo:

• Para verificar ou pesquisar um ponto de extremidade em uma programação recorrente, adicione o gatilho integrado chamado HTTP como a primeira etapa no seu fluxo de trabalho. Sempre que o gatilho verifica o ponto de extremidade, o gatilho chama ou envia uma solicitação para o ponto de extremidade. A resposta do endpoint determina se o fluxo de trabalho é executado. O gatilho passa qualquer conteúdo da resposta do ponto de extremidade para as ações no seu fluxo de trabalho.

• Para chamar um endpoint de qualquer outro lugar no seu fluxo de trabalho, adicione a ação incorporada chamada HTTP. A resposta do ponto de extremidade determina a maneira como as ações restantes do fluxo de trabalho são executadas.

Pré-requisitos

• Uma conta e uma assinatura do Azure. Se você não tiver uma assinatura do Azure, inscreva-se em uma conta gratuita do Azure.

• O URL do endpoint de destino que você deseja chamar.

• O recurso do aplicativo lógico com o fluxo de trabalho de onde você deseja chamar o ponto de extremidade externo.

  Para iniciar seu fluxo de trabalho com o gatilho HTTP , você precisa ter um fluxo de trabalho em branco. Para usar a ação HTTP , seu fluxo de trabalho pode começar com um gatilho que melhor se ajusta ao seu cenário. Os fluxos de trabalho de exemplo neste artigo usam o gatilho HTTP .

  Se você não tiver um recurso de aplicativo lógico e um fluxo de trabalho, crie-os agora seguindo as etapas para o aplicativo lógico desejado:

  • Criar um exemplo de fluxo de trabalho de aplicativo lógico de consumo
  • Criar um exemplo de fluxo de trabalho do aplicativo lógico Standard

Referência técnica do conector

Para obter informações técnicas sobre parâmetros de gatilho e ação, consulte as seguintes seções no guia de referência de esquema:

• Parâmetros de gatilho HTTP
• Parâmetros de ação HTTP

Adicionar um gatilho HTTP

Esse gatilho embutido faz uma chamada HTTP para a URL especificada para o endpoint e retorna uma resposta.

Adicionar uma ação HTTP

Esta ação incorporada envia uma chamada HTTPS ou HTTP para a URL especificada de um endpoint e retorna uma resposta.

Saídas de gatilho e ação

Um gatilho OU ação HTTP gera as seguintes informações:

Segurança de URL para chamadas de saída

Para obter informações sobre criptografia, segurança e autorização para chamadas de saída de seu fluxo de trabalho, como TLS (Transport Layer Security), certificados autoassinados ou Autenticação Aberta da ID do Microsoft Entra, consulte o Access para chamadas de saída para outros serviços e sistemas.

Autenticação para ambiente de locatário único

Se você tiver um recurso de aplicativo lógico Standard nos Aplicativos Lógicos do Azure de locatário único e quiser usar uma operação HTTP com qualquer um dos seguintes tipos de autenticação, conclua as etapas de instalação extras para o tipo de autenticação correspondente. Caso contrário, a chamada falhará.

• Certificado TLS: adicione a configuração WEBSITE_LOAD_ROOT_CERTIFICATESdo aplicativo e defina o valor para a impressão digital do certificado TLS.

• Certificado do cliente ou Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) com o tipo de credencial Certificate: Adicione a configuração do aplicativo WEBSITE_LOAD_USER_PROFILE, e defina o valor como 1.

Autenticação de certificado TLS

1. Nas configurações do aplicativo do recurso do aplicativo lógico, adicione ou atualize a configuração do aplicativo chamada WEBSITE_LOAD_ROOT_CERTIFICATES. Para obter etapas específicas, consulte Gerenciar configurações de aplicativo – local.settings.json.

2. Para o valor da configuração, forneça a impressão digital do seu certificado TLS como o certificado raiz confiável.

   "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS-certificate>"

Por exemplo, se você estiver trabalhando no Visual Studio Code, siga estas etapas:

1. Abra o arquivo local.settings.json do seu projeto de aplicativo de lógica.

2. Values No objeto JSON, adicione ou atualize a WEBSITE_LOAD_ROOT_CERTIFICATES configuração:

   {
      "IsEncrypted": false,
      "Values": {
         <...>
         "AzureWebJobsStorage": "UseDevelopmentStorage=true",
         "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS-certificate>",
         <...>
      }
   }
   

Para obter mais informações, consulte Gerenciar configurações do aplicativo – local.settings.json.

Certificado do cliente ou OAuth do Microsoft Entra ID com autenticação do tipo de credencial Certificado

1. Nas configurações do aplicativo do recurso do aplicativo lógico, adicione ou atualize a configuração do aplicativo chamada WEBSITE_LOAD_USER_PROFILE. Para obter etapas específicas, consulte Gerenciar configurações do aplicativo – local.settings.json

2. Para o valor de configuração, especifique 1.

   "WEBSITE_LOAD_USER_PROFILE": "1"

Por exemplo, se você estiver trabalhando no Visual Studio Code, siga estas etapas:

1. Abra o arquivo local.settings.json do seu projeto de aplicativo de lógica.

2. Values No objeto JSON, adicione ou atualize a WEBSITE_LOAD_USER_PROFILE configuração:

   {
      "IsEncrypted": false,
      "Values": {
         <...>
         "AzureWebJobsStorage": "UseDevelopmentStorage=true",
         "WEBSITE_LOAD_USER_PROFILE": "1",
         <...>
      }
   }
   

Se você estiver trabalhando no portal do Azure, abra seu aplicativo lógico. Em Configurações no menu da barra lateral, selecione Variáveis de ambiente. Nas configurações do aplicativo, adicione ou edite a configuração.

Conteúdo com o tipo multipart/form-data

Para lidar com o conteúdo que tem multipart/form-data tipo em solicitações HTTP, você pode adicionar um objeto JSON que inclui o $content-type e $multipart os atributos no corpo da solicitação HTTP usando esse formato.

"body": {
   "$content-type": "multipart/form-data",
   "$multipart": [
      {
         "body": "<output-from-trigger-or-previous-action>",
         "headers": {
            "Content-Disposition": "form-data; name=file; filename=<file-name>"
         }
      }
   ]
}

Por exemplo, suponha que você tenha um fluxo de trabalho que envia uma solicitação HTTP POST para um arquivo do Excel para um site usando a API desse site, que dá suporte ao multipart/form-data tipo. O exemplo a seguir mostra como essa ação pode aparecer:

Aqui está o mesmo exemplo que mostra a definição JSON da ação HTTP na definição de fluxo de trabalho subjacente:

"HTTP_action": {
   "inputs": {
      "body": {
         "$content-type": "multipart/form-data",
         "$multipart": [
            {
               "body": "@trigger()",
               "headers": {
                  "Content-Disposition": "form-data; name=file; filename=myExcelFile.xlsx"
               }
            }
         ]
      },
      "method": "POST",
      "uri": "https://finance.contoso.com"
   },
   "runAfter": {},
   "type": "Http"
}

Conteúdo com o tipo application/x-www-form-urlencoded

Para inserir dados form-urlencoded no corpo de uma solicitação HTTP, é preciso especificar que os dados têm o tipo de conteúdo application/x-www-form-urlencoded. No gatilho ou ação HTTP, adicione o cabeçalho content-type. Defina o valor do cabeçalho como application/x-www-form-urlencoded.

Por exemplo, suponha que você tenha um aplicativo lógico que envia uma solicitação HTTP POST para um site, que dá suporte ao application/x-www-form-urlencoded tipo. Veja a aparência dessa ação:

Comportamento assíncrono de solicitação-resposta

Para fluxos de trabalho com estado em Aplicativos Lógicos do Azure multilocatário e de locatário único, todas as ações baseadas em HTTP seguem a operação assíncrona padrão como o comportamento padrão. Esse padrão especifica que, após uma ação HTTP chamar ou enviar uma requisição para um ponto de extremidade, serviço, sistema ou API, o receptor da requisição retorna imediatamente uma resposta 202 ACCEPTED. Esse código confirma que o destinatário aceitou a solicitação, mas não concluiu o processamento. A resposta pode incluir um location cabeçalho que especifica o URI e uma ID de atualização que o chamador pode usar para sondar ou verificar o status da solicitação assíncrona até que o receptor pare de processar e retorne uma resposta de sucesso 200 OK ou outra resposta não 202. No entanto, o autor da chamada não precisa esperar o processamento da solicitação. Ele pode continuar e executar a próxima ação. Para obter mais informações, consulte mensagens síncronas versus assíncronas.

Para fluxos de trabalho sem estado nos Aplicativos Lógicos do Azure de locatário único, as ações baseadas em HTTP não usam o padrão de operação assíncrona. Em vez disso, eles só são executados de forma síncrona, retornam a resposta ACEITA 202 como está e prosseguem para a próxima etapa na execução do fluxo de trabalho. Se a resposta incluir um location cabeçalho, um fluxo de trabalho sem estado não sondará o URI especificado para verificar o status. Para seguir o padrão de operação assíncrona padrão, use um fluxo de trabalho com estado.

• A definição de JSON subjacente da ação HTTP segue implicitamente o padrão de operação assíncrona.

• A ação HTTP, mas não o gatilho, tem uma configuração de padrão assíncrono , que é habilitada por padrão. Essa configuração especifica que o chamador não aguarda a conclusão do processamento e pode passar para a próxima ação, mas continua verificando o status até que o processamento seja interrompido. Se desabilitada, essa configuração especifica que o autor da chamada aguarda o processamento ser concluído antes de passar para a próxima ação.

  Para localizar a configuração de padrão assíncrono :

  1. No designer de fluxo de trabalho, selecione a ação HTTP .
  2. No painel de informações que é aberto, selecione Configurações.
  3. Em Rede, localize a configuração de padrão assíncrono .

Desabilitar operações assíncronas

Às vezes, talvez você queira desabilitar o comportamento assíncrono da ação HTTP em cenários específicos, por exemplo, quando quiser:

• Evitar tempos limite de HTTP para tarefas de execução prolongada
• Desabilitar verificação de cabeçalhos de localização

Desativar a configuração de padrão assíncrono

1. No designer de fluxo de trabalho, selecione a ação HTTP e, no painel de informações que é aberto, selecione Configurações.

2. Em Rede, localize a configuração de padrão assíncrono . Desative a configuração para Desativada se estiver habilitada.

Desabilitar o padrão assíncrono na definição de JSON da ação

Na definição de JSON subjacente da ação HTTP, adicione a opção DisableAsyncPattern de operação à definição da ação para que a ação siga o padrão de operação síncrona. Para obter mais informações, consulte também Executar ações em um padrão de operação síncrona.

Evitar tempos limite de HTTP para tarefas de execução prolongada

As solicitações HTTP têm um limite de tempo limite. Se você tiver uma ação HTTP de execução longa que expira por causa desse limite, você tem estas opções:

• Desabilite o padrão de operação assíncrona da ação HTTP para que a ação não pesquise ou verifique continuamente o status da solicitação. Em vez disso, a ação aguarda que o receptor responda com o status e os resultados após a conclusão do processamento da solicitação.

• Substitua a ação HTTP pela ação webhook HTTP, que aguarda o receptor responder com o status e os resultados após a conclusão do processamento da solicitação.

Configurar o intervalo entre tentativas de repetição com o cabeçalho Retry-After

Para especificar o número de segundos entre tentativas de repetição, você pode adicionar o Retry-After cabeçalho à resposta de ação HTTP. Por exemplo, se o ponto de extremidade de destino retornar o 429 - Too many requests código de status, você poderá especificar um intervalo mais longo entre novas tentativas. O cabeçalho Retry-After também funciona com o código de status 202 - Accepted.

Este é o mesmo exemplo que mostra a resposta de ação HTTP que contém Retry-After:

{
    "statusCode": 429,
    "headers": {
        "Retry-After": "300"
    }
}

Suporte à paginação

Às vezes, o serviço de destino responde retornando os resultados uma página de cada vez. Se a resposta especificar a próxima página com a propriedade nextLink ou a propriedade @odata.nextLink, você poderá ativar a configuração de Paginação na ação HTTP. Essa configuração faz com que a ação HTTP siga automaticamente esses links e obtenha a próxima página. No entanto, se a resposta especificar a próxima página com qualquer outra etiqueta, talvez seja necessário adicionar um loop no fluxo de trabalho. Faça com que esse loop siga essa etiqueta e obtenha cada página manualmente até que a etiqueta seja nula.

Desabilitar a verificação de cabeçalhos de localização

Alguns pontos de extremidade, serviços, sistemas ou APIs retornam uma 202 ACCEPTED resposta que não tem um location cabeçalho. Para evitar que uma ação HTTP verifique continuamente o status da solicitação quando o location cabeçalho não existir, você pode ter estas opções:

• Desabilite o padrão de operação assíncrona da ação HTTP para que a ação não pesquise ou verifique continuamente o status da solicitação. Em vez disso, a ação aguarda que o receptor responda com o status e os resultados após a conclusão do processamento da solicitação.

• Substitua a ação HTTP pela ação webhook HTTP, que aguarda o receptor responder com o status e os resultados após a conclusão do processamento da solicitação.

Problemas conhecidos

Cabeçalhos HTTP omitidos

Se um gatilho HTTP ou ação incluir esses cabeçalhos, os Aplicativos Lógicos do Azure removerão esses cabeçalhos da mensagem de solicitação gerada sem mostrar nenhum aviso ou erro:

• Accept-* cabeçalhos, exceto Accept-version
• Allow
• Cabeçalhos Content-*, exceto Content-Disposition, Content-Encoding e Content-Type, que são respeitados quando você usa as operações POST e PUT. No entanto, os Aplicativos Lógicos do Azure descartam esses cabeçalhos quando você usa a GET operação.
• Cabeçalho Cookie, mas os Aplicativos Lógicos do Azure respeitam qualquer valor que você especificar usando a propriedade Cookie.
• Expires
• Host
• Last-Modified
• Origin
• Set-Cookie
• Transfer-Encoding

Embora os Aplicativos Lógicos do Azure não impeçam você de salvar aplicativos lógicos que usam um gatilho HTTP ou uma ação com esses cabeçalhos, os Aplicativos Lógicos do Azure ignoram esses cabeçalhos.

O conteúdo da resposta não corresponde ao tipo de conteúdo esperado

A ação HTTP gerará um erro BadRequest se a ação HTTP chamar a API de back-end com o Content-Type cabeçalho definido como application/json, mas a resposta do back-end não contiver conteúdo no formato JSON, o que falhará na validação de formato JSON interno.

Conteúdo relacionado

• Conectores gerenciados para Azure Logic Apps
• Conectores internos de Aplicativos Lógicos do Azure