Object Page

Una object page encaja siempre que la tarea gira en torno a un único business object: modificar un pedido de cliente y sus posiciones, crear un pedido de compra como draft, liberar una factura bloqueada o comparar un draft con la versión guardada. El floorplan sirve tanto para unos pocos campos como para objetos complejos con muchas secciones y tablas relacionadas.

Dos criterios ayudan a decidir:

• Si los usuarios necesitan contexto primero, como el estado del objeto, sus cifras clave y los elementos relacionados, encaja la object page estándar.
• Si los usuarios solo introducen datos y no necesitan cabecera ni navegación entre secciones, la form entry object page, una variante que oculta ambas, es más ligera.

Ejemplo: un comprador de Alder Manufacturing abre un pedido de compra para Bright Freight, revisa los datos de la cabecera y luego edita dos posiciones. Una object page encaja cuando la pregunta es "¿qué pasa con este objeto concreto?"

Una object page se compone de cinco áreas, de arriba abajo:

1. Título de cabecera: el título y el subtítulo del objeto, una imagen opcional, el estado de edición cuando existe un draft y una barra de herramientas con acciones como Edit, Delete, Related Apps y Share.
2. Facets de cabecera: datos clave como pares etiqueta-valor o pequeños elementos visuales, como un micro chart o una valoración. SAP recomienda un máximo de cinco pares etiqueta-valor.
3. Barra de navegación: anclas que saltan a cada sección dentro de una única página con desplazamiento, o pestañas que muestran una sección cada vez.
4. Área de contenido: secciones y subsecciones con formularios, tablas de elementos relacionados, gráficos o componentes reutilizables.
5. Barra de herramientas del pie: en modo de edición, Save o Create, las acciones determinantes y el botón de mensajes.

Al elegir una fila en una tabla de posiciones se abre una subobject page para la entidad hija, con botones de paginación para pasar de una posición a otra. Cada área de una object page responde a una pregunta: qué es esto, qué importa, dónde está y cómo termino.

En ABAP CDS, todos estos facets se escriben como entradas @UI.facet con un tipo, como una referencia a un field group o una colección, y un propósito que distingue los facets de cabecera de las secciones estándar. Solo se representan dos niveles de collection facets. La elección entre anclas y pestañas es un ajuste de manifest.json, sectionLayout, con Page como valor predeterminado en OData V4. Por tanto, la estructura de la object page se define casi por completo en UI.Facets.

Con un servicio habilitado para draft, la object page crea un draft en cuanto un usuario empieza a editar o crear. El draft se guarda en segundo plano mientras el usuario trabaja, lo que da lugar a cuatro comportamientos:

• el trabajo no guardado sobrevive a una interrupción o a un fallo, y el usuario puede retomarlo más tarde;
• el draft actúa como bloqueo, de modo que otros usuarios ven que el objeto se está editando;
• las validaciones y el control de campos se ejecutan durante la edición, no solo al final;
• Save convierte el draft en la versión activa.

SAP Fiori elements para OData V4 distingue los drafts exclusivos, propiedad de un usuario, de los drafts colaborativos que varios usuarios pueden editar juntos; SAP documenta los drafts colaborativos solo para servicios basados en RAP. Tanto RAP como CAP proporcionan la gestión de draft en el lado del servicio. Sin draft, nada llega al back-end hasta que el usuario guarda, y SAP recomienda aplicaciones sin draft solo para flujos sencillos. El soporte de draft es la decisión de servicio que más determina cómo se percibe la edición en una object page.

Sí. Las opciones dependen de quién es el propietario de la aplicación:

• Su propia aplicación: los puntos de extensión añaden secciones y subsecciones personalizadas, facets de cabecera, elementos de formulario, acciones y columnas de tabla; se pueden colocar componentes reutilizables en las secciones; con OData V4, los building blocks y las custom pages del flexible programming model cubren carencias mayores.
• Una aplicación entregada por SAP: adaptation projects (SAP Fiori tools) o adaptación key user, sin modificar el código de SAP.

En SAP S/4HANA Cloud Public Edition, las vías disponibles siguen los modelos de extensibilidad de SAP para esa edición; consulte la documentación de extensibilidad de su release.

Las secciones personalizadas tienen un coste de rendimiento. OData V4 ofrece request groups y carga diferida (lazy loading) para las object pages; en OData V2, la carga diferida debe activarse para cada sección personalizada. Una prueba práctica: si la mayoría de las secciones son personalizadas, una custom page o SAPUI5 freestyle puede ser más honesto que una object page muy extendida.

1. Demasiadas secciones en una única página con desplazamiento. Agrupe secciones o cambie a pestañas, que SAP recomienda para las grid tables.
2. Cabeceras sobrecargadas. Más de unos pocos datos de cabecera convierten la cabecera en un segundo formulario.
3. Anidamiento profundo de facets. Los collection facets por debajo del segundo nivel se ignoran, y un collection facet que envuelve un único reference facet puede representarse mal; use directamente el reference facet.
4. Comas en los títulos de sección. SAP Fiori elements usa las comas como delimitadores al agrupar mensajes, así que evítelas en los títulos de secciones y subsecciones.
5. Editar sin draft. Los usuarios pierden la posibilidad de retomar el trabajo y la información de bloqueo.

Cuando falta una sección, compruebe en este orden: la anotación UI.Facets en los metadatos del servicio, el nivel del facet, su target qualifier, cualquier condición UI.Hidden y un archivo de anotaciones local que pueda sustituir el UI.Facets del back-end. La mayoría de los defectos de una object page son problemas de estructura de facets, no errores de representación.