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.
En Azure Portal, abra su recurso de aplicación lógica Estándar y el flujo de trabajo en blanco en el diseñador.
-
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.
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:
Para agregar otros parámetros disponibles, abra la lista Parámetros avanzados y seleccione los parámetros que desee.
Agregue cualquier otra acción que quiera ejecutar cuando se active el desencadenador.
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.
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.
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.
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:
Para agregar otros parámetros disponibles, abra la lista Parámetros avanzados y seleccione los parámetros que desee.
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.
Certificado TLS/SSL: agregue la configuración de la aplicación,
WEBSITE_LOAD_ROOT_CERTIFICATES
, y establezca el valor para la huella digital de su certificado TLS/SSL.certificado de cliente o Autenticación abierta de Id. de Entra de Microsoft (OAuth de Id. de Entra de Microsoft) con el tipo de credencial "Certificado": agregue la configuración de la aplicación,
WEBSITE_LOAD_USER_PROFILE
y establezca el valor en1
.
Autenticación con certificados TLS/SSL
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
.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:
Abra el archivo local.settings.json del proyecto de aplicación lógica.
En el objeto JSON
Values
, agregue o actualice la configuraciónWEBSITE_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:
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).
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:
- Edición de la configuración de host y aplicación para aplicaciones lógicas en Azure Logic Apps de inquilino único
- Certificados y App Service aislado
Certificado de cliente o Microsoft Entra ID OAuth con autenticación de tipo de credencial "Certificado"
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
.Para el valor de configuración, especifique
1
."WEBSITE_LOAD_USER_PROFILE": "1"
Por ejemplo, si trabaja en Visual Studio Code, siga estos pasos:
Abra el archivo local.settings.json del proyecto de aplicación lógica.
En el objeto JSON
Values
, agregue o actualice la configuraciónWEBSITE_LOAD_USER_PROFILE
:{ "IsEncrypted": false, "Values": { <...> "AzureWebJobsStorage": "UseDevelopmentStorage=true", "WEBSITE_LOAD_USER_PROFILE": "1", <...> } }
Para más información, revise la siguiente documentación:
- Edición de la configuración de host y aplicación para aplicaciones lógicas en Azure Logic Apps de inquilino único
- Certificados y App Service aislado
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
Flujo de trabajo de consumo
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
Flujo de trabajo de consumo
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*
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.
En Redes, busque la configuración Patrón asincrónico.
Flujo de trabajo de consumo
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.
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:
- Evitar los tiempos de espera de HTTP para las tareas de ejecución prolongada
- Deshabilitar la comprobación de encabezados de ubicación
Desactivación de la configuración Modelo asincrónico
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.
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-*
, exceptoAccept-version
Allow
- Encabezados
Content-*
exceptoContent-Disposition
,Content-Encoding
yContent-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.