Hier is een scenario dat voorkomt in Maximo-implementaties: je hebt een lijst met vragen, misschien voor een offerte van een leverancier, en elke vraag vereist een ander type antwoord. Sommige vereisen een Ja/Nee-keuzelijst. Sommige vereisen een aangepaste lijst met waarden. Sommige zijn gewoon vrije tekst.
‍

Het instinct is vaak om voor elk type een apart veld aan te maken: één veld met een YORN-domein, een ander met een aangepast domein, een ander met platte tekst. Dat werkt, maar het betekent dat je datamodel groeit met elk nieuw vraagtype, en je schermindeling elke keer moet worden bijgewerkt.
‍

In deze blog bespreken we een andere aanpak: een enkel WAARDE-veld dat dynamisch zijn gedrag verandert - vrije tekst, Ja/Nee-opzoeking, Ja/Nee/N.v.t.-opzoeking, of een aangepast domein - op basis van de beantwoorde vraag. Geen wijzigingen in de schermindeling. Geen nieuwe velden. Slechts twee kleine automatiseringsscripts.

De Opzet

De context voor dit voorbeeld is een vragenlijst gebouwd op een aangepast Maximo object met drie sleutelvelden:

• VRAAG - de vraagtekst

• WAARDE - het antwoordveld. Dit is het veld dat we dynamisch maken

• DATATYPE - het besturingsveld dat het gedrag van WAARDE aanstuurt

‍

Het Kernidee: Het WAARDE-veld is geconfigureerd in Application Designer als een gewoon tekstvak zonder statisch domein. Of het een vrije-tekstveld of een specifieke opzoeking wordt, wordt tijdens runtime bepaald door het DATATYPE-veld, aangestuurd door twee automatiseringsscripts.

Aansturing vanuit een ALN-domein

Vragen worden beheerd in een ALN-domein. Elke invoer gebruikt twee velden:

• Het VALUE-veld van de domeininvoer bevat de vraagtekst.

• Het DESCRIPTION-veld bevat de datatypecode, het signaal dat bepaalt hoe het VALUE-antwoordveld zich gedraagt.

Bij een specifieke statuswijziging wordt het VALUE-veld van de ALN-domeininvoer gekopieerd naar het QUESTION-veld van het aangepaste object, en het DESCRIPTION-veld wordt gekopieerd naar het DATATYPE-veld van het aangepaste object. De exacte trigger is afhankelijk van uw vereisten.

Hier zijn de datatypecodes en wat elke code betekent voor het VALUE-antwoordveld:
‍

Waarom dit krachtig is: Het toevoegen van een nieuwe vrije-tekstvraag of een vraag die gebruikmaakt van een bestaand opzoektype (FNSYN, FNSYNNA, FNSDESKTOP) vereist niets meer dan een nieuwe rij in het ALN-domein. Nul codewijzigingen, nul schermwijzigingen.
‍

Application Designer-configuratie

In Application Designer wordt het VALUE-veld als een standaard tekstvak aan het scherm toegevoegd. Cruciaal is dat er geen lookup statisch aan is toegewezen.

Dit is essentieel. Als er een lookup statisch zou zijn toegewezen, zou dit de scripts overschrijven. Het veld moet als een leeg canvas worden gelaten, zodat de twee automatiseringsscripts volledige controle hebben tijdens runtime.

De twee scripts die het laten werken

Twee Maximo-automatiseringsscripts zijn gekoppeld aan het VALUE-attribuut op het aangepaste object. Samen beheren ze de volledige lookup-levenscyclus.

Script 1 - Het Initialisatiescript (INI)

Scriptnaam: IBM.CUSTOMOBJECT.VALUE.INI

Dit script wordt geactiveerd wanneer de record wordt geladen. De taak is eenvoudig: als het DATATYPE een van de herkende opzoektypen is, stelt het lookupname = "valuelist" in om het opzoekpictogram op het VALUE-veld te activeren. Als het datatype null of onherkend is, wordt niets ingesteld en blijft het veld als gewone vrije tekst.

# Script  : IBM.CUSTOMOBJECT.VALUE.INI 
# Trigger : Attribute Initialization — VALUE attribute 
# Purpose : If this question requires a lookup, activate the valuelist control. 

if mbo.getString("DATATYPE") in ["FNSYN", "FNSDESKTOP", "FNSYNNA"]: 
    lookupname = "valuelist" 

# If DATATYPE is null or unrecognised, no lookupname is set — 
# VALUE renders as a plain free-text box. 

Script 2 - Het Ophaalscript (RL)

Scriptnaam: IBM.CUSTOMOBJECT.VALUE.RL

Dit script wordt geactiveerd wanneer de gebruiker op het opzoekpictogram op het VALUE-veld klikt. Het leest DATATYPE en koppelt dit aan het juiste ALN-domein, waarbij Maximo wordt verteld welk object moet worden opgevraagd, welke WHERE-clausule moet worden toegepast en welke sleutels moeten worden teruggekoppeld.

# Script  : IBM.CUSTOMOBJECT.VALUE.RL 
# Trigger : Retrieve lookup — VALUE attribute 
# Purpose : Map the DATATYPE to the correct ALN domain. 

if mbo.getString("DATATYPE") == "FNSYN": 
    relationObject = "ALNDOMAIN" 
    relationWhere  = "domainid = 'YORN' and value=:value" 
    listWhere      = "domainid = 'YORN'" 
    srcKeys        = ["value"] 
    targetKeys     = ["value"] 

elif mbo.getString("DATATYPE") == "FNSYNNA": 
    relationObject = "ALNDOMAIN" 
    relationWhere  = "domainid = 'YNNA' and value=:value" 
    listWhere      = "domainid = 'YNNA'" 
    srcKeys        = ["value"] 
    targetKeys     = ["value"] 

elif mbo.getString("DATATYPE") == "FNSDESKTOP": 
    relationObject = "ALNDOMAIN" 
    relationWhere  = "domainid = 'FNSDESKTOP' and value=:value" 
    listWhere      = "domainid = 'FNSDESKTOP'" 
    srcKeys        = ["value"] 
    targetKeys     = ["value"] 

Patroonopmerking: Dit voorbeeld gebruikt ALNDOMAIN voor alle opzoekacties. Voor opzoekacties buiten het ALN-domein (numerieke domeinen, tabeldomeinen) zullen de relationObject- en sleuteltoewijzing verschillen. Het algemene patroon blijft hetzelfde - alleen het doel verandert.
‍

‍

Een nieuw opzoektype toevoegen

De meeste nieuwe vragen vereisen geen codewijzigingen - voeg gewoon een rij toe aan het ALN-domein. De enige uitzondering is wanneer u een gloednieuw opzoekdomein nodig heeft dat de scripts nog niet eerder hebben gezien. In dat geval:

1. Maak het nieuwe ALN-domein aan met de bijbehorende waarden.

2. Voeg een nieuwe rij toe aan het ALN-domein van de vragenlijst met de nieuwe datatypecode in het DESCRIPTION-veld.

3. Voeg het nieuwe datatype toe aan de if-conditie in het INI-script.

4. Voeg een nieuw elif-blok toe in het RL-script dat het nieuwe datatype aan zijn domein koppelt.

Eenmaal voltooid, zal elke toekomstige vraag die dat datatype gebruikt automatisch de juiste opzoekactie overnemen, zonder verdere wijzigingen.

‍

‍

Een enkel veld meerdere doelen laten dienen is een overzichtelijk, onderhoudbaar ontwerppatroon. Door DATATYPE te gebruiken als besturingssignaal tijdens runtime en alle logica in twee gerichte scripts te houden, blijft de oplossing eenvoudig te begrijpen en gemakkelijk uit te breiden.

De belangrijkste conclusie: je hebt geen nieuw veld nodig voor elk nieuw vraagtype. Je hebt een goed gestructureerd ALN-domein, een controleveld en twee scripts nodig die weten wat ze ermee moeten doen.

‍