Partilhar via

Chamar endpoints HTTP ou HTTPS externos de fluxos de trabalho no Azure Logic Apps

Aplica-se a: Azure Logic Apps (Consumo e Standard)

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

Observação

Para criar um fluxo de trabalho que receba e responda a chamadas HTTPS de entrada, consulte Criar fluxos de trabalho que você pode chamar, acionar ou aninhar usando pontos de extremidade HTTPS nos Aplicativos Lógicos do Azure. Para usar o gatilho interno de Solicitação, consulte Receber e responder a chamadas HTTPS de entrada para fluxos de trabalho nos Aplicativos Lógicos do Azure.

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 sondar um ponto de extremidade num horário recorrente, adicione o gatilho interno chamado HTTP como primeiro passo no teu fluxo de trabalho. Cada vez 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 seu fluxo de trabalho será executado. O gatilho passa qualquer conteúdo da resposta do endpoint para as ações no seu fluxo de trabalho.

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

Pré-requisitos

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:

Adicionar um gatilho HTTP

Este gatilho interno faz uma chamada HTTP para a URL especificada para um endpoint e retorna uma resposta.

  1. No portal do Azure, abra seu recurso de aplicativo lógico padrão.

  2. No menu da barra lateral do recurso, em Fluxos de trabalho, selecione Fluxos de trabalho e, em seguida, selecione o fluxo de trabalho em branco.

  3. No menu da barra lateral do fluxo de trabalho, em Ferramentas, selecione o designer para abrir o fluxo de trabalho.

  4. Adicione o gatilho HTTP interno ao seu fluxo de trabalho seguindo as etapas gerais para adicionar um gatilho.

    Este exemplo renomeia o gatilho para HTTP trigger - Call endpoint URL para que o gatilho tenha um nome mais descritivo. Além disso, o exemplo adiciona posteriormente uma ação HTTP e os nomes das operações no fluxo de trabalho devem ser exclusivos.

  5. Forneça os valores para os parâmetros de gatilho HTTP que você deseja incluir na chamada para o ponto de extremidade de destino. Configure a recorrência para a frequência com que você deseja que o gatilho verifique o ponto de extremidade de destino.

  6. Na lista Parâmetros avançados , selecione Autenticação.

    Se você selecionar um tipo de autenticação diferente de Nenhum, as configurações de autenticação serão diferentes com base na sua seleção. Para obter mais informações sobre tipos de autenticação disponíveis para HTTP, consulte os seguintes artigos:

  7. Adicione quaisquer outras ações que você deseja executar quando o gatilho for acionado.

  8. Quando terminar, salve seu fluxo de trabalho. Na barra de ferramentas do designer, selecione Salvar.

Adicionar uma ação HTTP

Essa ação interna envia uma chamada HTTPS ou HTTP para a URL especificada para um ponto de extremidade e retorna com uma resposta.

  1. No portal do Azure, abra seu recurso de aplicativo lógico padrão.

  2. No menu da barra lateral de recursos, em Fluxos de trabalho, selecione Fluxos de trabalho e, em seguida, selecione o fluxo de trabalho.

  3. No menu da barra lateral do fluxo de trabalho, em Ferramentas, selecione o designer para abrir o fluxo de trabalho.

    Este exemplo usa o gatilho HTTP adicionado na seção anterior.

  4. Adicione a ação interna HTTP ao seu fluxo de trabalho seguindo as etapas gerais para adicionar uma ação.

    Este exemplo renomeia a ação para HTTP action - Call endpoint URL para que a ação tenha um nome mais descritivo. Além disso, os nomes de operação em seu fluxo de trabalho devem ser exclusivos.

  5. Forneça os valores para os parâmetros de ação HTTP que você deseja incluir na chamada para o ponto de extremidade de destino.

  6. Na lista Parâmetros avançados , selecione Autenticação.

    Se você selecionar um tipo de autenticação diferente de Nenhum, as configurações de autenticação serão diferentes com base na sua seleção. Para obter mais informações sobre tipos de autenticação disponíveis para HTTP, consulte os seguintes artigos:

  7. Adicione quaisquer outras ações que você deseja executar quando o gatilho for acionado.

  8. Quando terminar, salve seu fluxo de trabalho. Na barra de ferramentas do designer, selecione Salvar.

Saídas de gatilho e ação

Um gatilho ou ação HTTP produz as seguintes informações:

Propriedade Tipo Descrição
headers Objeto JSON Os cabeçalhos da solicitação
body Objeto JSON O objeto com o conteúdo do corpo da solicitação
status code Número inteiro O código de status da solicitação
Código de estado Descrição
200 OK
202 Aceito
400 Solicitação inválida
401 Não autorizado
403 Proibido
404 Não encontrado
500 Erro de servidor interno. Ocorreu um erro desconhecido.

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 do seu fluxo de trabalho, como TLS (Transport Layer Security), certificados autoassinados ou Autenticação Aberta do Microsoft Entra ID, consulte Acesso 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 padrão em 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 configuração adicionais para o tipo de autenticação correspondente. Caso contrário, a chamada falhará.

Autenticação de certificado TLS

  1. Nas definições da aplicação lógica, adicione ou atualize a definição da aplicação chamada WEBSITE_LOAD_ROOT_CERTIFICATES. Para obter etapas específicas, consulte Gerenciar configurações do aplicativo - local.settings.json.

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

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

Por exemplo, se estiver a trabalhar no Visual Studio Code, siga estes passos:

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

  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>",
      <...>
   }
}

Observação

Para localizar a impressão digital, siga estes passos:

  • No menu de recursos do aplicativo lógico, em Configurações, selecione Certificados.
  • Selecione Trazer seus próprios certificados (.pfx) ou Certificados de chave pública (.cer).
  • Localize o certificado que pretende utilizar e copie a impressão digital.

Para obter mais informações, consulte Localizar a impressão digital - Serviço de Aplicativo do Azure.

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

Certificado de cliente ou Microsoft Entra ID OAuth com autenticação de tipo de credencial de 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 da configuração, especifique 1.

    "WEBSITE_LOAD_USER_PROFILE": "1"

Por exemplo, se estiver a trabalhar no Visual Studio Code, siga estes passos:

  1. Abra o arquivo local.settings.json do seu projeto de aplicação 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. Em Configurações do aplicativo, adicione ou edite a configuração.

Conteúdo com tipo multipart/form-data

Para manipular o conteúdo que tem multipart/form-data tipo em solicitações HTTP, você pode adicionar um objeto JSON que inclui os $content-type atributos e $multipart 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 suporta o multipart/form-data tipo. O exemplo a seguir mostra como essa ação pode aparecer:

Captura de tela que mostra o fluxo de trabalho com ação HTTP e dados de formulário com várias partes.

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 fornecer dados codificados em formulário URL no corpo de uma solicitação HTTP, deve especificar que os dados têm o application/x-www-form-urlencoded tipo de conteúdo. 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 suporta o application/x-www-form-urlencoded tipo. Veja como essa ação pode parecer:

Captura de tela que mostra o fluxo de trabalho com solicitação HTTP e cabeçalho de tipo de conteúdo definido como application slash x-www-form-urlencoded.

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 o padrão de operação assíncrona como o comportamento padrão. Esse padrão especifica que, depois que uma ação HTTP chama ou envia uma solicitação para um ponto de extremidade, serviço, sistema ou API, o recetor retorna imediatamente uma resposta 202 ACCEPTED . Este código confirma que o destinatário aceitou o pedido, mas não terminou o processamento. A resposta pode incluir um location cabeçalho que especifica o URI e um ID de atualização que o chamador pode usar para sondar ou verificar o status da solicitação assíncrona até que o recetor pare de processar e retorne uma resposta de sucesso 200 OK ou outra resposta não 202. No entanto, o chamador não precisa esperar que a solicitação termine o processamento e pode continuar a executar a próxima ação. Para obter mais informações, consulte Mensagens síncronas versus assíncronas.

Para fluxos de trabalho sem estado em Azure Logic Apps de instância única, as ações baseadas em HTTP não usam o padrão de operações assíncronas. Em vez disso, eles só são executados de forma síncrona, retornam a resposta 202 ACCEPTED as-ise 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, use em vez disso um fluxo de trabalho com estado.

  • A definição 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 espera a conclusão do processamento e pode passar para a próxima ação, mas continua verificando o status até que o processamento pare. Se desabilitada, essa configuração especifica que o chamador aguarda a conclusão do processamento 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 se abre, selecione Configurações.
    3. Em Rede, localize a configuração de padrão assíncrono .

Desativar operações assíncronas

Às vezes, convém desabilitar o comportamento assíncrono da ação HTTP em cenários específicos, por exemplo, quando quiser:

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 se abre, selecione Configurações.

  2. Em Rede, localize a configuração de padrão assíncrono . Ative a configuração para Desativado , se habilitada.

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

Na definição JSON subjacente da ação HTTP, adicione a DisableAsyncPattern opção 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.

Evite tempos limite HTTP para tarefas de longa execução

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

  • Desative 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 destinatário responda com o status e os resultados após o processamento da solicitação.

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

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

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

Aqui está o mesmo exemplo que mostra a resposta da ação HTTP que contém Retry-After:

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

Suporte de 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 nextLink ou @odata.nextLink propriedade, você poderá ativar a configuração 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 tag, talvez seja necessário adicionar um loop ao fluxo de trabalho. Faça com que esse loop siga essa tag e obtenha manualmente cada página até que a tag seja nula.

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

Alguns endpoints, 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 existe, você pode ter estas opções:

  • Desative 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 destinatário responda com o status e os resultados após o processamento da solicitação.

  • Substitua a ação HTTP pela ação HTTP Webhook, que aguarda que o recetor responda 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 ou ação HTTP 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 para Accept-version
  • Allow
  • Content-* cabeçalhos, exceto Content-Disposition, Content-Encoding, e Content-Type, que são respeitados quando o utilizador utiliza 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.
  • Cookie cabeçalho, mas os Aplicativos Lógicos do Azure honram qualquer valor que 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 ou ação HTTP com esses cabeçalhos, os Aplicativos Lógicos do Azure ignoram esses cabeçalhos.

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

A ação HTTP lança 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 falha na validação interna do formato JSON.

Conteúdo relacionado