Aquí hay un escenario que surge en implementaciones de Maximo: tienes una lista de preguntas, quizás para una cotización de proveedor, y cada pregunta necesita un tipo de respuesta diferente. Algunas necesitan un desplegable de Sí/No. Algunas necesitan una lista de valores personalizada. Algunas son simplemente texto libre.
‍

El instinto suele ser crear un campo separado para cada tipo: un campo con un dominio YORN, otro con un dominio personalizado, otro de texto plano. Eso funciona, pero significa que tu modelo de datos crece con cada nuevo tipo de pregunta, y el diseño de tu pantalla necesita actualizarse cada vez.
‍

En este blog exploramos un enfoque diferente: un único campo VALOR que cambia dinámicamente su comportamiento —texto libre, búsqueda Sí/No, búsqueda Sí/No/NA o un dominio personalizado— según la pregunta que se responde. Sin cambios en el diseño de la pantalla. Sin campos nuevos. Solo dos pequeños scripts de automatización.

La Configuración

El contexto para este ejemplo es un cuestionario construido sobre un objeto personalizado de Maximo con tres campos clave:

• PREGUNTA - el texto de la pregunta

• VALOR - el campo de respuesta. Este es el campo que estamos haciendo dinámico

• TIPO DE DATO - el campo de control que impulsa el comportamiento de VALOR

‍

La Idea Principal: El campo VALOR se configura en Application Designer como un cuadro de texto simple sin un dominio estático adjunto. Si se convierte en un campo de texto libre o en una búsqueda específica se decide en tiempo de ejecución por el campo TIPO DE DATO, impulsado por dos scripts de automatización.

Gestionándolo desde un dominio ALN

Las preguntas se mantienen en un dominio ALN. Cada entrada utiliza dos campos:

• El campo VALUE de la entrada del dominio contiene el texto de la pregunta.

• El campo DESCRIPTION contiene el código del tipo de dato, la señal que controla el comportamiento del campo de respuesta VALUE.

En un cambio de estado particular, el campo VALUE de la entrada del dominio ALN se copia en el campo QUESTION del objeto personalizado, y el campo DESCRIPTION se copia en el campo DATATYPE del objeto personalizado. El disparador exacto dependerá de su requisito.

Aquí están los códigos de tipo de dato y lo que significa cada uno para el campo de respuesta VALUE:
‍

Por qué esto es potente: Añadir una nueva pregunta de texto libre o una pregunta que utilice un tipo de búsqueda existente (FNSYN, FNSYNNA, FNSDESKTOP) no requiere más que una nueva fila en el dominio ALN. Cero cambios de código, cero cambios de pantalla.
‍

Configuración del Diseñador de Aplicaciones

En el Diseñador de Aplicaciones, el campo VALUE se añade a la pantalla como un cuadro de texto estándar. Fundamentalmente, no se le asigna estáticamente ninguna búsqueda.

Esto es esencial. Si se asignara una búsqueda de forma estática, anularía los scripts. El campo debe dejarse como un lienzo en blanco para que los dos scripts de automatización tengan control total en tiempo de ejecución.

Los dos scripts que lo hacen funcionar

Dos scripts de automatización de Maximo están adjuntos al atributo VALUE del objeto personalizado. Juntos gestionan el ciclo de vida completo de la búsqueda.

Script 1 - El script de inicialización (INI)

Nombre del script: IBM.CUSTOMOBJECT.VALUE.INI

Este script se ejecuta cuando se carga el registro. Su función es sencilla: si el DATATYPE es uno de los tipos de búsqueda reconocidos, establece lookupname = "valuelist" para activar el icono de búsqueda en el campo VALUE. Si el tipo de dato es nulo o no reconocido, no se establece nada y el campo permanece como texto libre.

# 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 - El script de recuperación (RL)

Nombre del script: IBM.CUSTOMOBJECT.VALUE.RL

Este script se ejecuta cuando el usuario hace clic en el icono de búsqueda del campo VALUE. Lee el DATATYPE y lo asigna al dominio ALN correcto, indicando a Maximo qué objeto consultar, qué cláusula WHERE aplicar y qué claves asignar de vuelta.

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

Nota sobre el patrón: Este ejemplo utiliza ALNDOMAIN para todas las búsquedas. Para búsquedas de dominios que no son ALN (dominios numéricos, dominios de tabla), la asignación de relationObject y clave será diferente. El patrón general sigue siendo el mismo; solo cambia el objetivo.
‍

‍

Cómo añadir un nuevo tipo de búsqueda

La mayoría de las nuevas preguntas no requieren cambios en el código; simplemente añada una fila al dominio ALN. La única excepción es cuando necesita un dominio de búsqueda completamente nuevo que los scripts no hayan visto antes. En ese caso:

1. Cree el nuevo dominio ALN con sus valores.

2. Añada una nueva fila al dominio ALN del cuestionario con el nuevo código de tipo de dato en el campo DESCRIPTION.

3. Añada el nuevo tipo de dato a la condición 'if' en el script INI.

4. Añada un nuevo bloque 'elif' en el script RL que asigne el nuevo tipo de dato a su dominio.

Una vez hecho esto, cualquier pregunta futura que utilice ese tipo de dato seleccionará automáticamente la búsqueda correcta, sin necesidad de más cambios.

‍

‍

Hacer que un solo campo sirva para múltiples propósitos es un patrón de diseño limpio y mantenible. Al usar DATATYPE como señal de control en tiempo de ejecución y mantener toda la lógica en dos scripts específicos, la solución sigue siendo fácil de entender y de extender.

La conclusión clave: no necesitas un campo nuevo para cada nuevo tipo de pregunta. Necesitas un dominio ALN bien estructurado, un campo de control y dos scripts que sepan qué hacer con él.

‍