Esta será la primera de una serie de publicaciones de blog que ayudarán a explicar las secuencias de comandos de automatización en Maximo. En este post explicaré qué es y por qué se añadió al producto. En futuras publicaciones, me centraré principalmente en cómo utilizarlos para cumplir distintos tipos de requisitos de personalización, pero también abordaré algunas funciones relativamente desconocidas que existen en los scripts de automatización, destacaré las ventajas y desventajas de las opciones de personalización (incluidas las opciones que no son de los scripts de automatización) y analizaré algunas de nuestras mejores prácticas a la hora de crear scripts. Tener algo de experiencia en programación será beneficioso, pero intentaré explicarte la mayor parte del código para que puedas entender por qué hago lo que hago. Y si tienes alguna pregunta, no dudes en publicarla en el foro de Maximo para que otros también puedan beneficiarse de la respuesta.

Maximo es un producto altamente configurable (consulte nuestro Soluciones página de nuestras ofertas). Con unos conocimientos técnicos mínimos, los usuarios pueden añadir nuevos campos, realizar cambios en la pantalla o restringir los valores de los atributos en Maximo. Pero una vez que empiezas a necesitar ir más allá de esas capacidades, es cuando la gente empieza a hacer preguntas sobre las personalizaciones de Java y los scripts de automatización. Y si es algo que no has hecho antes, al principio puede resultar bastante intimidante. Esperamos que esta serie de blogs ayude a eliminar la mayor parte de la intimidación y le permita alcanzar sus objetivos empresariales más rápido.

Empecemos por hablar de lo que son los scripts de automatización en Maximo. Para aquellos que no lo sepan, los scripts de automatización son códigos personalizados. Pueden ser scripts pequeños (tenemos algunos que tienen una sola línea) o scripts muy grandes (tenemos algunos que tienen casi mil líneas de código). Estas secuencias de comandos suelen escribirse en Python o JavaScript, ya que son los dos lenguajes compatibles de fábrica en Maximo, pero se puede utilizar cualquier lenguaje JSR 223 si lo configuras. Los scripts de automatización se agregaron en Maximo 7.5 (ya existía un precursor en las versiones de TI de Maximo anteriores) y se mejoraron significativamente en Maximo 7.6. IBM ha seguido mejorando los scripts de automatización en varios paquetes de funciones desde la publicación de la versión 7.6, de modo que cualquier usuario que tenga la última versión de Maximo 7.6 (actualmente 7.6.0.9) podrá utilizar algunas funciones que no existían en las versiones anteriores. Cuando esto ocurra en nuestros ejemplos, intentaré aclarar qué versión lo admitía por primera vez y, si es posible, mencionaré opciones alternativas.

Los scripts de automatización suelen estar vinculados a un evento en Maximo mediante un punto de lanzamiento. Algunas de las funciones más recientes (como las integraciones) no tienen un punto de lanzamiento real definido y, en su lugar, se invocan utilizando una estructura de nombres especial en el script. Comprender estas opciones de punto de lanzamiento es fundamental para desarrollar en Maximo (abordaremos todos los puntos de lanzamiento en detalle en esta serie de blogs). Esta flexibilidad de las opciones de eventos le permite ejecutar el código en el momento más adecuado. Esto permite que su script reciba llamadas con menos frecuencia, lo que puede mejorar considerablemente el rendimiento en Maximo para scripts más complicados.

¿Cuándo se deben usar los scripts de automatización? Una vez que aprendes el poder de los scripts de automatización, suele ser tentador utilizarlos para todas tus necesidades de personalización. Tengo la firme opinión de que los scripts solo deben utilizarse cuando el marco Maximo aún no sea compatible con lo que necesita hacer. Un ejemplo común que he visto en el que los scripts de automatización se utilizan incorrectamente es el uso de un script de automatización para cruzar un valor de un objeto a otro. Si no hay transformación, es mejor utilizar un dominio cruzado. Se activan de forma fiable (los eventos pueden suprimirse para impedir que el script se ejecute o la aplicación puede estar en modo administrador, lo que impide que se ejecuten todos los scripts) y, sinceramente, funcionan.

Otro ejemplo que veo mal utilizado es el uso de un script de automatización para requerir o hacer que los campos sean de solo lectura. Hay algunos escenarios en los que esto tiene sentido, pero en la mayoría de los casos, el uso de una restricción global de datos lo logra de una manera mucho mejor y más confiable. Como en el caso anterior, si tu script no se activa (ya sea porque el evento esté suprimido o esté en modo administrador), es posible que algo que intentas restringir o exigir en un proceso empresarial no esté configurado. Además, al intentar consolidar la mayoría de los requisitos de campo en un solo lugar, es más fácil encontrarlos e identificar dónde se requieren y en qué condiciones.

¿Cuáles son algunas de las ventajas y desventajas de los scripts de automatización en comparación con la personalización de Java? La mayor ventaja de Automation Scripting es el proceso de implementación. A diferencia de la personalización de Java, los scripts de automatización se pueden agregar, modificar o deshabilitar sin ningún tiempo de inactividad. Eso por sí solo hace que sea difícil de superar para la mayoría de las organizaciones. Las personalizaciones de Java pueden tardar horas en implementarse si están agrupadas en clústeres, lo que hace que el desarrollo y las pruebas lleven mucho más tiempo, además del impacto empresarial que supone perder el acceso a Maximo. A menudo, algunos desarrolladores me dicen que esto no es un problema porque la empresa ha programado horas de inactividad para implementar estos cambios. Pero, ¿qué ocurre cuando tu código tiene un error? Los problemas suelen identificarse durante el horario laboral y las personalizaciones de Java no se pueden desactivar ni modificar sin una interrupción.

Otra ventaja es que puedes vincular fácilmente tu script de automatización al inicio de varios eventos en Maximo. Por ejemplo, si quieres que un script se active cuando cambien los atributos del número de activos o de la ubicación, puedes hacerlo con un script de automatización y dos puntos de inicio. Puede invocar el mismo fragmento de código con las personalizaciones de Java, pero debe ampliar (o escribir) la clase de campo para cada uno de los atributos, lo que requiere mantener más código que simplemente escribir esa parte común.

Una de mis ventajas favoritas es que la utilización de scripts de automatización te permite aprovechar ambos lenguajes. Los scripts en general suelen ser más simples que el mismo código en Java. Pero lo que realmente ahorra tiempo es cuando hay una manera realmente genial de hacer algo en Jython que es más difícil o detallado en Java. Un ejemplo sencillo es comprobar si un atributo en Maximo está establecido. A veces, cuando llamas a getString («ATTRIBUTENAME»), obtienes un valor NULL y, a veces, obtienes una cadena en blanco. ¡En Java tienes que escribir ambas comprobaciones como getString («ATTRIBUTENAME»)! =null y getString («ATTRIBUTENAME»)! =». En Jython, solo puedo decir si mbo.getString («ATTRIBUTENAME») y manejará ambos escenarios. No te preocupes por el ejemplo (lo trataremos en nuestra próxima entrada de blog), me pareció que era más fácil destacar el ejemplo.

El uso de scripts de automatización para la personalización presenta algunas desventajas. La primera es que, si es algo que hay que hacer en el modo de administrador, tendrás que escribir código Java. No creemos que sea un caso de uso habitual porque la mayoría de nuestras personalizaciones están orientadas a los negocios y las transacciones comerciales no deberían realizarse durante el modo de administración por motivos distintos a los de la creación de scripts.

Otro ejemplo en el que las personalizaciones de Java son mejores es cuando se necesita anular un método para suprimir la lógica. Por ejemplo, supongamos que IBM hace algo en uno de sus archivos de clase que usted no desea que ocurra. Puedes intentar deshacer lo que hacen en ese método en un script, pero si escribes una clase de Java puedes simplemente evitar que se ejecute el código y simplemente ejecutar tu código personalizado. Una vez más, esto no es habitual para nosotros, porque si IBM está haciendo algo, probablemente debería dejarlo así o correrás el riesgo de causar otros problemas en el futuro.

Por último, hay ocasiones en las que no es posible crear un script de automatización. IBM ha agregado continuamente eventos adicionales para que los scripts de automatización los escuchen y ha mejorado su funcionalidad (como los cuadros de diálogo Sí/No/Cancelar), pero habrá ocasiones en las que necesite hacer algo que simplemente no es posible con el marco actual. Algunos mejorarán en futuras versiones (¡por ejemplo, la posibilidad de cerrar un cuadro de diálogo!) , y es posible que algunos nunca lo logren. Los scripts de automatización nunca tendrán una cobertura del 100%, pero ayudarán al administrador promedio de Maximo a lograr cosas increíbles.

‍