✒️ABAP HANA / ¿Qué cambia en ABAP a partir de SAP HANA? Por Juan Hernández

Lección 2: Que cambia en ABAP a partir de SAP HANA?

Analizamos a nivel conceptual que cambia en ABAP a partir de SAP HANA.

CAP 1.- Cambios en ABAP a partir de SAP HANA

Después de haber comprendido como ha sido la evolución de las bases de datos en los últimos 20 años, que es SAP HANA, cuáles son sus principios generales, su arquitectura y demás cuestiones, no preguntamos:

¿Como afectan todas las innovaciones de software anteriormente descritas al desarrollo de aplicaciones en ABAP?

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:

o 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, mejoramos el tipo de respuesta inmediata para las consultas activadas por los usuarios finales dentro de las transacciones de diálogo.

o Ampliar

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

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.

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

CAP 2.- Resumen

Ejemplo de programación para dato-to-code

REPORT z_sale_items.

DATA p_date TYPE d.

p_date = ‘20141125’.

DATA (lo_timer) = cl_abap_runtime=>créate_hr_timer( ).

DATA (lo_list) = NEW ZCL_SALE_ITEMS ( ).

DATA (timeA) = lo_timer=>get_runtime ( ).

lo_list => GET_SALES_FROM_DAY(

EXPORTING

i_date = p_date

IMPORTING

T_invoice_header = DATA(lt_invoice_head)

t_invoice_item = DATA(lt_invoice_item)

t_customer_info = DATA(lt_customer_info) ) .

DATA(timeB) = lo_timer=> get_runtime( ).

DATE (elapsed_time) = (timeB – timeA ) / 1000.

Cl_demo_output=>next_section(title = |Elapsed Runtime (ABAP): (elapsed_time) ms.| ).

Cl_demo_output=>write_data( name = ‘customer Information’ value = lt_csutomer_info ) .

Cl_demo_output=>display( ).

Este reporte ejecuta un query y devuelve los datos de una factura de una fecha deterninada. Tarda 2700ms

Ejemplo de programación para code-to-data.

REPORT z_sale_items_amdp.

DATA p_date TYPE d.

p_date = ‘20141125’.

DATA (lo_timer) = cl_abap_runtime=>créate_hr_timer( ).

DATA (lo_list) = NEW zcl_demo_paid_on_date_amdp ( ).

DATA (timeA) = lo_timer=>get_runtime ( ).

lo_list =>paid_on_date(

EXPORTING

iv_payment_date = p_date

IMPORTING

et_invoice_header = DATA(lt_invoice_head)

et_invoice_item = DATA(lt_invoice_item)

et_customer_info = DATA(lt_customer_info) ) .

DATA(timeB) = lo_timer=> get_runtime( ).

DATE (elapsed_time) = (timeB – timeA ) / 1000.

Cl_demo_output=>next_section(title = |Elapsed Runtime (AMDP): (elapsed_time) ms.| ).

Cl_demo_output=>write_data( name = ‘customer Information’ value = lt_csutomer_info ) .

Cl_demo_output=>display( ).

Este reporte ejecuta un query y devuelve los datos de una factura de una fecha determinada. Tarda 320 ms.

ADMP = Managed data base Procedures

AMDP nueva herramienta de SAP que nos permite crear procedimientos de bases de datos en ABAP