NEW
Font size
WorksheetsSeminario - Primer Día
Total questions: 6
Worksheet time: 3mins
Para el módulo de 'Gestión de Gastos', la solución implementa el Cloud Application Programming Model (CAP) con Node.js y PostgreSQL. ¿Cuál es el principal impulsor económico y técnico ('driver') para desacoplar esto del entorno ABAP/HANA?
CAP elimina la necesidad de definir un modelo de datos, permitiendo una estructura de datos totalmente dinámica y sin esquema.
Node.js permite ejecutar la lógica de negocio directamente en el navegador del cliente, eliminando la carga del servidor.
La reducción de costos al utilizar una base de datos Open Source como PostgreSQL
PostgreSQL ofrece una integración nativa con los BAPIs de SAP ECC que HANA no puede proporcionar en la nube.
En el contexto de SAP Fiori Elements y SAP Build Work Zone, ¿cómo se logra la generación de interfaces de usuario (List Reports, Object Pages) sin escribir código JavaScript (cero código frontend)?
Utilizando 'Screen Personas' para grabar las acciones del usuario y generar scripts de automatización.
Mediante la inyección de CSS dinámico desde el Launchpad que interpreta los nombres de las tablas de base de datos.
A través de Anotaciones CDS (Semantic Annotations) en el modelo de datos que el framework Fiori Elements interpreta en tiempo de ejecución.
Mediante la compilación de vistas XML estáticas generadas por SAP Build Apps y exportadas al sistema ABAP.
Al utilizar SAP Build Apps para la interfaz móvil de solicitud, ¿qué mecanismo se emplea para interactuar con la lógica de negocio compleja y la persistencia de datos ubicada en el backend (CAP)?
Integración mediante envío de correos electrónicos estructurados que el backend procesa por lotes (batch input).
Conexión directa JDBC a la base de datos PostgreSQL omitiendo la capa de aplicación para mejorar la latencia.
Réplica de la lógica de negocio mediante fórmulas de Excel dentro de la propia aplicación móvil.
Consumo de APIs REST/OData expuestas por el servicio CAP mediante conectores de datos configurados visualmente.
En el flujo de orquestación con SAP Build Process Automation (BPA), cuando un gerente aprueba una solicitud, el sistema debe actualizar el estado de la entidad. ¿Cuál es el patrón de diseño correcto para realizar esta actualización manteniendo el principio de 'Clean Core'?
BPA envía un evento a SAP Event Mesh, y el frontend móvil escucha este evento para actualizar la base de datos local.
BPA utiliza un script SQL inyectado para modificar el campo 'STATUS' directamente en la tabla de base de datos.
BPA ejecuta una 'Service Task' que invoca una API del backend (CAP/RAP) para que este ejecute la actualización y registre el log.
El usuario debe entrar manualmente a la aplicación Fiori después de aprobar en el workflow para cambiar el estado.
Para modernizar las notificaciones y reemplazar el correo electrónico, se utiliza SAP Integration Suite para conectar con Microsoft Teams. ¿Qué capacidad específica de Integration Suite simplifica la autenticación y homogeneiza la API de terceros (Teams, Slack, entre otros.)?
Integration Advisor
Open Connectors
Cloud Connector
Value Mapping
Analizando el flujo 'End-to-End' completo de la solución presentada, seleccione la secuencia técnica correcta que garantiza la integridad transaccional y la experiencia de usuario descrita.
Build Apps (UI) -> RAP (Guarda Gastos) -> Event Mesh -> Teams (Aprueba).
CAP (Envía) -> Build Apps (Aprueba/Rechaza) -> BPA (Workflow) -> CAP (Actualiza Estado a Aprobado) -> Integration Suite (Notifica vía Email).
Fiori Elements (UI) -> BPA (Guarda y Aprueba) -> CAP (Solo lectura) -> Email.
Build Apps (UI) -> Integration Suite (Guarda en BD) -> BPA (Aprueba) -> Teams (Notifica).
