Compartir a través de


Llamada a puntos de conexión HTTP o HTTPS externos desde flujos de trabajo en Azure Logic Apps

Se aplica a: Azure Logic Apps (consumo + estándar)

Algunos escenarios pueden requerir que cree un flujo de trabajo de aplicación lógica que envíe solicitudes salientes a puntos de conexión en otros servicios o sistemas a través de HTTP o HTTPS. Por ejemplo, supongamos que quiere supervisar un punto de conexión de servicio para el sitio web comprobando ese punto de conexión según una programación específica. Al producir un evento específico en ese punto de conexión, como el sitio web, ese evento desencadena el flujo de trabajo y ejecuta las acciones de ese flujo de trabajo.

Nota:

Para crear un flujo de trabajo que reciba y responda a llamadas HTTPS entrantes en su lugar, consulte Creación de flujos de trabajo que puede llamar, desencadenar o anidar mediante puntos de conexión HTTPS en Azure Logic Apps y la Acción integrada Solicitud y Respuesta.

En esta guía se muestra cómo usar el desencadenador HTTP y la acción HTTP para que el flujo de trabajo pueda enviar llamadas salientes a otros servicios y sistemas, por ejemplo:

  • Agregue el desencadenador HTTP como primer paso del flujo de trabajo para comprobar o sondear un punto de conexión según una programación recurrente. Cada vez que el desencadenador comprueba el punto de conexión, el desencadenador llama a o envía una solicitud al punto de conexión. La respuesta del punto de conexión determina si se ejecuta el flujo de trabajo. El desencadenador pasa cualquier contenido de la respuesta del punto de conexión a las acciones del flujo de trabajo.

  • Para llamar a un punto de conexión desde cualquier parte del flujo de trabajo, agregue la acción HTTP. La respuesta del punto de conexión determina cómo se ejecutan las acciones restantes de su flujo de trabajo.

Requisitos previos

  • Una cuenta y una suscripción de Azure. Si no tiene una suscripción de Azure, regístrese para obtener una cuenta gratuita de Azure.

  • Dirección URL del punto de conexión de destino al que desea llamar

  • Flujo de trabajo de la aplicación lógica desde donde desea llamar al punto de conexión de destino. Para empezar con el desencadenador HTTP, necesita un flujo de trabajo en blanco. Para usar la acción HTTP, inicie el flujo de trabajo con cualquier desencadenador que desee. En este ejemplo se usa el desencadenador HTTP como primer paso.

Referencia técnica del conector

Para obtener información técnica sobre los parámetros de desencadenador y acción, consulte las secciones siguientes:

Agregar un desencadenador HTTP

Este desencadenador integrado realiza una llamada HTTP a la dirección URL especificada para un punto de conexión y devuelve una respuesta.

  1. En Azure Portal, abra su recurso de aplicación lógica Estándar y el flujo de trabajo en blanco en el diseñador.

  2. Siga estos pasos generales para agregar el desencadenador integrado denominado HTTP al flujo de trabajo.

    Este ejemplo cambia el nombre del desencadenador para Desencadenar HTTP: llamada a la dirección URL del punto de conexión para que el desencadenador tenga un nombre más descriptivo. Además, en el ejemplo posterior se agrega una acción HTTP y los nombres de operación del flujo de trabajo deben ser únicos.

  3. Proporcione los valores de los Parámetros de desencadenador HTTP que quiere incluir en la llamada al punto de conexión de destino. Configure la periodicidad con la frecuencia con la que desea que el desencadenador compruebe el punto de conexión de destino.

    Si selecciona un tipo de autenticación distinto de Ninguno, la configuración de autenticación difiere en función de la selección. Para obtener más información sobre los tipos de autenticación disponibles para HTTP, consulte los temas siguientes:

  4. Para agregar otros parámetros disponibles, abra la lista Parámetros avanzados y seleccione los parámetros que desee.

  5. Agregue cualquier otra acción que quiera ejecutar cuando se active el desencadenador.

  6. Cuando haya terminado, guarde el flujo de trabajo. En la barra de herramientas del diseñador, seleccione Save (Guardar).

Adición de una acción HTTP

Esta acción integrada realiza una llamada HTTP a la dirección URL especificada para un punto de conexión y devuelve una respuesta.

  1. En el Azure Portal, abra su aplicación lógica de consumo y su flujo de trabajo en el diseñador.

    En este ejemplo se usa el desencadenador HTTP agregado en la sección anterior como primer paso.

  2. Siga estos pasos generales para agregar la acción integrada denominada HTTP al flujo de trabajo.

    En este ejemplo se cambia el nombre de la acción a Acción HTTP: llamada a la dirección URL del punto de conexión para que el paso tenga un nombre más descriptivo. Además, los nombres de operación del flujo de trabajo deben ser únicos.

  3. Proporcione los valores de los Parámetros de acción HTTP que quiere incluir en la llamada al punto de conexión de destino.

    Si selecciona un tipo de autenticación distinto de Ninguno, la configuración de autenticación difiere en función de la selección. Para obtener más información sobre los tipos de autenticación disponibles para HTTP, consulte estos temas:

  4. Para agregar otros parámetros disponibles, abra la lista Parámetros avanzados y seleccione los parámetros que desee.

  5. Cuando haya terminado, guarde el flujo de trabajo. En la barra de herramientas del diseñador, seleccione Save (Guardar).

Salidas de los desencadenadores y las acciones

Esta es más información sobre las salidas de un desencadenador o una acción HTTP, que devuelve la siguiente información:

Propiedad Tipo Descripción
headers Objeto JSON Encabezados de la solicitud
body Objeto JSON Objeto con el contenido del cuerpo de la solicitud
status code Entero Código de estado de la solicitud
status code Descripción
200 Aceptar
202 Aceptadas
400 Solicitud incorrecta
401 No autorizado
403 Prohibida
404 No encontrado
500 Error interno del servidor. Error desconocido.

Seguridad de direcciones URL para llamadas salientes

Para obtener información sobre el cifrado, la seguridad y la autorización de las llamadas salientes del flujo de trabajo, como Seguridad de la capa de transporte (TLS), anteriormente conocido como Capa de sockets seguros (SSL), certificados autofirmados o Autenticación abierta de Microsoft Entra ID (Microsoft Entra ID OAuth), consulte Acceso seguro y datos: acceso para llamadas salientes a otros servicios y sistemas.

Autenticación para un entorno de inquilino único

Si tiene un recurso de aplicación lógica estándar en Azure Logic Apps de inquilino único y quiere usar una operación HTTP con cualquiera de los siguientes tipos de autenticación, asegúrese de completar los pasos de configuración adicionales para el tipo de autenticación correspondiente. De lo contrario, se produce un error en la llamada.

Autenticación con certificados TLS/SSL

  1. En la configuración de la aplicación del recurso de aplicación lógica, agregue o actualice la configuración de la aplicación, WEBSITE_LOAD_ROOT_CERTIFICATES.

  2. Para el valor de configuración, proporcione la huella digital del certificado TLS/SSL como certificado raíz de confianza.

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

Por ejemplo, si trabaja en Visual Studio Code, siga estos pasos:

  1. Abra el archivo local.settings.json del proyecto de aplicación lógica.

  2. En el objeto JSON Values, agregue o actualice la configuración WEBSITE_LOAD_ROOT_CERTIFICATES:

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

    Nota:

    Para buscar la huella digital, siga estos pasos:

    1. En el menú de recursos de la aplicación lógica, en Configuración, seleccione Configuración de TLS/SSL>Certificados de clave privada (.pfx) o Certificados de clave pública (.cer).

    2. Encuentre el certificado que quiere usar y copie la huella digital.

    Para obtener más información, consulte Busque la huella digital: Azure App Service.

Para más información, revise la siguiente documentación:

Certificado de cliente o Microsoft Entra ID OAuth con autenticación de tipo de credencial "Certificado"

  1. En la configuración de la aplicación del recurso de aplicación lógica, agregue o actualice la configuración de la aplicación, WEBSITE_LOAD_USER_PROFILE.

  2. Para el valor de configuración, especifique 1.

    "WEBSITE_LOAD_USER_PROFILE": "1"

Por ejemplo, si trabaja en Visual Studio Code, siga estos pasos:

  1. Abra el archivo local.settings.json del proyecto de aplicación lógica.

  2. En el objeto JSON Values, agregue o actualice la configuración WEBSITE_LOAD_USER_PROFILE:

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

Para más información, revise la siguiente documentación:

Contenido con el tipo multipart/form-data

Para controlar el contenido que tiene el tipo multipart/form-data en las solicitudes HTTP, puede agregar un objeto JSON que incluya los atributos $content-type y $multipart al cuerpo de la solicitud HTTP con este 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 ejemplo, supongamos que tiene un flujo de trabajo que envía una solicitud HTTP POST para un archivo de Excel a un sitio web mediante la API de ese sitio, que admite el tipo multipart/form-data. En el ejemplo siguiente se muestra cómo puede aparecer esta acción:

Flujo de trabajo Estándar

Captura de pantalla que muestra el flujo de trabajo estándar con la acción HTTP y los datos de formularios de varias partes.

Flujo de trabajo de consumo

Captura de pantalla que muestra el flujo de trabajo consumo con la acción HTTP y los datos de formularios de varias partes.

Este es el mismo ejemplo que muestra la definición de JSON de la acción HTTP en la definición de flujo de trabajo subyacente:

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

Contenido con tipo application/x-www-form-urlencoded

Para proporcionar datos form-urlencoded en el cuerpo de una solicitud HTTP, debe especificar que los datos tienen el tipo de contenido application/x-www-form-urlencoded. En la acción o el desencadenador HTTP, agregue el encabezado content-type. Establezca el valor de encabezado en application/x-www-form-urlencoded.

Por ejemplo, imagine que tiene una aplicación lógica que envía una solicitud HTTP POST a un sitio web que admite el tipo application/x-www-form-urlencoded. Este es el aspecto de esta acción:

Flujo de trabajo Estándar

Captura de pantalla que muestra el flujo de trabajo estándar con una solicitud HTTP y el encabezado content-type configurado como application/x-www-form-urlencoded.

Flujo de trabajo de consumo

Captura de pantalla que muestra el flujo de trabajo consumo con el encabezado solicitud HTTP y tipo de contenido establecido en application/x-www-form-urlencoded.

Comportamiento asincrónico de la solicitud-respuesta

Para flujos de trabajo con estado en Azure Logic Apps multiinquilino y de inquilino único, todas las acciones basadas en HTTP siguen el patrón de operación asincrónico estándar como comportamiento predeterminado. Este patrón especifica que, después de que una acción HTTP llame a o envíe una solicitud a un punto de conexión, servicio, sistema o API, el receptor devolverá inmediatamente una respuesta "202 ACCEPTED". Este código confirma que el receptor aceptó la solicitud, pero no ha finalizado el procesamiento. La respuesta puede incluir un encabezado location que especifica el URI y un identificador de actualización que el autor de la llamada puede usar para sondear o comprobar el estado de la solicitud asincrónica hasta que el receptor detiene el procesamiento y devuelve una respuesta de operación correcta "200 OK" u otra respuesta que no sea 202. Sin embargo, el autor de la llamada no tiene que esperar a que la solicitud finalice el procesamiento y puede continuar ejecutando la siguiente acción. Para más información, consulte Diseño de la comunicación entre servicios para microservicios.

Para los flujos de trabajo sin estado en instancias de Azure Logic Apps de inquilino único, las acciones basadas en HTTP no usan el patrón de operación asincrónica. En su lugar, solo se ejecutan sincrónicamente, devuelven la respuesta "202 ACCEPTED" tal y como está, y van al paso siguiente en la ejecución del flujo de trabajo. Si la respuesta incluye un encabezado location, un flujo de trabajo sin estado no sondea al URI especificado para comprobar el estado. Para seguir el patrón de operación asincrónica estándar, use en su lugar un flujo de trabajo con estado.

  • La definición de la notación de objetos JavaScript (JSON) subyacente de la acción HTTP sigue implícitamente el modelo asincrónico de operación.

  • La acción HTTP, pero no desencadenador, tiene una configuración Patrón asincrónico, que está habilitada de manera predeterminada. Esta configuración especifica que el autor de la llamada no espera a que finalice el procesamiento y puede pasar a la siguiente acción, pero continúa comprobando el estado hasta que el procesamiento se detiene. Si está deshabilitada, esta configuración especifica que el autor de la llamada espera a que finalice el procesamiento antes de pasar a la siguiente acción.

    Para encontrar la configuración Patrón asincrónico, siga estos pasos en función de si tiene un flujo de trabajo estándar o de consumo:

    Flujo de trabajo Estándar*

    1. En el diseñador de flujo de trabajo, seleccione la acción HTTP. En el panel de información que se abre, seleccione Configuración.

    2. En Redes, busque la configuración Patrón asincrónico.

    Flujo de trabajo de consumo

    1. En el diseñador de flujos de trabajo, en la barra de título de la acción HTTP, seleccione el botón de puntos suspensivos (...), que abre la configuración de la acción.

    2. Busque la opción de configuración Modelo asincrónico.

Deshabilitación de las operaciones asincrónicas

En ocasiones, es posible que desee deshabilitar el comportamiento asincrónico de la acción HTTP en escenarios específicos, por ejemplo, si prefiere:

Desactivación de la configuración Modelo asincrónico

  1. En el diseñador de flujo de trabajo, seleccione la acción HTTP y, en el panel de información que se abre, seleccione Configuración.

  2. En Redes, busque la configuración Patrón asincrónico. Active la configuración en Desactivado si está habilitado.

Deshabilitación del modelo asincrónico en la definición JSON de la acción

En la definición de JSON subyacente de la acción HTTP, agregar la opción de operación de "DisableAsyncPattern" a la definición de la acción para que la acción siga el modelo sincrónico de operación en su lugar. Para más información, consulte también Ejecución de acciones en un modelo sincrónico de operación.

Evitar los tiempos de espera de HTTP para las tareas de ejecución prolongada

Las solicitudes HTTP tienen un límite de tiempo de espera. Si tiene una acción HTTP de ejecución prolongada que agota el tiempo de espera debido a este límite, tiene estas opciones:

  • Deshabilite el modelo asincrónico de operación de la acción HTTP para que la acción no sondee continuamente ni compruebe el estado de la solicitud. En su lugar, la acción espera a que el receptor responda con el estado y los resultados una vez finalizado el procesamiento de la solicitud.

  • Reemplace la acción HTTP por la acción de webhook HTTP, que espera a que el receptor responda con el estado y los resultados después de que la solicitud finalice el procesamiento.

Configuración del intervalo entre reintentos con el encabezado Retry-After

Para especificar el número de segundos entre reintentos, puede agregar el encabezado Retry-After a la respuesta de acción HTTP. Por ejemplo, si el punto de conexión de destino devuelve el código de estado 429 - Too many requests, puede especificar un intervalo más largo entre reintentos. El encabezado Retry-After también funciona con el código de estado 202 - Accepted.

Este es el mismo ejemplo que muestra la respuesta de acción HTTP que contiene Retry-After:

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

Compatibilidad con la paginación

A veces, el servicio de destino responde devolviendo los resultados una página a la vez. Si la respuesta especifica la página siguiente con la propiedad nextLink o @odata.nextLink, puede activar la configuración paginación en la acción HTTP. Esta configuración hace que la acción HTTP siga automáticamente estos vínculos y obtenga la página siguiente. Sin embargo, si la respuesta especifica la página siguiente con cualquier otra etiqueta, es posible que tenga que agregar un bucle al flujo de trabajo. Haga que este bucle siga esa etiqueta y obtenga manualmente cada página hasta que la etiqueta sea null.

Deshabilitar la comprobación de encabezados de ubicación

Algunos puntos de conexión, servicios, sistemas o API devuelven una respuesta 202 ACCEPTED que no tiene el encabezado location. Para evitar que una acción HTTP compruebe continuamente el estado de la solicitud cuando no existe el encabezado location, puede tener estas opciones:

  • Deshabilite el modelo asincrónico de operación de la acción HTTP para que la acción no sondee continuamente ni compruebe el estado de la solicitud. En su lugar, la acción espera a que el receptor responda con el estado y los resultados una vez finalizado el procesamiento de la solicitud.

  • Reemplace la acción HTTP por la acción de webhook HTTP, que espera a que el receptor responda con el estado y los resultados después de que la solicitud finalice el procesamiento.

Problemas conocidos

Encabezados HTTP omitidos

Si un desencadenador o una acción HTTP incluye estos encabezados, Azure Logic Apps quita estos encabezados del mensaje de solicitud generado sin mostrar ninguna advertencia o error:

  • Encabezados Accept-*, excepto Accept-version
  • Allow
  • Encabezados Content-* excepto Content-Disposition, Content-Encoding y Content-Type, que se respetan cuando se usan las operaciones POST y PUT. Sin embargo, Azure Logic Apps quita estos encabezados cuando se usa la operación GET.
  • El encabezado Cookie, pero Azure Logic Apps respeta cualquier valor que especifique mediante la propiedad Cookie.
  • Expires
  • Host
  • Last-Modified
  • Origin
  • Set-Cookie
  • Transfer-Encoding

Aunque Azure Logic Apps no le impedirá guardar aplicaciones lógicas que usen un desencadenador o una acción HTTP con estos encabezados, Azure Logic Apps omite estos encabezados.

El contenido de la respuesta no coincide con el tipo de contenido esperado

La acción HTTP produce un error BadRequest si la acción HTTP llama a la API de back-end con el encabezado Content-Type establecido en aplicación/json, pero la respuesta del back-end no contiene realmente contenido en formato JSON, lo que produce un error en la validación interna del formato JSON.

Pasos siguientes