Thumbnail image

Pruebas de carga en Azure con Dynamics 365 Finance and Operations

!
Atención: Este artículo se publicó hace más de 365 días. La información podría estar desactualizada.
Advertencia
Este artículo ha sido traducido automáticamente con Copilot y todavía está pendiente de revisión manual. Ante cualquier error por favor revise el original el inglés cambiando el idioma en la parte superior-derecha

Hace un par de meses, Microsoft Azure Load Testing (MALT) se lanzó como servicio totalmente gestionado y ya está generalmente disponible. Este servicio permite generar cargas a gran escala contra nuestras aplicaciones. Azure Load Testing ofrece múltiples capacidades que pueden aprovecharse para automatizar las pruebas de carga en implementaciones de aplicaciones empresariales y en fases de hyper‑care, y también para complementar otras estrategias de pruebas como la automatización funcional con RSAT:

  • Generar carga a gran escala de forma rápida y sencilla.
  • Identificar cuellos de botella con insights accionables.
  • Integrar las pruebas de carga en tus workflows de DevOps.
  • Usar un servicio de pruebas completamente gestionado en Azure.
  • Seguridad y cumplimiento integrados.
  • Mantener costes bajos pagando solo por lo que usas.

Crear una prueba de carga simple con MALT es sencillo, como explica el Quickstart: Create and run a load test with Azure Load Testing, pero eso solo generará carga contra la página de inicio, lo cual no basta para estresar correctamente una aplicación Dynamics.

Para hacerlo bien, debemos crear peticiones personalizadas que aprovechen componentes diversos de Dynamics como el framework de batch, endpoints OData, servicios web estándar o personalizados, etc. Esto se consigue ejecutando un script JMeter existente en Azure Load Testing. A continuación indico cómo:

Crear un script de carga personalizado para aplicaciones Finance and Operations

  • JMeter organiza sus componentes en una estructura de árbol similar a cómo Dynamics AX/F&O organiza el AOT. Principalmente crearemos Thread Groups, y dentro de estos grupos añadiremos las acciones necesarias (hay muchas acciones incluidas y se pueden extender con plugins). Cuando se ejecuta el script, cada Thread Group crea un número configurable de hilos que aumentarán la carga según lo deseado. Este diseño puede entenderse como diagramas de flujo (por ejemplo en Logic Apps), pero sin el diseño visual.

  • En este ejemplo muy simple crearé 3 Thread Groups. El primero envía una petición al servidor de login OAuth para obtener un token de autenticación; los otros dos Thread Groups harán acciones GET y POST contra endpoints OData, reutilizando el mismo token. El árbol se vería así:

  • Como el script de carga necesitará parámetros externos, como la URL del entorno, credenciales y secretos, podemos crear variables en el script JMeter para recibir esos parámetros. La función GetSecret se integra con Azure Load Testing, por lo que podremos pasar esos valores desde un Azure Key Vault en un paso posterior.
  • Usaremos esas variables más adelante, por ejemplo al usar la URL del entorno y el Tenant Id para solicitar un token OAuth:
  • Este token se extrae con un JSON Extractor y se persiste como variable de sesión mediante un BeanShell PostProcessor, de modo que pueda usarse en pasos posteriores fuera de ese Thread Group.

  • A continuación se configura un HTTP Header Manager para especificar los headers adecuados para OAuth, incluyendo la variable que contiene el access token:

  • Finalmente, podemos usar una acción HTTP Request para enviar un GET a un endpoint OData y seleccionar, por ejemplo, la información de un cliente concreto:
  • Observa cómo podemos parametrizar la petición de forma configurable, aprovechar variables externas o incluso leer datos desde CSV de forma nativa en JMeter. ¡Esto lo dejamos para la siguiente entrada! :)

  • De forma similar, podemos crear un pool de hilos para enviar datos a Finance and Operations mediante POST a endpoints OData. Podemos enviar JSON directamente o usar las versiones con parámetros, y también leer datos desde un archivo externo.

  • El script puede probarse localmente en JMeter pulsando Run, y usando los nodos View Results Tree para depurar las peticiones y respuestas del servidor.

  • Cuando el script esté listo, guarda el plan de prueba como un fichero JMX (File → Save). Cargaremos este fichero en Azure Load Testing para ejecutarlo a escala.

Cargar un JMX personalizado en Azure Load Testing

  • Primero, crea un recurso de Azure Load Testing en tu suscripción Azure.
  • Navega a tu recurso y usa Upload a JMeter script y luego Create.
  • En el primer paso asigna un nombre al test y pulsa Next.
  • A continuación selecciona y sube tu fichero JMX y pulsa Next.
  • En el paso (Load) puedes especificar cuántas instancias Engine se ejecutarán. Esto es importante: ese número se combina con el número de hilos de tus Thread Groups para determinar el total de hilos durante la ejecución (se multiplican). Más info: Configure Azure Load Testing for high-scale load tests - Azure Load Testing | Microsoft Learn

  • En el último paso (Test Criteria) puedes fijar umbrales mínimos que determinarán si el test se marca como “failed” si no se cumplen. Esto requiere tuning y depende del caso y de la potencia del entorno que pruebes.

¡Y ya está! Guarda y lanza la prueba, y disfruta de los resultados:

¡Esto es solo el comienzo!

  • Este test queda configurado en tu instancia de Azure Load Test y puede ejecutarse manualmente o como parte de tus pipelines de DevOps.
  • Actualmente el ejemplo genera datos aleatorios, pero JMeter puede usar CSVs como fuente de datos para generar pruebas más significativas y relacionadas.
  • Puedes aprovechar tus servicios web existentes (custom o estándar) para generar distintos tipos de carga según necesites.
  • Azure Load Testing también puede conectar con distintas aplicaciones, por lo que es útil para orquestar integraciones complejas que involucren terceros.
  • Azure Load Testing puede integrar datos desde Azure Insights, de modo que los resultados de test se enriquezcan con telemetría de componentes Azure.
  • ¡Es un producto relativamente nuevo! ¿Tienes ideas interesantes? Ayuda al equipo creando o votando ideas!

Publicado originalmente en “Dynamics F&O in the Field”, el blog del equipo Customer Success — Cloud Solution Architecture en Microsoft.

Publicaciones similares