✒️¿Qué cambia en ABAP a partir de SAP HANA?

Luego de haber comprendido cómo ha sido la evolución de las bases de datos en los últimos 20 años, qué es SAP HANA, cuales son sus principios generales, su arquitectura y demás cuestiones, seguramente nos estamos preguntando:

¿Cómo afectan todas las innovaciones de software anteriormente descriptas al desarrollo de aplicaciones en ABAP?.

A lo largo de esta lección contestaremos esta interesante pregunta describiendo las opciones técnicas que benefician a la programación ABAP cuando utilizamos SAP HANA y explicaremos el concepto de Code PushDown.

Desde el punto de vista de un desarrollador ABAP, el uso de SAP HANA proporciona las siguientes nuevas opciones técnicas:

Acelerar

Con SAP HANA podemos acelerar los programas ABAP existentes. Por un lado, esto nos permite reducir el tiempo necesario para ejecutar trabajos en segundo plano o de fondo de manera significativa. Por otro lado, podemos mejorar el tiempo de respuesta inmediata para las consultas activadas por los usuarios finales dentro de las transacciones de diálogo también conocidas como transacciones online.

Ampliar

Podemos utilizar SAP HANA para personalizar y extender las aplicaciones existentes de una manera que va más allá de la aceleración única de estas aplicaciones.

Algunos programas ABAP que solo se podían ejecutar como trabajos en segundo plano o de fondo en el pasado debido a su tiempo de respuesta ahora se pueden convertir en transacciones interactivas de diálogo o online con SAP HANA. Además, se puede mejorar la usabilidad y la funcionalidad de las transacciones de diálogo ABAP implementando SAP HANA.

Dichas mejoras incluyen análisis integrados y búsquedas de texto completo con tolerancia a errores. A esta nueva herramienta de SAP HANA se la conoce con el nombre Full Text Searches.

Innovar

Finalmente podemos desarrollar aplicaciones nuevas e innovadoras y tipos de aplicaciones utilizando ABAP y SAP HANA.

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 tomar 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).

Para que las aplicaciones aprovechen las innovaciones de hardware y software de SAP HANA, al menos parte de la lógica de la aplicación debe ejecutarse en la base de datos.

Esto es especialmente 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 la 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 específicamente para SAP HANA utilizan el paradigma code-to-data.

Como podemos ver en la Figura anterior, los datos de la aplicación se colocan en la capa de la base de datos cuando se utiliza el paradigma data-to-code. Básicamente, la lógica de la aplicación, que comprende la lógica de orquestación y lógica de cálculo, se ejecuta por completo en la capa de aplicación. La lógica de presentación se ejecuta en la capa de presentación.

AUDIO ACLARATIVO: La lógica de la aplicación se divide en dos secciones, por un lado la "lógica de orquestación" la cual controla los procesos de negocio y el flujo de datos y determina cómo 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 que después de guardar una reserva de vuelo, el sistema envía automáticamente un correo electrónico 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 vuelo, podríamos decir que un ejemplo de la lógica de cálculo sería que para sugerir el mejor vuelo a un 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 de usuario SAP GUI, SAP Enterprise Portal o SAP NetWeaver Business Client NWBC. Con este procedimiento, es posible enviar millones de registros desde la base de datos 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 el cálculo, por lo que más valiosa será la ejecución en la base de datos.

Con este enfoque, la cantidad de datos transferidos desde la base de datos 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 calculados que el usuario desea ver.

Gracias a la arquitectura del servidor de aplicaciones ABAP y a la independencia de la base de datos que proporciona Open SQL, podemos desarrollar aplicaciones ABAP sin conocer los detalles específicos de la base de datos.

Además de Open SQL, también podemos utilizar 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 bases de datos admitidos por SAP.

Esta es probablemente la razón por la que solo hemos usado SQL nativo y operaciones específicas de la base de datos en casos excepcionales en el pasado.

La base de datos generalmente era vista como una caja negra o un sistema cerrado con una estructura interna que no era necesario considerar.

Sin embargo, 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 base de datos es muy útil.

Para beneficiarse realmente de SAP HANA y lograr un rendimiento óptimo, la base de datos debe convertirse en una "caja blanca".

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 (en ocasiones, otros elementos que también podrían ser cajas negras) entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace.

Por tanto, de una caja negra deben 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).

Si un programa se va a utilizar no solo en SAP HANA sino también en otros sistemas, debemos tener en cuenta con mucho cuidado los pros y contra de optimizarlo.

Si bien podríamos, por ejemplo, tener un rendimiento significativamente mejor, tenemos por el otro lado como desventaja el código ABAP dependiente de la base de datos que resulta de esta optimización.

Dentro de un programa, podríamos distinguir entre el código ABAP para SAP HANA y el código ABAP para otros sistemas de bases de datos mediante IF ... ENDIF o CASE...ENDCASE.

Si el código ABAP se vuelve demasiado complejo, podríamos modularizar cada implementación para cada base de datos. En el caso extremo, deberíamos desarrollar un programa ABAP separado para cada sistema de base de datos.

Luego de haber visto a lo largo de esta lección algunos de los cambios conceptuales más significativos que presenta SAP HANA desde el punto de vista del desarrollo ABAP, nos preguntamos:

¿Cómo deberían afrontar los programadores ABAP el impacto de SAP HANA en el desarrollo de aplicaciones?.

No es suficiente simplemente comprender los impactos descritos sino que para poder optimizar las aplicaciones ABAP existentes y desarrollar nuevas aplicaciones o tipos de aplicaciones basados en ABAP y SAP HANA, los desarrolladores necesitamos adquirir experiencia.

Para optimizar las aplicaciones existentes para SAP HANA, especialmente teniendo en cuenta la performance, necesitamos saber que programas y patrones de código dentro de esos programas son los candidatos a ser modificados.

Debemos 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.