![](/cvo_files/imgs_sap_abap/logos/logo_cvo_academy_it.png)
✒️¿Qué cambia en ABAP a partir de SAP HANA?
¿Qué cambia en ABAP a partir de SAP HANA?
![¿Qué cambia en ABAP a partir de SAP HANA? ¿Qué cambia en ABAP a partir de SAP HANA?](https://www.cvosoft.com/cvo_files/imgs_sap_abap/og-images/234.jpg)
Cambios en ABAP a partir de SAP HANA
1. Nuevas opciones técnicas.
Desde el punto de vista de un desarrollador ABAP, el uso de SAP HANA proporciona las siguientes nuevas opciones técnicas:
Algunas aplicaciones que se ejecutaban en segundo plano debido a tiempo de respuesta, ahora se pueden convertir en aplicaciones interactivas de dialogo. Además, se puede mejorar la usabilidad y la funcionalidad de las transacciones de dialogo ABAP.
Dichas mejoras incluyen análisis integrados y búsquedas de texto completo con tolerancia a errores. Esta nueva herramienta se le conoce con el nombre Full Text Searches.
En este contexto, a menudo se menciona la convergencia del procesamiento de transacciones en línea OLTP, el procesamiento analítico en línea OLAP y las aplicaciones híbridas.
Las aplicaciones híbridas combinan funciones transaccionales y analíticas dentro de un sistema único para que los usuarios finales puedan tomas medidas directas basadas en conocimientos adquiridos en tiempo real a partir de análisis de datos. (por ejemplo, apoyados por algoritmos estadísticos para predicciones basadas en datos históricos)
2. Code Pushdown
Para que las aplicaciones aprovechen las innovaciones de hardware y software de SAP HANA, al menos una parte de la lógica de la aplicación debe ejecutarse en la base de datos.
Esto es importante si se realizan cálculos complejos con grandes cantidades de datos.
El proceso de mover código de aplicación de la capa de aplicación a la capa de base de datos se denomina pushdown de código o code Pushdown.
Hasta ahora, las aplicaciones ABAP utilizaban el paradigma data-to-code. Las aplicaciones optimizadas o desarrolladas para SAP HANA utilizan el paradigma code-to-data.
NOTA: La lógica de la aplicación se divide en dos secciones, la lógica de orquestación que controla los procesos de negocios y el flujo de datos y determina como se combinan y procesan los resultados del cálculo. Tomando como ejemplo el modelo de datos de vuelos, podríamos decir que un ejemplo de la lógica de orquestación sería después de guardar una reserva de vuelo, el sistema envía automáticamente un correo al viajero.
Por otro lado, la lógica de cálculo identifica los algoritmos utilizados para realizar cálculos basados en los datos de la aplicación. Tomando como ejemplo el modelo de datos de vuelos, podríamos decir que un ejemplo de la lógica de cálculo sería que, para sugerir el mejor vuelo para el viajero, el sistema analiza el vuelo histórico y los datos de reserva antes de una reserva y luego calcula un puntaje por vuelo.
Con data-to-code una aplicación o programa ABAP lee los registros de la base de datos. Los registros se almacenan en las tablas internas del servidor de aplicaciones.
La lógica de la aplicación se implementa en base a este principio. Para la presentación, los registros o los datos calculados en base a estos registros se transfieren a la interfaz gráfica del usuario. (SAP GUI, SAP Enterprise Portal, SAP NetWeaver Business Client NWBC). De este modo es posible enviar desde la BD millones de registros al servidor de aplicaciones.
Con code-to-data los datos de la aplicación también se colocan en la capa de base de datos. Sin embargo, parte de la lógica de la aplicación se ejecuta en la capa de aplicación, mientras que parte de ella se implementa en la capa de base de datos. En un caso extremo, toda la lógica de la aplicación se puede ejecutar en la capa de la base de datos. Nada cambia fundamentalmente en la ejecución de la lógica de presentación.
Al aplicar el paradigma code-to-data a un programa ABAP, ocurre lo siguiente: los datos de una aplicación code-to-data son almacenados en la base de datos.
La lógica de orquestación se implementa en el servidor de aplicaciones. La lógica de cálculo generalmente se ejecuta en la base de datos. Cuanto más complejo es el cálculo, más registros se necesitan para realizarlo, por lo que más valiosa será la ejecución en la base de datos.
Con este enfoque, la cantidad de registros transferidos desde la BD al servidor de aplicaciones se puede mantener al mínimo. Incluso si se necesitan millones de registros para un cálculo, el sistema solo transfiere los pocos cientos de registros que el usuario desea ver.
3. La base de datos como una caja blanca.
Gracias a la arquitectura del servidor de aplicaciones ABAP y a la independencia de la BD que proporciona Open SQL, podemos desarrollar aplicaciones ABAP sin conocer los detalles específicos de la BD.
Además de Open SQL, también podemos usar Native SQL. Con Native SQL podemos ejecutar operaciones específicas de la base de datos que no son compatibles con Open SQL.
Sin embargo, la desventaja de Native SQL es que los programas que utilizan operaciones específicas de la base de datos no se pueden ejecutar en todos los sistemas de BD admitidos por SAP.
Esta es probablemente la razón por la que solo hemos usado SQL nativo y operaciones especificas en casos excepcionales en el pasado. Generalmente la BD era vista como una caja negra o sistema cerrado.
Si la lógica de la aplicación, o al menos parte de ella, ahora debe ejecutarse (y posiblemente implementarse) en la base de datos, el conocimiento de los detalles específicos de la BD es muy útil.
Para beneficiarse realmente de SAP HANA y lograr un rendimiento óptimo, la base de datos debe convertirse en una “caja blanca”.
NOTA: CAJA NEGRA. Se denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce sin tener en cuenta su funcionamiento interno.
En otras palabras, de una caja negra nos interesará su forma de interactuar con el medio que le rodea, entendiendo que es lo que hace, pero sin dar importancia a como lo hace.
Por tanto, de una cada negra debe estar muy bien definidas sus entradas y salidas, es decir, su interfaz, en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.
Al optimizar programas para SAP HANA, siempre debemos preguntarnos si estos programas también van a utilizarse en diferentes sistemas de bases de datos. (Que a menudo es el caso).
Dentro de un programa podríamos diferenciar el código para SAP HANA y el código ABAP para otros sistemas de BD
Analizamos las principales características que presenta la plataforma ECLIPSE y presentaremos las nuevas herramientas para el desarrollo de programas ABAP y la gestión de la base de datos.
4. Calificaciones requeridas para los desarrolladores ABAP
¿Como deberían afrontar los programadores ABAP el impacto de SAP HANA en el desarrollo de aplicaciones?
Además de comprender los impactos descritos, para poder optimizar las aplicaciones ABAP existentes y desarrollar nuevas aplicaciones o tipos de aplicaciones basados en ABAP y SAP HANA, debemos adquirir experiencia.
Estudiar los programas y saber que patrones de código son candidatos para ser modificados.
Familiarizarnos con las herramientas de desarrollo que se utilizan para identificar los programas a optimizar para pasar al nuevo paradigma code-to-data y debemos ser capaces de ejecutar un análisis en tiempo de ejecución para identificar esos programas a fondo.
 
 
 
Sobre el autor
Publicación académica de Maximiliano Belgrado, en su ámbito de estudios para el Máster ABAP for HANA.
Maximiliano Belgrado
Profesión: Ingeniero en Software - Argentina - Legajo: FW60S
✒️Autor de: 10 Publicaciones Académicas
🎓Egresado del módulo:
Disponibilidad Laboral: PartTime