Hier ist ein Szenario, das häufig in Maximo-Implementierungenauftritt: Sie haben eine Liste von Fragen, vielleicht für ein Lieferantenangebot, und jede Frage erfordert einen anderen Antworttyp. Manche benötigen ein Ja/Nein-Dropdown. Manche benötigen eine benutzerdefinierte Werteliste. Manche sind einfach Freitext.
‍

Der Instinkt ist oft, für jeden Typ ein separates Feld zu erstellen: ein Feld mit einer Ja/Nein-Domäne, ein weiteres mit einer benutzerdefinierten Domäne, ein weiteres als Klartext. Das funktioniert, aber es bedeutet, dass Ihr Datenmodell mit jedem neuen Fragetyp wächst und Ihr Bildschirm-Layout jedes Mal aktualisiert werden muss.
‍

In diesem Blog stellen wir einen anderen Ansatz vor: ein einziges VALUE-Feld, das sein Verhalten – Freitext, Ja/Nein-Auswahl, Ja/Nein/Nicht zutreffend-Auswahl oder eine benutzerdefinierte Domäne – dynamisch basierend auf der beantworteten Frage ändert. Keine Änderungen am Bildschirm-Layout. Keine neuen Felder. Nur zwei kleine Automatisierungsskripte.

Die Einrichtung

Der Kontext für dieses Beispiel ist ein Fragebogen, der auf einem benutzerdefinierten Maximo Objekt mit drei Schlüsselfeldern basiert:

• QUESTION – der Fragetext

• VALUE – das Antwortfeld. Dies ist das Feld, das wir dynamisch gestalten

• DATATYPE – das Steuerfeld, das das Verhalten von VALUE steuert

‍

Die Kernidee: Das VALUE-Feld wird im Application Designer als einfaches Textfeld ohne statische Domäne konfiguriert. Ob es zu einem Freitextfeld oder einer spezifischen Auswahl wird, entscheidet zur Laufzeit das DATATYPE-Feld, gesteuert durch zwei Automatisierungsskripte.

Steuerung über eine ALN-Domäne

Fragen werden in einer ALN-Domäne verwaltet. Jeder Eintrag verwendet zwei Felder:

• Das Feld VALUE des Domäneneintrags enthält den Fragetext.

• Das Feld DESCRIPTION enthält den Datentypcode, das Signal, das steuert, wie sich das Antwortfeld VALUE verhält.

Bei einer bestimmten Statusänderung wird das Feld VALUE des ALN-Domäneneintrags in das Feld QUESTION des benutzerdefinierten Objekts kopiert und das Feld DESCRIPTION wird in das Feld DATATYPE des benutzerdefinierten Objekts kopiert. Der genaue Auslöser hängt von Ihren Anforderungen ab.

Hier sind die Datentypcodes und was jeder einzelne für das Antwortfeld VALUE bedeutet:
‍

Das macht es so leistungsfähig: Das Hinzufügen einer neuen Freitextfrage oder einer Frage, die einen bestehenden Suchtyp (FNSYN, FNSYNNA, FNSDESKTOP) verwendet, erfordert lediglich eine neue Zeile in der ALN-Domäne. Keine Codeänderungen, keine Bildschirmänderungen.
‍

Application Designer-Konfiguration

Im Application Designer wird das Feld VALUE als Standard-Textfeld zum Bildschirm hinzugefügt. Entscheidend ist, dass ihm keine Suche statisch zugewiesen wird.

Dies ist unerlässlich. Würde eine Suche statisch zugewiesen, würde sie die Skripte überschreiben. Das Feld muss als leere Leinwand belassen werden, damit die beiden Automatisierungsskripte zur Laufzeit die volle Kontrolle haben.

Die beiden Skripte, die es ermöglichen

Zwei Maximo-Automatisierungsskripte sind dem Attribut VALUE des benutzerdefinierten Objekts zugeordnet. Zusammen steuern sie den gesamten Lebenszyklus der Suche.

Skript 1 – Das Initialisierungsskript (INI)

Skriptname: IBM.CUSTOMOBJECT.VALUE.INI

Dieses Skript wird ausgeführt, wenn der Datensatz geladen wird. Seine Aufgabe ist einfach: Wenn der DATATYPE einer der erkannten Nachschlagetypen ist, setzt es lookupname = "valuelist", um das Nachschlage-Symbol im Feld VALUE zu aktivieren. Ist der Datentyp null oder nicht erkannt, wird nichts gesetzt und das Feld bleibt als einfacher Freitext bestehen.

# 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. 

Skript 2 – Das Abrufskript (RL)

Skriptname: IBM.CUSTOMOBJECT.VALUE.RL

Dieses Skript wird ausgeführt, wenn der Benutzer auf das Nachschlage-Symbol im Feld VALUE klickt. Es liest den DATATYPE und ordnet ihn der korrekten ALN-Domäne zu, wobei Maximo mitgeteilt wird, welches Objekt abgefragt werden soll, welche WHERE-Klausel anzuwenden ist und welche Schlüssel zurückzugeordnet werden sollen.

# 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"] 

Hinweis zum Muster: Dieses Beispiel verwendet ALNDOMAIN für alle Nachschlagevorgänge. Bei Nachschlagevorgängen außerhalb der ALN-Domäne (numerische Domänen, Tabellendomänen) unterscheiden sich relationObject und Schlüsselzuordnung. Das Gesamtkonzept bleibt dasselbe – nur das Ziel ändert sich.
‍

‍

Hinzufügen eines neuen Nachschlagetyps

Die meisten neuen Fragen erfordern keine Codeänderungen – fügen Sie einfach eine Zeile zur ALN-Domäne hinzu. Die einzige Ausnahme ist, wenn Sie eine völlig neue Nachschlage-Domäne benötigen, die die Skripte noch nicht kennen. In diesem Fall:

1. Erstellen Sie die neue ALN-Domäne mit ihren Werten.

2. Fügen Sie eine neue Zeile zur ALN-Domäne des Fragebogens hinzu, mit dem neuen Datentypcode im Feld DESCRIPTION.

3. Fügen Sie den neuen Datentyp zur if-Bedingung im INI-Skript hinzu.

4. Fügen Sie einen neuen elif-Block im RL-Skript hinzu, der den neuen Datentyp seiner Domäne zuordnet.

Sobald dies erledigt ist, wird jede zukünftige Frage, die diesen Datentyp verwendet, automatisch den korrekten Nachschlagevorgang übernehmen, ohne dass weitere Änderungen erforderlich sind.

‍

‍

Ein einziges Feld für mehrere Zwecke zu nutzen, ist ein sauberes, wartbares Designmuster. Indem man DATATYPE als Laufzeit-Steuersignal verwendet und die gesamte Logik in zwei fokussierten Skripten hält, bleibt die Lösung einfach zu verstehen und leicht erweiterbar.

Die wichtigste Erkenntnis: Sie benötigen kein neues Feld für jeden neuen Fragetyp. Sie benötigen eine gut strukturierte ALN-Domäne, ein Steuerfeld und zwei Skripte, die wissen, was damit zu tun ist.

‍