Enfoques de migración para BizTalk Server a Azure Integration Services

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:

• ¿Por qué migrar de BizTalk Server a Azure Integration Services?
• Elija las mejores ofertas de Azure Integration Services para su caso

Opciones de estrategia

En la siguiente sección se describen varias estrategias de migración junto con sus ventajas y desventajas:

migración mediante lift-and-shift

En Azure Marketplace, puede encontrar la opción de aprovisionar máquinas virtuales que incluyen licencias de BizTalk con el modelo de pago por uso. Esta oferta proporciona la ventaja de utilizar las capacidades de infraestructura como servicio (IaaS) de Microsoft mediante un modelo de precios basado en el consumo. Aunque el uso de estas máquinas virtuales puede aliviar algunos desafíos en la administración de BizTalk Server infraestructura, este enfoque no aborda las programaciones de ciclo de vida de soporte técnico y las fechas límite de BizTalk Server.

Con las organizaciones que abrazan la transformación digital trasladándose a la nube o adoptándola, muchas tienen las tareas comunes de interrumpir su infraestructura VMware, Hyper-V o de servidor físico y migrar esta funcionalidad a IaaS en Azure. Esta opción ayuda a reducir los problemas mencionados anteriormente, pero no aborda la base de código de BizTalk.

Con BizTalk Server 2013 y versiones posteriores, puede optar por ejecutar sus servidores BizTalk en las instalaciones, como antes, o ejecutarlos en un servidor virtual en Azure. La ejecución del entorno de BizTalk Server en la nube ofrece las siguientes ventajas:

• No es necesario hardware privado ni infraestructura, por lo que no hay mantenimiento de hardware.
• Mayor disponibilidad para su infraestructura de servidores, que puede abarcar varios centros de datos o replicarse en zonas de disponibilidad.
• Acceso a sus servidores desde cualquier lugar a través de Internet.
• Microsoft realiza una copia de seguridad de las imágenes.
• Implementación rápida de nuevos servidores mediante imágenes integradas disponibles en Azure Marketplace.
• Escalado vertical rápido para los servidores cambiando los tamaños de máquina virtual para agregar memoria y CPU, agregar unidades de disco duro, etc.
• Seguridad mejorada para su entorno mediante el uso de Azure Security Center. Este servicio identifica las amenazas de seguridad y le proporciona una ruta de investigación cuando se producen incidentes de seguridad

Integración híbrida

Aunque las capacidades de BizTalk Server y Azure Integration Services pueden superponerse, funcionan mejor cuando se utilizan juntas. La mayoría de las organizaciones que no trasladan toda su infraestructura a la nube tienen principalmente los siguientes motivos:

• Directivas de empresa
• Directivas de país o región
• Directivas específicas del dominio del sector

Además, no todas las funcionalidades o aplicaciones existen en la nube, o algunas de las que están disponibles pueden no ser tan sólidas como las locales. Sin embargo, para seguir el ritmo de la revolución de la nube y ampliar las capacidades empresariales, muchas organizaciones empiezan utilizando ofertas SaaS junto con sus sistemas locales. Muchos procesos empresariales pueden beneficiarse de las estrategias de desarrollo e implementación basadas en la nube.

Al adoptar una estrategia de integración híbrida, todavía puede aprovechar las inversiones tecnológicas en los sistemas de los que depende su organización, pero seguir beneficiándose de nuevas funcionalidades, un rendimiento mejorado y una estructura de costos más baja de aplicaciones basadas en la nube, como Azure.

Con BizTalk Server 2016, la versión independiente del adaptador de Microsoft BizTalk Server para Logic Apps proporcionó la oportunidad de implementar parte de la lógica de integración como servicio en Azure mediante Azure Logic Apps para conectar cientos de servicios en la nube. Este adaptador ayudó con integraciones locales e integraciones híbridas al ofrecer las siguientes funcionalidades:

• Integre los servicios en la nube con BizTalk Server mediante adaptadores integrados, como Azure Logic Apps, Azure Service Bus, Azure Event Hubs, Azure Blob Storage y correo, programación y contactos Office 365.

• Use el conector BizTalk Server en Azure Logic Apps para conectarse desde Azure Logic Apps a BizTalk Server.

• Publique puntos de conexión BizTalk Server mediante Azure API Management para que las organizaciones puedan exponer puntos de conexión a desarrolladores internos y asociados externos.

Con BizTalk Server 2020, la instalación incluyó automáticamente el adaptador para Azure Logic Apps junto con los adaptadores integrados para conectarse fácilmente con el entorno de nube.

Big bang

Un enfoque de "big bang" o "cambio directo" 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.

Iterativo (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 Integration Services 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.

Planear la migración

En la siguiente sección se proporcionan instrucciones sobre la planeación de la migración y las áreas que se deben tener en cuenta.

Planeamiento de la preparación

La preparación representa una parte crítica del proceso de planeamiento. Cuando comprenda la amplitud y profundidad del proyecto, la previsibilidad mejora en varias dimensiones, como los costos, la complejidad, las escalas de tiempo y el éxito general del proyecto. La lista siguiente incluye áreas específicas para revisar y abordar como parte del proceso de carta del proyecto.

Área	Descripción
Tema de	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. Durante este proceso de catalogación, recopile la siguiente información para proporcionar contexto: - 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
Complejidad	Para ayudarle a conocer los niveles de complejidad de sus interfaces, examine los tipos de reglas de negocio de esas interfaces y los requisitos técnicos que necesitan personalización para satisfacer sus necesidades o requisitos de rendimiento.
Value	Evalúe el valor de las interfaces para que pueda determinar la prioridad de las interfaces que se van a volver a implementar. Aunque comenzar con interfaces de bajo riesgo puede tener sentido, después de que se sienta cómodo trabajando con Azure Integration Services, asegúrese de centrarse primero en el trabajo de mayor valor.
Costos	Establezca el ámbito del proyecto y calcule los costos porque un proyecto de migración requiere capital para iniciar la ejecución. Proteja el presupuesto del proyecto, ya sea a través del planeamiento presupuestado de capital o operativo, y administre el ámbito del proyecto a lo largo del proceso.
Dependencias de la aplicación y del sistema	Identifique y tenga en cuenta estas dependencias al iniciar el planeamiento del proyecto, por lo que puede evitar sorpresas al iniciar la ejecución del proyecto.
Registro de riesgos	Cree y use este artefacto para identificar y realizar un seguimiento de los riesgos que se exponen mientras trabaja a través de ejercicios de planeación de proyectos. Cuando conozca los riesgos, podrá mitigarlos de forma proactiva y comunicarse con el liderazgo. También puede eliminar los bloqueadores al principio cuando son menos costosos de abordar.

Herramientas de migración

La herramienta de línea de comandos Azure Integration Migrator, también llamada herramienta de migración de BizTalk, es un proyecto de código abierto de Microsoft que puede ayudarle en las fases de planificación y ejecución de su proyecto de migración junto con el traslado de aplicaciones de BizTalk Server a Azure Integration Services. También puede usar esta herramienta para descubrir información y estrategias útiles para migrar las soluciones a la nube.

Esta herramienta se ejecuta en las siguientes fases:

1. Descubra

   Extrae BizTalk Server recursos e identifica los artefactos de BizTalk que se van a migrar. Lee los ensamblados y la información del archivo de enlace.

   Requisitos: MSI para la aplicación biztalk Server y todas las aplicaciones de BizTalk Server a las que se hace referencia

2. Parse

   Lee los artefactos de BizTalk Server y compila un modelo de datos de origen para la aplicación de BizTalk Server.

3. Análisis

   Compila un modelo de datos de destino de Azure Integration Services mediante el modelo de datos de origen de la fase de análisis. Básicamente, la herramienta revisa los recursos de BizTalk Server, identifica qué elementos se pueden migrar y compila un modelo de datos del destino de Azure Integration Services. 

4. Report

   Genera un informe que describe los recursos de BizTalk Server encontrados y los elementos que se pueden migrar. El informe también contiene información detallada sobre el contenido de las aplicaciones de origen y destino junto con detalles sobre los posibles problemas con la conversión.

5. Convertir

   Genera plantillas de recursos de Azure Manager y scripts de la CLI de Azure que puede usar para compilar las aplicaciones en Azure mediante el modelo de datos de destino.

6. Verify

   Esta fase no está integrada actualmente en la herramienta, pero ejecuta los scripts de instalación para implementar la aplicación en Azure. Después, puede evaluar si la aplicación generada proporciona la misma funcionalidad que la aplicación local de BizTalk Server.

En el diagrama siguiente se muestran las fases en las que se ejecuta la herramienta Azure Integration Migrator:

Roles y aptitudes clave del equipo para una migración correcta

Para migrar correctamente los flujos de trabajo de integración de BizTalk Server a Azure Integration Services, establezca un equipo que tenga los siguientes roles y aptitudes importantes, que abarcan varias materias:

Role	Aptitudes
Administradores de proyectos	Responsable de dirigir el proyecto general y ofrecer el ámbito acordado dentro de los límites para el tiempo y el presupuesto.
Líder de Scrum	Administra activamente el trabajo pendiente y facilita la priorización de las actividades del proyecto.
Arquitectos	Asegúrese de que el proyecto se alinea con los principios de arquitectura empresarial y proporcione instrucciones sobre cómo navegar por la incertidumbre y los obstáculos.
Desarrolladores	Trabaja activamente en la migración de componentes de BizTalk Server a Azure Integration Services.
Evaluadores de control de calidad	Crea planes de prueba y ejecute pruebas con esos planes. Realiza un seguimiento, comunique y evalúa los errores y defectos como parte del planeamiento del sprint del proyecto.
Evaluadores de pruebas de aceptación de usuarios (UAT)	Proporciona a las partes interesadas del negocio la ayuda necesaria para asegurarse de que no se introducen regresiones al trasladar las interfaces de una plataforma existente a una nueva.
Especialistas en administración de cambios	Evalúa el impacto en los procesos y roles existentes. Crea un plan para ayudar a mitigar los problemas percibidos antes de que surjan.

Para ayudar a proporcionar algunos o todos los recursos descritos anteriormente, considere los asociados que tienen experiencia con la realización de migraciones. Como miembros del equipo, pueden ayudar a reducir el riesgo, mejorar el tiempo de comercialización y hacer que el proyecto sea más predecible con sus conjuntos de aptitudes y experiencia.

Planeación de procesos de compilación

Para la planificación de la compilación, Microsoft recomienda incluir sprints y elementos de trabajo para administrar los servicios básicos, como la autenticación, el registro, el control de excepciones, etc. Esta inclusión ayuda a evitar volver a trabajar más adelante en los ciclos de desarrollo causados por no abordar las necesidades subyacentes. También quiere evitar los desarrolladores bloqueados debido a decisiones que requieren que otras partes interesadas tomen.

En la lista siguiente solo se tratan algunas áreas que se deben tener en cuenta:

Área	Descripción
Authentication	Solucione las siguientes preguntas y otros sobre la autenticación antes de profundizar demasiado en los ciclos de desarrollo. - ¿Su organización cuenta con normas sobre sistemas de autenticación? - ¿Puede usar identidades administradas y entidades de servicio en Azure? - ¿Se permiten o no las claves de API y autenticación básicas? Esta actividad puede ser una buena oportunidad para incorporar a los arquitectos empresariales que pueden asegurarse de obtener acuerdos claros sobre qué esquemas de autenticación usar.
Registro	Considere la posibilidad de recopilar y almacenar telemetría en un repositorio de datos centralizado, que es un patrón popular que usan las soluciones de integración. Por ejemplo, Azure Logic Apps (estándar) puede insertar telemetría en Application Insights en Azure Monitor. Azure Logic Apps (consumo) puede insertar telemetría en Log Analytics, también en Azure Monitor. También puede incluir propiedades con seguimiento para que los desarrolladores puedan incluir más contexto a medida que los mensajes fluyan a través de la plataforma de integración. Por ejemplo, estos datos pueden incluir números de pedido de trabajo, información de pedido de compra o cualquier otra cosa que pueda ser útil, útil y relevante para su organización. Posiblemente, la solución de cada organización puede diferir en función de las necesidades de la organización. Por ejemplo, algunas organizaciones quieren tener control total sobre qué y cuándo se registran los datos. En este escenario, puede crear API o conectores personalizados y, a continuación, instrumentar el código en función de hitos específicos. Independientemente del enfoque que elija, asegúrese de que los desarrolladores comprendan claramente las expectativas para evitar futuras reelaboraciones.
Control de excepciones	Abordar el hecho de tener una estrategia y un patrón coherente al principio para controlar las excepciones y los errores con el fin de evitar futuras reelaboraciones. Asegúrese de crear claridad en torno a esta área antes de crear aplicaciones lógicas. En la lista siguiente se incluyen algunas preguntas que se deben responder al abordar el control de excepciones: - ¿Cómo se usarán los ámbitos y la configuración de "Ejecutar después" para detectar excepciones? - ¿Cómo puede usar la expresión result() para comprender mejor dónde se produce una excepción en un flujo de trabajo y encontrar más información sobre la causa subyacente? - Después de elegir cómo detectar excepciones, ¿cómo desea registrar estos datos y comunicarse con las partes interesadas? Asegúrese de que estas decisiones concuerdan con su estrategia de registro, tal y como se ha mencionado anteriormente. Lo ideal es que haya establecido un proceso que busque activamente nuevos eventos de error en el almacén de datos de registro. Desde allí, puede responder a estos eventos y organizar un proceso de excepción. Es posible que tenga que filtrar o agregar eventos de error duplicados, registrar un vale en la solución de administración de servicios de TI de su organización y elegir cómo enviar notificaciones. Las notificaciones pueden tener diferentes rutas, en función de la gravedad del problema y de la hora del día. Para lograr agilidad, cree un flujo de trabajo para administrar este proceso.
Análisis	Para demostrar la salud y la higiene generales de la solución a las partes interesadas, tenga en cuenta las diferentes lentes que usan las partes interesadas para examinar, por ejemplo: - Los ejecutivos pueden estar más interesados en el estado general, los recuentos de transacciones o el volumen, y el valor empresarial que generan esas transacciones, pero no los matices técnicos generales. - Un administrador de primera línea podría estar más interesado en el estado general, pero también en los detalles técnicos, como las características de rendimiento, para asegurarse de que se cumplen los acuerdos de nivel de servicio. - Es probable que los analistas de soporte técnico estén interesados en el estado general del servicio, las excepciones y los cuellos de botella de rendimiento. Mientras reúne la estrategia de análisis, tenga en cuenta las partes interesadas y el tipo de datos que les interesen. Este proceso de pensamiento le ayuda a asegurarse de realizar un seguimiento de información útil y hacer que los datos sean accesibles para fines de informes. Si encuentra brechas de cobertura, es posible que tenga que volver a visitar los elementos de trabajo relacionados con el registro y agregar las tareas adecuadas para solucionar estas brechas.
Cadencia	Al enviar los proyectos de integración y aprender de esas experiencias, asegúrese de capturar las lecciones que inevitablemente surgen. Planee sprints de corrección o ciclos al principio del viaje para que pueda corregir el curso antes de que el costo sea demasiado grande. De este modo, puede evitar introducir demasiada deuda técnica en su nueva plataforma.

Plan de la implementación

Cuando prevé y prepara un plan de implementación, aumenta las oportunidades de una implementación correcta. Con BizTalk Server, después de crear toda la infraestructura y los entornos, ha cambiado el foco a la implementación de soluciones.

Con Azure, esta experiencia difiere con algunas actividades que se deben tener en cuenta en primer lugar, como abordar la implementación de la infraestructura entre distintos entornos, que pueden incluir diferentes suscripciones de Azure, grupos de recursos de Azure o alguna combinación, por ejemplo:

• Azure Key Vault: secretos y directivas de acceso
• Azure Service Bus: colas, temas, suscripciones, filtros y directivas de acceso
• Azure App Service: planes, redes y autenticación

A continuación, puede centrarse posteriormente en la implementación de soluciones entre distintos entornos.

Planeamiento de pruebas

Para asegurarse de que las partes interesadas estén satisfechos con la solución que proporciona, es importante tener en cuenta las pruebas para cualquier proyecto de migración. Una nueva solución debe proporcionar más valor en comparación con la solución anterior, sin regresiones que puedan afectar al negocio.

Tenga en cuenta las siguientes recomendaciones de pruebas para su proyecto de migración:

• Establezca su línea de base respondiendo a las siguientes preguntas:

  1. ¿Dispone de pruebas?
  2. ¿Se ejecutan las pruebas sin errores?
  3. ¿Son precisos los resultados de las pruebas?

  Para tener confianza en que el equipo no ha introducido regresiones, necesita la capacidad de comparar los resultados de la nueva plataforma con pruebas confiables de la plataforma existente. Por tanto, si no tiene una línea de base, asegúrese de establecerla.

  Naturalmente, no querrás gastar muchos recursos estableciendo pruebas contra una plataforma que se retira, pero necesitas responder a la pregunta: "¿Cómo sé que todo funciona correctamente?". Si se encuentra en esta situación, empiece a establecer su línea de base en función de las prioridades y cree un plan para mitigar las áreas en las que tenga carencias.

• Configure la estrategia de prueba para la nueva plataforma.

  Suponiendo que esté familiarizado con su línea base, ahora puede pensar en cómo probar en su nueva plataforma. Si tiene problemas para establecer la línea base, aproveche la oportunidad de configurar una base sólida para su nueva plataforma.

  Cuando piense en probar la nueva plataforma, tenga en cuenta la automatización. Aunque tener una plataforma le permite crear rápidamente interfaces, confiar en pruebas manuales reduce esas ganancias de productividad.

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

Go Live

Una vez que el equipo finalice las pruebas, piense en las tareas necesarias para poner la nueva plataforma de integración en producción:

1. Crear un plan de comunicación.

   Aunque puede que cuente con un pequeño equipo para implementar los aspectos técnicos y los detalles de un proyecto de modernización de una plataforma de integración, es probable que tenga muchas partes interesadas a las que debe mantener informadas sobre el proyecto de migración. Si no tiene una estrategia de comunicación clara, creará ansiedad entre los demás implicados. Además, tenga en cuenta las partes interesadas externas que debe incluir en su plan de comunicación. Por ejemplo, es posible que quiera incluir otros socios comerciales o clientes que puedan verse afectados por los próximos eventos. No se olvide tampoco de estas partes interesadas.

   Por tanto, comuníquelo pronto y con frecuencia aportando claridad en las áreas que afecten a las partes interesadas, por ejemplo, qué espera de ellos, cuándo se les necesita, durante cuánto tiempo, etc. Al proporcionar un plan conciso y claro, crea confianza para las partes interesadas y mantiene la energía positiva en torno a su proyecto. Elimine cualquier duda asegurándose de que su equipo está preparado para la ejecución. De lo contrario, corre el riesgo de arruinar la moral debido a percepciones, especulaciones y rumores de que su proyecto podría fracasar.

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

     Identifique las acciones que puede o debe realizar con antelación, para no dejarlo todo para el día del cambio. Por lo general, la transición a una nueva plataforma de integración suele implicar una implementación de "campo verde", por lo que puede preparar muchos componentes y configuraciones al principio del ciclo. Cuanto más pueda completar antes de la ventana de mantenimiento de su plataforma original, más problemas podrá eliminar y mejorar el resultado general de su evento de transición.

   • Ensayo general

     Las partes interesadas suelen desear cierta previsibilidad en torno a los próximos acontecimientos. Entonces, ¿cómo proporcionar previsibilidad en torno a algo que nunca se ha hecho antes? Con un ensayo general que implemente su plataforma de integración en un entorno de preproducción, puede validar su plan de transición y los plazos previstos para cada paso del proceso.

     De lo contrario, subestimar el tiempo que puede llevar un paso puede provocar un efecto dominó de retrasos. En conjunto, estos retrasos pueden costar una cantidad significativa de tiempo e interrumpir la empresa. Si realiza un ensayo general, podrá basar su planificación en datos reales. Es posible que el equipo también encuentre problemas que habrían causado problemas durante el período de vida en producción. Cuando el equipo detecta y documenta los problemas con antelación, está mejor preparado y se arriesga a tener menos sorpresas durante el evento real de transición.

   • Personas

     Asegúrese de que exista una responsabilidad clara en torno a qué persona posee cada paso concreto del plan. Como estrategia de mitigación inteligente, identifique y prepare personas de apoyo en caso de que la persona principal no esté disponible para realizar la tarea, debido a circunstancias inesperadas.

   • Estimaciones del programa

     Después de ejecutar un ensayo, el equipo debe comprender mejor cuánto tiempo puede tardar cada tarea en completarse. Puede usar estas estimaciones para prever un calendario, de modo que las personas sepan cuándo las necesita y aproximadamente de cuánto tiempo disponen para terminar su tarea.

   • Deshabilitar interfaces en la plataforma antigua

     Siempre que entienda todas las dependencias existentes, puede empezar a desactivar interfaces en su antigua plataforma de integración antes de activar interfaces en la nueva plataforma. Algunas arquitecturas complejas pueden requerir que deshabilites interfaces secuenciales en un orden específico para evitar sorpresas. En función de la naturaleza de la interfaz, es posible que no pueda desactivar todas las interfaces de la plataforma de integración antigua. Por ejemplo, si tiene un sistema de línea de negocio que envía mensajes a su plataforma de integración, asegúrese de tener en cuenta estas situaciones en su plan de transición.

   • Habilitación de interfaces en la nueva plataforma

     De forma similar a cómo puede tener interfaces secuenciales que requieren que deshabilite en un orden específico, es posible que tenga nuevas interfaces secuenciales para habilitar con el mismo requisito. Antes de empezar a habilitar interfaces, asegúrese de que comprende todas las dependencias y de que ha identificado el orden necesario para habilitar las nuevas interfaces secuenciales.

     Nota

     Tenga cuidado de ejecutar los pasos para habilitar las interfaces de una manera metódica y sistemática para evitar errores que arriesgan el éxito del proyecto.

   • Pruebas de validación

     Esta actividad es muy importante, por lo que debe incluir este trabajo en el plan de transición. Una vez habilitadas las interfaces, confirme que funcionan según lo previsto antes de pasar a la fase "Go o No-go". Lo ideal es realizar pruebas de validación que no afecten a los datos principales de la empresa. Esta guía proporciona más información sobre las pruebas de validación para sus nuevas interfaces en una sección posterior.

3. Determinar un plan de reversión.

   Afortunadamente, ahora dispone de un enfoque estructurado y detallado para implantar su nueva plataforma de integración. Sin embargo, pueden surgir sorpresas, así que determine los pasos necesarios para volver a la plataforma de integración anterior. De este modo, tendrá un plan preparado por si acaso.

   Cuando piense en estos pasos, tenga en cuenta los eventos que podrían desencadenar una reversión. Además, alinee su plan con las personas que necesita para tomar la decisión de revertir. Esta guía ofrece más información en la sección sobre la toma de decisiones "Go o No-go".

4. Ejecutar pruebas de validación.

   El plan de transición debe haber incluido los detalles de este trabajo. Una vez habilitadas las interfaces, confirme que funcionan según lo previsto antes de pasar a la fase "Go o No-go". Lo ideal es realizar pruebas de validación que no afecten a los datos principales de la empresa.

   Lo ideal, por ejemplo, es que sus pruebas de validación puedan leer datos de un sistema de línea de negocio de producción, pero no puedan escribir datos, lo que crea un problema de cumplimiento. De lo contrario, tendrá que esperar a que una transacción comercial fluya a través de sus interfaces y validar que todo funciona como su equipo espera.

5. Planificar las operaciones o el apoyo a la producción.

   Aunque el trabajo de migración de interfaces entre plataformas suele consumir la mayor parte de los recursos del proyecto, hay que tener en cuenta el soporte continuo para las interfaces y la nueva plataforma.

   • Asegúrese de compartir la cantidad y el nivel de conocimientos adecuados entre el equipo del proyecto y el de operaciones.

   • Cree y mantenga al día una lista de contactos que contenga datos de contacto tanto técnicos como empresariales para que cualquiera pueda ponerse en contacto con los miembros del equipo adecuados cuando sea necesario.

   • Para que la respuesta de asistencia a los clientes sea más fluida y puntual, tenga listos los procesos y la documentación de asistencia antes de la puesta en marcha. Puede ayudar a reducir el estrés de los clientes, el equipo de asistencia y el equipo del proyecto si evita que un miembro del equipo de asistencia tenga que resolverlo todo cuando se produzca un incidente.

6. Elegir "Go o No-go" para pasar a producción.

   En este paso, trabaje con las partes interesadas competentes para decidir si el proyecto puede pasar a producción. Por ejemplo, las partes interesadas pueden ser la dirección, la gestión del proyecto, las operaciones y los representantes de la empresa.

7. Celebre el éxito de su equipo.

   ¡Enhorabuena! Después de terminar un proyecto que tiene un impacto positivo en su organización o empresa, ha llegado el momento de reconocer a su equipo por todo su duro trabajo y celebrar un logro increíble. Asegúrese de reconocer el mérito de su equipo de forma adecuada y significativa. La falta de reconocimiento es una forma segura de destruir la moral.

8. Hacer una retrospectiva.

   Como en cualquier actividad de ingeniería, su equipo adquiere una valiosa perspectiva y amplía sus conocimientos aprendiendo de la experiencia. Reúnase con su equipo para discutir y captar las áreas que han ido bien, las que no han ido bien y las que pueden mejorar. Procure mantener esta conversación en un entorno no amenazador y de apoyo, y céntrese en el objetivo de aprender y crecer, no en el de culpar. Comparta las lecciones aprendidas con los directivos y otras partes interesadas. Este ejercicio genera confianza en todo el equipo y representa la madurez de la ingeniería.

Procedimientos recomendados para la migración

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 aplicaciones lógicas 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 tienen contexto y dificultan enormemente la diferenciación y asignación de conexiones a sus aplicaciones lógicas, sobre todo para los desarrolladores que no están familiarizados con este espacio y tienen que encargarse del mantenimiento de esas aplicaciones lógicas.

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 una aplicación lógica OrderQueue o un flujo de trabajo 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. La funcionalidad de la acción Ámbito es similar al concepto de región en Visual Studio. 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.

Revisar, reflexionar y aprender

De vez en cuando, valore y evalúe sus aplicaciones lógicas existentes, especialmente cuando fallen. No solo analice el proceso de negocio para encontrar qué y dónde puede mejorar, sino también analice el historial de ejecución de su flujo de trabajo para aprender de los fallos, errores y equivocaciones que se hayan producido. Azure Logic Apps proporciona un historial de ejecución tan rico, que tiene una alta probabilidad de descubrir cosas nuevas acerca de su aplicación a medida que revisa el historial de ejecución de su flujo de trabajo. Como todo desarrollo de código, pueden surgir algunos casos extremos o de esquina. A medida que los descubra, actualice sus interfaces para tener en cuenta estas situaciones y mejorar la fiabilidad general de sus soluciones.

Una realidad para los equipos de proyecto es que los desarrolladores intentan capturar genéricamente los errores para, al menos, protegerse un poco de los problemas. A medida que el equipo descubre y comprende mejor dónde pueden fallar las cosas, puede ser más prescriptivo sobre cómo protegerse de los problemas.

Al igual que las organizaciones realizan regularmente ejercicios de "equipo rojo", como pruebas de penetración o intentos de suplantación de identidad, la seguridad no es una actividad de "fijar y olvidar". A medida que aparezcan nuevos esquemas y enfoques de autenticación, revise periódicamente sus interfaces, revise sus medidas de seguridad e incorpore los nuevos desarrollos pertinentes y apropiados que proporcionen los enfoques más seguros.

DevOps es otra área que debe evaluar periódicamente. A medida que Microsoft o la comunidad introduce nuevas plantillas o enfoques, evalúe estas actualizaciones para determinar si puede obtener más ventajas.

Pasos siguientes

Ahora ha aprendido más sobre los enfoques de migración disponibles, las consideraciones de planificación y los procedimientos recomendados para mover cargas de trabajo de BizTalk Server a Azure Integration Services. Para proporcionar comentarios detallados sobre esta guía, puede usar el siguiente formulario:

Envíe comentarios sobre la guía de migración para BizTalk Server a Azure Integration Services