Hace unas semanas me topé con este tweet, en el que Matt Harding mencionaba todos los términos que dan título a este artículo:
Is it just me, or does having CAP, RAP, HANA and non-RAP Core Data Services, with InA semantic behaviour differences to Fiori Elements mean that doco on CDS is very hit and miss (currently trying to figure out semantics for InA Description field for use in SAC)?
— Matt Harding (@mattharding) November 27, 2020
Ciertamente es sorprendente la cantidad de términos que aparecen en el mismo, pero no está de más que sepamos qué es cada cosa; al menos, tener una ligera idea. Allá vamos:
RAP: RESTful Application Programming
Este modelo de programación nos permite diseñar aplicaciones UI5 que consuman información de nuestro backend mediante OData o APIs, la cual estará previamente modelada utilizando CDS.
Hay un curso en openSAP que os lo cuenta paso a paso, más que recomendable: Building Apps with the ABAP RESTful Application Programming Model
Para abrir boca, podéis hacer este breve tutorial: Get to Know the ABAP RESTful Application Programming Model
Y aquí os dejo el artículo que escribí hace una semanas:
ABAP RESTful Application Programming Model: ¿qué es?
CAP: Cloud Application Programming
En este caso hablaríamos de desarrollo cloud puro y duro, con lenguajes como Node.js o Java, o con el mismo ABAP, pero la versión cloud.
Tendremos distintas herramientas de desarrollos y distintos SDKs, aunque hay algo que es clave y común a lo que he comentado en el punto anterior, cuando hablaba de RAP: la forma de modelar los datos, utilizando CDS.
Podéis hacer un ejemplo, siguiendo los pasos que os cuentan en esta misión: Build a Business Application Using CAP for Node.js
Aquí os dejo un enlace donde podéis encontrar toda la información sobre esto: Welcome to CAP
Por supuesto, también hay un curso de openSAP: Building Applications with SAP Cloud Application Programming Model
Os recuerdo un artículo sobre esto:
SAP Cloud Application Programming Model: ¿qué es?
OData
OData, simplificando mucho, es el protocolo de comunicación estándar que utilizamos para que nuestras aplicaciones del frontend se entiendan con los datos que tenemos en el backend.
Sobre esto, escribí un artículo, donde intentaba aclarar qué era esto:
SAPUI5, OData y Fiori: pongamos un poco de orden
CDS: Core Data Services
Como hemos visto anteriormente, los CDS son la pieza clave para modelar nuestra información y que después sea consumida por nuestra aplicaciones.
Nuestra aplicaciones nunca deberían trabajar contra la base de datos, sino que se comunicarán a través de ella, vía consumo de CDS, los cuales me servirán para modelar dicha información y añadir capacidades adicionales a la misma.
Más detalles sobre esto:
Core Data Services: ¿esto qué es?
Fiori Elements
De esto os hablé recientemente, como digo en el artículo, básicamente son una serie de plantillas de aplicaciones Fiori con una funcionalidad determinada y preparadas para consumir información, que habrá sido previamente modelada con CDS y “traducida” por OData.
Para no repetirme, os dejo aquí el artículo de hace unos días:
SAP Fiori Elements: ¿qué es esto?
HANA
HANA, aparte de ser una base de datos en memoria, es una plataforma que nos ofrece capacidades adicionales a lo que sería el simple almacenamiento de datos: análisis geoespacial, de texto, predictivo…
Sobre alguna de estas capacidades, podéis encontrar también varios cursos en openSAP: Curso de SAP HANA en openSAP
Y, por supuesto, no olvidéis que ya podemos tener HANA en la nube:
SAP HANA Cloud: ¿qué es?
InA: Information Access
Cuando hablamos de S/4HANA, hablamos muchas veces de analíticas embebidas, que tenemos disponibles gracias a esa doble capa (transaccional y analítica) que nos ofrece HANA.
Además, a veces querremos consumir dicha información desde una herramienta como SAP Analytics Cloud (SAC), por ejemplo, para lo que necesitaremos poder conectarnos directamente a SAP HANA.
Bien, pues esto es lo que hacemos con el servicio InA: exponer la información que tenemos en HANA y permitir que SAC la consuma en directo.
Aquí tenéis un documento específico sobre esto (de 2017, ojo): Live Data Connection to SAP HANA and SAP Cloud Platform
SAC: SAP Analytics Cloud
SAP Analytics Cloud es un producto con capacidad de visualización de datos, predicción y planificación, que está llamado a sustituir a muchas de la herramientas actuales (Lumira, Web Intelligence, BEx…) en el corto/medio plazo y que va a estar integrada como herramienta de reporting en la mayoría de las soluciones SAP.
Si no os habéis pegado aún con ella, os recomiendo que empecéis por este curso de openSAP: Intelligent Decisions with SAP Analytics Cloud
Con una cuenta trial os será suficiente para seguir el curso y, además, podéis encontrar muchísima información más, en la página oficial del producto: SAP Analytics Cloud
Además, ahora la cuenta trial trae también capacidades de planificación, como os conté en este otro artículo:
SAP Analytics Cloud ahora por 90 días y con planificación
Bueno, pues ya he repasado todos los términos que aparecían en el mencionado tweet… ¿es necesario conocerlos todos? Digamos que es importante que al menos os suenen. Después, dependiendo de tu especialización, tendrás que profundizar más en unos o en otros.
Si nos ceñimos, por ejemplo, a un perfil desarrollador y otro más de analista de datos, el primero debería conocer RAP, CAP, OData y Fiori Elements, mientras que el segundo tendría que pegarse más con HANA, InA y SAC.
¿Y los CDS? Los dos y cualquiera que quiera entender cómo estructura SAP la información de todas sus aplicaciones y cómo eso ha ido evolucionando hacia modelos más generales como el SAP One Domain Model.
Madre mía, lo que puede dar de sí un tweet, ¿no? 😉
Así es, son muchos las piezas ( Legos jaja) disponibles para armar nuestras propuestas de soluciones SAP Cloud nativas (Foundry). Muy Feliz de que SAP abra las puertas a las tecnologías libres (Java, Node.JS) y las soporte con CDS, creando un excelente framework como lo es CAP.