¿Por qué migrar de BizTalk Server a Azure Logic Apps?

En esta guía se proporciona información general sobre las razones y ventajas, las funcionalidades y otra información que le ayudarán a empezar a migrar de BizTalk Server a Azure Logic Apps. Siguiendo esta guía, encontrará más guías que abarcan estrategias de migración, consideraciones de planeación y procedimientos recomendados para ayudarle a ofrecer resultados correctos.

Razones y ventajas

Al migrar las cargas de trabajo de integración a Azure Logic Apps, puede aprovechar las siguientes ventajas principales:

¿Cómo funciona BizTalk Server?

BizTalk Server usa una arquitectura de publicación-suscripción del motor de mensajería que utiliza la base de datos de cuadro de mensajes. El cuadro de mensajes es responsable de almacenar mensajes, propiedades de mensaje, suscripciones, estados de orquestación, datos de seguimiento y otra información.

Cuando BizTalk Server recibe un mensaje, el servidor lo pasa y lo procesa a través de una canalización. Este paso normaliza y publica el mensaje en el cuadro de mensajes. BizTalk Server evalúa las suscripciones y determina el destinatario previsto para el mensaje, en función de las propiedades del contexto del mensaje. Por último, BizTalk Server redirige el mensaje al destinatario previsto, en función de las suscripciones o filtros. Este destinatario es una orquestación o un puerto de envío, que es un destino al que BizTalk Server envía mensajes o un origen del que BizTalk Server puede recibir mensajes. BizTalk Server transmite los mensajes a través de un puerto de envío pasándolos por una canalización de envío. La canalización de envío serializa los mensajes con el formato nativo que el receptor espera antes de enviarlos a través de un adaptador.

La base de datos de cuadro de mensajes tiene los siguientes componentes:

• Agente de mensajería

  BizTalk Server interactúa con el cuadro de mensajes por medio de este agente, que proporciona interfaces para publicar mensajes, suscribirse a mensajes, recuperar mensajes, etc.

• Una o varias bases de datos de SQL Server

  Estas bases de datos proporcionan el almacén de persistencia para mensajes, partes de mensaje, propiedades de mensaje, suscripciones, estado de orquestación, datos de seguimiento, colas de host para el enrutamiento, etc.

En la imagen siguiente se muestra cómo funciona el motor de mensajería de BizTalk Server:

Cuando un puerto de recepción recibe un mensaje, el cuadro de mensajes almacena ese mensaje para procesarlo por medio de procesos empresariales o redirigirlo a cualquier puerto de envío que tenga suscripciones a mensajes específicos.

Para obtener más información, consulte Arquitectura de publicación-suscripción más adelante en esta guía.

Azure Logic Apps: Sucesor de BizTalk

Azure Logic Apps es la plataforma de integración y orquestación de flujos de trabajo de nivel empresarial de Microsoft. Esta plataforma está diseñada para procesos deterministas, de larga duración y con estado en entornos híbridos y en la nube. El diferenciador clave combina flujos de trabajo visuales de poco código con funcionalidades de plataforma de Azure de primera clase: seguridad, identidad, redes, supervisión y gobernanza. Azure Logic Apps admite varios modelos de implementación (consumo, estándar, híbrido), que permiten a los clientes ejecutar flujos de trabajo totalmente administrados en Azure o cerca de los sistemas locales al tiempo que mantienen la confiabilidad, la administración de estado y la ejecución auditable. Esta flexibilidad hace que la plataforma sea la red troncal natural para modernizar los patrimonios de BizTalk Server, la orquestación de integraciones B2B/EDI y la conexión de SaaS, ERP, CRM y sistemas heredados en los que la durabilidad y la observabilidad no son negociables.

Sin embargo, Azure Logic Apps no es únicamente "código bajo". Los clientes usan rutinariamente la extensibilidad de código pro junto con flujos de trabajo visuales: C#, JavaScript y PowerShell insertados, código personalizado a través de funciones locales que se ejecutan en Azure Logic Apps y conectores personalizados. Esta extensibilidad permite a los equipos insertar lógica de negocios compleja, transformaciones, control de protocolos y validación directamente dentro de las orquestaciones sin interrumpir el modelo de flujo de trabajo. En escenarios reales, como el procesamiento de notificaciones, la incorporación, las canalizaciones de cumplimiento, las integraciones de sistemas centrales y sanitarios, los clientes dependen de Azure Logic Apps para actuar como la capa de ejecución controlada que combina la orquestación determinista con código personalizado y, cada vez más, decisiones asistidas por IA, al tiempo que se conserva la gobernanza, la seguridad y la confianza operativa a escala.

En Azure Logic Apps, puede crear procesos empresariales ejecutables y aplicaciones como flujos de trabajo de Logic Apps mediante una forma de programación mediante "bloques de construcción" con un diseñador visual y operaciones preconstruidas a partir de cientos de conectores, lo que requiere un mínimo de código. Un flujo de trabajo de aplicación lógica comienza con una operación de desencadenador seguida de una o varias operaciones de acción, donde cada operación funciona como un paso lógico en el proceso de implementación del flujo de trabajo. El flujo de trabajo puede usar acciones para llamar a software, servicios y sistemas externos. Algunas acciones realizan tareas de programación, como condiciones, bucles, operaciones de datos, administración de variables, etc.

Azure Logic Apps ofrece, por ejemplo, las siguientes ventajas:

• Orientado al diseñador (declarativo)

  Diseñe procesos complejos usando herramientas de diseño fáciles de entender para implementar patrones y flujos de trabajo que, de otro modo, podrían ser difíciles de implementar en el código.

• Desarrollo de código primero

  Cree soluciones completas basadas en código con Visual Studio Code, lo que le permite reutilizar el código heredado de .NET Framework existente e incorporar las versiones más recientes de .NET.

• Flexible y escalable

  Azure Logic Apps es un servicio informático basado en la nube, sin servidor, altamente escalable que se escala y se adapta automáticamente para satisfacer las necesidades empresariales en constante evolución.

Experiencias para desarrolladores

En esta sección se resume cómo cambian las herramientas de desarrollo al migrar desde BizTalk Server (centrado en Visual Studio) a Azure Logic Apps (centrado en Visual Studio Code) y por qué muchos equipos encuentran el modelo de flujo de trabajo de Azure Logic Apps más rápido para compilar y mantener más fácil.

• Herramientas y modelo de creación

  Con BizTalk, el trabajo diario de integración se realiza en Visual Studio y se distribuye entre varios tipos de artefactos, como esquemas, mapas, orquestaciones y canalizaciones, además de paquetes de implementación (MSI/enlaces) en entornos de servidor compartidos.

  Con Azure Logic Apps, muchos equipos se mueven a Visual Studio Code para editar definiciones de flujo de trabajo y archivos relacionados mediante un enfoque más sencillo de "flujo de trabajo + conectores" que reduce la complejidad de la solución y fomenta cambios más pequeños y incrementales. En la práctica, Visual Studio Code suele ser más rápido instalar, actualizar y estandarizar entre equipos que mantener la alineación de las versiones de BizTalk y Visual Studio. Las definiciones de flujo de trabajo basadas en texto tienden a mejorar las operaciones de diff y merge en Git, las revisiones de código y la reutilización en comparación con las soluciones de BizTalk grandes y compiladas.

• Lo que hace que el traslado a Azure Logic Apps sea una mejora

  Azure Logic Apps empareja el desarrollo basado en Visual Studio Code con diagnósticos nativos de la nube. Puede validar y actualizar rápidamente los flujos de trabajo y, a continuación, usar el historial de ejecución del flujo de trabajo para ver las entradas y salidas de la operación sin depender de consolas del lado servidor y solucionar problemas de instancias de host. En los proyectos de migración, esta ventaja normalmente acelera la iteración (editar, implementar, actualizar, validar), mejora la colaboración porque los flujos de trabajo son más fáciles de revisar y actualizar, y admite la separación del entorno más limpia mediante la externalización de conexiones y configuraciones, lo que reduce el desfase de configuración "funciona en ese servidor".

Connectors

Los conectores proporcionan operaciones que puede usar como pasos en los flujos de trabajo. Al compilar flujos de trabajo con Azure Logic Apps, los conectores le ayudan a trabajar con datos, eventos y recursos en aplicaciones, servicios, sistemas, protocolos y plataformas a menudo sin escribir código. Puede crear soluciones de integración para servicios y sistemas de Microsoft y asociados, incluidos BizTalk Server, Salesforce, Office 365, IBM Mainframes, bases de datos SQL y muchos servicios de Azure, como Azure Functions, Azure Storage y Azure Service Bus, además de aplicaciones locales, SaaS y API. Si no existe ningún conector precompilado para el recurso al que desea acceder, puede usar la operación HTTP genérica para comunicarse con el servicio o puede crear un conector personalizado.

Técnicamente, un conector es un proxy o contenedor en torno a una API que usa el servicio o sistema subyacentes para comunicarse con Azure Logic Apps. Los conectores proporcionan conectividad en Azure Logic Apps y ofrecen una abstracción junto con API que suelen ser propiedad del sistema SaaS subyacente. Para simplificar la llamada a estas API, los conectores usan metadatos para describir el contrato de mensajería, de modo que los desarrolladores sepan qué datos se esperan en la solicitud y en la respuesta. A continuación, el conector expone las operaciones como desencadenadores o acciones con propiedades configurables. Algunos desencadenadores y acciones requieren que primero cree y configure una conexión al servicio o sistema subyacente y autentique el acceso a una cuenta de usuario.

La mayoría de los conectores de Azure Logic Apps están integrados o administrados. Algunos conectores están disponibles en ambas versiones y la disponibilidad depende de si se crea un flujo de trabajo de aplicación lógica estándar o de consumo. En escenarios de migración de BizTalk Server, se recomiendan flujos de trabajo de aplicaciones lógicas estándar porque las funcionalidades de migración de BizTalk están disponibles en el nivel Estándar.

Para muchas migraciones de BizTalk, los conectores que seleccione se basan en requisitos de integración comunes, como la conectividad local, la transferencia de archivos como SFTP, sistemas de mensajería y sistemas de línea de negocio.

• Los conectores integrados se ejecutan de forma nativa en el entorno de ejecución de Azure Logic Apps. En comparación con los conectores administrados, los conectores integrados suelen reducir la latencia y evitar llamadas por conexión al servicio de conector administrado, en función del conector y el escenario.

• Microsoft se encarga de implementar, hospedar y administrar los conectores administrados en Azure. Estos conectores proporcionan desencadenadores y acciones para los servicios en la nube, los sistemas locales o ambos.

En la galería de conectores del diseñador, los conectores integrados aparecen en la etiqueta Integrada , mientras que los conectores administrados aparecen en la etiqueta Compartido . En el caso de los flujos de trabajo de aplicaciones lógicas de consumo, los conectores administrados siguen el modelo de precios Estándar o Enterprise.

• Los conectores personalizados permiten encapsular las API REST, normalmente mediante una definición de OpenAPI o api SOAP mediante un WSDL, cuando no existe ningún conector precompilado. Si no existen conectores creados previamente para las API que desea usar, puede crear un conector personalizado y acceder a ese conector desde flujos de trabajo de aplicación lógica con los permisos adecuados.

En el caso de las API REST, normalmente se describe la API mediante una definición de OpenAPI. En el caso de las API SOAP, se usa un WSDL. El conector personalizado crea un contrato entre Azure Logic Apps y la API que ayuda a componer mensajes de solicitud y recibir respuestas tipificadas que puede usar en acciones posteriores. Los conectores personalizados pueden hacer referencia a API públicas o API privadas, incluidas las API de la red local.

Al implementar un conector personalizado, se proporciona una interfaz común para enviar solicitudes y recibir respuestas tipificadas, lo que simplifica la experiencia de desarrollo.

Para obtener más información, consulte:

• Conectores integrados en Azure Logic Apps
• Conectores administrados en Azure Logic Apps
• Lista de todos los conectores de Logic Apps
• Conectores y API personalizados

Modelado de datos y artefactos

Al migrar integraciones a Azure Logic Apps, normalmente necesita lo siguiente:

• Modelado de datos en flujo de trabajo, por ejemplo, análisis sintáctico, composición y asignación.

• Una estrategia clara para almacenar e implementar artefactos reutilizables, como esquemas, mapas, plantillas y ensamblados.

En las secciones siguientes se resumen las principales opciones integradas para las transformaciones y los lugares comunes para almacenar los artefactos auxiliares para flujos de trabajo estándar y escenarios B2B compartidos.

• Modelado de datos en flujos de trabajo: operaciones de datos, expresiones y plantillas Liquid

  Para la mayoría de las transformaciones JSON en los flujos de trabajo de la aplicación lógica, use operaciones de datos integradas, como las acciones de Compose y Parse JSON, junto con expresiones y acciones de control de flujo de trabajo, como condiciones y bucles, para dar forma a los datos. Para escenarios de mapeo más complejos, especialmente cuando quiera una plantilla reutilizable para transformaciones de JSON a JSON, de JSON a texto, de XML a JSON o de XML a texto, puede usar una plantilla Liquid. Las plantillas Liquid describen los mapeos mediante el lenguaje de plantillas Liquid de código abierto. Puede versionar e implementar plantillas como artefactos junto a su flujo de trabajo.

• Operaciones XML basadas en esquemas: Analizar XML y Compose XML

  Para escenarios de creación y validación XML en flujos de trabajo de aplicaciones lógicas, puede usar operaciones XML integradas, como Compose XML con esquema y Analizar XML con esquema. Estas acciones son las más útiles cuando se necesita una gestión de XML fuertemente tipada (basada en XSD), en lugar de gestionar la carga como texto sin formato. Por ejemplo, necesita nombres de elementos coherentes, tipos de datos y estructura en varios flujos de trabajo.

• Almacenamiento de artefactos en aplicaciones lógicas estándar

  En el caso de los flujos de trabajo de aplicación lógica estándar, puede almacenar artefactos de integración en el propio recurso de la aplicación lógica. En Azure Portal, puede cargar mapas y esquemas directamente en el recurso de aplicación lógica estándar. Si trabaja en Visual Studio Code, puede agregar esquemas, mapas y plantillas a las carpetas adecuadas bajo el directorio Artefactos del proyecto y desplegarlos junto con el flujo de trabajo. Esta funcionalidad facilita mantener artefactos en el control de código fuente.

  Los flujos de trabajo estándar admiten llamar a ensamblados compilados personalizados, como los ensamblados de .NET Framework, en mapas XSLT. Esta compatibilidad le ayuda con escenarios de migración de BizTalk que dependen de la lógica de transformación existente.

• Almacenar artefactos B2B compartidos en una cuenta de integración

  Una cuenta de integración es un recurso de Azure que proporciona acceso centralizado a artefactos B2B e integración reutilizables que pueden compartir varios flujos de trabajo. Los artefactos pueden incluir socios comerciales, contratos, esquemas XSD, mapas XSLT, mapas basados en plantillas liquid, certificados, configuraciones por lotes y ensamblados de .NET Framework.

  Normalmente, se usan cuentas de integración en escenarios B2B/EDI en los que desea un almacén de artefactos compartido y regulado independiente de cualquier flujo de trabajo único. En el caso de los flujos de trabajo estándar, puede evitar con frecuencia una cuenta de integración empaquetando esquemas, mapas y plantillas con el proyecto de aplicación lógica estándar y al implementarlos juntos. Los flujos de trabajo estándar también admiten la llamada a ensamblados de .NET Framework desde transformaciones XSLT, lo que puede ayudarle a migrar las bibliotecas auxiliares y mapas de BizTalk existentes. Si prefiere un enfoque basado en proyectos, agregue esquemas, asignaciones y ensamblados en Visual Studio Code y, a continuación, implemente en Azure.

• Esquemas EDI: artefactos XSD especializados para integraciones B2B

  Los esquemas de documento EDI definen la estructura o el cuerpo de un tipo de documento de transacción EDI. En los proyectos de migración de BizTalk, los equipos suelen empezar reutilizando las mismas definiciones XSD y validando iterativamente las variaciones específicas del socio comercial. En el caso de los flujos de trabajo de Azure Logic Apps, muchos esquemas EDI de BizTalk en el repositorio de GitHub de integración de Microsoft están disponibles públicamente para su uso. En función del enfoque de implementación, puede almacenar estos esquemas junto con una aplicación lógica estándar como artefactos de proyecto o centralmente en una cuenta de integración para reutilizarlos en varios flujos de trabajo.

Connectivity

El modelo de conectividad de Azure Logic Apps difiere de BizTalk Server, parcialmente debido a la evolución de la economía de API. Puesto que cada vez más organizaciones exponen acceso a los sistemas y datos subyacentes, es necesario un enfoque independiente de la plataforma. REST es ahora el enfoque arquitectónico dominante para diseñar servicios web modernos.

En Azure Logic Apps, REST es el enfoque predeterminado para conectar sistemas. Puesto que Microsoft y otros proveedores de software exponen servicios RESTful con sus sistemas y datos, Azure Logic Apps puede exponer y consumir este tipo de información. La especificación OpenAPI hace posible que tanto personas como PC comprendan la interacción entre un cliente y un servidor por medio de metadatos. De esta comprensión se derivan las cargas de solicitud y respuesta, es decir, puede usar contenido dinámico para rellenar las entradas de una acción de flujo de trabajo y usar las salidas de la respuesta en acciones posteriores.

Los esquemas de autenticación varían para cada conector, en función del proveedor de software que implementa el servicio subyacente al que llama el conector. Por lo general, estos esquemas incluyen los siguientes tipos:

• Básico
• Certificado de cliente
• Active Directory OAuth
• Sin formato
• Identidad administrada

Microsoft proporciona capas de protección sólidas mediante el cifrado de datos durante el tránsito y en reposo. Cada vez que el tráfico de los clientes de Azure se mueve entre los centros de datos, fuera de los límites físicos que no están controlados por Microsoft o en nombre de Microsoft, un método de cifrado de capa de vínculo de datos que usa los estándares de seguridad IEEE 802.1AE MAC (MACsec) se aplica de punto a punto en el hardware de red subyacente.

Microsoft le da la opción de usar el protocolo TLS (Seguridad de la capa de transporte) para proteger los datos que viajan entre los servicios en la nube y los clientes. Los centros de datos de Microsoft negocian una conexión TLS con sistemas cliente que se conectan a servicios de Azure. TLS proporciona una autenticación sólida, privacidad e integridad de los mensajes (que permite la detección de manipulación, interceptación y falsificación de mensajes), interoperabilidad, flexibilidad de los algoritmos y facilidad de implementación y uso.

Aunque esta sección se centra en la conectividad RESTful a través de conectores, puede implementar la conectividad del servicio web SOAP a través de la experiencia del conector personalizado o mediante la experiencia de API Management, que proporciona excelentes funcionalidades SOAP. Para más información, consulte Incremento del valor empresarial mediante la integración de activos heredados SOAP con Azure Logic Apps y Azure API Management.

Durabilidad de los mensajes

Azure Logic Apps proporciona durabilidad de los mensajes de las siguientes formas:

• Los flujos de trabajo con estado de las aplicaciones lógicas estándar conservan el estado del flujo de trabajo y las entradas y salidas de operación en el almacenamiento mediante puntos de control. Esta persistencia proporciona una ejecución duradera y un historial de ejecución de flujo de trabajo enriquecido para que pueda revisar las entradas y salidas de operación detalladas.

• Puede volver a enviar o volver a ejecutar una ejecución de flujo de trabajo en Azure Portal o mediante API.

  Si se reenvía, el flujo de trabajo podría procesar el mismo mensaje nuevamente, por lo que asegúrese de que sus diseños asuman un procesamiento al menos una vez e implementen la idempotencia. Por ejemplo, use claves de desduplicación, upserts o efectos exactamente una vez en el destino.

  En función del tipo de flujo de trabajo y la configuración, también puede volver a enviar desde un punto específico de la ejecución. Sin embargo, asegúrese de que los sistemas posteriores puedan controlar de forma segura los reintentos y los posibles duplicados.

• En Azure Service Bus, un receptor puede procesar un mensaje usando la mensajería con bloqueo-inspección y luego resolver ese mensaje explícitamente. Por ejemplo, el receptor puede completar el mensaje y, a continuación, quitarlo de la cola, o el receptor puede abandonar el mensaje y hacer que esté disponible para volver a entregarlo.

  Para usar esta funcionalidad en Azure Logic Apps, use el conector de Azure Service Bus. El modo peek-lock mejora la confiabilidad y admite patrones de reintento o reentrega. Sin embargo, el procesamiento de extremo a extremo, exactamente una vez, normalmente sigue requiriendo idempotencia en los sistemas descendentes.

• Con RabbitMQ, normalmente puede lograr durabilidad mediante colas o intercambios duraderos junto con mensajes persistentes y confiando en las confirmaciones del consumidor para que el sistema pueda volver a entregar mensajes si se produce un error en el procesamiento antes de enviar una confirmación. Al integrar utilizando el conector RabbitMQ, aplique el mismo principio de diseño que otros agentes: suponga que habrá reintentos y posibles duplicados, y haga que el procesamiento descendente sea idempotente.

• Con IBM MQ, normalmente puede abordar la durabilidad y la entrega confiable mediante mensajes persistentes y procesamiento transaccional (unidades de trabajo). De este modo, podrá confirmar o revertir los mensajes recibidos y el trabajo conjunto en sentido descendente. Si se produce un error antes de confirmar el trabajo o se confirma un mensaje, el mensaje puede estar disponible para volver a entregarse.

  Cuando use el conector IBM MQ, diseñe para garantizar al menos una entrega y gestione posibles duplicados en el destino. En escenarios de migración de BizTalk, este patrón normalmente se asigna al diseño del flujo de trabajo de la aplicación lógica y los puntos de conexión de destino para el reprocesamiento seguro, por ejemplo, mediante el uso de identificadores de correlación, desduplicación y escrituras idempotentes, en lugar de confiar solo en el agente para un comportamiento de extremo a extremo, exactamente una vez.

Arquitectura de publicación-suscripción

En comparación con el motor de mensajería de BizTalk Server, Azure Logic Apps usa conectores y servicios de mensajería externos para implementar patrones de mensajería junto con la orquestación de flujos de trabajo. En el caso de los patrones de publicación-suscripción (pub-sub) con Azure Logic Apps, las opciones de broker comunes incluyen Azure Service Bus (temas y suscripciones) y RabbitMQ. Azure Service Bus es un broker de mensajes empresariales totalmente administrado con colas y temas de publicación/suscripción que puede usar para desacoplar aplicaciones y servicios, proporcionando las siguientes ventajas:

• Equilibrio de carga entre procesos de trabajo concurrentes.
• Enrutamiento y transferencia de datos de forma segura y con control más allá de los límites de las aplicaciones y los servicios.
• Coordinación del trabajo transaccional que requiere un alto grado de confiabilidad.

Azure Logic Apps incluye un Conector de Azure Service Bus que puede usar para publicar y suscribirse a mensajes. La ventaja es que puede usar la mensajería independientemente del flujo de trabajo. A diferencia de BizTalk Server, la mensajería se desacopla del motor de flujo de trabajo. Puede crear suscripciones de mensajes en Azure Service Bus y usar propiedades de mensaje (propiedades de usuario) como pares clave-valor evaluados por filtros en una suscripción de tema. Estas propiedades de usuario se definen cuando se configura una operación de Azure Service Bus agregando uno o varios pares clave-valor. Para obtener una demostración, consulte el vídeo: Pub Sub Messaging mediante Azure Integration Services - Parte 2: Enrutamiento basado en contenido.

Azure Logic Apps con flujos de trabajo estándar también incluye un conector integrado RabbitMQ que puede usar para enviar y recibir mensajes. En RabbitMQ, normalmente se implementa el patrón pub-sub publicando en un intercambio y haciendo que varios consumidores reciban mensajes a través de colas independientes enlazadas a ese intercambio, a menudo mediante claves de enrutamiento o enrutamiento basado en encabezados, en función del tipo de intercambio. Este enfoque admite patrones de distribución basados en distribución ramificada y enrutamiento, similares en intención a los temas y reglas de suscripción de Service Bus, pero configurados mediante intercambios, enlaces y configuraciones de cola de RabbitMQ. RabbitMQ suele ser una buena opción cuando tiene una infraestructura de RabbitMQ local existente, necesita las capacidades de un agente en entornos donde Azure Service Bus no está disponible, o desea mantener la mensajería localizada en la red donde se ejecutan los productores y consumidores. Al igual que con cualquier integración basada en un agente, diseñe pensando en los reintentos y los posibles duplicados, por ejemplo, utilizando confirmaciones, colas duraderas y mensajes persistentes cuando sea necesario, y asegúrese de que el procesamiento posterior sea idempotente.

Para muchos proyectos de migración de BizTalk, Azure Service Bus es la opción predeterminada común para pub-sub nativo de la nube, ya que el servicio está totalmente administrado y proporciona semántica integrada de temas y suscripciones con filtrado. En el caso de los requisitos locales de pub-sub, RabbitMQ puede ser una mejor opción, especialmente con el modelo de implementación híbrida de Azure Logic Apps, ya que Azure Service Bus es un servicio en la nube y no tiene una opción de implementación local. En estos casos, normalice la semántica de durabilidad y reintento y aplique la idempotencia en los límites del flujo de trabajo y del punto de conexión.

Motor de reglas de negocio

Azure Logic Apps incluye el motor de reglas de Azure Logic Apps. Este motor de reglas incluye el entorno de ejecución del motor de reglas de negocios (BRE) de BizTalk para que pueda usar directivas BRE de BizTalk existentes. Actualmente, la compatibilidad solo existe para hechos de XML y .NET Framework.

Networking

Para la conectividad entrante y saliente, Azure proporciona varias maneras de aislar sus servicios dentro de un límite de red y conectar cargas de trabajo locales y en la nube. En la siguiente lista se describen diferentes formas de integrar recursos de Azure con recursos que están dentro del perímetro de una red:

• conexiones híbridas

  Tanto un servicio de Azure como una característica de Azure App Service, conexiones híbridas admite escenarios y ofrece funcionalidades más allá de las de Azure App Service. Si desea obtener más información sobre el uso fuera de Azure App Service, consulte Protocolo de conexiones híbridas de Azure Relay. En Azure App Service, puede usar conexiones híbridas para acceder a los recursos de la aplicación en cualquier red que pueda realizar llamadas salientes a Azure a través del puerto 443. Conexiones híbridas proporciona acceso desde una aplicación a un punto de conexión TCP y no habilita ninguna forma nueva de acceder a la aplicación. En Azure App Service, cada conexión híbrida se correlaciona con una combinación única de host y puerto TCP. Esta funcionalidad permite que sus aplicaciones accedan a recursos que estén en cualquier sistema operativo, siempre y cuando haya un punto de conexión TCP. Conexiones híbridas no conoce ni se preocupa por el protocolo de la aplicación ni por el recurso al que quiere acceder. Esta característica simplemente proporciona acceso de red.

• Integración de la red virtual

  Con la integración de Azure Virtual Network, puede conectar un recurso de Azure a una red virtual configurada en Azure, de modo que la aplicación puede acceder a los recursos de esa red virtual. La integración de redes virtuales en Azure Logic Apps solo se usa para realizar llamadas salientes desde un recurso de Azure a la red virtual.

  Con el emparejamiento de red virtual, puede conectar redes locales a Azure, lo que proporciona conectividad bidireccional entre los recursos del entorno local y los servicios de Azure. Los Servicios de integración Azure proporcionan conectividad de red virtual, lo que permite una integración híbrida.

  En la siguiente imagen se muestra un recurso de aplicación lógica estándar con la página Redes abierta y la integración de red virtual habilitada, como aparece resaltado en el cuadro Tráfico saliente. Esta configuración garantiza que todo el tráfico saliente salga de esta red virtual.

  

• Puntos de conexión privados

  Un punto de conexión privado es una interfaz de red que usa una dirección IP privada de la red virtual. Esta interfaz de red se conecta de forma privada y segura a un recurso de Azure basado en Azure Private Link. Al habilitar un punto de conexión privado, incorpora ese recurso de Azure a la red virtual y permite que los recursos de la red realicen llamadas entrantes al recurso de Azure.

Código personalizado

En Azure Logic Apps, puede crear y ejecutar código de .NET en el flujo de trabajo de la aplicación lógica estándar. Para ello, debe usar Visual Studio Code con la extensión Azure Logic Apps (Estándar).

El conector Operaciones de código insertado proporciona las acciones denominadas Ejecutar código JavaScript, Ejecutar código de script CSharp y Ejecutar código de PowerShell. Puede usar estas acciones para agregar código, que admite entradas y salidas de contenido dinámicos. El motor de Azure Logic Apps espera que este código tenga tiempos de ejecución cortos. Una vez que el código completa la ejecución, la salida está disponible para las acciones de nivel inferior que se usarán en el flujo de trabajo.

Como se mencionó anteriormente, la compatibilidad con la llamada a ensamblados de .NET Framework desde un mapa XSLT está disponible actualmente en los flujos de trabajo de la aplicación lógica al cargar esos ensamblados en una cuenta de integración. Esta funcionalidad facilita la admisión de reglas de transformación de datos personalizadas. Para los flujos de trabajo de aplicaciones lógicas estándar, puede llamar al código de .NET Framework desde mapas XSLT sin una cuenta de integración. También puede agregar ensamblados y asignaciones a un proyecto de aplicación lógica estándar en Visual Studio Code e implementarlos después en Azure. Para obtener más información, consulte Compatibilidad con ensamblados de .NET Framework agregada a transformaciones XSLT de Azure Logic Apps (estándar).

Grupos de aplicaciones

En Azure Logic Apps, puede incluir y ejecutar varios flujos de trabajo en un recurso de aplicación lógica estándar, lo que da lugar a una relación de 1 a varios. Si está trabajando en modo local en un proyecto de aplicación lógica estándar en Visual Studio Code, el recurso de la aplicación lógica se asigna a este único proyecto. Con este enfoque, puede agrupar fácilmente y de forma lógica las cargas de trabajo, el código y los artefactos relacionados en el mismo proyecto e implementar ese proyecto como una sola unidad.

Las arquitecturas en la nube funcionan de forma diferente a los paradigmas basados en servidor, como BizTalk. Azure Logic Apps (Estándar) usa un modelo de extracción para incorporar código y artefactos. Como resultado, copiarás los artefactos necesarios adicionales en tu proyecto y, luego, los desplegarás con tu código y otros artefactos. En algunos casos, es posible que quiera evitar tener que copiar el código y los artefactos necesarios. Si es así, puede considerar la posibilidad de convertir esta funcionalidad en un servicio que puede administrar por separado, pero que puede llamar desde un flujo de trabajo.

Por ejemplo, supongamos que tiene una transformación de datos que se usa mucho en su organización. En lugar de incluir la asignación para la transformación en varios proyectos de aplicación lógica, puede implementar una interfaz que proporcione la transformación como un servicio. Después, puede administrar el ciclo de vida de ese servicio aparte de los proyectos de aplicaciones lógicas y llamar al servicio desde los flujos de trabajo.

Con la capacidad de incluir varios flujos de trabajo en un proyecto de aplicación lógica estándar, puede preguntarse cómo organizaría esos flujos de trabajo dentro de un proyecto o entre varios proyectos. La respuesta normalmente depende de sus requisitos, por ejemplo:

• Afinidad de procesos empresariales.
• Supervisión y soporte técnico completos.
• Seguridad, control de acceso basado en rol y aislamiento de red.
• Rendimiento e importancia para la empresa.
• Ubicación geográfica y redundancia geográfica.

Para obtener más información, consulte Organización de flujos de trabajo de aplicaciones lógicas en Azure Logic Apps (Estándar).

Seguridad y gobernanza

Azure Logic Apps admite las siguientes características de seguridad:

• Azure Key Vault

  Puede almacenar credenciales, secretos, claves de API y certificados con Azure Key Vault. En Azure Logic Apps, puede acceder a esta información con el conector de Azure Key Vault y excluir esta información de los registros de la plataforma y el historial de ejecución usando la funcionalidad de entradas y salidas seguras.

  Más adelante, en la sección Seguimiento de esta guía, se describe la funcionalidad del historial de ejecución, que proporciona una reproducción paso a paso de la ejecución de un flujo de trabajo. Aunque Azure Logic Apps ofrece la propuesta de valor de capturar cada entrada y cada salida en una ejecución de un flujo de trabajo, a veces es necesario administrar el acceso a los datos confidenciales de un modo más pormenorizado. Puede configurar la ofuscación de estos datos usando la funcionalidad de entradas y salidas seguras en los desencadenadores y las acciones para ocultar ese contenido del historial de ejecución y evitar el envío de esos datos a Azure Monitor, específicamente a Log Analytics y Application Insights. En la siguiente imagen se muestra un resultado de ejemplo de haber habilitado las entradas y salidas seguras en el historial de ejecución.

  

• Integración basada en OAuth

  La mayoría de los conectores usan este tipo de autenticación al crear conexiones. Este enfoque hace que la integración con muchos servicios SaaS sea tan fácil como proporcionar su dirección de correo electrónico y contraseña. Azure API Management también admite OAuth, así que puede usar ambos servicios juntos proporcionando un esquema de autenticación unificado.

  Esta funcionalidad no está disponible de forma nativa en BizTalk Server.

• Identidades administradas

  Azure Logic Apps (Estándar) puede autenticar el acceso a las cuentas de almacenamiento mediante una identidad administrada. Además, algunos conectores admiten el uso de identidades administradas para autenticar el acceso a los recursos protegidos por Microsoft Entra ID. Cuando use una identidad administrada para autenticar la conexión, no tiene que proporcionar credenciales, secretos ni tokens de Microsoft Entra.

Administración de aplicaciones y del acceso

Azure Portal es una herramienta común que usan los administradores y el personal de soporte técnico para ver y supervisar el estado de las interfaces. Para Azure Logic Apps, esta experiencia incluye un seguimiento completo de las transacciones que está disponible en el historial de ejecución. También está disponible el control de acceso basado en rol (RBAC) pormenorizado, de modo que puede administrar y restringir el acceso a los recursos de Azure en varios niveles.

Almacenamiento

Azure Logic Apps se basa en Azure Storage para almacenar y cifrar los datos en reposo automáticamente. Este cifrado protege los datos y le ayuda a cumplir los compromisos de cumplimiento y seguridad de la organización. De forma predeterminada, Azure Storage usa claves que administra Microsoft para cifrar sus datos. Para más información, consulte Cifrado de Azure Storage para datos en reposo.

Al trabajar con Azure Storage en Azure Portal, todas las transacciones se realizan a través de HTTPS. También puede trabajar con Azure Storage usando la API REST de Storage a través de HTTPS. Para exigir el uso de HTTPS al llamar a las API REST para acceder a objetos de cuentas de almacenamiento, habilite la transferencia segura que requiere la cuenta de almacenamiento.

El modelo de implementación híbrida de Azure Logic Apps (estándar) se basa en SQL Server. Esta dependencia le permite usar entornos de SQL Server locales existentes con BizTalk Server.

Procesamiento de archivos grandes

Existen algunas diferencias fundamentales entre el procesamiento de archivos grandes con BizTalk Server frente a Azure Logic Apps. Por ejemplo, examine cuidadosamente escenarios de mensajes grandes para encontrar la solución adecuada, porque puede haber otras formas de resolver este problema en un entorno de nube moderno.

Límites de tamaño de archivo

En Azure, existen límites de tamaño de archivo para garantizar experiencias coherentes y confiables. Para validar el escenario, asegúrese de revisar la documentación sobre los límites de servicio de Azure Logic Apps. Algunos conectores admiten la fragmentación de los mensajes que superan el límite de tamaño predeterminado, que varía en función del conector. La fragmentación de mensajes funciona dividiendo un mensaje grande en mensajes más pequeños.

Azure Logic Apps no es el único servicio que tiene límites de tamaño para los mensajes. Por ejemplo, Azure Service Bus también tiene estos límites. Para obtener más información sobre el control de mensajes grandes en Azure Service Bus, consulte Compatibilidad con mensajes grandes.

Para evitar limitaciones de tamaño de archivo, puede implementar el patrón de comprobante, que funciona dividiendo un mensaje grande en un comprobante y una carga. Envía el comprobante a la plataforma de mensajería y almacena la carga en un servicio externo. De este modo, puede procesar mensajes grandes, a la vez que protege el bus de mensajes y el cliente de la sobrecarga. Este patrón también ayuda a reducir los costos, ya que el almacenamiento suele ser más barato que las unidades de recursos que utiliza la plataforma de mensajería.

Supervisión y alertas

En Azure Logic Apps, puede habilitar la compatibilidad con Application Insights, que proporciona visualizaciones seleccionadas como base para supervisar los servicios de Azure. Estas visualizaciones le ayudan a supervisar de forma más eficaz los flujos de trabajo estándar mediante paneles diseñados específicamente para Azure Logic Apps (Estándar). El ámbito del panel abarca los flujos de trabajo dentro de una aplicación lógica Estándar. El panel se basa en libros de Azure y ofrece varias visualizaciones. Puede ampliar y personalizar fácilmente estos libros para satisfacer necesidades específicas.

Serverless 360 es una solución externa de Kovai que proporciona supervisión y administración mediante la asignación de servicios de Azure, como Azure Logic Apps, Azure Service Bus, Azure API Management y Azure Functions. Puede volver a procesar mensajes usando colas de mensajes fallidos en Azure Service Bus, habilitar la recuperación automática para abordar interrupciones intermitentes del servicio y configurar la supervisión proactiva por medio de transacciones sintéticas.

Puede configurar reglas de supervisión personalizadas y ver los registros en el portal. Puede enviar notificaciones a través de varios canales, como correo electrónico, Microsoft Teams y ServiceNow. Para determinar visualmente el estado de las interfaces, hay disponibles mapas de servicio.

Supervisión de la actividad económica

Como desarrollador o analista de negocios que trabaja en soluciones que integran servicios y sistemas mediante varios recursos de Azure, es posible que tenga dificultades para visualizar la relación entre los componentes técnicos de la solución y su escenario empresarial. Para incluir el contexto empresarial sobre los recursos de Azure en la solución, puede crear procesos empresariales que representen visualmente la lógica de negocios implementada por estos recursos. En Azure Business Process Tracking, un proceso de negocio es una serie de fases que representan las tareas que fluyen a través del escenario empresarial del mundo real.

Otra opción es usar una solución externa de Kovai denominada Serverless 360. Junto con la plataforma de supervisión, puede usar la característica Supervisión de la actividad económica, que proporciona un seguimiento completo de los flujos de los procesos empresariales en integraciones híbridas y nativas de nube. Esta característica incluye un conector administrado que los desarrolladores pueden usar para instrumentar código y capturar datos empresariales importantes. Después, los administradores pueden crear paneles y compartirlos con analistas de negocios.

Seguimiento

Azure Logic Apps proporciona un historial de ejecución de flujo de trabajo enriquecido para que los desarrolladores y los analistas de soporte técnico puedan revisar la telemetría de acción por acción, incluidas todas las entradas y salidas procesadas. Para ayudar a proteger los datos confidenciales, puede habilitar las entradas y salidas seguras en acciones individuales de flujos de trabajo. Esta funcionalidad ofusca u oculta los datos de los registros y los historiales de ejecución de los flujos de trabajo para evitar filtraciones.

Además de la ofuscación de datos, puede usar reglas de RBAC de Azure para proteger el acceso a los datos. Azure RBAC incluye roles integrados específicos para Azure Logic Apps (Estándar). Más allá de Azure RBAC, puede restringir el acceso al historial de ejecución en Azure Logic Apps por intervalo de direcciones IP.

Hosting

• Planes de hospedaje

  En Azure Logic Apps de un solo inquilino, puede usar un único plan de servicio de flujo de trabajo para hospedar varias aplicaciones lógicas estándar. Esto significa que no tiene que implementar todos los flujos de trabajo en un único recurso de aplicación lógica estándar. En lugar de esto, puede organizar estos flujos de trabajo en grupos lógicos (aplicaciones lógicas) para facilitar la administración de otros aspectos de la solución. Este enfoque le ayuda a sacar el máximo partido al plan de servicio de flujo de trabajo y a las aplicaciones preparadas para el futuro, que puede implementar para que se puedan escalar individualmente.

  Una aplicación lógica estándar tiene los siguientes planes de tarifa: WS1, WS2 y WS3. Funcionalmente, cada nivel proporciona las mismas características. Los requisitos de proceso y memoria determinan cuál es lo mejor para su escenario, por ejemplo:

  Plan de tarifa	CPU virtual (vCPU)	Memoria (GB)
  WS1	1	3,5
  WS2	2	7
  WS3	4	14

  Para obtener más información, consulte Planes de tarifa en el modelo Estándar.

• Modelo de implementación híbrida

  Azure Logic Apps ofrece un modelo de implementación híbrida para que pueda implementar y hospedar flujos de trabajo de aplicaciones lógicas estándar en escenarios locales, de nube privada o de nube pública. Este modelo proporciona las funcionalidades para hospedar soluciones de integración en entornos parcialmente conectados cuando necesita usar el procesamiento local, el almacenamiento de datos y el acceso a la red. Con la opción híbrida, tiene la libertad y flexibilidad de elegir el mejor entorno para los flujos de trabajo. Para más información, consulte Configuración de su propia infraestructura para aplicaciones lógicas estándar mediante la implementación híbrida.

• Disponibilidad y redundancia

  En Azure, las zonas de disponibilidad proporcionan resistencia, disponibilidad distribuida y escalabilidad de zona en modo activo/activo/activo. Para aumentar la disponibilidad de las cargas de trabajo de aplicaciones lógicas, puede habilitar la compatibilidad con zonas de disponibilidad, pero solo cuando crea la aplicación lógica. Necesitará al menos tres zonas de disponibilidad en cualquier región de Azure que admita y habilite la redundancia de zona. La plataforma Azure Logic Apps distribuye estas zonas y cargas de trabajo de aplicaciones lógicas entre estas zonas. Esta funcionalidad es un requisito clave para habilitar las arquitecturas resistentes y proporcionar alta disponibilidad si se producen errores en el centro de datos en una región. Para obtener más información, consulte Compilación de soluciones para alta disponibilidad mediante zonas de disponibilidad.

• Entorno aislado y dedicado

  En el caso de las aplicaciones lógicas estándar, tiene la opción de seleccionar App Service Environment (ASE) v3 para el entorno de implementación. Con ASE v3, obtiene un entorno totalmente aislado y dedicado para ejecutar aplicaciones a gran escala con precios predecibles. Usted paga solo por el plan de App Service para ASE, independientemente del número de aplicaciones lógicas que cree y ejecute.

Para ver escenarios que requieren servicios de integración de Azure adicionales, consulte la siguiente documentación:

• Niveles de mensajería Estándar y Premium de Azure Service Bus
• Azure API Management: Comparación de niveles basado en características

Implementación

Azure Logic Apps admite infraestructura como código (IaC) al proporcionar la capacidad de crear recursos de infraestructura mediante plantillas de Administración de recursos de Azure. Aunque las plantillas de ARM pueden parecer complejas de entender e implementar como una solución unificada, puede usar herramientas de abstracción, como Bicep, Terraform o Pulumi, que proporcionan una experiencia similar al código para crear la definición de la infraestructura. Aunque estas herramientas proporcionan capas de abstracción sobre las plantillas de ARM, en última instancia generan plantillas de ARM y pueden implementarlas automáticamente.

Con la infraestructura implementada, puede aplicar la lógica que implementa los flujos de trabajo completos. Dado que los Servicios de integración Azure ofrecen una colección de herramientas para implementar los flujos de trabajo de integración, debe implementar cada componente. En el caso de las soluciones creadas con los Servicios de integración Azure, las canalizaciones de CI/CD suelen basarse en la implementación de una orquestación de componentes. Los ingenieros de DevOps pueden usar acciones integradas que abstraen las actividades de implementación, o bien usan acciones genéricas que ejecutan comandos de la CLI o scripts de automatización, como PowerShell y Bash. En la mayoría de los casos, los ingenieros personalizan las canalizaciones en función de las necesidades de la aplicación, revisan las instrucciones de la documentación oficial y usan repositorios de ejemplo como punto de partida.

El proceso para preparar cada componente para la implementación suele tener en cuenta los siguientes pasos:

• Fase de integración continua

  1. Obtener la versión más reciente del código fuente.

  2. Preparar el código con la configuración específica del entorno.

     Los detalles de este paso dependen de la compatibilidad de cada tecnología con la inserción externa de variables de entorno. La premisa básica es que la información de configuración basada en el entorno, como cadenas de conexión y referencias a recursos externos, se abstrae para hacer referencia a un repositorio de configuración de la aplicación. Por tanto, en este escenario, almacenaría referencias que pueden existir como texto no cifrado directamente en el repositorio de configuración de la aplicación, pero almacenaría los valores confidenciales, como secretos, en forma de punteros de referencia a entradas de un almacén de secretos, como un almacén de claves de Azure Key Vault.

     Azure Logic Apps hace posible este enfoque para un recurso de aplicación lógica estándar gracias a la compatibilidad con referencias al repositorio de configuración de la aplicación. Después, puede asignar pares nombre-valor a entradas del almacén de claves.

  3. Empaquetar el código para implementarlo en varios entornos.

• Fase de implementación continua

  1. Implementar el código empaquetado en el entorno de destino.

  2. Actualizar el repositorio de configuración de la aplicación con los valores de entorno correctos, ya sea como texto no cifrado o como referencias a entradas del almacén de claves.

  3. Actualizar los permisos necesarios que dependan del código.

  4. Preparar la aplicación para ejecutarla, si es necesario.

Coincidencia de características

En la tabla y diagrama siguientes se muestra cómo se comparan y coinciden los recursos, artefactos, características y funcionalidades entre BizTalk Server, Azure Logic Apps (Estándar) y otros servicios. Intente usar las características de Azure Logic Apps tanto como sea posible para crear una solución coherente y rentable.

Azure Logic Apps Estándar (nube)

Azure Logic Apps Standard Hybrid (en las instalaciones)

Si desea mantenerse al día de las últimas inversiones, suscríbase al blog de Tech Community sobre integraciones en Azure.

Pasos siguientes

Ha obtenido más información sobre cómo Azure Logic Apps se compara con BizTalk Server. A continuación, revise los enfoques y recursos sugeridos, las consideraciones de planeación y los procedimientos recomendados para la migración.