Analytical List Page (ALP)

Una analytical list page es adecuada cuando los usuarios necesitan ver un patrón antes de saber sobre qué elementos actuar. El gráfico responde "¿dónde está el problema?", y la tabla de debajo responde "¿qué documentos?".

• Si los usuarios ya conocen su selección y solo necesitan las filas, un list report es más sencillo.
• Si los usuarios necesitan un gráfico, filtros y los elementos en una sola página, use una analytical list page.
• Si un rol necesita un resumen de varios temas, una overview page resulta más adecuada.
• Si el objetivo es seguir un único KPI gobernado desde el launchpad, una app de KPI de SAP Smart Business es la opción más cercana.

Ejemplo: un responsable de compras de Alder Manufacturing selecciona la barra de Bright Freight en un gráfico de valor de pedidos por proveedor y abre los elementos retrasados en la tabla ya acotada. La app Monitor Purchase Order Items de SAP (F2358) sigue este patrón. Una analytical list page es la elección correcta cuando el análisis y la acción forman parte de la misma tarea.

Una analytical list page se compone de cuatro regiones, de arriba abajo:

1. Cabecera: el título de la página, las variantes de página y, de forma opcional, KPI tags: etiquetas breves y pulsables con un valor de KPI que abren una card de KPI.
2. Barra de filtros visuales: pequeños gráficos, uno por campo de filtro, cada uno con una medida por valor de dimensión. Elegir una barra o un punto establece el filtro. Una barra de filtros compacta con campos clásicos es el modo alternativo, y se mantiene sincronizada.
3. Gráfico principal: un gráfico interactivo de los datos filtrados. Seleccionar un segmento del gráfico acota la tabla.
4. Tabla: los elementos subyacentes, con acciones y navegación a una object page o a otra app.

El área de contenido muestra el gráfico, la tabla o ambos (la vista híbrida). El rasgo que define una analytical list page es que el gráfico y la tabla comparten un mismo estado de filtro, de modo que cada selección refina ambos.

En OData V2, la analytical list page tiene su propia plantilla y solo funciona con servicios analíticos; defaultContentView y defaultFilterMode fijan la vista y el modo de filtro iniciales. En OData V4, un list report recibe una configuración views con un primary path para el gráfico, un secondary path para la tabla y un defaultPath. Si una ruta configurada no existe, la app V4 no se carga. Por tanto, una analytical list page solo es tan buena como el modelo analítico que hay detrás.

Un filtro visual es un campo de filtro representado como gráfico, construido sobre la ayuda de valores del campo:

1. La anotación ValueList del campo referencia una presentation variant.
2. El filtro visual usa solo la primera medida y la primera dimensión de su primer gráfico.
3. El tipo de gráfico decide qué se muestra: un gráfico de barras muestra los tres valores superiores o inferiores; un gráfico de líneas muestra los seis primeros o últimos puntos de datos y necesita una dimensión de fecha u hora; OData V2 ofrece además un gráfico de anillo.
4. La selección del usuario se convierte en un valor de filtro, que también aparece en la barra de filtros compacta.

La ayuda de valores que hay detrás del filtro visual debe devolver los mismos registros que la del campo de filtro normal; de lo contrario, las selecciones dejan de sincronizarse. SAP documenta los filtros visuales en OData V4 como soportados con restricciones; por ejemplo, solo se representan gráficos de barras y de líneas, y solo se usan la primera medida y la primera dimensión de la anotación del gráfico. Los filtros visuales hacen que una analytical list page sea rápida de explorar, a costa de un modelado adicional para cada campo de filtro.

Sí, según la versión de OData y el propietario de la app:

• OData V2, app propia: la analytical list page tiene sus propias extensiones de app: acciones personalizadas en la tabla y en el gráfico, filtros personalizados para la barra de filtros compacta y los KPI tags, y una API de actualización.
• OData V4, app propia: la analytical list page es una variante del list report, así que parta de las opciones de extensión del list report y compruebe en el SAPUI5 SDK cuáles admite la variante ALP.
• Una app entregada por SAP: adaptation projects o adaptación key user, sin modificar el código de SAP; en SAP S/4HANA Cloud Public Edition, use solo las opciones de extensibilidad que SAP documenta para esa edición.

Dos comportamientos integrados son relevantes. En el flexible column layout, la analytical list page solo admite el diseño de dos columnas con la primera columna expandida. Cuando My Home está habilitado, los usuarios pueden convertir el gráfico en una card de Insights, salvo que los desarrolladores oculten esa opción. Las extensiones de una analytical list page deben quedarse en los márgenes, porque la interacción entre gráfico y tabla es lo que los usuarios valoran.

1. Construir sobre un servicio sin agregación. Los gráficos necesitan un entity set que admita agregación; un servicio puramente transaccional no puede alimentarlos.
2. Rutas de anotación mal escritas. En OData V4, un primary path o secondary path erróneo impide que la app se cargue.
3. Ayudas de valores que no coinciden. Cuando el filtro visual y el filtro normal leen registros distintos, las selecciones se desincronizan.
4. Filtros visuales de líneas sobre dimensiones que no son fechas. No se representan; use un gráfico de barras.
5. KPI tags que contradicen los tiles de KPI. Consultas distintas detrás de un mismo nombre de KPI producen cifras distintas.

Cuando el gráfico principal está vacío, compruebe por este orden: el soporte de agregación en el entity set, la ruta del gráfico en manifest.json, un UI.Chart por defecto sin qualifier y, después, los filtros y las autorizaciones del usuario. La mayoría de los defectos de una analytical list page son defectos del modelo de datos y de las anotaciones que afloran en el gráfico.