Procedimientos recomendados de creación de scripts

Las secuencias de comandos le permiten ampliar la lógica empresarial IBM® Maximo® Manage mediante Python, JavaScript, o cualquier otro lenguaje de secuencias de comandos JSR223-compliant. Todo el código de script se compila en el código de bytes Java™ y se almacena en la memoria caché como parte de las memorias caché de tiempo de ejecución de Maximo Manage . Cuando se inicia el script, es el código de bytes almacenado en memoria caché que ejecuta la máquina virtual Java utilizando el puente JSR223 . Puesto que el código de script se ejecuta en la misma hebra que otra lógica empresarial de Maximo Manage escrita en Java, el código de script mal escrito puede afectar negativamente al rendimiento del sistema. Siga las directrices de rendimiento de Maximo Manage porque los scripts son equivalentes al código personalizado Maximo Manage .

Elegir el punto de lanzamiento y el acontecimiento correctos

Los puntos de ejecución son puntos desencadenantes de script. A menudo, elegir el punto de lanzamiento correcto puede ayudar a evitar ciertos problemas de rendimiento en el scripting. Por ejemplo, en releases anteriores, no había soporte disponible para la inicialización del valor de atributo. Esto ha llevado a muchos desarrolladores de scripts a utilizar el suceso de inicialización de punto de ejecución de objeto (OLP) para inicializar los valores de atributo de objeto de negocio (MBO) de Maximo. Aunque la funcionalidad no se ha visto afectada, puede provocar problemas de rendimiento al seleccionar muchos MBO. El script del evento de inicialización OLP es ejecutado para cada MBO que es seleccionado en el MboSet, aunque el atributo cuyo valor está siendo inicializado por el script no sea usado o mostrado. Puede evitar este problema cambiando el punto de ejecución de objeto por un punto de ejecución de atributo para el suceso de valor de inicialización. El siguiente código de script de ejemplo muestra que thisvalue es el valor de inicialización de atributo actual:

if priority is not None:
   thisvalue=2*priority

La infraestructura MBO sólo inicia este script cuando el código o la interfaz de usuario hacen referencia a este atributo.

Otro ejemplo de la opción de punto de ejecución son los sucesos de omisión de integración. A menudo, los desarrolladores utilizan los scripts de salida de usuario para determinar si necesitan omitir un mensaje de integración de salida. Sin embargo, en este punto el sistema ya ha incurrido en el coste de serializar los MBO. En su lugar, debe utilizar el script de filtro de sucesos de canal de publicación que se invoca cuando se desencadena el suceso y antes de que se produzca una serialización de los MBO. El ejemplo siguiente muestra los scripts de filtro de sucesos que funcionan con los MBO.

if service.getMbo().getString("status")=="APPR":
  evalresult=False
evalresult=True

Evitar sucesos de inicialización de objetos costosos si se invocan desde la ficha Lista

Es posible que desee utilizar scripts de inicialización de objetos costosos sólo cuando el objeto se inicializa desde la pestaña Principal y no desde la pestaña Lista . En la pestaña Principal , sólo hay un objeto. En la pestaña Lista , hay muchos objetos. En estos casos, el siguiente código de ejemplo es útil:

from psdi.common.context import UIContext
if UIContext.getCurrentContext() is not None and UIContext.isFromListTab()==False:
    ..costly initialization..

Tenga cuidado con los scripts de sucesos de punto de ejecución en conflicto

La infraestructura de scripts le permite adjuntar varios scripts al mismo suceso de punto de ejecución. Esto plantea un problema si el código de script espera ejecutarlo en un orden determinado antes o después de otros scripts en el mismo suceso de punto de ejecución. Puesto que el tema de suceso de Maximo es un mapa no ordenado, los sucesos se desencadenan sin una orden fija. Esto puede provocar problemas si la dependencia de orden no se gestiona correctamente. Debe evaluar la razón para adjuntar varios scripts para el mismo suceso de punto de ejecución y evaluar si tiene más sentido combinarlos en un script. La otra opción es asegurarse de que no haya ninguna dependencia entre los scripts.

Evitar llamar a guardar en medio de una transacción

Este patrón de codificación puede causar problemas en la activación de transacciones y eventos de Maximo Manage . Idealmente, cuando una transacción está en curso, el script debe intentar formar parte de esa transacción que lo engloba. Los MBO creados o actualizados por un script son automáticamente parte de la transacción global siempre que se hayan creado a partir del MBO de punto de ejecución de script o de cualquier MBO relacionado. Si crea una MBO utilizando la API MXServer.getMXServer().getMboSet(“…”, quedaría fuera de la transacción englobante a menos que la añada explícitamente a la siguiente transacción englobante:

mbo.getMXTransaction().add(<newly created a mboset>)

Llamando a MboSet.count () muchas veces

Un error común al escribir scripts es comprobar el recuento de un MboSet varias veces. La llamada count () termina activando un SQL cada vez que se llama. Un mejor enfoque es invocarlo una vez, almacenar el valor en una variable y reutilizar esa variable para el flujo de código posterior. El ejemplo siguiente muestra este enfoque.

cnt = mboset.count()
if cnt<=1:
  service.log(“skipping this as count is “+cnt)

No lo codifique como se muestra en el ejemplo siguiente.

if mboset.count()<=1:
  service.log(“skipping this as count is “+mboset.count())

Cierre del MboSet

La infraestructura MBO siempre libera los MboSets que se crean una vez completada una transacción. Esto es cierto si todos los MboSets se han creado como un conjunto relacionado con el MBO de punto de ejecución o cualquiera de sus MBO relacionados. Sin embargo, si el MboSet se crea utilizando la API MXServer.getMXServer().getMboSet(..), el código del script es responsable de cerrar y borrar ese MboSet. El ejemplo siguiente muestra cómo borrar el MboSet.

try:
  ..some code..
finally:
  mboset.cleanup()

Si no borra los MboSets, pueden producirse errores de memoria insuficiente.

Evitar el script de compatibilidad de Mozilla para Nashorn

Se recomienda pasar de Rhino y Java 7 a Nashorn y Java 8 por razones de rendimiento. Nashorn funciona mejor en Java 8 que Rhino. El uso del script de compatibilidad de Mozilla con Nashorn puede dar como resultado un bajo rendimiento en Java 8.

Comprobar si el registro está habilitado antes del registro

El registro a menudo se realiza dentro del script sin comprobar el nivel de registro. El ejemplo siguiente muestra cómo esto puede afectar al rendimiento:

service.log("count of mbos "+mboset.count())

Lamentablemente, este código hace que se llame a mboset.count() aunque el registro de script esté inhabilitado.

Un método mejor es comprobar si la depuración está habilitada antes de llamar a mboset.count().

from psdi.util.logging import MXLoggerFactory
logger = MXLoggerFactory.getLogger("maximo.script");
debugEnabled = logger.isDebugEnabled()

if debugEnabled:
  service.log("count of mbos "+mboset.count())

La siguiente función de la variable service le permite comprobar si el registro está habilitado:

if service.isLoggingEnabled():
  service.log(“count of mbos “+mboset.count())

Evitar el acceso a la caché de scripts

Acceder a la caché de scripts desde el código del script de automatización da lugar a una dependencia circular y provoca inestabilidad cuando se carga la caché de scripts, es decir, carga parcial. Cuando escriba un script, utilice los scripts de la biblioteca para el desarrollo de scripts modulares y evite así acceder al script desde la caché.