Bewährte Verfahren für Scripting

Mit Scripting können Sie die Geschäftslogik Maximo® Manage mithilfe von Python, JavaScript, oder einer anderen JSR223-compliant Scripting-Sprache erweitern. Der gesamte Scriptcode wird in Java™ -Bytecode kompiliert und als Teil der Maximo Manage -Laufzeitcaches zwischengespeichert. Wenn das Script gestartet wird, ist es der zwischengespeicherte Bytecode, der von der Java Virtual Machine über die JSR223 -Bridge ausgeführt wird. Da der Scriptcode in demselben Thread wie andere in Java geschriebene Maximo Manage -Geschäftslogik ausgeführt wird, kann sich ein schlecht geschriebener Scriptcode negativ auf die Leistung des Systems auswirken. Befolgen Sie die Maximo Manage -Leistungsrichtlinien, da Scripting dem angepassten Code von Maximo Manage entspricht.

Wahl des richtigen Startpunkts und der richtigen Veranstaltung

Startpunkte sind Auslöserpunkte für Scripts. Durch die Wahl des richtigen Startpunkts lassen sich bestimmte Leistungsprobleme bei der Skripterstellung oft vermeiden. In früheren Releases war beispielsweise keine Unterstützung für die Initialisierung von Attributwerten verfügbar. Dies führte dazu, dass viele Scriptentwickler das OLP-Initialisierungsereignis (Object Launch Point, Objektstartpunkt) verwenden, um die Attributwerte des Maximo-Geschäftsobjekts (MBO) zu initialisieren. Obwohl die Funktionalität nicht beeinträchtigt wurde, können Leistungsprobleme auftreten, wenn Sie viele MBOs auswählen. Das Skript für die OLP-Initialisierung wird für jedes MBO ausgeführt, das MboSet, ausgewählt ist, auch wenn das Attribut, dessen Wert durch das Skript initialisiert wird, nicht verwendet oder angezeigt wird. Sie können dieses Problem vermeiden, indem Sie den Objektstartpunkt in einen Attributstartpunkt für das Initialisierungswertereignis ändern. Der folgende Beispielscriptcode zeigt, dass thisvalue der aktuelle Initialisierungswert des Attributs ist:

if priority is not None:
   thisvalue=2*priority

Das MBO-Framework startet dieses Script nur, wenn der Code oder die Benutzerschnittstelle auf dieses Attribut verweist.

Ein weiteres Beispiel für die Auswahl eines Startpunkts ist das Überspringen von Integrationsereignissen. Häufig verwenden Entwickler das Benutzerexit-Scripting, um festzustellen, ob sie eine abgehende Integrationsnachricht überspringen müssen. Zu diesem Zeitpunkt hat das System jedoch bereits die Kosten für die Serialisierung der MBOs verursacht. Stattdessen sollten Sie die Ereignisfilter-Scripterstellung für Veröffentlichungskanäle verwenden, die aufgerufen wird, wenn das Ereignis ausgelöst wird und bevor eine Serialisierung von MBOs erfolgt. Das folgende Beispiel zeigt das Ereignisfilterscripting, das mit den MBOs funktioniert.

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

Kostenintensive Objektinitialisierungsereignisse vermeiden, wenn sie über die Registerkarte 'Liste' aufgerufen werden

Sie können kostenintensive Objektinitialisierungsscripts nur verwenden, wenn das Objekt über die Registerkarte Main und nicht über die Registerkarte List initialisiert wird. Auf der Registerkarte Main gibt es nur ein Objekt. Auf der Registerkarte Liste gibt es viele Objekte. In solchen Fällen ist der folgende Beispielcode hilfreich:

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

Achten Sie auf widersprüchliche Scripts für Startpunktereignisse

Mit dem Scripting-Framework können Sie mehrere Scripts an dasselbe Startpunktereignis anhängen. Dies stellt ein Problem dar, wenn der Script-Code erwartet, dass er in einer bestimmten Reihenfolge vor oder nach bestimmten anderen Scripts in demselben Startpunktereignis ausgeführt wird. Da das Maximo-Ereignisthema eine ungeordnete Karte ist, werden die Ereignisse ohne festen Auftrag ausgelöst. Dies kann zu Problemen führen, wenn die Bestellabhängigkeit nicht ordnungsgemäß verwaltet wird. Sie sollten den Grund für das Anhängen mehrerer Scripts für dasselbe Startpunktereignis bewerten und bewerten, ob es sinnvoller ist, sie zu einem Script zu kombinieren. Die andere Option besteht darin, sicherzustellen, dass keine Abhängigkeit zwischen den Scripts besteht.

Aufruf von 'save' in der Mitte einer Transaktion vermeiden

Dieses Codierungsmuster kann zu Problemen bei Maximo Manage -Transaktionen und Ereignisauslösung führen. Wenn eine Transaktion in Bearbeitung ist, sollte das Script im Idealfall versuchen, Teil dieser umfassenden Transaktion zu werden. Die von einem Script erstellten oder aktualisierten MBOs sind automatisch Teil der umfassenden Transaktion, solange sie vom Scriptstartpunkt MBO oder einem zugehörigen MBO erstellt wurden. Wenn Sie ein MBO mithilfe ).getMboSet(“…” erstellen, liegt es außerhalb der umfassenden Transaktion, es sei denn, Sie fügen es explizit der folgenden umfassenden Transaktion hinzu:

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

MboSet.count () mehrmals aufrufen

Ein häufiger Fehler beim Schreiben von Scripts besteht darin, die Anzahl eines MboSet mehrfach zu überprüfen. Der count () -Aufruf löst bei jedem Aufruf eine SQL aus. Ein besserer Ansatz ist, sie einmal aufzurufen, den Wert in einer Variablen zu speichern und diese Variable für nachfolgenden Codeablauf wiederzuverwenden. Das folgende Beispiel veranschaulicht diesen Ansatz.

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

Codieren Sie es nicht wie im folgenden Beispiel gezeigt.

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

MboSet schließen

Das MBO-Framework gibt immer die MboSets frei, die nach Abschluss einer Transaktion erstellt werden. Dies gilt, wenn alle MboSets als zugehörige Gruppe für das Startpunkt-MBO oder eines der zugehörigen MBOs erstellt wurden. Wenn MboSet jedoch mithilfe ).getMboSet( erstellt wird, ist der Skriptcode für das Schließen und Löschen MboSet verantwortlich. Das folgende Beispiel zeigt, wie das MboSetgelöscht wird.

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

Wenn Sie MboSets, nicht löschen, kann es zu Fehlermeldungen wegen unzureichendem Arbeitsspeicher kommen.

Vermeiden Sie das Mozilla -Kompatibilitätsscript für Nashorn.

Die Umstellung von Rhino und Java 7 auf Nashorn und Java 8 wird aus Leistungsgründen empfohlen. Nashorn funktioniert in Java 8 besser als Rhino. Die Verwendung des Mozilla -Kompatibilitätsscripts mit Nashorn kann zu einer schlechten Leistung in Java 8 führen.

Prüfen Sie vor der Protokollierung, ob die Protokollierung aktiviert ist.

Die Protokollierung erfolgt häufig im Script, ohne die Protokollebene zu überprüfen. Das folgende Beispiel zeigt, wie sich dies auf die Leistung auswirken kann:

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

Dieser Code führt leider dazu, dass mboset.count() aufgerufen wird, obwohl die Scriptprotokollierung inaktiviert ist.

Eine bessere Methode besteht darin, zu prüfen, ob das Debugging aktiviert ist, bevor mboset.count() aufgerufen wird.

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

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

Mit der folgenden Funktion in der Variablen service können Sie überprüfen, ob die Protokollierung aktiviert ist:

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

Zugriff auf Skript-Cache vermeiden

Der Zugriff auf den Skript-Cache über den Automatisierungsskriptcode führt zu einer zirkulären Abhängigkeit und verursacht Instabilität, wenn der Skript-Cache geladen wird, d. h. bei Teilladung. Wenn Sie ein Skript schreiben, verwenden Sie Bibliotheksskripte für die modulare Skriptentwicklung und vermeiden Sie so den Zugriff auf das Skript aus dem Cache.