Worklist

Una worklist encaja cuando el conjunto de elementos ya está definido por la tarea y el trabajo del usuario consiste en recorrerlo: solicitudes de pedido que esperan a un comprador, documentos a los que les falta un campo, entregas pendientes de confirmar. Procesar suele significar abrir un elemento, revisarlo y, después, completarlo o pasarlo a otra persona.

El criterio de decisión es dónde recae el esfuerzo de selección:

• Si los usuarios deben combinar varios criterios antes de que la lista tenga sentido, use un list report.
• Si la lista está predefinida y los usuarios actúan principalmente sobre ella, use una worklist.
• Si los elementos son tareas de workflow que un motor de workflow asigna al usuario, My Inbox ya proporciona la bandeja de entrada, con decisiones, reenvío y sustitución.

Ejemplo: el equipo de compras de Alder Manufacturing abre una worklist de solicitudes de pedido, ordenadas en pestañas por estado, y procesa una a una las solicitudes abiertas de Cedar Office Supply y Bright Freight. Una worklist es la opción adecuada cuando el primer paso de la tarea es procesar, no buscar.

Una página worklist tiene cuatro regiones, de arriba abajo:

1. Título de cabecera: el nombre de la cola de trabajo, sin la cabecera cargada de variantes de un list report.
2. Pestañas por estado: vistas opcionales, definidas por los desarrolladores, que dividen los elementos en grupos como abiertos, en proceso y completados. Cada pestaña puede mostrar el número de elementos que contiene.
3. Campo de búsqueda: una búsqueda de texto libre en la barra de herramientas de la tabla, que sustituye a la barra de filtros.
4. Tabla: los propios elementos, con acciones en la barra de herramientas o en cada fila y navegación a una object page para ver los detalles.

En SAP Fiori elements para OData V2, la worklist usa por defecto una responsive table, muestra el número de filas en el título de la tabla y oculta la gestión de variantes salvo que el desarrollador la habilite. La worklist de V2 tampoco ofrece exportación a hoja de cálculo. Una worklist renuncia a la barra de filtros a cambio de una página más plana que da prioridad a los elementos y sus acciones.

La configuración difiere entre las dos variantes de SAP Fiori elements:

Las pestañas de estado son vistas múltiples. Los desarrolladores las definen con anotaciones UI.SelectionVariant o UI.SelectionPresentationVariant y las enumeran en manifest.json. En V4, el modo de tablas múltiples representa una icon tab bar, y la opción showCounts, desactivada por defecto, añade el número de elementos a cada pestaña. Las columnas de la tabla proceden de UI.LineItem, y cada pestaña puede apuntar a su propio line item mediante una presentation variant. Por tanto, configurar una worklist es sobre todo configurar un list report sin la barra de filtros.

Sí. SAP documenta la worklist como un list report simplificado, por lo que se aplican las opciones del list report:

• Su propia aplicación: los puntos de extensión añaden columnas, acciones y vistas personalizadas; en OData V4, los building blocks y las custom pages del flexible programming model cubren carencias mayores. También se pueden añadir vistas personalizadas como pestañas adicionales mediante una controller extension.
• Una aplicación entregada por SAP: los adaptation projects creados con SAP Fiori tools, o la adaptación key user, modifican la aplicación sin modificar el código de SAP.

En SAP S/4HANA Cloud Public Edition, compruebe cuáles de estas vías admite SAP para la aplicación en cuestión.

Un límite práctico: cuando los usuarios piden varios campos de filtro, el requisito se ha convertido en un list report, y volver a habilitar la barra de filtros es más honesto que construir filtros personalizados alrededor de una worklist. Extender una worklist funciona bien para acciones y columnas, y peor para la búsqueda.

1. Usar una worklist para búsquedas abiertas. Sin barra de filtros, los usuarios se desplazan y buscan en lugar de seleccionar; un list report encaja mejor.
2. Apuntarla a un entity set enorme. Una barra de filtros oculta implica que el contenido se carga al inicio, por lo que las selection variants de las pestañas ya deben acotar los datos.
3. Pestañas que se solapan. Si un elemento puede aparecer en dos pestañas de estado, los recuentos dejan de cuadrar y los usuarios desconfían de la cola.
4. Esperar recuentos en tiempo real. En OData V4, actualizar el recuento de una pestaña mediante un side effect global solo funciona para una vista que el usuario ya ha abierto, así que planifique cómo se actualizan los recuentos después de las acciones.
5. Reconstruir My Inbox. Modelar las aprobaciones de workflow como una worklist personalizada duplica el reenvío, la sustitución y la gestión de tareas que My Inbox ya proporciona.

Cuando los recuentos parezcan incorrectos, compruebe en este orden: la selection variant de cada pestaña, los solapamientos entre pestañas y si la pestaña se actualizó después de la última acción. La mayoría de los problemas de una worklist son problemas de diseño de la selección, no defectos del framework.