Maximo kan bedrijfslogica op vele manieren afdwingen. Elke aanpak heeft enkele voordelen en verschillende niveaus van technische vaardigheden die moeten worden toegepast. Het vereisen van een veld op het scherm kan op verschillende manieren worden benaderd.

De eerste manier om verplichte velden aan te maken in Maximo is door via Application Designer een veld in te stellen op „verplicht”; dit is een eenvoudige manier om een specifiek veld 100% van de tijd vereist te maken in een enkele applicatie. Dit is een uitstekende optie voor gebruikers die slechts met één enkele applicatie in Maximo communiceren en waarvoor het veld altijd vereist is. De tweede benadering is nuttig wanneer een gebruiker voorwaardelijke logica wil toevoegen aan het veld „vereist”; dit kan worden gedaan door gegevensbeperkingen te gebruiken. Deze gegevensbeperkingen kunnen worden geïmplementeerd op een beveiligingsgroep of op mondiaal niveau. Ik vind dat wereldwijde gegevensbeperkingen meestal goed werken. Deze aanpak is complexer dan de wijziging van de Application Designer, omdat u een where-clausule moet schrijven. Dit is een ideale oplossing in mijn gereedschapstas, omdat ze zo veelzijdig zijn.

Beide benaderingen zijn geweldig omdat ze in de applicatie zichtbaar een veld als „vereist” kunnen weergeven. Deze benaderingen zijn efficiënt in de toepassing, maar zijn nog steeds eenvoudig te implementeren en te ondersteunen. Een nadeel is dat wanneer een status op een werkorder wordt gewijzigd, een veld dat in de vorige status niet vereist was, mogelijk verplicht wordt in de nieuw bijgewerkte status. Een werkorder met de WAPPR-status wordt bijvoorbeeld naar de APPR-status verplaatst en een veld dat niet vereist was in de WAPPR-status is vereist binnen de APPR-status; wanneer de gebruiker de status gaat wijzigen, krijgt hij een algemene foutmelding dat een veld vereist is. Het andere nadeel is dat voorwaardelijke logica slechts zo goed kan zijn als de vaardigheden van de uitvoerder om een where-clausule te schrijven.

Automatiseringsscripts blinken uit in het leveren van complexe logica met duidelijke boodschappen. Het toevoegen van aangepaste bedrijfslogica aan de statuswijziging van een record is een uitstekende toepassing voor automatiseringsscripts. Ik heb deze aanpak gebruikt voor de wijzigingsstatus van activa, werkorders, serviceaanvragen, inkooporders en configuratie-items. Ik heb gemerkt dat automatiseringsscripts me in staat stellen om gerichte berichten af te leveren met logica die zo complex kan zijn als nodig is. Ik zal enkele veelvoorkomende voorbeelden geven.

Startpunt

Door een startpunt op basis van attributen te gebruiken, kan de logica elke keer dat de status verandert, worden geactiveerd. In het onderstaande voorbeeld implementeer ik een validatie van de wijzigingsstatus van een bedrijfsmiddel. Als u de validatie vaker wilt uitvoeren, kunt u een startpunt voor het opslaan van objecten gebruiken.

Foutmelding

Door het automatiseringsscript te koppelen aan een Maximo Message kunnen specifieke en flexibele berichten aan de gebruiker worden gegeven. Voor elk automatiseringsscript dat ik implementeer, heb ik graag een bijbehorend bericht met een parameter waaraan ik een bericht kan doorgeven. Dit bericht is geconfigureerd in de databaseconfiguratie in het dialoogvenster Berichten. De „{0}” is de parameter die we met een aangepast bericht doorgeven.

Zodra u een bericht in het automatiseringsscript hebt, kunt u met dat bericht een foutmelding aanroepen. Merk op dat de eerste twee parameters aangeven welk bericht moet worden gebruikt. De derde parameter is een array die aan het bericht wordt doorgegeven. Wanneer aangeroepen, vervangt de „{0}” in het bericht de eerste tekenreeks in de array. Als u een „{1}” aan uw bericht toevoegt, wordt dit gekoppeld aan de tweede waarde in de array.

service.error („emx”,” AssetStatusValidation”, [„Adres is vereist om naar de ACTVE-status te gaan.”])

Voorbeelden:

Vereist adres wanneer de status is gewijzigd in ACTIEF

als mbo.getString („STATUS”) =="ACTIVE” en mbo.IsNull („EMXAddress”):

service.error („emx”,” AssetStatusValidation”, [„Adres is vereist om naar de ACTVE-status te gaan.”])

Vereiste waarde voor alle activaspecificaties wanneer de status wordt gewijzigd in OPERATIONEEL

als mbo.getString („STATUS”) =="OPERATING”:

mboSetAssetSpec= mbo.getMBOset („$EMXASSETSPECREQUIRED”, „ASSETSPEC”, „assetnum =:assetnum en siteid=:siteid”)

mboAssetSpec = mboSetAssetSpec.moveFirst ()

terwijl Mbo Spec instelt:

als mboAssetSpec.isNull („ALNVALUE”) en mboAssetSpec.isNull („NUMVALUE”) en mboAssetSpec.isNull („TABLEVALUE”):

service.error („emx”, „AssetStatusValidation”, ["Asset Spec" + mboAssetSpec.getString („ASSETATTRID”) + "moet niet null zijn"])

mboAssetSpec = mboSetAssetSpec.moveNext ()

Alle WO-taken moeten COMP zijn om over te schakelen naar COMP

if (mbo.getString („STATUS”) == „COMP”):

mboSetTask = mbo.getMboset („$EMXWOTASK”, „WOACTIVITY”, „historyflag=0 en istask=0) en status! ="COMP” en parent=:wonum en siteid=:siteid”)

if (niet mboSetTask.isEmpty ())

service.error („emx”,” woStatusValidation”, [„Deze werkorder bevat „+mboSetTask .count () + „open onderliggende werkorders die compleet moeten zijn om deze werkorder te voltooien.”])