Enfoques de migración de BizTalk Server a Azure Logic Apps
Esta guía abarca estrategias y recursos de migración además de consideraciones de planificación y prácticas recomendadas para ayudarle a ofrecer soluciones de migración satisfactorias.
Nota
Para obtener una descripción general de la migración y una guía para elegir los servicios en Azure para su migración, revise la siguiente documentación:
Opciones de estrategia
En las siguientes secciones se describen varias estrategias de migración junto con sus ventajas y desventajas:
Big bang
Un enfoque de "big bang" o "cambio directo" es un enfoque que requiere una gran cantidad de planeamiento y no se recomienda para las organizaciones que no están familiarizados con Azure Logic Apps o que tienen sistemas o soluciones grandes para migrar. Cuando una organización implementa una nueva pila de tecnología, normalmente se producen nuevos aprendizajes. Al invertir demasiado pronto o demasiado, no tendrá la oportunidad de beneficiarse de las lecciones aprendidas y ajustarse sin arriesgarse a un trabajo significativo.
Este enfoque también puede tardar más tiempo en obtener o acumular valor. Si ya ha completado algunas actividades de migración, pero aún no las ha publicado en producción debido a otros trabajos pendientes o en curso, los artefactos migrados no generan valor para su organización.
Se recomienda considerar este enfoque solo si tiene cargas de trabajo de BizTalk pequeñas y de baja complejidad, expertos en la materia (SME) que conocen el entorno de BizTalk y asignaciones directas entre las características de BizTalk que usa actualmente y Azure Logic Apps. La experiencia con Azure Logic Apps también reduce considerablemente los riesgos con este enfoque.
Iterativo o basado en ondas (recomendado)
Este enfoque proporciona la oportunidad de que su organización logre un valor incrementalmente, pero antes de lo contrario. El equipo del proyecto puede obtener información sobre la pila de tecnología al principio mediante retrospectivas. Por ejemplo, puede implementar una interfaz o proyecto de BizTalk existente en producción y, a continuación, obtener información sobre las necesidades de la solución, que incluyen administración, escalabilidad, operaciones y supervisión. Después de obtener este conocimiento, puede planear sprints para optimizar las funcionalidades existentes o introducir nuevos patrones que puede usar posteriormente en el trabajo futuro.
Independientemente de su enfoque, si planea pasar a Azure Logic Apps o Azure en general, considere la posibilidad de refactorizar las soluciones de BizTalk Server en soluciones nativas de nube o sin servidor antes de retirar la infraestructura del servidor. Esta opción es una estrategia excelente si su organización quiere transformar completamente la empresa en la nube.
BizTalk Server y Azure Logic Apps tienen arquitecturas diferentes. Para modernizar aún más las soluciones, puede usar los Servicios de integración Azure para ampliar las funcionalidades de Azure Logic Apps que abordan las necesidades principales de integración de clientes.
Para obtener una mayor rentabilidad de la inversión (ROI), se recomienda que cualquier migración de BizTalk use las funcionalidades nativas principales de Azure Logic Apps (estándar) tanto como sea posible además de otros Servicios de integración Azure según sea necesario. Esta combinación hace posible escenarios adicionales, por ejemplo:
- Funcionalidades híbridas nativas en la nube con Azure Logic Apps (estándar) con implementación híbrida
- Funcionalidades de flujo de trabajo con estado o sin estado en Azure Logic Apps (estándar)
- Integración nativa, integrada (en la aplicación) del sistema central y los rangos intermedios con conectores en Azure Logic Apps (estándar)
- Mensajería pub-sub mediante Azure Service Bus
- Funcionalidades de SOAP avanzada en Azure API Management
Entrega de un proyecto de migración de BizTalk
Para completar este proyecto, se recomienda seguir el enfoque iterativo o basado en onda y usar el proceso de Scrum. Aunque Scrum no incluye un concepto de Sprint Zero (Sprint 0) para las actividades previas al sprint, se recomienda centrar su primer sprint en la alineación del equipo y la detección técnica. Después de Sprint 0, siga la ejecución de varios sprints de migración y céntrese en publicar características hacia un producto mínimo viable (MVP).
Sprint 0
Durante este sprint, se recomienda ejecutar la detección de entornos de BizTalk Server con el planeamiento de ondas. Comprender la amplitud y profundidad del proyecto es fundamental para el éxito. En la lista siguiente se incluyen las áreas específicas que se van a abordar durante sprint 0:
| Área | Descripción |
|---|---|
| Detección | Capture datos sobre todas las interfaces y aplicaciones para que pueda obtener información sobre el número de interfaces y aplicaciones que necesita migrar. También debe asignar complejidad a cada interfaz o proceso. Durante este proceso de catalogación, recopile la siguiente información para priorizar el trabajo: - Adaptadores en uso - Características de BizTalk Server en uso, como Business Activity Monitoring, Business Rules Engine, EDI, etc. - Código personalizado, como expresiones, mapas y componentes de canalización - Rendimiento de mensajes - Tamaños de mensaje - Dependencies - Dependencias de la aplicación y del sistema |
| Diseño de arquitectura | Cree la arquitectura de alto nivel que se usará como punto focal para la migración. Este diseño incluye elementos que abordan las necesidades funcionales y no funcionales de alto nivel. |
| Definición de producto viable mínimo (MVP) | Defina las características de primera oleada. Es decir, los procesos que necesitan soporte técnico después de completar la primera oleada. |
| Trabajo pendiente de migración inicial | Defina las primeras características de onda y sus elementos de trabajo con elaboración técnica. |
Herramientas de detección
Para ayudarle con la detección de migración, puede usar la herramienta de línea de comandos de Azure Integration Migrator, también denominada herramienta de migración de BizTalk, que es un proyecto de código abierto de Microsoft. Esta herramienta usa un enfoque por fases para ayudarle a descubrir información y estrategias útiles para migrar las soluciones a la nube. Se recomienda usar la herramienta de migración solo para la detección y la generación de informes. También puede considerar la posibilidad de usar otros productos para la detección de asociados que proporcionan soluciones en este espacio.
Si quiere otra manera de generar un inventario con elementos de BizTalk Server, puede usar The BizTalk Documenter, que está desarrollado por Mark Brimble. Esta herramienta funciona con BizTalk Server 2020, a pesar de indicar que solo se admite BizTalk Server 2016.
Diseño de arquitectura
Aunque Azure Logic Apps proporciona funcionalidades que le permiten reutilizar recursos de BizTalk Server, debe tener un diseño de arquitectura moderno para adoptar las ventajas de las funcionalidades más modernas. Desde una perspectiva funcional, use la lógica de negocios tanto como sea posible. Desde una perspectiva de modernización de productos, use los Servicios de integración Azure tanto como pueda. Para conocer los problemas de calidad y transversales, se recomienda usar el Marco de trabajo bien diseñado de Azure.
En este marco, las migraciones de BizTalk son cargas de trabajo críticas. En este término se describen colecciones de recursos de aplicación que requieren alta disponibilidad en la plataforma, lo que significa que siempre deben estar disponibles, ser operativos y resistentes a errores.
Para completar el diseño de la arquitectura para la migración de BizTalk, siga la metodología de diseño para cargas de trabajo críticas en Azure. Para obtener una arquitectura y topología iniciales, revise y use la arquitectura de referencia descrita en integración empresarial básica en Azure en el Centro de arquitectura de Azure.
Para configurar el entorno inicial, use el Acelerador de zona de aterrizaje de Servicios de integración Azure, que está destinada para crear e implementar una plataforma de integración mediante un diseño típico de zona de aterrizaje empresarial.
Definición de proyecto viable mínimo (MVP)
Un MVP es una versión de producto que tiene suficientes características que puede usar el cliente. Esta versión muestra las posibilidades y el potencial del producto para recopilar comentarios de los clientes y continuar el trabajo. Para una migración de BizTalk, la definición de MVP refleja las iteraciones, oleadas o grupos de sprints que necesita para avanzar en las características de trabajo y para satisfacer las cargas de trabajo de integración iniciales.
Se recomienda que la definición de MVP incluya los siguientes resultados empresariales, que se expresan como Epopeyas en terminología de Scrum:
Resultados empresariales (epopeyas)
- ¿Cuál es el objetivo principal que desea lograr?
- ¿Qué funcionalidades o características debe abordar para este MVP?
- ¿Qué son los flujos de proceso de negocio? Esta pregunta proporciona la oportunidad de optimizar los procesos existentes admitidos por BizTalk Server.
- ¿Cuáles son las decisiones empresariales, por ejemplo, los resultados empresariales que afectan al MVP o cuál es la disponibilidad de recursos?
Se recomienda que el MVP incluya los siguientes resultados procesos en el ámbito, que se expresan como Características en terminología de Scrum:
Procesos dentro del ámbito (características)
| Característica | Descripción |
|---|---|
| Funcionalidad del sistema de alto nivel | Puede extraer esta información mediante las herramientas de detección y expresar las descripciones en términos de características. |
| Actores o personajes | Use esta información para determinar qué personas se han visto afectadas por los escenarios admitidos por el MVP. |
| Orquestaciones | Puede extraer esta información mediante las herramientas de detección. |
| Entidades de datos y mensajes | Estos elementos le ofrecen la oportunidad de saber si puede incluir mejoras adicionales en los datos intercambiados por el entorno de BizTalk Server. |
| Asignaciones de datos | El mundo actual se basa en JSON. Sin embargo, BizTalk Server usa XML. Este momento es una gran oportunidad para decidir el formato de datos y las necesidades de conversión para la nueva plataforma. |
| Reglas de negocio | Estas reglas centradas en datos abren una oportunidad para que se replantee su enfoque o reutilícelas mediante el uso de funcionalidades de Azure Logic Apps. |
| Consideraciones sobre privacidad de datos | Debe hacer que la privacidad sea una prioridad máxima. A menos que el cliente elija el modelo de implementación híbrida en Azure Logic Apps (estándar), debe abordar esta área en cada oleada debido a posibles cambios en el entorno de implementación. |
| Consideraciones normativas | Este aspecto es más relevante si los clientes no tienen cargas de trabajo basadas en la nube. |
| Protección por diseño | Debe diseñar cada característica teniendo en cuenta la seguridad. |
| Características propuestas para la coexistencia | Al entregar cada oleada, tiene un cierto grado de coexistencia. Debe alinear esta arquitectura híbrida con los indicadores de nivel de servicio (SLI) existentes y los objetivos de nivel de servicio (SLO). |
| Consideraciones no funcionales | Los procesos empresariales pueden tener requisitos no funcionales diferentes. No todo debe ocurrir en tiempo real. Por el contrario, no todo es un proceso por lotes. |
| Métricas empresariales | Una oportunidad opcional para mostrar el progreso del trabajo de migración. |
También querrá identificar y enumerar las distintas variables fuera del ámbito que dan forma al ámbito del trabajo MVP, por ejemplo:
- Disponibilidad de recursos
- Riesgos
- Documentación
- Tiempo de comercialización
Trabajo pendiente inicial
El trabajo pendiente inicial es un conjunto de casos de usuario, que se agrupan en características para crear los procesos dentro del ámbito para el MVP. En otras palabras, un MVP se representa mediante elementos de Scrum conocidos como Epopeyas, Características Y Casos de usuario. Idealmente, cada Epopeya abarca un grupo de aplicaciones de BizTalk o proyectos de BizTalk. Puede usar la regla sencilla de asociar una aplicación de BizTalk o un proyecto de BizTalk a una característica.
Por ejemplo, supongamos que tiene un proyecto de BizTalk Server con una orquestación denominada "LoanRequests" que los clientes usan para solicitar préstamos bancarios. Por lo tanto, tiene las siguiente característica y caso de usuario propuestas:
Característica: procesamiento de préstamos
Caso de usuario: "Como cliente, quiero enviar una solicitud de préstamo para que el banco pueda agregar fondos a mi cuenta segura".
Este caso de usuario, que puede existir actualmente como una implementación en BizTalk Server, puede implementar las siguientes tareas mediante Azure Logic Apps y Servicios de integración Azure:
- Recopilar artefactos reutilizables de BizTalk.
- Crear un flujo de trabajo de solicitud de préstamo con Azure Logic Apps.
- Configure la mensajería asincrónica mediante Azure Service Bus o IBM MQ.
- Asigne JSON a datos XML mediante un flujo de trabajo de Azure Logic Apps.
- Personalice los Servicios de integración Azure según sea necesario para los patrones de mensajería.
En el diagrama siguiente se muestran las duraciones sugeridas para epopeyas, características, casos de usuario y tareas, que subdivide los casos de usuario. Aunque las decisiones de implementación afectan a estas duraciones, suponen que usa artefactos de BizTalk existentes en Azure Logic Apps. Cree los flujos de trabajo estándar mediante las plantillas de flujo de trabajo precompiladas tanto como sea posible.
Oleadas de migración (sprints)
Una vez que el equipo complete Sprint 0, debe tener una vista clara del MVP que se va a compilar. Una oleada es un conjunto de sprints. El trabajo pendiente inicial debe incluir elementos de trabajo que sigan el diagrama siguiente tanto como sea posible:
Durante una oleada, el equipo completa las actividades para migrar, probar y liberar a producción. Vamos a examinar más detenidamente lo que sucede en cada oleada.
Migrate
Durante cada oleada, la migración se centra en los casos de usuario acordados. Para la primera oleada, el equipo se centra en el trabajo pendiente inicial. Las decisiones tecnológicas deben usar la información de la asignación de características de BizTalk Server, descrita por Coincidencia de características: ¿Por qué migrar de BizTalk Server a Azure Logic Apps?
En el diagrama siguiente se muestran los eventos que deben producirse durante las oleadas de migración:
| Paso | Description |
|---|---|
| 1 | Descubra las interfaces y aplicaciones de BizTalk existentes. Aunque se introdujo en Sprint 0, esta actividad debe ocurrir cuando se inicia cada oleada. Es posible que los clientes sigan realizando cambios en el entorno de BizTalk. Recursos: - Herramienta de migración de BizTalk - Herramienta de documentador de BizTalk |
| 2 | Configure el entorno de migración inicial. Puede usar el Acelerador de zona de aterrizaje de los Servicios de integración Azure, que es un Cloud Adoption Framework para crear e implementar una plataforma de integración que tiene un diseño típico de zona de aterrizaje empresarial. Como propietario de la carga de trabajo, puede lograr con confianza el estado técnico de destino mediante la guía de arquitectura y recursos de migración de BizTalk proporcionada. Para obtener una arquitectura de ejemplo, consulte Ejemplo del entorno de migración. |
| 3 | Cree y pruebe flujos de trabajo de aplicaciones lógicas estándar que se ejecutan en Azure Logic Apps de un solo inquilino mediante Azure Portal o Visual Studio Code con la extensión de Azure Logic Apps (estándar). Con Visual Studio Code puede desarrollar, probar y almacenar localmente el proyecto de aplicación lógica mediante cualquier sistema de control de código fuente. Para más información, consulte la siguiente documentación: - Creación de un flujo de trabajo de aplicación lógica Estándar usando Azure Portal - Creación de un flujo de trabajo de aplicación lógica Estándar usando Visual Studio Code Para ver un diagrama que muestra una aplicación lógica de ejemplo y conexiones, consulte Entorno de migración de ejemplo. |
| 4 | Para obtener todas las ventajas de implementar fácilmente y de forma coherente los flujos de trabajo de aplicación lógica estándar en diferentes entornos y plataformas, también deberá automatizar los procesos de compilación e implementación. La extensión Azure Logic Apps (estándar) para Visual Studio Code proporciona herramientas para crear y mantener procesos automatizados de compilación e implementación mediante Azure DevOps. Para obtener más información, consulte Automatización de la compilación e implementación de flujos de trabajo de aplicaciones lógicas Estándar con Azure DevOps. |
| 5 | Para implementar aplicaciones lógicas estándar críticas que estén siempre disponibles y con capacidad de respuesta, incluso durante las actualizaciones o el mantenimiento, habilite la implementación sin tiempo de inactividad con la creación y use ranuras de implementación. Cero tiempo de inactividad significa que, al implementar las nuevas versiones de la aplicación, los usuarios finales no experimentan interrupciones ni tiempos de inactividad. Para obtener más información, consulte Configuración de ranuras de implementación para habilitar la implementación sin tiempo de inactividad en Azure Logic Apps. |
En el diagrama siguiente se muestra un entorno de migración inicial de ejemplo con una aplicación lógica estándar que organiza flujos de trabajo que se comunican con las API, los servicios, las soluciones híbridas y los recursos locales:
Prueba
Cada oleada tiene sus propias actividades de prueba, que se insertan en cada caso de usuario. Si quiere usar pruebas de desplazamiento a la izquierda, asegúrese de completar las tareas siguientes:
Automatizar las pruebas.
Azure Logic Apps (Estándar) incluye la capacidad de realizar pruebas automatizadas. En la lista siguiente se incluye más información y recursos disponibles gratuitamente en GitHub:
Pruebas automatizadas con Azure Logic Apps (Estándar) del equipo de Azure Logic Apps
Con Azure Logic Apps (Estándar), las pruebas automatizadas ya no son difíciles de realizar debido a la arquitectura subyacente, que se basa en el entorno de ejecución de Azure Functions y se pueden ejecutar en cualquier lugar en el que se pueda ejecutar Azure Functions. Puede escribir pruebas para flujos de trabajo que se ejecutan localmente o en una canalización de CI/CD. Para más información, consulte el proyecto de ejemplo del marco de pruebas de Azure Logic Apps.
Este marco de pruebas incluye las siguientes funcionalidades:
- Escribir pruebas automatizadas para la funcionalidad de un extremo a otro en Azure Logic Apps.
- Realizar una validación específica en los niveles de ejecución y acción del flujo de trabajo.
- Comprobar las pruebas en un repositorio de Git y ejecutar localmente o dentro de canalizaciones de CI/CD.
- Funcionalidades de prueba ficticias para acciones HTTP y conectores de Azure.
- Configurar las pruebas para usar valores de configuración diferentes de producción.
Cuaderno de estrategias de integración: Pruebas estándar de Logic Apps de Michael Stephenson, Microsoft MVP
El marco de pruebas del cuaderno de estrategias de integración se basa en el marco de pruebas proporcionado por Microsoft y admite escenarios adicionales:
- Conéctese a un flujo de trabajo en una aplicación lógica estándar.
- Obtenga la dirección URL de devolución de llamada para que pueda desencadenar el flujo de trabajo desde una prueba.
- Compruebe los resultados de la ejecución del flujo de trabajo.
- Compruebe las entradas y salidas de la operación del historial de ejecución del flujo de trabajo.
- Conéctese a marcos de pruebas automatizadas que los desarrolladores de aplicaciones lógicas puedan usar.
- Conéctese a SpecFlow para admitir el desarrollo controlado por el comportamiento (BDD) para aplicaciones lógicas.
Independientemente de los enfoques automatizados o recursos que use, está bien en su camino para tener pruebas de integración automatizadas coherentes y repetibles.
Configure pruebas de respuesta simulada mediante resultados estáticos.
Independientemente de si configuró pruebas automatizadas, puede usar la capacidad de resultados estáticos en Azure Logic Apps para establecer temporalmente respuestas ficticias en el nivel de acción. Esta funcionalidad le permite emular el comportamiento de un sistema específico al que desea llamar. A continuación, puede realizar algunas pruebas iniciales de forma aislada y reducir la cantidad de datos que crearía en sistemas de línea de negocio.
Ejecutar pruebas en paralelo.
Lo ideal es que ya tenga pruebas de integración de línea base para el entorno de BizTalk Server y las pruebas automatizadas establecidas para Azure Logic Apps. Después, puede ejecutar pruebas en paralelo de una manera que le ayude a comprobar las interfaces mediante los mismos conjuntos de datos y mejorar la precisión general de las pruebas.
Lanzamiento a producción
Una vez que el equipo termine y cumpla la "definición de hecho" para los casos de usuario, tenga en cuenta las siguientes tareas:
Cree un plan de comunicación para el lanzamiento a producción.
Elaborar un “plan de transición”.
Un plan de transición incluye los detalles sobre las tareas y actividades necesarias para pasar de la plataforma actual a la nueva, incluidos los pasos que su equipo tiene previsto ejecutar. Incluya las siguientes consideraciones en su plan de transición:
- Pasos de requisitos previos
- Ensayo general
- People (Personas)
- Estimaciones del programa
- Deshabilitar interfaces en la plataforma antigua
- Habilitación de interfaces en la nueva plataforma
- Pruebas de validación
Determinar un plan de reversión.
Ejecutar pruebas de validación.
Planificar las operaciones o el apoyo a la producción.
Elija criterios de "ir o no ir" para publicar en producción.
Celebre el éxito de su equipo.
Hacer una retrospectiva.
Procedimientos recomendados para una migración de BizTalk
Aunque los procedimientos recomendados pueden variar de una organización a otra, considere la posibilidad de realizar un esfuerzo consciente para promover la coherencia, lo que ayuda a reducir los esfuerzos innecesarios que "reinventan la rueda" y la redundancia de componentes comunes similares. Si ayuda a facilitar la reutilización, su empresa podrá crear más rápidamente interfaces más fáciles de mantener. El tiempo de comercialización es un factor clave para la transformación digital, por lo que una de las principales prioridades es reducir las fricciones innecesarias para los desarrolladores y los equipos de asistencia.
Cuando establezca sus propios procedimientos recomendados, considere la posibilidad de alinearse con las siguientes directrices:
Convenciones generales de nomenclatura para los recursos de Azure
Asegúrese de establecer y aplicar de forma coherente buenas convenciones de nomenclatura en todos los recursos de Azure, desde los grupos de recursos hasta cada tipo de recurso. Para sentar una base sólida para la capacidad de descubrimiento y soporte, una buena convención de nomenclatura comunica el propósito. El punto más importante para las convenciones de nomenclatura es que usted las tenga, y que su organización las entienda. Cada organización tiene matices que puede tener que tener en cuenta.
Para obtener orientación sobre esta práctica, consulte las siguientes recomendaciones y recursos de Microsoft:
- Ejemplos de abreviaturas para recursos de Azure
- Herramienta de nomenclatura de Azure, que genera nombres compatibles con Azure, le ayuda a estandarizar los nombres y automatiza el proceso de nomenclatura.
Convenciones de nomenclatura para los recursos de Azure Logic Apps
El diseño de su aplicación lógica y flujo de trabajo proporciona un punto de partida clave, ya que esta área ofrece flexibilidad a los desarrolladores para crear nombres únicos.
Nombres de recursos de aplicaciones lógicas
Para diferenciar entre recursos de app lógica de consumo y estándar, puede usar diferentes abreviaturas, por ejemplo:
- Consumo: LACon
- Estándar: LAStd
Desde una perspectiva organizativa, puede diseñar un patrón de nomenclatura que incluya la unidad de negocio, el departamento, la aplicación y, opcionalmente, el entorno de implementación, como DEV, UAT, PROD, etc., por ejemplo
LAStd-<*business-unit-name*>-<*department-name* or *application-name*>-<*environment-name*>
Supongamos que tiene una aplicación lógica estándar en desarrollo que implementa flujos de trabajo para el departamento de RR.HH. en la unidad de negocio de Servicios Corporativos. Puede nombrar el recurso de la aplicación lógica LAStd-CorporateServices-HR-DEV y usar la notación Pascal Case cuando sea necesario para mantener la coherencia.
Nombres de flujo de trabajo de la aplicación lógica
Un recurso de aplicación lógica de consumo siempre se asigna a un único flujo de trabajo, por lo que solo necesita un nombre. Un recurso de aplicación lógica estándar puede incluir varios flujos de trabajo, así que diseñe una convención de nomenclatura que también pueda aplicar a los flujos de trabajo miembros. Para estos flujos de trabajo, considere una convención de nomenclatura basada en el nombre del proceso, por ejemplo:
Process-<*process-name*>
Así, si tuviera un flujo de trabajo que implementa tareas de incorporación de empleados, como la creación de un registro de empleado, podría nombrar el flujo de trabajo Process-EmployeeOnboarding.
A continuación se presentan más consideraciones para el diseño de la convención de nomenclatura de su flujo de trabajo:
- Siga el patrón Primario-secundario para flujos de trabajo en las que desee resaltar alguna relación entre uno o más flujos de trabajo.
- Tenga en cuenta si un flujo de trabajo publica o consume un mensaje.
Nombres de las operaciones del flujo de trabajo
Al agregar un desencadenador o una acción a su flujo de trabajo, el diseñador asigna automáticamente el nombre genérico predeterminado para esa operación. Sin embargo, los nombres de las operaciones deben ser únicos dentro de su flujo de trabajo, por lo que el diseñador añade sufijos numéricos secuenciales en las instancias posteriores de la operación, lo que dificulta la legibilidad y el descifrado de la intención original del desarrollador.
Para que los nombres de las operaciones tengan más sentido y sean más fáciles de entender, puede agregar un breve descriptor de la tarea después del texto predeterminado y usar la notación Pascal Case para mantener la coherencia. Por ejemplo, para la acción Parse JSON, puede usar un nombre como Parse JSON-ChangeEmployeeRecord. Con este enfoque u otros similares, seguirá recordando que la acción es Parse JSON y el propósito específico de la acción Por lo tanto, si necesita usar los resultados de esta acción más tarde en acciones de flujo de trabajo posteriores, puede identificar y encontrar esos resultados más fácilmente.
Nota
Para las organizaciones que usan mucho las expresiones, considere una convención de nomenclatura que no promueva el uso de espacios en blanco (' '). El lenguaje de expresiones de Azure Logic Apps sustituye los espacios en blanco por guiones bajos ('_'), lo que puede complicar la creación. Al evitar los espacios por adelantado, ayuda a reducir la fricción al crear expresiones. En su lugar, use un guión ('-'), que facilita la lectura y no afecta a la creación de expresiones.
Para evitar posibles retrabajos posteriores y problemas en torno a las dependencias descendentes, que se crean cuando se usan salidas de operaciones, cambie el nombre de sus operaciones inmediatamente cuando las agregue a su flujo de trabajo. Normalmente, las acciones descendentes se actualizan automáticamente cuando cambia el nombre de una operación. Sin embargo, Azure Logic Apps no cambia automáticamente el nombre de las expresiones personalizadas que haya creado antes de realizar el cambio de nombre.
Nombres de conexión
Al crear una conexión en el flujo de trabajo, el recurso de conexión subyacente obtiene automáticamente un nombre genérico, como sql o office365. Al igual que los nombres de las operaciones, los nombres de las conexiones también deben ser únicos. Las conexiones subsiguientes con el mismo tipo reciben un sufijo numérico secuencial, por ejemplo, sql-1, sql-2, y así sucesivamente. Estos nombres no proporcionan ningún contexto, lo que hace que sea difícil diferenciar y asignar las conexiones a sus flujos de trabajo, especialmente para los desarrolladores que no conocen el espacio de la solución y tienen que mantener estos flujos de trabajo.
Por lo tanto, es importante que los nombres de las conexiones sean significativos y coherentes por las siguientes razones:
- Legibilidad
- Facilitar la transferencia de conocimientos y la compatibilidad
- Gobernanza
Una vez más, tener una convención de nomenclatura es fundamental, aunque el formato no es demasiado importante. Por ejemplo, puede usar el siguiente patrón como guía:
CN-<*connector-name*>-<*logic-app-or-workflow-name*>
Como ejemplo concreto, podría cambiar el nombre de una conexión de Service Bus en un flujo de trabajo de aplicación lógica OrderQueue con CN-ServiceBus-OrderQueue como nuevo nombre. Para más información, consulte la entrada de blog Turbo360 (Anteriormente Serverless360) Procedimientos recomendados, sugerencias y trucos de aplicación lógica: #11 convención de nomenclatura de conectores.
Control de excepciones con ámbitos y opciones de "Ejecutar después"
Los ámbitos proporcionan la capacidad de agrupar múltiples acciones para que pueda implementar el comportamiento Try-Catch-Finally. En el diseñador, puede contraer y expandir el contenido de un ámbito para mejorar la productividad del desarrollador.
Al implementar este patrón, también puede especificar cuándo ejecutar la acción Ámbito y las acciones que contiene, basándose en el estado de ejecución de la acción precedente, que puede ser Exitoso, Fallido, Omitido o Fuera de tiempo. Para configurar este comportamiento, use las opciones Ejecutar después (runAfter) de la acción Ámbito:
- es correcta
- ha sufrido un error
- Se omite
- Ha agotado el tiempo de espera
Consolidar servicios compartidos
Al crear soluciones de integración, considere la posibilidad de crear y usar servicios compartidos para tareas comunes. Puede hacer que su equipo cree y exponga una colección de servicios compartidos que su equipo de proyecto y otros puedan usar. Todo el mundo ganará en productividad, uniformidad y capacidad para aplicar la gobernanza a las soluciones de su organización. Las siguientes secciones describen algunas áreas en las que podría considerar la introducción de servicios compartidos:
| Servicio compartido | Motivos |
|---|---|
| Registro centralizado | Proporciona patrones comunes para que los desarrolladores instrumenten su código con el registro adecuado. A continuación, puede configurar vistas de diagnóstico que le ayuden a determinar el estado y la compatibilidad de la interfaz. |
| Seguimiento empresarial y supervisión de la actividad empresarial | Captura y expone datos para que los expertos en la materia puedan comprender mejor el estado de sus transacciones empresariales y realizar consultas analíticas de autoservicio. |
| Datos de configuración | Separa los datos de configuración de su aplicación del código para que pueda trasladar más fácilmente su aplicación de un entorno a otro. Asegúrese de proporcionar un enfoque unificado coherente y fácilmente replicable para acceder a los datos de configuración, de modo que los equipos de proyecto puedan centrarse en resolver el problema empresarial en lugar de dedicar tiempo a las configuraciones de la aplicación para su implementación. De lo contrario, si cada proyecto aborda esta separación de forma única, no podrá beneficiarse de las economías de escala. |
| Conectores personalizados | Crea conectores personalizados para sistemas internos que no tengan conectores predefinidos en Azure Logic Apps para simplificar el trabajo de tu equipo de proyecto y de otros. |
| Conjuntos de datos comunes o fuentes de distribución de datos | Exponga conjuntos de datos y fuentes comunes como API o conectores para que los equipos de proyecto los usen y evite reinventar la rueda. Todas las organizaciones tienen conjuntos de datos comunes que necesitan para integrar sistemas en un entorno empresarial. |
Pasos siguientes
Ahora ha aprendido más sobre los enfoques de migración disponibles y los procedimientos recomendados para mover cargas de trabajo de BizTalk Server a Azure Logic Apps. Para proporcionar comentarios detallados sobre esta guía, puede usar el siguiente formulario: