Hace tres días eché un vistazo a las nuevas características de la versión 10.0.25 actualmente en el programa PEAP, leyendo tranquilamente hasta que vi algo sobre custom scripts en prod, algo que decía:
Run custom X++ scripts with zero downtime
Podéis imaginar mi cara cuando leí esto. Al principio estaba confundido, luego sorprendido y luego confundido de nuevo. Después de leer la descripción, la situación no mejoró:
Esta característica le permite cargar y ejecutar paquetes desplegables que contienen scripts X++ personalizados sin tener que pasar por Microsoft Dynamics Lifecycle Services (LCS) o suspender su sistema. Por lo tanto, puede corregir pequeñas inconsistencias de datos sin causar ningún tiempo de inactividad.
¿Nos acaban de dar una forma de ejecutar código en producción sin tener que desplegarlo? Sí, así es. Como mucha gente ha dicho estos dos últimos días: «¡Los jobs de X++ han vuelto!». Y hay muchas discusiones sobre la función de custom scripts.
Funcionalidad de custom scripts
Si quieres aprender a habilitarla en una VM dev y usarla, puedes leer el post del blog de Marijan Huljić‘s: AX2012 jobs are back in D365 (kind of). E incluso MFP ha hecho un video.
Yo voy a obviar eso y hacer algunos comentarios sobre su implementación y dar mi opinión.
¿Cómo funciona?
Si habéis leído la entrada del blog de Marijan, ya habréis visto que subimos un Paquete Desplegable al entorno. Entre la subida y la ejecución del código pasan varias cosas:
- Este DP se guarda en la cuenta de almacenamiento blob de Azure del entorno.
- Al probarlo o ejecutarlo, se descomprime en la ruta temporal DIXF establecida en los parámetros del DMF.
- Se eliminan todos los archivos excepto el ensamblaje DLL del paquete.
- El proceso busca una clase con esta firma exacta
public static void main(Args _args)- A continuación, utilizando Reflection de .NET, ejecutará el código contenido en el método main. El uso de Reflection no es raro en el código estándar, pero me ha sorprendido. Creo que no había otra forma de hacerlo, así que es lógico.
Y algunos hallazgos:
- No hay código desplegado en el entorno.
- Se puede subir un DP de un modelo/paquete que ya existe en prod.
- Un DP sólo puede contener una clase con un método main, así que esto dificulta lo que he dicho en el punto anterior.
- Antes de ejecutar el código hay que aprobarlo, testearlo y aprobar el test. Ve a leer la entrada del blog de Marijan si aún no lo has hecho.
- Si subes un DP con dos clases con un método main, se cancelará la subida.
- Una vez que has ejecutado un trabajo, no puede volver a ejecutarse. Pero puedes subir el mismo DP de nuevo.
¿Debemos utilizar esta función?
Tengo muchos sentimientos encontrados con respecto a la función de custom scripts. El principal atractivo de la función es que nos permite arreglar cosas bastante rápido, EN PRODUCCIÓN. Y para mí este es también el principal problema.
Entiendo que algunas empresas operan 24 horas al día, 7 días a la semana, y tener que hacer un mantenimiento no planificado en producción interrumpe el funcionamiento normal del negocio. Y para mí, este es uno de los pocos casos de uso en los que la función estaría 100% justificada.
Entonces, ¿qué respondo a la pregunta que encabeza esta sección? Sí, por supuesto, si no tienes otra alternativa.
Hay varios escenarios en los que lo utilizaríamos. Por ejemplo, los simples arreglos de datos. Pero si se trata de un simple arreglo, ¿por qué apresurarse a hacer esto? ¿No se puede esperar a hacer una actualización planificada del entorno con una corrección?
¿Y si el problema es muy urgente porque está deteniendo el negocio? Si ya está parando el negocio, ¿qué problema hay en hacer una actualización inesperada?
Hemos sobrevivido 6 años sin esta opción y os prometo que después de 2 meses trabajando con AX7 no echaba de menos el acceso a la BD o poder ejecutar código en prod como hacíamos en versiones anteriores. OK, tal vez fueron 3 meses.
¿Cómo lo utilizaría?
Si tuviera que usarlo y ejecutar código en prod, haría algo primero: desplegar el código en un entorno sandbox y ejecutarlo allí.
Por favor, por favor, por favor, si alguna vez ejecutas scripts personalizados en prod no te fíes de lo que pasa en un dev box. No confíes en su rendimiento. Evita desarrollar, probar en dev, y subirlo a producción. Esto de hecho es válido para cualquier desarrollo que hagas.
Además, haz uso de la aprobación, no entres con el usuario administrador para aprobarlo. Haz que el cliente lo testee y lo apruebe en un entorno sandbox antes de la ejecución real. Y luego haz que el cliente lo pruebe de nuevo en producción.
Y antes de hacerlo, asegúrate de que el problema que quieres resolver con esto no puede ser resuelto de ninguna otra manera: DMF, OData, Power Automate o incluso una actualización nocturna.
