¿No te suena eso de SAP Fiori Practitioner Forum? Se trata de un grupo privado de expertos de SAP Fiori que se reúne el tercer jueves de cada mes para ver lo último de SAP Fiori de la mano de los primeros espadas en la materia.
Suena un poco a los Carbonari pero si estás interesado en participar solo tienes que ponerte en contacto con Toros Aledjian. Aunque todos los Webinar del mundo son relativamente insufribles, este se hace llevadero.
La sesión del 16 de Julio me ha parecido especialmente relevante porque se ha centrado en el uso de SAP Fiori Tools desde SAP Business Application Studio (BAS). Cuanto más voy viendo de esta tecnología más potente me parece.
En el post donde presentábamos SAP Fiori Elements terminaba diciendo que el mayor problema que tiene esta tecnología es que una vez que las aplicaciones están terminadas se dispara el tiempo de desarrollo de las modificaciones sobre la aplicación construida.
¿Qué es Fiori Elements?
Vamos a hacer un primer acercamiento al concepto de Fiori Elements, una tecnología fundamental en el desarrollo actual de interfaces de usuario en SAP.
Fiori se presento oficialmente allá por 2013 (para los que dicen que esto es nuevo) con un paquete inicial de 25 aplicaciones que pasaron a ser 81 en 2014. Esto es lo que después se llamó Fiori 1.0…
Precisamente para solucionarlo SAP Fiori Tools provee al desarrollador de Fiori en BAS de herramientas en forma de desarrollo guiado para hacer esas modificaciones a las aplicaciones hechas con Fiori Elements de forma rápida y sencilla reduciendo además la cantidad de código necesario.
SAP está dando respuesta de esta forma al mayor problema que había con su actual modelo de desarrollo de interfaces de usuario. Se incrementa la productividad del desarrollador acelerando significativamente el proceso de creación de aplicaciones y su posterior mantenimiento.
Además, de esta forma se sigue empoderando a los desarrolladores que vienen del Abap tradicional dando valor a un importante capital humano que tienen los clientes, partners e independientes.
Vamos a ver un poco lo que se pudo ver en la reunión.
Tras una presentación de las ventajas de Fiori Elements, entra en escena SAP Fiori Tools como (traduzco a mi manera) «instrucciones de desarrollo guiado paso a paso y generación de fragmentos de código«.
Ya sabéis la obsesión que tiene SAP de cambiar los nombres a todo, no vaya a ser que nos relajemos y nos despistemos. SAP llama Fiori Tools a todo lo que tiene que ver con la creación de una aplicación SAP Fiori Elements. Sin embargo todo eso ya existía tanto en BAS como en el WebIDE, para mi SAP Fiori Tools es lo nuevo que han entregado ahora, la parte de los Desarrollos Guiados.
Es importante destacar que los Desarrollos Guiados de SAP Fiori Tools están disponibles en SAP Business Application Studio (BAS) y Visual Studio Code, pero no lo tenemos (ni lo tendremos) en SAP WebIDE Full-Stack. Una razón más para emprender la migración de nuestro entorno de desarrollo.
En efecto, el buscador de procedimientos disponibles es muy sencillo y los pasos fáciles de seguir, generando al final el código automáticamente en el sitio apropiado.
Toda la parte del modelado de la aplicación en BAS se simplifica considerablemente respecto al WebIDE.
Nos quedamos con tres ideas finales:
- SAP Fiori Elements & SAP Fiori Tools aceleran el desarrollo de aplicaciones Fiori.
- SAP Fiori Elements proporciona una Experiencia de Usuario consistente.
- El uso de SAP Fiori Tools reduce la cantidad de código en las aplicaciones.
Para terminar, una vez dicho lo maravillo que es Fiori Elements y Fiori Tools, quisiera destacar donde veo yo el handicap de las Fiori Tools. Estamos hablando de una tecnología que proporciona herramientas en el front para el desarrollo de aplicaciones y que es común tanto para el desarrollo de aplicaciones CAP como RAP, es decir, desarrollo de aplicaciones siguiendo la metodología SAP Cloud Application Programing Model y también aplicaciones que vienen del ABAP RestFull Programming Model.
Me centro en este segundo caso, ya sea que estamos en el servicio ABAP que tenemos disponible en el entorno Cloud Foundry de SCP o ya sea que venimos de la arquitectura convencional de S/4 HANA con un sistema On premise. En este escenario considero que es un error el planteamiento de algunas de las utilidades de SAP Fiori Tools porque muchos de estos procedimientos se basan en anotaciones en la aplicación. El lugar correcto para la extensión de un servicio es el backend preferiblemente antes que el front-end. Es decir, siempre es preferible una CDS extensión de metadatos antes que una anotación en el front-end. ¿Por qué?
- Es el camino que está siguiendo el propio SAP en sus nuevos desarrollos. Inicialmente SAP creaba sus CDS de consumo junto con sus metadatos pero actualmente crea las CDS de consumo casi vacías y una CDS extensión de metadatos que utiliza como base para la construcción de la aplicación Fiori. Estas CDS de extensión quedan categorizadas para que puedan ser fácilmente substituidas (ampliadas) por una CDS de extensión a nivel de partner o de cliente.
- La CDS con metadatos se consultará más fácilmente por un desarrollador de backend e incluso por un consultor funcional.
- Por mi experiencia, las aplicaciones SAP Fiori Elements se rompen. Así, directamente. Especialmente si juegas con el editor visual. Hay casos donde no me ha quedado más remedio que rehacer la aplicación. Una CDS no falla jamás.
- Toda la parte front-end cambia a un ritmo vertiginosos mientras que la parte back-end va a un ritmo más reposado. Teniendo la semántica en el back queda todo más estable.
- Si la semántica está en el back-end dejamos abierta la puerta a que pueda ser explotada por otra tecnología diferente a SAPUI5.
Si te has quedado con ganas de más te recomiendo que te unas al grupo y consultes el contenido disponible en SAP Jam. Ahora llega el momento de remangarse y darle caña…