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:

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

Adicionar um gatilho HTTP

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

Standard

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:

   • Adicionar autenticação a chamadas de saída
   • Autenticar o acesso a recursos com identidades gerenciadas

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.

Consumo

1. No portal do Azure, abra seu aplicativo lógico de consumo e 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:

   • Adicionar autenticação a chamadas de saída
   • Autenticar o acesso a recursos com identidades gerenciadas

4. Para adicionar outros parâmetros disponíveis, abra a lista Adicionar novo parâmetro 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.

Standard

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:

   • Adicionar autenticação a chamadas de saída
   • Autenticar o acesso a recursos com identidades gerenciadas

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.

Consumo

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:

   • Adicionar autenticação a chamadas de saída
   • Autenticar o acesso a recursos com identidades gerenciadas

4. Para adicionar outros parâmetros disponíveis, abra a lista Adicionar novo parâmetro 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á.

• Certificado TLS/SSL: WEBSITE_LOAD_ROOT_CERTIFICATESadicione a configuração do aplicativo e defina o valor para a impressão digital do seu certificado TLS/SSL.

• Certificado de cliente ou Autenticação de Abertura de ID do Microsoft Entra (Microsoft Entra ID OAuth) com o tipo de credencial "Certificado": adicione a configuração WEBSITE_LOAD_USER_PROFILEdo aplicativo e defina o valor como 1.

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:

• Editar configurações de host e aplicativo para aplicativos lógicos em Aplicativos Lógicos do Azure de locatário único
• Certificados de cliente privado - Serviço de Aplicativo do Azure

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:

• Editar configurações de host e aplicativo para aplicativos lógicos em Aplicativos Lógicos do Azure de locatário único
• Certificados de cliente privado - Serviço de Aplicativo do Azure

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

Fluxo de trabalho de consumo

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

Fluxo de trabalho de consumo

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:

• Evite tempos limite HTTP para tarefas de longa execução
• Desativar a verificação de cabeçalhos de localização

Desativar a configuração Padrão assíncrono

Standard

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.

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, ative a configuração para Desativado, se habilitada, e selecione Concluído.

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

• Conectores gerenciados para Aplicativos Lógicos do Azure
• Conectores internos para Aplicativos Lógicos do Azure