Dit wordt de eerste in een reeks blogposts die helpen bij het uitleggen van automatiseringsscripts in Maximo. Ik zal in dit bericht bespreken wat het is en waarom het aan het product is toegevoegd. In toekomstige berichten zal ik me vooral concentreren op hoe je ze kunt gebruiken om aan verschillende soorten aanpassingsvereisten te voldoen, maar zal ik ook enkele relatief onbekende functies behandelen die in Automation Scripts aanwezig zijn, de voor- en nadelen van aanpassingsopties belichten (inclusief niet-Automation Script-opties), en enkele van onze beste praktijken bespreken bij het bouwen van scripts. Enige codeerervaring is nuttig, maar ik zal proberen de meeste code uit te leggen, zodat je begrijpt waarom ik doe wat ik doe. En als je vragen hebt, plaats ze dan gerust op het Maximo-forum, zodat anderen ook van het antwoord kunnen profiteren.

Maximo is een zeer configureerbaar product (bekijk onze Oplossingen pagina voor ons aanbod). Met minimale technische vaardigheden kunnen gebruikers nieuwe velden toevoegen, schermwijzigingen aanbrengen of de waarden van kenmerken beperken in Maximo. Maar als je eenmaal verder moet gaan dan die mogelijkheden, dan beginnen mensen vragen te stellen over automatiseringsscripts/Java-aanpassingen. En als het iets is dat je nog niet eerder hebt gedaan, kan het in het begin behoorlijk intimiderend zijn. Hopelijk helpt deze blogserie om de meeste intimidatie te elimineren en kunt u uw bedrijfsdoelstellingen sneller bereiken.

Laten we beginnen te praten over wat Automation Scripts zijn in Maximo. Voor degenen die het niet weten: automatiseringsscripts zijn aangepaste code. Dit kunnen kleine scripts zijn (sommige bestaan uit slechts één regel) of zeer grote scripts (sommige bestaan uit bijna duizend regels code). Deze scripts worden meestal geschreven in Python of JavaScript, omdat dit de twee talen zijn die standaard worden ondersteund in Maximo, maar elke JSR 223-taal kan worden gebruikt als u deze configureert. Automatiseringsscripts zijn toegevoegd in Maximo 7.5 (een voorloper bestond eerder in de IT-versies van Maximo) en zijn aanzienlijk verbeterd in Maximo 7.6. IBM is sinds de release van 7.6 doorgegaan met het verbeteren van automatiseringsscripts in verschillende functiepakketten, zodat iemand met de nieuwste versie van Maximo 7.6 (momenteel 7.6.0.9) bepaalde functies kan gebruiken die in eerdere versies niet aanwezig waren. Als dat in onze voorbeelden gebeurt, zal ik proberen duidelijk te maken welke versie dat als eerste ondersteunde en indien mogelijk alternatieve opties noemen.

Automatiseringsscripts zijn meestal gekoppeld aan een gebeurtenis in Maximo met behulp van een startpunt. Sommige van de nieuwere functies (zoals integraties) hebben geen echt startpunt gedefinieerd en worden in plaats daarvan aangeroepen door gebruik te maken van een speciale naamgevingsstructuur in het script. Het begrijpen van deze Launch Point-opties is van cruciaal belang voor de ontwikkeling in Maximo (we zullen alle startpunten in detail behandelen in deze blogserie). Dankzij deze flexibiliteit van eventopties kunt u uw code op het meest geschikte moment uitvoeren. Hierdoor wordt uw script minder vaak aangeroepen, wat de prestaties in Maximo voor complexere scripts aanzienlijk kan verbeteren.

Wanneer moet je Automation Scripts gebruiken? Als u eenmaal de kracht van automatiseringsscripts onder de knie hebt, is het vaak verleidelijk om deze te gebruiken voor al uw aanpassingsbehoeften. Ik ben er sterk van overtuigd dat scripts alleen moeten worden gebruikt als het Maximo-framework nog niet ondersteunt wat je moet doen. Een veelvoorkomend voorbeeld dat ik heb gezien waarbij automatiseringsscripts worden misbruikt, is het gebruik van een automatiseringsscript om een waarde van het ene object naar het andere over te steken. Als er geen transformatie is, kun je beter een cross-over domein gebruiken. Deze worden betrouwbaar uitgevoerd (gebeurtenissen kunnen worden onderdrukt, waardoor uw script niet kan worden gestart, of de toepassing kan zich in de beheerdersmodus bevinden, waardoor alle scripts niet kunnen worden gestart) en werken eerlijk gezegd gewoon.

Een ander voorbeeld dat ik verkeerd zie worden gebruikt, is het gebruik van een automatiseringsscript om velden te verplichten of alleen leesbaar te maken. Er zijn enkele scenario's waarin dit logisch is, maar in de meeste gevallen bereikt het gebruik van een wereldwijde gegevensbeperking dit op een veel betere en betrouwbaardere manier. Net als voorheen, als je script niet wordt gestart (de gebeurtenis is onderdrukt of de beheerdersmodus), dan is iets dat je probeert te beperken/vereist in een bedrijfsproces mogelijk niet ingesteld. En als je probeert de meeste veldvereisten op één plek te consolideren, kun je gemakkelijk vinden wanneer je wilt bepalen waar en onder welke voorwaarden.

Wat zijn enkele voor- en nadelen van automatiseringsscripts in vergelijking met Java-aanpassingen? Het grootste voordeel van Automation Scripting is het implementatieproces. In tegenstelling tot Java-aanpassingen kunnen automatiseringsscripts zonder downtime worden toegevoegd, gewijzigd of uitgeschakeld. Dat alleen al maakt het voor de meeste organisaties moeilijk te verslaan. De implementatie van Java-aanpassingen kan uren duren als u geclusterd bent, waardoor het ontwikkelen en testen aanzienlijk langer duurt, naast de zakelijke gevolgen van het verlies van Maximo-toegang. Ik hoor vaak van sommige ontwikkelaars dat dit geen probleem is, omdat het bedrijf downtime heeft gepland om deze wijzigingen door te voeren. Maar wat gebeurt er als je code een bug bevat? Problemen worden vaak tijdens kantooruren vastgesteld en Java-aanpassingen kunnen niet zonder onderbreking worden uitgeschakeld of gewijzigd.

Een ander voordeel is dat u uw automatiseringsscript eenvoudig kunt koppelen aan meerdere gebeurtenissen in Maximo. Als u bijvoorbeeld wilt dat een script wordt geactiveerd wanneer de kenmerken van het assetnum of de locatie veranderen, kunt u dat doen met een automatiseringsscript en twee startpunten. Je kunt hetzelfde stuk code aanroepen met Java Customizations, maar je moet de veldklasse voor elk van de attributen uitbreiden (of schrijven), waardoor je meer code moet onderhouden dan alleen het schrijven van dat gemeenschappelijke gedeelte.

Een van mijn favoriete voordelen is dat u met Automation Scripts kunt profiteren van beide talen. Scripts zijn over het algemeen eenvoudiger dan dezelfde code in Java. Maar waar dit echt tijd bespaart, is wanneer er een geweldige manier is om iets in Jython te doen dat moeilijker of uitgebreider is in Java. Een eenvoudig voorbeeld is om te controleren of een attribuut in Maximo is ingesteld. Soms krijg je een NULL-waarde terug als je getString aanroept („ATTRIBUTENAME”), soms een lege tekenreeks. In Java moet je beide controles schrijven, zoals getString („ATTRIBUTENAME”)! =null en getString („ATTRIBUTENAME”)! =””. In Jython kan ik gewoon zeggen of mbo.getString („ATTRIBUTENAME”) en het kan beide scenario's aan. Maak je geen zorgen over het voorbeeld (dat behandelen we in onze volgende blogpost), ik vond het gewoon het gemakkelijkst om het voorbeeld te benadrukken.

Er kleven enkele nadelen aan het gebruik van automatiseringsscripts voor aanpassing. De eerste is dat als u in de beheerdersmodus iets moet doen, u Java-code moet schrijven. We vinden dat niet gebruikelijk, omdat de meeste van onze aanpassingen bedrijfsgericht zijn en zakelijke transacties niet mogen plaatsvinden tijdens de beheermodus om andere redenen dan alleen scripting.

Een ander voorbeeld waarbij Java-aanpassingen beter zijn, is wanneer u een methode moet overschrijven om logica te onderdrukken. Stel dat IBM bijvoorbeeld iets doet in een van hun klassebestanden waarvan u niet wilt dat het voorkomt. Je kunt proberen om in een script ongedaan te maken wat ze met die methode doen, maar als je een Java-klasse schrijft, kun je gewoon voorkomen dat de code wordt uitgevoerd en gewoon je aangepaste code uitvoeren. Nogmaals, dit is niet gebruikelijk voor ons, want als IBM iets doet, moet het waarschijnlijk met rust worden gelaten, anders loop je het risico dat je later nog andere problemen veroorzaakt.

Ten slotte zijn er momenten waarop een automatiseringsscript niet mogelijk is. IBM heeft voortdurend extra gebeurtenissen toegevoegd waar automatiseringsscripts naar kunnen luisteren en verbeterde functionaliteit (zoals Ja/Nee/Cancel-dialogen), maar soms moet u iets doen dat met het huidige raamwerk gewoon niet mogelijk is. Sommige zullen in toekomstige versies verbeteren (zoals de mogelijkheid om een dialoog te sluiten!) , en sommigen zullen het misschien nooit halen. Automatiseringsscripts zullen nooit 100% dekking hebben, maar zullen de gemiddelde beheerder van Maximo helpen om een aantal verbazingwekkende dingen te bereiken.

‍