Maximo kann Geschäftslogik auf viele Arten durchsetzen. Jeder Ansatz hat einige Vorteile und erfordert unterschiedliche technische Fähigkeiten, die umgesetzt werden müssen. Die Anforderung eines Felds auf dem Bildschirm kann auf verschiedene Arten angegangen werden.

Der erste Ansatz zur Erstellung von Pflichtfeldern in Maximo besteht darin, ein Feld über den Anwendungsdesigner auf „erforderlich“ zu setzen. Dies ist eine einfache Möglichkeit, ein bestimmtes Feld in einer einzigen Anwendung zu 100% als erforderlich zu kennzeichnen. Dies ist eine hervorragende Option für Benutzer, die in Maximo nur mit einer einzigen Anwendung interagieren und für die das Feld immer erforderlich ist. Der zweite Ansatz ist hilfreich, wenn ein Benutzer dem Feld „erforderlich“ eine bedingte Logik hinzufügen möchte. Dies kann mithilfe von Datenbeschränkungen erreicht werden. Diese Datenbeschränkungen können auf Sicherheitsgruppen- oder globaler Ebene implementiert werden. Ich finde, dass globale Datenbeschränkungen die meiste Zeit gut funktionieren. Dieser Ansatz ist komplexer als die Änderung am Anwendungsdesigner, da Sie eine WHERE-Klausel schreiben müssen. Dies ist eine unverzichtbare Lösung in meiner Werkzeugtasche, da sie so vielseitig sind.

Beide Ansätze sind großartig, da sie ein Feld in der Anwendung sichtbar als „erforderlich“ anzeigen können. Diese Ansätze sind in der Anwendung effizient und dennoch einfach zu implementieren und zu unterstützen. Ein Nachteil besteht darin, dass, wenn der Status eines Arbeitsauftrags geändert wird, ein Feld, das im vorherigen Status nicht erforderlich war, im neuen aktualisierten Status erforderlich werden kann. Beispiel: Ein Arbeitsauftrag im WAPR-Status wird in den APPR-Status verschoben, und ein Feld, das im WAPPR-Status nicht erforderlich war, ist im APPR-Status erforderlich. Wenn der Benutzer den Status ändert, erhält er eine allgemeine Fehlermeldung, dass ein Feld erforderlich ist. Der andere Nachteil ist, dass bedingte Logik nur so gut sein kann wie die Fähigkeiten des Implementierers beim Schreiben einer WHERE-Klausel.

Automatisierungsskripte zeichnen sich dadurch aus, dass sie komplexe Logik mit klaren Botschaften liefern. Das Hinzufügen einer benutzerdefinierten Geschäftslogik zur Statusänderung eines Datensatzes ist ein großartiger Anwendungsfall für Automatisierungsskripte. Ich habe diesen Ansatz bei der Statusänderung von Anlagen, Arbeitsaufträgen, Serviceanfragen, Bestellungen und Konfigurationselementen verwendet. Ich habe festgestellt, dass Automatisierungsskripte es mir ermöglichen, zielgerichtete Nachrichten mit einer Logik zu übermitteln, die so komplex wie nötig sein kann. Ich werde einige gängige Beispiele nennen.

Startpunkt

Durch die Verwendung eines attributbasierten Startpunkts kann die Logik jedes Mal ausgelöst werden, wenn sich der Status ändert. Im folgenden Beispiel implementiere ich eine Validierung eines Asset-Änderungsstatus. Wenn Sie die Validierung häufiger ausführen möchten, können Sie einen Startpunkt zum Speichern von Objekten verwenden.

Fehlermeldung

Durch die Kopplung des Automatisierungsskripts mit einer Maximo-Message können dem Benutzer spezifische und flexible Nachrichten gegeben werden. Für jedes Automatisierungsskript, das ich implementiere, möchte ich eine entsprechende Nachricht mit einem Parameter haben, an den ich eine Nachricht weitergeben kann. Diese Nachricht wird in der Datenbankkonfiguration im Nachrichtendialog konfiguriert. Der „{0}“ wird der Parameter sein, den wir mit einer benutzerdefinierten Nachricht übergeben.

Sobald Sie eine Meldung im Automatisierungsskript haben, können Sie mithilfe der Nachricht einen Fehler aufrufen. Beachten Sie, dass die ersten beiden Parameter die zu verwendende Nachricht angeben. Der dritte Parameter ist ein Array, das an die Nachricht übergeben wird. Wenn es aufgerufen wird, ersetzt das „{0}“ in der Nachricht die erste Zeichenfolge im Array. Das Hinzufügen eines „{1}“ zu Ihrer Nachricht würde dem zweiten Wert im Array zugeordnet werden.

service.error („emx“, „assetStatusValidation“, [„Adressen sind erforderlich, um in den ACTIVE-Status zu wechseln.“])

Beispiele:

Erforderliche Adresse, wenn der Status auf AKTIV geändert wurde

wenn mbo.getString („STATUS“) =="ACTIVE“ und mbo.isNull („emxAddress“):

service.error („emx“, „assetStatusValidation“, [„Adressen sind erforderlich, um in den ACTIVE-Status zu wechseln.“])

Wert für alle Anlagenspezifikationen erforderlich, wenn der Status in OPERATING geändert wurde

wenn mbo.getString („STATUS“) =="OPERATING“:

mbosetAssetSpec= mbo.getMBOSet („$EMXASSETSPECREQUIRED“, "ASSETSPEC“, "assetnum =:assetnum und siteid=:siteid“)

mboAssetSpec = mboSetAssetSpec.moveFirst ()

während mboAssetSpec:

wenn mboAssetSpec.isNull („ALNVALUE“) und mboAssetSpec.isNull („NUMVALUE“) und mboAssetSpec.isNull („TABLEVALUE“):

service.error („emx“, "assetStatusValidation“, ["Asset Spec" + mboAssetSpec.getString („ASSETATTRID“) + "darf nicht null sein"])

mboAssetSpec = mboSetAssetSpec.moveNext ()

Alle WO-Tasks müssen COMP sein, um zu COMP zu wechseln

wenn (mbo.getString („STATUS“) == „COMP“):

mbosetTask = mbo.getMBOSet („$EMXWOTASK“, "WOACTIVITY“, "historyflag=0 und istask=0 und status! ="COMP“ und parent=:wonum und siteid=:siteid“)

wenn (nicht mbosetTask.isEmpty ())

service.error („emx“,“ woStatusValidation“, [„Dieser Arbeitsauftrag enthält „+mbosetTask .count () + „offene untergeordnete Arbeitsaufträge, die abgeschlossen sein müssen, um diesen Arbeitsauftrag abzuschließen.“])