Procedure ottimali di script

Lo scripting consente di estendere la logica aziendale di IBM® Maximo® Manage utilizzando Python, JavaScript, o qualsiasi altro linguaggio di scripting JSR223-compliant. Tutto il codice script viene compilato in bytecode Java™ e viene memorizzato nella cache come parte delle cache di runtime Maximo Manage . Quando lo script viene avviato, è il bytecode memorizzato nella cache che viene eseguito dalla Java virtual machine utilizzando il bridge JSR223 . Poiché il codice script viene eseguito nello stesso thread di altre logiche di business Maximo Manage scritte in Java, il codice script scritto in modo non corretto può influire negativamente sulle prestazioni del sistema. Seguire le linee guida delle prestazioni di Maximo Manage perché gli script sono equivalenti al codice personalizzato Maximo Manage .

Scegliere il punto di lancio e l'evento corretto

I punti di avvio sono punti di attivazione script. Spesso, la scelta del punto di lancio corretto può aiutare a evitare alcuni problemi di prestazioni nello scripting. Ad esempio, nelle release precedenti, non era disponibile alcun supporto per l'inizializzazione del valore dell'attributo. Ciò ha portato molti sviluppatori di script a utilizzare l'evento di inizializzazione OLP (object launch point) per inizializzare i valori degli attributi MBO (Maximo business object). Anche se la funzionalità non è stata influenzata, potrebbe causare problemi di prestazioni quando si selezionano molti MBO. Lo script dell'evento di inizializzazione OLP viene eseguito per ogni MBO selezionato nell' MboSet, anche se l'attributo il cui valore viene inizializzato dallo script non viene utilizzato o visualizzato. È possibile evitare questo problema modificando il punto di avvio dell'oggetto in un punto di avvio dell'attributo per l'evento valore di inizializzazione. Il seguente codice di script di esempio mostra che thisvalue è il valore init dell'attributo corrente:
if priority is not None:
   thisvalue=2*priority

Il framework MBO avvia questo script solo quando il codice o l'interfaccia utente fanno riferimento a questo attributo.

Un altro esempio di scelta del punto di avvio è l'integrazione che ignora gli eventi. Spesso, gli sviluppatori utilizzano lo script di uscita utente per stabilire se è necessario ignorare un messaggio di integrazione in uscita. Tuttavia, a questo punto il sistema ha già sostenuto il costo della serializzazione degli MBO. Invece, è necessario utilizzare lo script del filtro eventi del canale di pubblicazione che viene richiamato quando l'evento viene attivato e prima che si verifichi la serializzazione degli MBO. Il seguente esempio mostra lo script del filtro eventi che funziona con gli MBO.
if service.getMbo().getString("status")=="APPR":
  evalresult=False
evalresult=True

Evita costosi eventi di inizializzazione degli oggetti se richiamati dalla scheda Elenco

È possibile utilizzare script di inizializzazione oggetti costosi solo quando l'oggetto viene inizializzato dalla scheda Principale e non dalla scheda Elenco . Nella scheda Principale , è presente un unico oggetto. Nella scheda Elenco sono presenti molti oggetti. In questi casi, il seguente codice di esempio è utile:
from psdi.common.context import UIContext
if UIContext.getCurrentContext() is not None and UIContext.isFromListTab()==False:
    ..costly initialization..

Attenzione agli script di eventi del punto di avvio in conflitto

Il framework di script permette di collegare più script allo stesso evento del punto di avvio. Ciò pone un problema se il codice dello script prevede di eseguirlo in un determinato ordine prima o dopo determinati altri script nello stesso evento del punto di avvio. Poiché l'argomento dell'evento Maximo è una mappa non ordinata, gli eventi vengono attivati senza un ordine fisso. Ciò può potenzialmente causare problemi se la dipendenza dell'ordine non viene gestita correttamente. È necessario valutare il motivo per allegare più script per lo stesso evento del punto di avvio e valutare se ha più senso combinarli in un unico script. L'altra opzione è assicurarsi che non vi siano dipendenze tra gli script.

Evitare di richiamare il salvataggio durante una transazione

Questo pattern di codifica può causare problemi alle transazioni Maximo Manage e all'attivazione degli eventi. Idealmente, quando una transazione è in corso, lo script deve provare a far parte di tale transazione. Gli MBO creati o aggiornati da uno script fanno automaticamente parte della transazione globale purché siano stati creati dall'MBO del punto di avvio dello script o da qualsiasi MBO correlato. Se si crea un MBO utilizzando l'API MXServer.getMXServer().getMboSet(“…”, esso si trova al di fuori della transazione di inclusione, a meno che non lo si aggiunga esplicitamente alla transazione di inclusione successiva:
mbo.getMXTransaction().add(<newly created a mboset>)

Chiamata di MboSet.count () molte volte

Un errore comune durante la scrittura degli script consiste nel verificare il conteggio di un MboSet più volte. La chiamata count () finisce per attivare un SQL ogni volta che viene richiamato. Un approccio migliore consiste nel richiamarlo una volta, memorizzare il valore in una var e riutilizzare tale var per il flusso di codice successivo. Il seguente esempio dimostra questo approccio.
cnt = mboset.count()
if cnt<=1:
  service.log(“skipping this as count is “+cnt)
Non codificarlo come mostrato nel seguente esempio.
if mboset.count()<=1:
  service.log(“skipping this as count is “+mboset.count())

Chiusura di MboSet

Il framework MBO rilascia sempre le MboSets create dopo il completamento di una transazione. Ciò si verifica se tutte le MboSets sono state create come serie correlata all'MBO del punto di avvio o ad uno qualsiasi degli MBO correlati. Tuttavia, se l' MboSet viene creato utilizzando l'API MXServer.getMXServer().getMboSet(..), il codice di script è responsabile della chiusura e della cancellazione di tale MboSet. Il seguente esempio mostra come cancellare MboSet.
try:
  ..some code..
finally:
  mboset.cleanup()

Se non si cancellano gli MboSets, possibile che si verifichino errori di esaurimento della memoria.

Evitare lo script di compatibilità Mozilla per Nashorn

Il passaggio da Rhino e Java 7 a Nashorn e Java 8 è consigliato per motivi di prestazioni. Nashorn ha prestazioni migliori in Java 8 rispetto a Rhino. L'utilizzo dello script di compatibilità Mozilla con Nashorn può causare scarse prestazioni in Java 8.

Verificare se la registrazione è abilitata prima della registrazione

La registrazione viene spesso eseguita nello script senza controllare il livello di log. Il seguente esempio mostra come ciò può influire sulle prestazioni:
service.log("count of mbos "+mboset.count())

Questo codice sfortunatamente causa la chiamata di mboset.count() anche se la registrazione script è disabilitata.

Un approccio migliore consiste nel verificare se il debug è abilitato prima di richiamare 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 seguente funzione nella variabile service consente di verificare se la registrazione è abilitata:
if service.isLoggingEnabled():
  service.log(“count of mbos “+mboset.count())

Evitare l'accesso alla cache degli script

L'accesso alla cache dello script dal codice dello script di automazione comporta una dipendenza circolare e causa instabilità quando la cache dello script viene caricata, ovvero quando il caricamento è parziale. Quando si scrive uno script, utilizzare gli script della libreria per lo sviluppo di script modulari ed evitare così di accedere allo script dalla cache.