Voici un scénario courant dans les implémentations Maximo: vous avez une liste de questions, peut-être pour un devis fournisseur, et chaque question nécessite un type de réponse différent. Certaines nécessitent une liste déroulante Oui/Non. D'autres nécessitent une liste de valeurs personnalisée. D'autres sont simplement du texte libre.
‍

L'instinct est souvent de créer un champ distinct pour chaque type : un champ avec un domaine YORN, un autre avec un domaine personnalisé, un autre en texte brut. Cela fonctionne, mais cela signifie que votre modèle de données s'agrandit avec chaque nouveau type de question, et que la mise en page de votre écran doit être mise à jour à chaque fois.
‍

Dans cet article, nous explorons une approche différente : un champ VALEUR unique qui modifie dynamiquement son comportement – texte libre, recherche Oui/Non, recherche Oui/Non/N/A, ou un domaine personnalisé – en fonction de la question à laquelle on répond. Pas de modifications de la mise en page de l'écran. Pas de nouveaux champs. Juste deux petits scripts d'automatisation.

La configuration

Le contexte de cet exemple est un questionnaire basé sur un objet Maximo personnalisé avec trois champs clés :

• QUESTION - le texte de la question

• VALEUR - le champ de réponse. C'est le champ que nous rendons dynamique

• DATATYPE - le champ de contrôle qui détermine le comportement de VALEUR

‍

L'idée principale : Le champ VALEUR est configuré dans Application Designer comme une zone de texte simple sans domaine statique associé. Qu'il devienne un champ de texte libre ou une recherche spécifique est décidé à l'exécution par le champ DATATYPE, piloté par deux scripts d'automatisation.

Pilotage à partir d'un domaine ALN

Les questions sont gérées dans un domaine ALN. Chaque entrée utilise deux champs :

• Le champ VALUE de l'entrée du domaine contient le texte de la question.

• Le champ DESCRIPTION contient le code du type de données, le signal qui contrôle le comportement du champ de réponse VALUE.

Lors d'un changement de statut particulier, le champ VALUE de l'entrée du domaine ALN est copié dans le champ QUESTION de l'objet personnalisé, et le champ DESCRIPTION est copié dans le champ DATATYPE de l'objet personnalisé. Le déclencheur exact dépendra de vos exigences.

Voici les codes de type de données et ce que chacun signifie pour le champ de réponse VALUE :
‍

Pourquoi c'est puissant : L'ajout d'une nouvelle question à texte libre ou d'une question utilisant un type de recherche existant (FNSYN, FNSYNNA, FNSDESKTOP) ne nécessite rien de plus qu'une nouvelle ligne dans le domaine ALN. Zéro modification de code, zéro modification d'écran.
‍

Configuration du Concepteur d'applications

Dans le Concepteur d'applications, le champ VALUE est ajouté à l'écran comme une zone de texte standard. Il est essentiel de noter que, aucune recherche n'y est attribuée statiquement.

C'est essentiel. Si une recherche était attribuée statiquement, elle annulerait les scripts. Le champ doit être laissé comme une toile vierge afin que les deux scripts d'automatisation aient un contrôle total à l'exécution.

Les deux scripts qui assurent son fonctionnement

Deux scripts d'automatisation Maximo sont attachés à l'attribut VALUE de l'objet personnalisé. Ensemble, ils gèrent le cycle de vie complet de la recherche.

Script 1 - Le script d'initialisation (INI)

Nom du script : IBM.CUSTOMOBJECT.VALUE.INI

Ce script se déclenche au chargement de l'enregistrement. Son rôle est simple : si le DATATYPE est l'un des types de recherche reconnus, il définit lookupname = "valuelist" pour activer l'icône de recherche sur le champ VALUE. Si le type de données est nul ou non reconnu, rien n'est défini et le champ reste un texte libre simple.

# 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 - Le script de récupération (RL)

Nom du script : IBM.CUSTOMOBJECT.VALUE.RL

Ce script se déclenche lorsque l'utilisateur clique sur l'icône de recherche du champ VALUE. Il lit le DATATYPE et le mappe au domaine ALN correct, indiquant à Maximo quel objet interroger, quelle clause WHERE appliquer et quelles clés mapper en retour.

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

Remarque sur le modèle : Cet exemple utilise ALNDOMAIN pour toutes les recherches. Pour les recherches de domaines non-ALN (domaines numériques, domaines de table), le relationObject et le mappage des clés seront différents. Le modèle global reste le même – seul l'objectif change.
‍

‍

Ajout d'un nouveau type de recherche

La plupart des nouvelles questions ne nécessitent aucune modification de code – il suffit d'ajouter une ligne au domaine ALN. La seule exception est lorsque vous avez besoin d'un tout nouveau domaine de recherche que les scripts n'ont jamais rencontré auparavant. Dans ce cas :

1. Créez le nouveau domaine ALN avec ses valeurs.

2. Ajoutez une nouvelle ligne au domaine ALN du questionnaire avec le nouveau code de type de données dans le champ DESCRIPTION.

3. Ajoutez le nouveau type de données à la condition "if" dans le script INI.

4. Ajoutez un nouveau bloc "elif" dans le script RL mappant le nouveau type de données à son domaine.

Une fois cela fait, toute future question utilisant ce type de données sélectionnera automatiquement la recherche correcte, sans nécessiter d'autres modifications.

‍

‍

Faire en sorte qu'un champ unique serve à plusieurs usages est un modèle de conception épuré et facile à maintenir. En utilisant DATATYPE comme signal de contrôle à l'exécution et en gardant toute la logique dans deux scripts dédiés, la solution reste simple à comprendre et facile à étendre.

Ce qu'il faut retenir : vous n'avez pas besoin d'un nouveau champ pour chaque nouveau type de question. Vous avez besoin d'un domaine ALN bien structuré, d'un champ de contrôle et de deux scripts qui savent quoi en faire.

‍