Form Entry Object Page

Una form entry object page es adecuada cuando toda la tarea consiste en introducir los datos de un único objeto nuevo y los usuarios no tienen nada que buscar antes: un formulario de solicitud, un registro, una solicitud de pedido sencilla iniciada desde un tile.

Criterios de decisión:

• No se necesita una lista ni hay contexto que revisar antes de escribir: una form entry object page.
• El objeto necesita tener a la vista un estado, datos clave o elementos relacionados: una object page estándar.
• Los usuarios buscan y luego crean o editan uno entre muchos objetos: un list report con una object page.
• Solo dos o tres campos: la creación mediante un diálogo desde un list report es más ligera.

Ejemplo: un empleado de Alder Manufacturing abre un tile "Create Purchase Requisition", llega directamente a un formulario vacío, introduce doce sillas de oficina de Cedar Office Supply y elige Create. Una form entry object page es la elección correcta cuando la app es el formulario.

Una form entry object page tiene tres regiones:

1. Título de la página: identifica lo que se está creando, por ejemplo una nueva solicitud de pedido.
2. Secciones del formulario: las secciones y los field groups definidos en UI.Facets, apilados en una sola página.
3. Barra de pie: las acciones que guardan o descartan el nuevo objeto, además del acceso a los mensajes de validación.

Lo que falta es deliberado: no hay header facets con datos clave, ni imagen, ni barra de anclas o pestañas entre secciones. Como la página muestra el mismo contenido que una object page estándar, una sección que funciona en una también funciona en la otra. Una form entry object page es una object page reducida al formulario y a la decisión de guardarlo.

En SAP Fiori elements para OData V4, tres ajustes convierten una object page en una página de entrada de formulario:

1. Configuración del destino en manifest.json: el destino usa la plantilla de object page, con content.header.visible y content.header.anchorBarVisible en false y el contenido de la cabecera no editable.
2. Modo de creación al iniciar: el componente de la app devuelve un modo preferido de creación a partir de sus parámetros de inicio, de modo que la app abre un objeto vacío en lugar de esperar una selección.
3. Un solo draft a la vez (opcional): el ajuste a nivel de app singleDraftForCreate hace que la app vuelva a abrir el draft no guardado del usuario en lugar de crear otro.

Las anotaciones no cambian: UI.Facets, UI.FieldGroup y UI.Identification definen el formulario exactamente igual que para una object page estándar. SAP documenta el patrón solo para SAP Fiori elements para OData V4. Es una propiedad de la app, no del sistema, así que funciona igual en SAP S/4HANA y en SAP BTP dondequiera que se ejecute un release de SAPUI5 que admita estos ajustes; compruebe el SAPUI5 SDK para su versión. Por tanto, configurar una form entry object page es una decisión de ajustes de página, no una tarea de modelado.

1. Olvidar el modo de inicio. Sin la preferencia de creación, la app no se abre en modo de creación y los usuarios no tienen una forma evidente de empezar.
2. Acumular drafts. Cada inicio abandonado puede dejar un draft; singleDraftForCreate vuelve a abrir el draft existente en su lugar.
3. Formularios largos sin navegación. Con la barra de anclas oculta, un formulario de diez secciones se convierte en un desplazamiento largo; divida el objeto o use una object page estándar con pestañas.
4. Editar objetos existentes en una página de entrada de formulario. Sin cabecera, los usuarios pierden el estado y los datos clave que necesitan al modificar datos.

Cuando la app se abre en modo de visualización o vacía en lugar de en modo de creación, compruebe primero los parámetros de inicio en Component.js, después que el primer destino sea la plantilla de object page y, por último, la configuración de draft del servicio. La mayoría de los problemas de una form entry object page son problemas de configuración del arranque, no de anotaciones.