Este es un escenario común en las implementaciones de Maximo: un planificador abre una orden de trabajo para un vehículo y necesita añadir media docena de tareas de reparación. Esas tareas no se inventan sobre la marcha. Ya existen como registros asociados a una ubicación de reparación, y el mismo grupo se utiliza una y otra vez.
‍

El instinto suele ser recurrir a un plan de trabajo. Esto funciona cuando el mismo conjunto de tareas se aplica siempre, pero falla en cuanto el planificador necesita un subconjunto arbitrario. Diez planes de trabajo se convierten en cuarenta, luego en cien, cada uno con ligeras variaciones respecto al anterior. La alternativa, escribir las tareas a mano, es más lenta y genera descripciones distintas cada vez que alguien escribe una palabra de forma diferente.
‍

En este blog exploramos una tercera opción: un cuadro de diálogo personalizado que enumera las tareas ya registradas, permite al planificador marcar las que desea y las copia en la orden de trabajo con un solo clic. Una opción de firma, un cuadro de diálogo y un breve script de automatización. Sin nuevos objetos, sin Java.

La configuración

El contexto es una pantalla de seguimiento de órdenes de trabajo con una tabla de tareas. Ya existen tres elementos:

• TASKREPLOC: un objeto personalizado que contiene el catálogo de tareas de reparación, cada una con una ubicación, un ID de tarea y una descripción. Omita esto si desea traer todas las tareas de trabajo utilizando un criterio específico.

• Una relación con el mismo nombre desde WORKORDER hacia ese objeto, delimitada para que el planificador solo vea las tareas relevantes para la orden de trabajo que tiene delante.

• SHOWTASKS: la relación predeterminada desde una orden de trabajo hacia sus tareas. Aquí es donde se depositan las filas copiadas.
  ‍

La idea central: el cuadro de diálogo no guarda nada por sí mismo. Es un selector. Lo único que hace es contener un conjunto de registros y recordar cuáles ha marcado el usuario. Una opción de firma activada desde el botón Aceptar transfiere el control a un script de automatización, y es este script el que realiza el trabajo real.

Paso 1: Crear la opción de firma

La opción de firma es el puente entre un botón en la pantalla y un script en el servidor. Sin ella, no hay forma de que un botón de comando llegue a un punto de inicio de acción.
‍

‍

El nombre de la opción, ADDREPTASK, es la cadena exacta que activará el botón del cuadro de diálogo y distingue entre mayúsculas y minúsculas.  
‍

Recuerde conceder ADDREPTASK a los grupos de seguridad que lo necesiten. Si la opción existe pero no se ha concedido, el botón aparece, el cuadro de diálogo se abre, pero al pulsar Aceptar no ocurre nada y no se muestra ningún error.

Paso 2: Añadir el botón que abre el cuadro de diálogo

En el Diseñador de aplicaciones, se añade un botón a la barra de herramientas de la tabla de tareas.
‍

‍
El truco aquí es: configurar el evento con el ID de un cuadro de diálogo es todo lo que se necesita para abrirlo. No hay scripts involucrados en esta parte de la solución, y no se requiere ningún ID de destino ni valor. Maximo detecta un nombre de evento que coincide con un cuadro de diálogo en la presentación y lo abre para el registro actual.

Paso 3: Definir el cuadro de diálogo

El cuadro de diálogo se añade al XML de la aplicación. Es breve y cada atributo tiene su razón de ser.
‍

<dialog beanclass="psdi.webclient.system.beans.MultiselectDataBean" 
        id="selectrepairtasks" label="Select Repair Tasks" 
        parentdatasrc="MAINRECORD" relationship="TASKREPLOC" 
        savemode="onunload"> 

  <table id="selectrepairtasks_select_table" inputmode="readonly" 
         label="Tasks" selectmode="multiple" width="700"> 
    <tablebody displayrowsperpage="15" filterable="true" 
               id="selectrepairtasks_select_table_tablebody"> 
      <tablecol id="selectrepairtasks_select_table_tablebody_1" 
                mxevent="toggleselectrow" type="event" 
                filterable="false" sortable="false"/> 
      <tablecol dataattribute="location"    id="..._tablebody_2"/> 
      <tablecol dataattribute="taskid"      id="..._tablebody_4"/> 
      <tablecol dataattribute="description" id="..._tablebody_3"/> 
    </tablebody> 
  </table> 

  <section id="selectrepairtasks_btn_section"> 
    <sectionrow id="selectrepairtasks_btn_row"> 
      <section datasrc="mainrecord" id="selectrepairtasks_act_section"> 
        <buttongroup id="selectrepairtasks_act_bg"> 
          <pushbutton id="selectrepairtasks_cancel" label="Cancel" 
                      mxevent="dialogcancel"/> 
          <pushbutton id="selectrepairtasks_add" label="Add Selected Tasks" 
                      mxevent="ADDREPTASK" default="true"/> 
        </buttongroup> 
      </section> 
    </sectionrow> 
  </section> 
</dialog> 

‍

Leyéndolo desde el principio:

• el beanclass MultiselectDataBean proporciona el comportamiento de selección y, lo que es más importante, recuerda la selección a medida que el usuario navega por las páginas de la lista.

• parentdatasrc MAINRECORD vincula el cuadro de diálogo a la orden de trabajo abierta actualmente, de modo que la relación se resuelve a partir de ella.

• La relación TASKREPLOC proporciona las filas. Esta es también la fuente de datos que el script leerá.

• selectmode multiple y la primera tablecol, con mxevent toggleselectrow, generan la columna de casillas de verificación.

• inputmode readonly impide que alguien edite el catálogo de origen desde el selector.

• savemode onunload confirma la fuente de datos de la orden de trabajo al cerrar el cuadro de diálogo, lo cual es lo que hace persistir las filas de tareas que añade el script.
  ‍

Los dos botones en la parte inferior es donde reside la decisión de diseño. Cancel utiliza el evento dialogcancel predeterminado. El botón Add Selected Tasks utiliza mxevent="ADDREPTASK", la opción de firma del paso 1.
‍

Un error común: copiar un cuadro de diálogo de selección múltiple predeterminado y dejar su botón OK como mxevent="dialogok" con un atributo de valor. Ese valor nombra un método Java en el bean de la aplicación, por lo que ejecutará alegremente algo escrito para una tabla completamente diferente. Un script de automatización nunca puede ser nombrado ahí. Ejecute la opción de firma en su lugar.

Paso 4: El script de automatización

El script es un punto de inicio de acción en WORKORDER, vinculado a la opción de firma ADDREPTASK.
‍

# Script  : ADDREPTASK 
# Trigger : Action launch point — WORKORDER, signature option ADDREPTASK 
# Purpose : Copy the repair tasks ticked in the dialog onto the work order. 

from psdi.mbo import MboConstants 

# mbo here is MAINRECORD, the work order, because the button sits in a 
# section with datasrc="mainrecord" 
target_set = mbo.getMboSet("SHOWTASKS") 

# read the ticked rows straight out of the dialog's data bean 
session   = service.webclientsession() 
databean  = session.getDataBean("selectrepairtasks")   # the dialog id 
mboSet    = databean.getMboSet() 
selection = mboSet.getSelection() 

for task in selection: 
    location    = task.getString("LOCATION") 
    description = task.getString("DESCRIPTION") 

    new_task = target_set.add() 
    new_task.setValue("repairfacility",   location,    MboConstants.NOACCESSCHECK | MboConstants.NOVALIDATION_AND_NOACTION) 
    new_task.setValue("description",      description, MboConstants.NOACCESSCHECK | MboConstants.NOVALIDATION_AND_NOACTION) 
    new_task.setValue("assetnum",         None,        MboConstants.NOACCESSCHECK | MboConstants.NOVALIDATION_AND_NOACTION) 
    new_task.setValue("parentchgsstatus", False,       MboConstants.NOACCESSCHECK | MboConstants.NOVALIDATION_AND_NOACTION) 
    new_task.setValue("woacceptscharges", False,       MboConstants.NOACCESSCHECK | MboConstants.NOVALIDATION_AND_NOACTION) 

service.closeDialog()

La parte que merece la pena estudiar: las tres líneas que obtienen la selección. El script solicita a la sesión del cliente web el bean de datos detrás del cuadro de diálogo, mediante el ID del diálogo, luego solicita a ese bean su MboSet y llama a getSelection(). Eso devuelve solo las filas que el usuario marcó. Recorra el bean de datos y la selección estará ahí simplemente.

El resto es Maximo estándar.  

Verlo en funcionamiento

La orden de trabajo comienza con una lista de tareas vacía y un solo botón.
‍

Al hacer clic, se abre el cuadro de diálogo con las tareas disponibles para esa orden de trabajo.
‍

El planificador marca lo que necesita. La casilla de verificación del encabezado selecciona las tres a la vez.
‍

Un clic en Añadir tareas seleccionadas y el cuadro de diálogo se cierra, mostrando una lista de tareas completa.
‍

‍
Toda la interacción requiere cuatro clics.

Ampliación del patrón

Nada en esta solución es específico para tareas de reparación. Para adaptarla a un origen o destino diferente, solo es necesario cambiar cuatro elementos:

1. La relación en el cuadro de diálogo, que determina las opciones de selección del usuario.

2. Las columnas en la tabla del cuadro de diálogo.

3. La relación a la que se añade el script.

4. El bloque setValue que asigna un valor a otro.
   ‍

La opción de firma, la configuración del botón y la lógica de getSelection nunca cambian.
‍

Algo que debe quedar claro desde el principio: defina correctamente la relación de origen. Un selector que devuelve todas las filas de un catálogo es inutilizable con datos reales. Filtre por atributos relacionados en la cláusula where de la relación, no en el script, para que el cuadro de diálogo solo obtenga lo necesario para mostrarse.

Conclusión

Los cuadros de diálogo personalizados tienen fama de ser complicados, y la parte difícil es casi siempre la misma: lograr que un botón en pantalla acceda al código del servidor que normalmente gestiona Java. Una vez que sabe que un evento de botón puede abrir un cuadro de diálogo y que una opción de firma puede ejecutar un script, el resto es solo un pequeño Script de Automatización.