Diferencias entre las aplicaciones lógicas de un solo inquilino estándar frente a las aplicaciones lógicas multiinquilino de consumo

Azure Logic Apps es una plataforma basada en la nube para crear y ejecutar flujos de trabajo de aplicaciones lógicas automatizados que integren sus aplicaciones, datos, servicios y sistemas. Esta plataforma permite desarrollar rápidamente soluciones de integración altamente escalables para escenarios intraempresariales y de negocio a negocio (B2B). Al crear un recurso de aplicación lógica, selecciona la opción de hosting de Consumo o la opción de hosting Estándar. Una aplicación lógica de consumo solo puede tener un flujo de trabajo que se ejecute en Azure Logic Apps multiinquilino. Una aplicación lógica estándar puede tener uno o varios flujos de trabajo que se ejecutan en inquilino único Azure Logic Apps o app Service Environment v3 (ASE v3).

Antes de elegir qué recurso de aplicación lógica se va a crear, revise la siguiente guía para obtener información sobre cómo los tipos de flujo de trabajo de la aplicación lógica se comparan entre sí. A continuación, puede elegir mejor qué entorno y flujo de trabajo de aplicación lógica se adaptan mejor a su escenario, requisitos de solución y el destino en el que desea implementar y ejecutar los flujos de trabajo.

Si no está familiarizado con Azure Logic Apps, consulte ¿Qué es Azure Logic Apps? y ¿Qué es un flujo de trabajo de aplicación lógica?.

Tipos y entornos de flujo de trabajo de aplicación lógica

En la tabla siguiente se resumen las diferencias entre un flujo de trabajo de aplicación lógica consumo y flujo de trabajo de aplicación lógica Estándar. También aprenderás cómo difiere el entorno de un solo inquilino del entorno multiinquilino para implementar, hospedar y ejecutar los flujos de trabajo.

Opción de hospedaje	Ventajas	Intercambio y uso de recursos	Modelo de precios y facturación	Administración de límites
Consumo Entorno de host: Azure Logic Apps multiinquilino	- Es la manera más fácil de empezar. - Paga por lo que usas - Totalmente administrado.	Un único recurso de aplicación lógica solo puede tener un flujo de trabajo. Todas las aplicaciones lógicas de varios inquilinos de Microsoft Entra comparten el mismo procesamiento (proceso), almacenamiento, red, etc. Con fines de redundancia, los datos se replican en la región emparejada. Para lograr alta disponibilidad, el almacenamiento con redundancia geográfica (GRS) está habilitado.	Consumo (pago por ejecución)	Azure Logic Apps administra los valores predeterminados para estos límites, pero usted puede cambiar algunos de estos valores, si existe esa opción para un límite específico.
Estándar (Plan de servicio de flujo de trabajo) Entorno de host: Azure Logic Apps de un solo inquilino Nota: Si el escenario requiere contenedores, cree aplicaciones lógicas basadas en un solo inquilino mediante Logic Apps habilitado para Azure Arc. Para más información, consulte ¿Qué es Azure Logic Apps habilitado para Azure Arc?	- Más conectores integrados hospedados en el entorno de ejecución de un solo inquilino para un mayor rendimiento y menores costos a escala - Mayor control y capacidad de ajuste en torno a la configuración de rendimiento y tiempo de ejecución. - Compatibilidad integrada para redes virtuales y puntos de conexión privados. - Permite crear sus propios conectores integrados.	Un solo recurso de aplicación lógica puede tener varios flujos de trabajo con estado y sin estado. Los flujos de trabajo en una sola aplicación lógica y en el inquilino comparten el mismo procesamiento (proceso), almacenamiento, red, etc. Los datos permanecen en la misma región donde se implementan las aplicaciones lógicas.	Estándar, basado en un plan de hospedaje con un plan de tarifa seleccionado. Si ejecuta flujos de trabajo con estado, que usan almacenamiento externo, el entorno en tiempo de ejecución de Azure Logic Apps realiza transacciones de almacenamiento que siguen los precios de Azure Storage.	Puede cambiar los valores predeterminados para muchos límites, en función de las necesidades de su escenario. Importante: Algunos límites tienen máximos fijos. En Visual Studio Code, los cambios que haga en los valores de límite predeterminados en los archivos de configuración de un proyecto de aplicación lógica no aparecerán en la experiencia del diseñador. Para obtener más información, consulte Edición de la configuración de la aplicación y el entorno para aplicaciones lógicas en Azure Logic Apps de un solo inquilino.
Estándar (App Service Environment v3) Entorno de host: App Service Environment v3 (ASEv3): solo planes de Windows	Misma funcionalidades como un solo inquilino más las siguientes ventajas: - Aislamiento completo de las aplicaciones lógicas. - Creación y ejecución de más aplicaciones lógicas que en Azure Logic Apps de un solo inquilino. - Pago solo por el plan de App Service ASE, independientemente del número de aplicaciones lógicas que cree y ejecute. - Posibilidad de habilitar el escalado automático o escalar manualmente con más instancias de máquina virtual o un plan de App Service diferente. - Permite heredar la configuración de red de la instancia de ASEv3 seleccionada. Por ejemplo, cuando se implementan en un ASE interno, los flujos de trabajo pueden acceder a los recursos de una red virtual asociada al ASE y tener puntos de acceso internos. Nota: Si se accede desde fuera de un ASE interno, ejecute historiales de flujos de trabajo en los que el ASE no pueda acceder a las entradas y salidas de acción.	Una sola aplicación lógica puede tener varios flujos de trabajo con estado y sin estado. Los flujos de trabajo en una sola aplicación lógica y en el inquilino comparten el mismo procesamiento (proceso), almacenamiento, red, etc. Los datos permanecen en la misma región donde se implementan las aplicaciones lógicas.	plan de App Service	Puede cambiar los valores predeterminados para muchos límites, en función de las necesidades de su escenario. Importante: Algunos límites tienen máximos fijos. En Visual Studio Code, los cambios que haga en los valores de límite predeterminados en los archivos de configuración de un proyecto de aplicación lógica no aparecerán en la experiencia del diseñador. Para obtener más información, consulte Edición de la configuración de la aplicación y el entorno para aplicaciones lógicas en Azure Logic Apps de un solo inquilino.

Flujo de trabajo y aplicación lógica Estándar

El flujo de trabajo y la aplicación lógicaEstándar están equipados con la tecnología de runtime rediseñada de Azure Logic Apps de un solo inquilino. Este runtime usa el modelo de extensibilidad de Azure Functions y se hospeda como una extensión en el runtime de Azure Functions. Este diseño proporciona portabilidad, flexibilidad y más rendimiento para los flujos de trabajo de aplicaciones lógicas, además de otras funcionalidades y ventajas heredadas de la plataforma Azure Functions y el ecosistema Azure App Service. Por ejemplo, puede crear, implementar y ejecutar aplicaciones lógicas basadas en un solo inquilino y sus flujos de trabajo en Azure App Service Environment v3 (solo planes de Windows).

El aplicación lógica Estándar presenta una estructura de recursos que puede hospedar varios flujos de trabajo, de forma similar a cómo una aplicación de funciones de Azure puede hospedar varias funciones. Con una asignación de uno a varios, los flujos de trabajo de la misma aplicación lógica y el inquilino comparten recursos de proceso y procesamiento, lo que proporciona un mejor rendimiento debido a su proximidad. Esta estructura difiere del recurso de aplicación lógica de Consumo, donde tiene una asignación de uno a uno entre el recurso de aplicación lógica y un flujo de trabajo.

Para obtener más información sobre las mejoras de portabilidad, flexibilidad y rendimiento, continúe con las secciones siguientes. Para obtener más información sobre el runtime de Azure Logic Apps de un solo inquilino o la extensibilidad de Azure Functions, revise la siguiente documentación:

• Azure Logic Apps en ejecución en cualquier ubicación: el runtime en profundidad
• Introducción a Azure Functions
• Enlaces y desencadenadores de Azure Functions

Portabilidad y flexibilidad

Al crear una aplicación lógica y un flujo de trabajo Estándar, puede implementar y ejecutar los flujos de trabajo en otros entornos, como Azure App Service Environment v3 (solo planes de Windows). Si usa Visual Studio Code con la extensión Azure Logic Apps (Estándar), puede desarrollar, compilar y ejecutar localmente los flujos de trabajo en el entorno de desarrollo sin tener que realizar la implementación en Azure. Si el escenario requiere contenedores, puede crear aplicaciones lógicas basadas en un solo inquilino mediante Logic Apps habilitado para Azure Arc. Para más información, consulte ¿Qué es Logic Apps habilitado para Azure Arc?.

Estas funcionalidades proporcionan mejoras importantes y ventajas importantes en comparación con el modelo multiinquilino, lo que requiere que se desarrolle con un recurso en ejecución existente en Azure. El modelo multiinquilino para automatizar Consumo implementación de recursos de aplicación lógica se basa en plantillas de Azure Resource Manager (plantillas de ARM), que combinan y controlan el aprovisionamiento de recursos para las aplicaciones y la infraestructura.

Con el recurso de aplicación lógica Estándar, la implementación es más fácil porque puede separar la implementación de las aplicaciones de la implementación de la infraestructura. Puede empaquetar los flujos de trabajo y el runtime de Azure Logic Apps de un solo inquilino como parte del recurso de aplicación lógica o proyecto. Puede usar pasos genéricos o tareas que compilan, ensamblan y comprimen los recursos de la aplicación lógica en artefactos listos para implementarse. Para implementar la infraestructura, todavía puede usar plantillas de ARM para aprovisionar por separado esos recursos junto con otros procesos y canalizaciones que usa para esos fines.

Para implementar la aplicación, copie los artefactos en el entorno host y, a continuación, inicie las aplicaciones para ejecutar los flujos de trabajo. O bien, integre los artefactos en canalizaciones de implementación mediante las herramientas y los procesos que ya conoce y usa. De este modo, puede realizar la implementación con herramientas propias que elija, independientemente de la pila de tecnología que use para el desarrollo.

Mediante las opciones de compilación e implementación estándar, puede centrarse en el desarrollo de las aplicaciones por separado de la implementación de la infraestructura. Como resultado, obtiene un modelo de proyecto más genérico en el que se pueden aplicar muchas opciones de implementación similares o las mismas que se usan para una aplicación genérica. También se beneficia de una experiencia más coherente al compilar canalizaciones de implementación para las aplicaciones y al ejecutar las pruebas y validaciones necesarias antes de la publicación en producción.

Rendimiento

Con la aplicación lógica Estándar, puede crear y ejecutar varios flujos de trabajo en el mismo recurso de aplicación lógica y el mismo inquilino únicos. Con esta asignación de uno a varios, estos flujos de trabajo comparten recursos, como los de proceso, procesamiento, almacenamiento y red, lo que proporciona un mejor rendimiento debido a su proximidad.

El recurso de aplicación lógica Estándar y el runtime de Azure Logic Apps de un solo inquilino proporcionan otra mejora significativa al hacer que los conectores administrados más populares estén disponibles como operaciones de conector integradas. Por ejemplo, puede usar operaciones de conector integradas para Azure Service Bus, Azure Event Hubs, SQL Server y otros. Mientras tanto, las versiones del conector administrado siguen estando disponibles y siguen funcionando.

Cuando usa las nuevas operaciones de conector integradas, se crean conexiones denominadas conexiones integradas o conexiones de proveedor de servicios. Sus homólogos de conexión administrada se denominan conexiones de API, que se crean y ejecutan por separado como recursos de Azure que también tiene que implementar mediante plantillas de ARM. Las operaciones integradas y sus conexiones se ejecutan localmente en el mismo proceso que ejecuta los flujos de trabajo. Ambos se hospedan en el runtime de Azure Logic Apps de un solo inquilino. Como resultado, las operaciones integradas y sus conexiones proporcionan un mejor rendimiento debido a la proximidad con sus flujos de trabajo. Este diseño también funciona bien con las canalizaciones de implementación porque las conexiones del proveedor de servicios se empaquetan en el mismo artefacto de compilación.

Residencia de datos

Los recursos de aplicación lógica Estándar se hospedan en instancias de Azure Logic Apps de un único inquilino, que no almacenan, procesan ni replican datos fuera de la región donde se implementan estos recursos de aplicación lógica, lo que significa que los datos de los flujos de trabajo permanecen en la misma región donde se crean e implementan sus recursos primarios.

Acceso directo a los recursos de redes virtuales de Azure

Los flujos de trabajo que se ejecutan en una instancia de Azure Logic Apps de un único inquilino pueden acceder directamente a recursos seguros como máquinas virtuales (VM), otros servicios y sistemas que están dentro de una red virtual de Azure.

Azure Logic Apps de un solo inquilino es una instancia dedicada del servicio Azure Logic Apps que utiliza recursos dedicados y se ejecuta por separado de Azure Logic Apps multiinquilino. La ejecución de flujos de trabajo en una instancia dedicada ayuda a reducir el impacto que podrían tener otros inquilinos de Azure en el rendimiento de las aplicaciones, también conocido como el efecto "vecinos ruidosos".

Azure Logic Apps de un solo inquilino también proporciona las ventajas siguientes:

• Sus propias direcciones IP estáticas, que son independientes de las direcciones IP estáticas que comparten las aplicaciones lógicas en Azure Logic Apps multiinquilino. Puede configurar una dirección IP de salida única, pública, estática y predecible para comunicarse con los sistemas de destino. De ese modo, no es necesario configurar aperturas adicionales del firewall en los sistemas de destino.

• Se aumentan los límites de duración de ejecución, retención de almacenamiento, rendimiento, solicitud HTTP y tiempos de espera de respuesta, tamaños de mensaje y solicitudes de conector personalizado. Para más información, consulte el artículo sobre los límites y la configuración de Azure Logic Apps.

Opciones de creación, compilación e implementación

Para crear un recurso de aplicación lógica basada en el entorno que desee, tiene varias opciones, por ejemplo:

Entorno de un solo inquilino

Opción	Recursos y herramientas	Más información
Azure Portal	Aplicación lógica Estándar	Creación de un ejemplo de flujo de trabajo de aplicación lógica del plan Estándar en Azure Logic Apps de un solo inquilino: Azure Portal
Visual Studio Code	Extensión Azure Logic Apps (estándar)	Creación de un ejemplo de flujo de trabajo de aplicación lógica del plan Estándar en Azure Logic Apps de un solo inquilino: Visual Studio Code
Azure CLI	Extensión Logic Apps de la CLI de Azure	az logicapp
Azure Resource Manager	- Local - DevOps	Azure Logic Apps de un solo inquilino
Logic Apps habilitado para Azure Arc	Ejemplo de Logic Apps habilitado para Azure Arc	- ¿Qué es Logic Apps habilitado para Azure Arc? - Creación e implementación de flujos de trabajo de aplicaciones lógicas basadas en un solo inquilino con Logic Apps habilitado para Azure Arc
API REST de Azure	API de REST de Azure App Service* Nota: La API de REST de la aplicación lógica Estándar se incluye con la API de REST de Azure App Service.	Introducción a la referencia de la API de REST de Azure

Entorno multiinquilino

Opción	Recursos y herramientas	Más información
Azure Portal	Aplicación lógica de consumo	Inicio rápido: Creación de un flujo de trabajo de aplicación lógica de consumo de ejemplo en Azure Logic Apps multiinquilino: Azure Portal
Visual Studio Code	Extensión Azure Logic Apps (consumo)	Inicio rápido: Creación de un flujo de trabajo de aplicación lógica de consumo de ejemplo en Azure Logic Apps multiinquilino: Visual Studio Code
CLI de Azure	Extensión Logic Apps de la CLI de Azure	- Inicio rápido: Creación y administración de flujos de trabajo de aplicaciones lógicas de consumo en Azure Logic Apps multiinquilino: CLI de Azure - az logic
Azure Resource Manager	Creación de una aplicación lógica mediante una plantilla de ARM	Inicio rápido: Creación e implementación de flujos de trabajo de aplicaciones lógicas de consumo en Azure Logic Apps multiinquilino: Plantilla de ARM
Azure PowerShell	Módulo Az.LogicApp	Introducción a Azure PowerShell
API REST de Azure	API de REST de Azure Logic Apps	Introducción a la referencia de la API de REST de Azure

Aunque las experiencias de desarrollo difieren en función de si crea recursos de aplicación lógica de consumo o estándar, puede buscar y todas las aplicaciones lógicas implementadas en su suscripción de Azure y acceder a estas.

Por ejemplo, en Azure Portal, la página Aplicaciones lógicas muestra los recursos de aplicación lógica de consumo y Estándar. En Visual Studio Code, las aplicaciones lógicas implementadas aparecen en la suscripción de Azure, pero las aplicaciones lógicas de Consumo aparecen en la ventana de Azure en la extensión Azure Logic Apps (consumo), mientras que las aplicaciones lógicas Estándar aparecen en la sección Recursos.

Flujos de trabajo con y sin estado

Dentro de una aplicación lógica Estándar , puede crear los siguientes tipos de flujo de trabajo:

• Con estado

  Cree un flujo de trabajo con estado cuando necesite mantener o revisar datos de eventos anteriores, o hacer referencia a ellos. Estos flujos de trabajo guardan todas las entradas, salidas y estados de las operaciones en almacenamiento externo. Esta información hace posible revisar los detalles y el historial de la ejecución del flujo de trabajo una vez finalizada cada ejecución. Los flujos de trabajo con estado proporcionan una alta resistencia en caso de interrupciones. Una vez restaurados los servicios y sistemas, puede reconstruir las ejecuciones interrumpidas a partir del estado guardado y volver a ejecutar los flujos de trabajo hasta su finalización. Los flujos de trabajo con estado pueden seguir ejecutándose durante mucho más tiempo que los flujos de trabajo sin estado.

  De forma predeterminada, los flujos de trabajo con estado en Azure Logic Apps multiinquilino y de inquilino único se ejecutan de forma asincrónica. Todas las acciones basadas en HTTP siguen el patrón de operación asincrónica estándar. Después de que una acción HTTP llame a un punto de conexión, servicio, sistema o API, o les envíe una solicitud, 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.

• Sin estado

  Cree un flujo de trabajo sin estado cuando no necesite conservar ni revisar datos de eventos anteriores, ni hacer referencia a ellos, en un almacenamiento externo después de que finaliza cada ejecución para su posterior revisión. Estos flujos de trabajo guardan todas las entradas y las salidas de cada acción y sus estados solo en la memoria, no en un almacenamiento externo. Como consecuencia, los flujos de trabajo sin estado tienen ejecuciones más cortas que normalmente terminan en menos de 5 minutos, un rendimiento más rápido con menores tiempos de respuesta, mayor rendimiento y costos de ejecución reducidos, ya que los detalles y el historial de ejecución del flujo de trabajo no se guardan en almacenamiento externo. Pero si se producen interrupciones, las ejecuciones interrumpidas no se restauran automáticamente, por lo que el autor de la llamada tiene que volver a enviarlas manualmente.

  Un flujo de trabajo sin estado proporciona el mejor rendimiento al administrar datos o contenido que no supera los 64 KB de tamaño total, como es el caso de un archivo. Los tamaños de contenido más grande, como varios datos adjuntos grandes, pueden ralentizar significativamente el rendimiento del flujo de trabajo o incluso provocar que el flujo de trabajo se bloquee debido a excepciones de memoria insuficiente. Si existe la posibilidad de que el flujo de trabajo tenga que controlar tamaños de contenido más grandes, use un flujo de trabajo con estado.

  Nota:

  En flujos de trabajo sin estado, solo puede usar desencadenadores de inserción donde no especifique una programación para ejecutarse para el flujo de trabajo. Estos desencadenadores basados en webhook esperan a que se produzca un evento o que los datos estén disponibles. Por ejemplo, el desencadenador Periodicidad solo está disponible para flujos de trabajo con estado. Para iniciar el flujo de trabajo, seleccione un desencadenador de inserción, como el desencadenador Request, Event Hubs o Service Bus. Para obtener más información sobre los desencadenadores, las acciones y los conectores limitados, no disponibles o no admitidos, vea Capacidades modificadas, limitadas, no disponibles o no admitidas.

  Los flujos de trabajo sin estado se ejecutan solo de manera sincrónica, por lo que no usan el patrón de operación asincrónica estándar que emplean los flujos de trabajo con estado. En su lugar, todas las acciones basadas en HTTP que devuelven una respuesta "202 ACCEPTED" continúan con el siguiente paso 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.

  Para facilitar la depuración, puede habilitar el historial de ejecución de un flujo de trabajo sin estado, lo que tiene algún impacto en el rendimiento, y luego deshabilitar el historial de ejecución cuando haya terminado. Para obtener más información, vea Creación de flujos de trabajo basados en un solo inquilino en Visual Studio Code o Creación de flujos de trabajo basados en un solo inquilino en Azure Portal.

Importante

Debe decidir el tipo de flujo de trabajo, con estado o sin estado, para implementar en el momento de la creación. Los cambios realizados en el tipo de flujo de trabajo después de la creación producen errores en tiempo de ejecución.

Resumen de diferencias entre flujos de trabajo con y sin estado

Con estado	Sin estado
Almacena el historial de ejecución, las entradas y las salidas.	No almacena el historial de ejecución, las entradas o las salidas de manera predeterminada.
Los desencadenadores del conector administrado están disponibles y permitidos.	Los desencadenadores del conector administrado no están disponibles o no están permitidos.
Admiten la fragmentación.	No admiten la fragmentación.
Admiten operaciones asincrónicas.	No admiten operaciones asincrónicas.
Edición de la duración máxima de ejecución predeterminada en la configuración del host.	Son perfectos para flujos de trabajo con una duración máxima inferior a 5 minutos.
Controla mensajes de gran tamaño.	Son perfectos para controlar tamaños de mensaje pequeños (menos de 64 K).

Diferencias de comportamiento anidado entre flujos de trabajo con y sin estado

Puede hacer que se pueda llamar a un flujo de trabajo desde otros flujos de trabajo que existan en la misma aplicación lógica Estándar mediante el Desencadenador de solicitud, el Desencadenador de Webhook HTTP o los desencadenadores de conectores administrados que tienen el tipo ApiConnectionWebhook y pueden recibir solicitudes HTTPS.

La siguiente lista describe los patrones de comportamiento que pueden seguir los flujos de trabajo anidados después de que un flujo de trabajo primario llame a un flujo de trabajo secundario:

• Patrón de sondeo asincrónico

  El flujo de trabajo primario no espera que el flujo de trabajo secundario responda a la llamada inicial. Sin embargo, el elemento primario comprueba continuamente el historial de ejecución del elemento secundario hasta que el elemento secundario se termine de ejecutar. De manera predeterminada, los flujos de trabajo con estado siguen este patrón, que es ideal para flujos de trabajo secundarios de ejecución prolongada que podrían superar los límites de tiempo de espera de las solicitudes.

• Patrón sincrónico ("desencadenar y olvidar")

  Al devolver de inmediato una 202 ACCEPTED respuesta, el flujo de trabajo secundario confirma la llamada del flujo de trabajo primario. Sin embargo, el elemento primario no espera que el elemento secundario devuelva resultados. En su lugar, el elemento primario continúa con la siguiente acción del flujo de trabajo y recibe los resultados cuando el elemento secundario se termina de ejecutar. Los flujos de trabajo con estado secundario que no incluyen una acción de respuesta siempre siguen el patrón sincrónico y proporcionan un historial de ejecución para que lo revise.

  Para habilitar este comportamiento, en la definición de JSON del flujo de trabajo, establezca la propiedad operationOptions en DisableAsyncPattern. Para obtener más información, consulte Tipos de desencadenador y de acción: Opciones de operación.

• Desencadenar y esperar

  Los flujos de trabajo sin estado se ejecutan en la memoria. Así, cuando un flujo de trabajo primario llama a un flujo de trabajo secundario sin estado, el primario espera una respuesta que devuelva los resultados del secundario. Este patrón funciona de forma similar al uso del desencadenador o acción HTTP integrado para llamar a un flujo de trabajo secundario. Los flujos de trabajo sin estado secundarios que no incluyen una acción Respuesta devuelven inmediatamente una respuesta 202 ACCEPTED, pero el primario espera a que el secundario finalice antes de continuar con la siguiente acción. Estos comportamientos solo se aplican a los flujos de trabajo sin estado secundarios.

La siguiente tabla identifica el comportamiento del flujo de trabajo secundario en función de si el primario y el secundario son con estado, sin estado o son tipos de flujo de trabajo mixtos. Lista después de la tabla

Flujo de trabajo primario	Flujo de trabajo secundario	Comportamiento del secundario
Con estado	Con estado	Asincrónico o sincrónico con la configuración "operationOptions": "DisableAsyncPattern"
Con estado	Sin estado	Desencadenar y esperar
Sin estado	Con estado	Sincrónico
Sin estado	Sin estado	Desencadenar y esperar

Otras funcionalidades del modelo de un solo inquilino

El modelo de un solo inquilino y el tipo de recurso Estándar incluyen muchas funcionalidades nuevas y actuales, como las siguientes:

• Creación de aplicaciones lógicas y sus flujos de trabajo a partir de más de 1400 conectores administrados para aplicaciones y servicios de Software como servicio (SaaS) y Plataforma como servicio (PaaS), además de conectores para sistemas locales.

  • Ahora hay más conectores administrados disponibles entre los conectores integrados en los flujos de trabajo Estándar. Las versiones integradas de los conectores se ejecutan de forma nativa en el tiempo de ejecución de Azure Logic Apps de un solo inquilino. Algunos conectores integrados también se conocen informalmente como conectores del proveedor de servicios. Para obtener una lista, consulte Conectores integrados en Consumo y Estándar.

  • Puede crear sus propios conectores integrados personalizados, para su uso con cualquier servicio que necesite, mediante el marco de extensibilidad de Azure Logic Apps de un solo inquilino. De forma similar a los conectores integrados, como Azure Service Bus y SQL Server, los conectores integrados personalizados proporcionan mayor rendimiento, baja latencia y conectividad local porque se ejecutan en el mismo proceso que el entorno de ejecución de un único inquilino. Sin embargo, los conectores integrados personalizados no son similares a los conectores administrados personalizados, que actualmente no se admiten. Para más información, consulte Introducción al conector personalizado y Creación de conectores integrados personalizados para aplicaciones lógicas estándar en Azure Logic Apps de inquilino único.

  • Puede usar las acciones siguientes en operaciones de Liquid y XML sin ninguna cuenta de integración. Estas operaciones incluyen las acciones siguientes:

    • XML: transformar XML, validar XML, Redacción XML con esquema y Análisis XML con esquema

    • Liquid: Transformar de JSON a JSON, Transformar de JSON a TEXT, Transformar de XML a JSON y Transformar de XML a TEXTO

    Nota

    Para usar estas acciones en flujos de trabajo Estándar, debe tener mapas de Liquid, mapas de XML o esquemas de XML. Puede cargar estos artefactos en Azure Portal desde el menú de recursos de la aplicación lógica, en Artifacts, que incluye las secciones Schemas y Maps. O bien, puede agregar estos artefactos a la carpeta Artifacts de su proyecto de Visual Studio Code mediante las carpetas Maps y Schemas respectivas. A continuación, puede usar estos artefactos en varios flujos de trabajo dentro de la misma aplicación lógica.

  • Los flujos de trabajo de aplicación lógica Estándar pueden desencadenarse desde cualquier lugar, ya que Azure Logic Apps genera cadenas de conexión de Firma de acceso compartido (SAS) que estas aplicaciones lógicas pueden usar para enviar solicitudes al punto de conexión en tiempo de ejecución de conexión a la nube. Azure Logic Apps guarda estas cadenas de conexión con otras opciones de configuración de la aplicación para que pueda almacenar fácilmente estos valores en Azure Key Vault al realizar la implementación en Azure.

  • Los flujos de trabajo de aplicaciones lógicas Estándar admiten la habilitación de la identidad administrada asignada por el sistema y varias identidades administradas asignadas por el usuario al mismo tiempo, aunque solo puede seleccionar una identidad que se usará a la vez. Aunque los conectores integrados basados en proveedores de servicios admiten el uso de la identidad asignada por el sistema, la mayoría actualmente no admite la selección de identidades administradas asignadas por el usuario para la autenticación, excepto los conectores HTTP y SQL Server.

    Nota

    De manera predeterminada, la identidad asignada por el sistema ya está habilitada para autenticar las conexiones en tiempo de ejecución. Esta identidad se diferencia de las credenciales de autenticación o de la cadena de conexión que se usan al crear una conexión. Si deshabilita esta identidad, las conexiones no funcionarán en tiempo d ejecución. Para ver este valor, en el menú de la aplicación lógica, en Configuración, seleccione Identidad.

• Ejecute, pruebe y depure las aplicaciones lógicas y sus flujos de trabajo localmente en el entorno de desarrollo de Visual Studio Code.

  Antes de ejecutar y probar la aplicación lógica, puede facilitar la depuración si agrega y usa puntos de interrupción dentro del archivo workflow.json de un flujo de trabajo. Pero los puntos de interrupción solo se admiten en las acciones en este momento, no en los desencadenadores. Para obtener más información, vea Creación de flujos de trabajo basados en un solo inquilino en Visual Studio Code.

• Publique o implemente directamente las aplicaciones lógicas y sus flujos de trabajo desde Visual Studio Code en varios entornos de hospedaje, como Azure y Logic Apps habilitado para Azure Arc.

• Habilite las capacidades de registro de diagnóstico y seguimiento de la aplicación lógica mediante Application Insights cuando lo admitan la configuración de la aplicación lógica y la suscripción de Azure.

• Con el plan prémium de Azure Functions puede acceder a funcionalidades de red, como la conexión e integración de forma privada con redes virtuales de Azure, de manera similar a Azure Functions al crear e implementar las aplicaciones lógicas. Para más información, revise la siguiente documentación:

  • Opciones de redes de Azure Functions

  • Azure Logic Apps en ejecución en cualquier ubicación: posibilidades de conexión de red con Azure Logic Apps

• Regenere las claves de acceso para las conexiones administradas usadas por flujos de trabajo individuales en una aplicación lógica Estándar. Para esta tarea, siga los mismos pasos para la aplicación lógica de Consumo, pero en el nivel de flujo de trabajo, no en el nivel de recursos de la aplicación lógica.

Conectores integrados para aplicaciones lógicas estándar

Los flujos de trabajo Estándar pueden usar muchos de los mismos conectores integrados que los flujos de trabajo de Consumo, pero no todos. Por el contrario, los flujos de trabajo Estándar tienen muchos conectores integrados que no están disponibles en los flujos de trabajo de Consumo.

Por ejemplo, los flujos de trabajo Estándar tienen tanto conectores administrados como integrados para Azure Blob, Azure Cosmos DB, Azure Event Hubs, Azure Service Bus, DB2, FTP, MQ, SFTP, SQL Server y más. Aunque un flujo de trabajo de consumo no tiene estas mismas versiones de conector integradas, están disponibles otros conectores integrados, como Azure API Management y Azure App Services.

En las instancias de Azure Logic Apps de inquilino único, los conectores integrados con atributos específicos se conocen informalmente como proveedores de servicios. Algunos conectores integrados admiten una sola forma de autenticar una conexión con el servicio subyacente. Otros conectores integrados pueden ofrecer una opción, como el uso de una cadena de conexión, Microsoft Entra ID o una identidad administrada. Todos los conectores integrados se ejecutan en el mismo proceso que el tiempo de ejecución rediseñado de Azure Logic Apps. Para más información, consulte la lista de conectores integrados para flujos de trabajo de aplicaciones lógicas estándar.

Importante

Asegúrese de configurar y probar correctamente cualquier desencadenador basado en el proveedor de servicios para confirmar la operación correcta. Un desencadenador basado en el proveedor de servicios con errores puede crear escalado innecesario, lo que puede aumentar drásticamente los costos de facturación. Por ejemplo, un error común es establecer un desencadenador sin conceder permiso o acceso a la aplicación lógica al destino, como una cola de Service Bus, un contenedor de blobs de Azure Storage, etc. Además, asegúrese de supervisar estos desencadenadores en todo momento para que pueda detectar y corregir rápidamente los problemas.

Capacidades modificadas, limitadas, no disponibles o no admitidas

Para el flujo de trabajo de la aplicación lógica Estándar, las siguientes funcionalidades son diferentes, están actualmente limitadas, no están disponibles o no son compatibles:

• Desencadenadores y acciones: los desencadenadores y las acciones integrados se ejecutan de forma nativa en Azure Logic Apps, mientras que los conectores administrados se hospedan y se ejecutan en Azure usando recursos compartidos. En el caso de los flujos de trabajo estándar, algunos desencadenadores y acciones integrados no están disponibles actualmente, como ventana deslizante, Azure App Service y operaciones de Azure App Service. Para iniciar un flujo de trabajo con o sin estado, use el desencadenador integrado, Solicitud, Event Hubs o Service Bus. El desencadenador de recurrencia solo está disponible para los flujos de trabajo con estado, no para flujos de trabajo sin estado. En el diseñador, los desencadenadores integrados y las acciones aparecen con la etiqueta En la aplicación, mientras que los desencadenadores y acciones del conector administrado aparecen con la etiqueta Compartido.

  Los flujos de trabajo sin estado solo pueden usar desencadenadores inserción donde no se especifica una programación para ejecutarse para el flujo de trabajo. Estos desencadenadores basados en webhook esperan a que se produzca un evento o que los datos estén disponibles. Por ejemplo, el desencadenador Periodicidad solo está disponible para flujos de trabajo con estado. Para iniciar el flujo de trabajo, seleccione un desencadenador de inserción, como el desencadenador Request, Event Hubs o Service Bus. Aunque puede habilitar conectores administrados para flujos de trabajo sin estado, la galería de conectores no muestra ningún conector administrado sondeo desencadenadores agregar.

  Nota:

  Para ejecutar localmente en Visual Studio Code, los desencadenadores y las acciones basados en webhook requieren configuración adicional. Para obtener más información, vea Creación de flujos de trabajo basados en un solo inquilino en Visual Studio Code.

  • Estos desencadenadores y acciones han cambiado o están limitados, no se admiten o no están disponibles:

    • La acción integrada, Azure Functions: Elija una función de Azure ahora está operaciones de Azure Functions: Llamada a una función de Azure. Esta acción solo funciona con las funciones que se crean a partir de la plantilla Desencadenador HTTP.

      En Azure Portal, puede seleccionar una función de desencadenador HTTP a la que tenga acceso mediante la creación de una conexión por medio de la experiencia del usuario. Si inspecciona la definición JSON de la acción de la función en la vista de código o el archivo workflow.json mediante Visual Studio Code, la acción se refiere a la función mediante una referencia connectionName. Esta versión abstrae la información de la función como una conexión que puede encontrar en el archivo connections.json del proyecto de aplicación lógica, que está disponible después de crear una conexión en Visual Studio Code.

      Nota

      En la versión de un solo inquilino, la acción de la función solo admite la autenticación de cadena de consulta. Azure Logic Apps obtiene la clave predeterminada de la función al realizar la conexión, la almacena en la configuración de la aplicación y la usa para la autenticación cuando se llama a la función.

      Como en el modelo multiinquilino, si renueva esta clave, por ejemplo, a través de la experiencia de Azure Functions en el portal, la acción de función ya no funciona debido a la clave no válida. Para corregir este problema, debe volver a crear la conexión a la función a la que quiere llamar o actualizar la configuración de la aplicación con la nueva clave.

    • El nombre de la acción integrada, Código en línea, se ha cambiado por el Operaciones de código en línea; ya no requiere una cuenta de integración y se han actualizado los límites.

    • La acción integrada Azure Logic Apps: Elegir un flujo de trabajo de aplicación lógica es ahora Operaciones de flujo de trabajo: Invocar un flujo de trabajo en esta aplicación de flujo de trabajo.

    • Actualmente, no se admiten conectores administrados personalizados. Sin embargo, puede crear operaciones integradas personalizadas si usa Visual Studio Code. Para obtener más información, revise Creación de flujos de trabajo basados en un solo inquilino mediante Visual Studio Code.

    • Un flujo de trabajo Estándar solo puede tener un desencadenador y no admite varios desencadenadores.

• Autenticación

  • Algunos desencadenadores basados en solicitudes que controlan las llamadas entrantes, como el desencadenador Solicitud, actualmente no admiten la autenticación Microsoft Entra ID OAuth (Microsoft Entra ID Open Authentication), mientras que otros, como el desencadenador Webhook HTTP, tienen esta compatibilidad.

  • Algunos conectores integrados basados en proveedores de servicios actualmente no admiten la selección de la identidad administrada asignada por el usuario para la autenticación. Sin embargo, tanto la compatibilidad con identidades administradas asignadas por el sistema como las asignadas por el usuario están disponibles en general. De forma predeterminada, la identidad administrada asignada por el sistema se habilita automáticamente.

• Depuración de puntos de interrupción en Visual Studio Code: aunque puede agregar y usar puntos de interrupción dentro del archivo workflow.json de un flujo de trabajo, los puntos de interrupción solo se admiten en las acciones en este momento, no en los desencadenadores. Para obtener más información, vea Creación de flujos de trabajo basados en un solo inquilino en Visual Studio Code.

• Historial de desencadenadores e historial de ejecución: para un flujo de trabajo de aplicación lógica Estándar, el historial de desencadenadores y el historial de ejecución en Azure Portal aparecen en el nivel del flujo de trabajo, no en el nivel de recurso de la aplicación lógica. Para obtener más información, consulte Creación de flujos de trabajo basados en un solo inquilino mediante Azure Portal.

• Plantillas de Terraform: no puede usar estas plantillas con un recurso de aplicación lógica Estándar para una implementación de infraestructura completa. Para más información, vea ¿Qué es Terraform en Azure?.

Permisos estrictos de tráfico de red y firewall

Si el entorno tiene requisitos de red estrictos o firewalls que limitan el tráfico, debe permitir el acceso de las conexiones del desencadenador o la acción en los flujos de trabajo. Opcionalmente, puede permitir el tráfico desde etiquetas de servicio y usar el mismo nivel de restricciones o directivas que Azure App Service. También debe buscar y usar los nombres de dominio completos (FQDN) de las conexiones. Para más información, revise las secciones correspondientes de la siguiente documentación:

• Permisos de firewall para aplicaciones lógicas de inquilino único: Azure Portal
• Permisos de firewall para aplicaciones lógicas de inquilino único: Visual Studio Code

Pasos siguientes

• Creación de flujos de trabajo basados en un solo inquilino en Azure Portal
• Creación de flujos de trabajo basados en un solo inquilino en Visual Studio Code

También nos gustaría conocer sus experiencias con Azure Logic Apps de un solo inquilino.

• En caso de errores o problemas, dirija los problemas a GitHub.
• Si tiene preguntas, solicitudes, ideas y comentarios, use este formulario de comentarios.