Partilhar via


Chamar pontos de extremidade HTTP ou HTTPS externos de fluxos de trabalho nos Aplicativos Lógicos do Azure

Aplica-se a: Aplicativos Lógicos do Azure (Consumo + Padrão)

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 você queira monitorar um ponto de extremidade de serviço para seu site verificando esse ponto de extremidade em uma agenda específica. Quando um evento específico acontece nesse ponto de extremidade, como o inativo do seu site, esse evento aciona seu fluxo de trabalho e executa as ações nesse fluxo de trabalho.

Nota

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 e a ação interna de Solicitação e Resposta.

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 em uma agenda recorrente, adicione o gatilho HTTP como a primeira etapa em seu 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 ponto de extremidade determina se o fluxo de trabalho é executado. O gatilho passa qualquer conteúdo da resposta do ponto de extremidade para as ações em seu fluxo de trabalho.

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

Pré-requisitos

  • Uma conta e subscrição do Azure. Se não tiver uma subscrição do Azure, inscreva-se para obter uma conta do Azure gratuita.

  • A URL do ponto de extremidade de destino que você deseja chamar

  • O fluxo de trabalho do aplicativo lógico de onde você deseja chamar o ponto de extremidade de destino. Para começar com o gatilho HTTP, você precisa de um fluxo de trabalho em branco. Para usar a ação HTTP, inicie seu fluxo de trabalho com qualquer gatilho desejado. Este exemplo usa o gatilho HTTP como a primeira etapa.

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:

Adicionar um gatilho HTTP

Esse gatilho interno faz uma chamada HTTP para a URL especificada para um ponto de extremidade e retorna uma resposta.

  1. No portal do Azure, abra o recurso do aplicativo lógico padrão e o fluxo de trabalho em branco no designer.

  2. Siga estas etapas gerais para adicionar o gatilho interno chamado HTTP ao seu fluxo de trabalho.

    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.

  3. 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.

    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 os tipos de autenticação disponíveis para HTTP, consulte os seguintes tópicos:

  4. Para adicionar outros parâmetros disponíveis, abra a lista Parâmetros avançados e selecione os parâmetros desejados.

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

  6. Quando tiver terminado, guarde o fluxo de trabalho. Na barra de ferramentas do estruturador, selecione Guardar.

Adicionar uma ação HTTP

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

  1. No portal do Azure, abra seu aplicativo lógico de consumo e fluxo de trabalho no designer.

    Este exemplo usa o gatilho HTTP adicionado na seção anterior como a primeira etapa.

  2. Siga estas etapas gerais para adicionar a ação interna chamada HTTP ao seu fluxo de trabalho.

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

  3. 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.

    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 os tipos de autenticação disponíveis para HTTP, consulte estes tópicos:

  4. Para adicionar outros parâmetros disponíveis, abra a lista Parâmetros avançados e selecione os parâmetros desejados.

  5. Quando tiver terminado, guarde o fluxo de trabalho. Na barra de ferramentas do estruturador, selecione Guardar.

Saídas de gatilho e ação

Aqui estão mais informações sobre as saídas de um gatilho ou ação HTTP, que retorna as seguintes informações:

Propriedade Type Description
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 Description
200 OK
202 Aceite
400 Mau pedido
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), anteriormente conhecido como SSL (Secure Sockets Layer), certificados autoassinados ou Autenticação Aberta do Microsoft Entra ID (Microsoft Entra ID OAuth), consulte Acesso seguro e dados - 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/SSL

  1. Nas configurações do aplicativo do recurso do aplicativo lógico, adicione ou atualize a configuração do aplicativo, WEBSITE_LOAD_ROOT_CERTIFICATES.

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

    "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS/SSL-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/SSL-certificate>",
          <...>
       }
    }
    

    Nota

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

    1. No menu de recursos do aplicativo lógico, em Configurações, selecione Configurações TLS/SSL Certificados>de chave privada (.pfx) ou Certificados de chave pública (.cer).

    2. 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 a seguinte documentação:

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

  1. Nas configurações do aplicativo do recurso do aplicativo lógico, adicione ou atualize a configuração do aplicativo, WEBSITE_LOAD_USER_PROFILE.

  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 aplicativo lógico.

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

Para obter mais informações, consulte a seguinte documentação:

Conteúdo com multipart/form-data type

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 ao 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:

Fluxo de trabalho padrão

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

Fluxo de trabalho de consumo

A captura de tela mostra o fluxo de trabalho de consumo 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 tipo application/x-www-form-urlencoded

Para fornecer dados codificados por url no corpo para uma solicitação HTTP, você precisa especificar que os dados têm o application/x-www-form-urlencoded tipo de conteúdo. No gatilho ou ação HTTP, adicione o content-type cabeçalho. 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:

Fluxo de trabalho padrão

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

Fluxo de trabalho de consumo

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

Comportamento assíncrono de solicitação-resposta

Para fluxos de trabalho com monitoração de 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 padrão 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 A integração assíncrona de microsserviços impõe a autonomia do microsserviço.

Para fluxos de trabalho sem monitoração de estado em 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 "202 ACCEPTED" 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 pesquisará 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 monitoração de estado.

  • A definição subjacente de JavaScript Object Notation (JSON) 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 Padrão assíncrono, siga estas etapas, com base no fato de você ter um fluxo de trabalho Padrão ou de Consumo:

    Fluxo de trabalho padrão*

    1. No designer de fluxo de trabalho, selecione a ação HTTP. No painel de informações que se abre, selecione Configurações.

    2. Em Rede, localize a configuração Padrão assíncrono.

    Fluxo de trabalho de consumo

    1. No designer de fluxo de trabalho, na barra de título da ação HTTP, selecione o botão de reticências (...), que abre as configurações da ação.

    2. Encontre a configuração 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 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 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 ponto de extremidade de destino retornar o código de 429 - Too many requests status, você poderá especificar um intervalo maior entre as tentativas. O Retry-After cabeçalho também funciona com o código de 202 - Accepted status.

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 à 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 @odata.nextLink , 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 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 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 honrados 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 operação GET.
  • Cookie mas os Aplicativos Lógicos do Azure honram qualquer valor especificado 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.

Próximos passos