SAP Build Apps

Un proyecto de SAP Build Apps pasa por cuatro etapas:

1. Crear. Los proyectos se crean en el lobby de SAP Build, ya sea como app web y móvil o como back-end de aplicación.
2. Diseñar. Quien construye la app coloca componentes en páginas dentro de un editor visual y les da estilo libremente. El comportamiento se define en el Logic Canvas como flujos lógicos: un evento, como pulsar un botón, seguido de funciones de flujo.
3. Conectar. Los datos provienen de destinations de SAP BTP de tipo OData o REST, que un administrador debe habilitar para SAP Build Apps en el SAP BTP cockpit, o de un back-end creado con visual cloud functions.
4. Entregar. Las apps web se compilan y despliegan en SAP BTP y pueden mostrarse en SAP Build Work Zone; las apps móviles se compilan como binarios de iOS para su publicación en el App Store o para pruebas locales, y como paquetes de Android en formato APK o AAB.

El resultado es una aplicación independiente que lee y escribe datos de SAP a través de API. Por lo tanto, SAP Build Apps es un cliente de SAP S/4HANA, nunca una modificación de este.

En abril de 2025, SAP presentó una oferta unificada de SAP Build que reúne el desarrollo de aplicaciones, la automatización de procesos y los sitios de negocio para usuarios low-code y code-first. En ese contexto, SAP declaró obsoleto SAP Build Apps como producto independiente, con efecto a partir del 23 de marzo de 2026. La documentación de SAP indica que:

• los proyectos nuevos deben iniciarse en SAP Build;
• los clientes existentes conservan el acceso a SAP Build Apps hasta que finalice su contrato vigente;
• una herramienta de migración transforma el archivo .mtar de los proyectos de front-end web en código React o SAPUI5 para SAP Business Application Studio, y cubre solo la UI;
• los datos de los proyectos de back-end se exportan como CSV y se importan manualmente en un proyecto CAP.

La herramienta se aplica solo a los front-ends de aplicaciones web; la página de SAP sobre el camino a seguir no describe ninguna migración para las compilaciones móviles nativas. Cualquier nueva inversión en SAP Build Apps debe empezar por comprobar la fecha de fin del contrato y la hoja de ruta actual de SAP Build.

• Libertad visual: la UI no está atada a los floorplans de SAP Fiori, lo que conviene a apps con marca propia, específicas de una tarea o con estilo de consumo.
• Web y móvil nativo desde un solo proyecto: el mismo proyecto visual puede orientarse a un navegador y a dispositivos móviles nativos.
• Prototipos rápidos: un business technologist puede producir en días un prototipo navegable y conectado a datos, lo que acorta las discusiones sobre requisitos.
• Conectividad con SAP a través de la plataforma: las destinations reutilizan la conectividad y la autenticación ya configuradas en SAP BTP.
• Encaje con clean core: las apps se ejecutan side-by-side y se comunican con SAP S/4HANA mediante API, por lo que no añaden código al núcleo del ERP.

Para apps pequeñas, bien delimitadas y con un responsable claro, SAP Build Apps entrega un front-end funcional con poco código.

• No es SAP Fiori elements. El diseño, la navegación y la accesibilidad son responsabilidad de quien construye la app; no hay un floorplan basado en anotaciones que mantenga las apps coherentes automáticamente.
• Las reglas de negocio pertenecen al back-end. Las validaciones, los precios o las contabilizaciones siguen teniendo que venir de las API de SAP S/4HANA. Reconstruirlos en lógica visual crea una segunda versión de la regla, no sincronizada.
• La lógica visual es más difícil de revisar a escala. Los flujos grandes son difíciles de comparar, probar y traspasar, una queja frecuente en las comunidades de profesionales cuando una app crece más allá de su primer responsable.
• Límites del ciclo de vida. La documentación de SAP señala que el versionado aún no es compatible con los proyectos de back-end, lo que afecta al transporte y a la reversión.
• Ciclo de vida del producto. La declaración como obsoleto del producto independiente convierte cada app existente de SAP Build Apps en un elemento de migración con un plazo fijado por el contrato.

Estos límites son propios del modelo low-code: SAP Build Apps acelera el front-end, mientras que la responsabilidad y la lógica de negocio siguen siendo decisiones de diseño ajenas a la herramienta.

Utilice estos criterios de decisión para una app como un registro de llegada de entregas para los conductores de Bright Freight en Alder Manufacturing:

Un error habitual es elegir la herramienta según quién está disponible y no según quién mantendrá la app dentro de tres años. SAP Build Apps encaja en apps acotadas, con responsable y específicas para un grupo de usuarios; las apps transaccionales coherentes encajan mejor en SAP Fiori elements.