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 desea 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. Cuando se produce un evento específico en ese punto de conexión, como que tu sitio web se caiga, dicho evento desencadena el flujo de trabajo y ejecuta las acciones correspondientes.

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:

• Para comprobar o sondear un punto de conexión en una programación periódica, agregue el desencadenador integrado denominado HTTP como primer paso en el flujo de trabajo. 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 disparador transfiere cualquier contenido de la respuesta del punto final a las acciones en su proceso de trabajo.

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

Prerrequisitos

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

• Recurso de la aplicación lógica que contiene el flujo de trabajo desde el cual desea llamar al punto de conexión externo.

  Para iniciar su flujo de trabajo con el desencadenador HTTP, debe tener un flujo de trabajo en blanco. Para usar la acción HTTP , el flujo de trabajo puede empezar con un desencadenador que mejor se adapte a su escenario. En los flujos de trabajo de ejemplo de este artículo se usa el desencadenador HTTP .

  Si no tiene un recurso de aplicación lógica y un flujo de trabajo, créelos ahora siguiendo los pasos de la aplicación lógica que desee:

  • Creación de un flujo de trabajo de aplicaciones lógicas de consumo de ejemplo
  • Creación de un flujo de trabajo de aplicación lógica estándar de ejemplo

Referencia técnica del conector

Para obtener información técnica sobre los parámetros de desencadenador y acción, consulte las secciones siguientes en la guía de referencia del esquema:

• Parámetros del desencadenador HTTP
• Parámetros de acción HTTP

Adición de 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.

Agregar una acción HTTP

Esta acción integrada envía una llamada HTTPS o HTTP a la dirección URL especificada para un punto de conexión y devuelve con una respuesta.

Salidas de los desencadenadores y las acciones

Un desencadenador o una acción HTTP genera la siguiente información:

Seguridad de direcciones URL para llamadas salientes

Para obtener información sobre el cifrado, la seguridad y la autorización de las llamadas salientes desde el flujo de trabajo, como Seguridad de la capa de transporte (TLS), certificados autofirmados o Autenticación abierta de Microsoft Entra ID, consulte Acceso para llamadas salientes a otros servicios y sistemas.

Autenticación para el entorno de un solo inquilino

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.

• Certificado TLS: agrege la configuración de la aplicación WEBSITE_LOAD_ROOT_CERTIFICATES y establezca el valor en la huella digital de su certificado TLS.

• Certificado de cliente o Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) con el tipo de credencial ‘Certificado’: Agregue la configuración de la aplicación , y establezca el valor en WEBSITE_LOAD_USER_PROFILE.

Autenticación de certificados TLS

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 denominada WEBSITE_LOAD_ROOT_CERTIFICATES. Para conocer los pasos específicos, consulte Administración de la configuración de la aplicación: local.settings.json.

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

   "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS-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 Values objeto JSON, agregue o actualice la WEBSITE_LOAD_ROOT_CERTIFICATES configuración:

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

Para obtener más información, consulte Administrar la configuración de la aplicación: local.settings.json.

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 denominada WEBSITE_LOAD_USER_PROFILE. Para conocer los pasos específicos, consulte Administración de la configuración de la aplicación: local.settings.json

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 Values objeto JSON, agregue o actualice la WEBSITE_LOAD_USER_PROFILE configuración:

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

Si está trabajando en el portal de Azure, abra su aplicación lógica. En Configuración en el menú de la barra lateral, seleccione Variables de entorno. En Configuración de la aplicación, agregue o edite la configuración.

Contenido con el tipo multipart/form-data

Para controlar el contenido que tiene multipart/form-data tipo en las solicitudes HTTP, puede agregar un objeto JSON que incluya los $content-type atributos y $multipart en el cuerpo de la solicitud HTTP mediante 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 multipart/form-data tipo. En el ejemplo siguiente se muestra cómo puede aparecer esta acción:

Este es el mismo ejemplo que muestra la definición 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 el 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 el desencadenador o la acción de HTTP, agregue el encabezado content-type. Establezca el valor del encabezado en application/x-www-form-urlencoded.

Por ejemplo, supongamos que tiene una aplicación lógica que envía una solicitud HTTP POST a un sitio web, que admite el application/x-www-form-urlencoded tipo . Así es como podría verse esta acción:

Comportamiento asincrónico de solicitud-respuesta

En el caso de los 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 devuelve inmediatamente una respuesta ACCEPTED 202 . Este código confirma que el receptor aceptó la solicitud, pero no ha terminado de procesarse. La respuesta puede incluir un location encabezado 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 deje de procesarse y devuelva una respuesta 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 Mensajería sincrónica frente a asincrónica.

En el caso de flujos de trabajo sin estado en Azure Logic Apps de un solo inquilino, 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 as-isy continúan con el paso siguiente en la ejecución del flujo de trabajo. Si la respuesta incluye un location encabezado, un flujo de trabajo sin estado no sondea el 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 JSON subyacente de la acción HTTP sigue implícitamente el patrón de operación asincrónica.

• La acción HTTP, pero no desencadenador, tiene una configuración de patrón asincrónico , que está habilitada de forma 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 se detenga el procesamiento. 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 buscar la configuración de patrón asincrónico :

  1. En el diseñador de flujo de trabajo, seleccione la acción HTTP .
  2. En el panel de información que se abre, seleccione Configuración.
  3. En Redes, busque la configuración de patrón asincrónico .

Deshabilitar operaciones asincrónicas

A veces, es posible que desee deshabilitar el comportamiento asincrónico de la acción HTTP en escenarios específicos, por ejemplo, cuando desee:

• Evitar los tiempos de espera de HTTP para las tareas de ejecución prolongada
• Deshabilitar la comprobación de encabezados de ubicación

Desactivar la configuración de patrones asincrónicos

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 de 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 JSON subyacente de la acción HTTP, agregue la DisableAsyncPattern opción de operación a la definición de la acción para que la acción siga el patrón de operación sincrónico en su lugar. Para obtener más información, vea también ejecutar acciones en un patrón de operación sincrónica.

Evitar tiempos de espera HTTP para 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 patrón de operación asincrónica 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 después de que la solicitud termine de procesarse.

• 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 termine de procesarse.

Configura el intervalo entre intentos de reintento utilizando el encabezado Retry-After

Para especificar el número de segundos entre reintentos, puede agregar el Retry-After encabezado a la respuesta de la acción HTTP. Por ejemplo, si el punto de conexión de destino devuelve el 429 - Too many requests código de estado, puede especificar un intervalo más largo entre reintentos. El Retry-After encabezado 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 el ajuste de 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 comprobación de encabezados de ubicación

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

• Deshabilite el patrón de operación asincrónica 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 después de que la solicitud termine de procesarse.

• 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 termine de procesarse.

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 GET operación.
• 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 impide guardar aplicaciones lógicas que usan un desencadenador HTTP o una acción 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 establecido en Content-Type, 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.

Contenido relacionado

• Conectores administrados para Azure Logic Apps
• Conectores integrados para Azure Logic Apps