✒️Las recomendaciones para desarrollar aplicaciones ABAP en SAP HANA

1 | Los tips prácticos importantes al desarrollar aplicaciones ABAP en SAP HANA

Vamos a analizar algunos consejos prácticos sobre temas que son importantes al desarrollar aplicaciones ABAP en SAP HANA.

Estos se dividen en las siguientes áreas:

Recomendaciones generales: proporcionaremos algunas recomendaciones generales para el desarrollo de ABAP en SAP HANA. Principalmente presentaremos los detalles que debemos considerar para la migración y optimización de los programas ABAP.

Pautas de performance: La velocidad de ejecución de los programas, naturalmente, desempeña un papel crucial en el contexto de SAP HANA.

Muchos escenarios de uso implican el acceso a grandes conjuntos de datos en tiempo real.

Una comprensión sólida de las pautas y técnicas para lograr un rendimiento óptimo es esencial.

Proporcionaremos una visión general de las recomendaciones existentes y nuevas, y discutiremos particularmente los cambios en comparación con las bases de datos tradicionales.

Analicemos a continuación los dos aspectos que acabamos de mencionar a través de ejemplos positivos y negativos.

2 | Las recomendaciones generales

Hemos recopilado algunas recomendaciones generales que debemos seguir para realizar la migración y el desarrollo en SAP HANA. Analicemos en detalle cada aspecto a tener en cuenta.

---

2.1 | El Almacenamiento por columnas Vs Almacenamiento por filas

Cuando creamos una tabla base de datos poder elegir crearla con almacenamiento por columnas (columnar) o por filas.

Por defecto la tabla se creará con almacenamiento por columnas.

Podemos analizar grandes conjuntos de datos de manera más eficiente en el almacenamiento por columnas.

SAP recomienda que configuremos todas las tablas bases de datos utilizando almacenamiento por columnas, siempre que no haya una razón específica para almacenarlas por filas.

Las tablas que contienen datos de la aplicación siempre se almacenan por columnas porque es muy probable que estos datos también se utilicen en escenarios de análisis.

Esto se aplica particularmente a las tablas que contienen una gran cantidad de registros de datos porque el almacenamiento por columnas proporciona mejores propiedades de compresión.

Esto también se aplica a las tablas que se utilizarán para búsquedas de texto.

AUDIO ACLARATIVO: Existen motivos para utilizar todavía el almacenamiento por filas en una tabla, Por ejemplo, si se accede a una tabla predominantemente mediante declaraciones en lenguaje de manipulación de datos DML en el tiempo, por ejemplo mediante Updates Insert o Delete, esta no puede ser una tabla de aplicaciones en la que posteriormente deseamos realizar análisis. Por lo tanto, principalmente las tablas técnicas de SAP son elegibles para el almacenamiento por filas. Los ejemplos incluyen tablas para el procesamiento de actualizaciones correspondientes al paquete STSK o para el procesamiento de llamadas a función remota RFC correspondientes al paquete SRFC. Normalmente se accede a estas tablas con un Select Single.

2.2 | Las implementaciones específicas de SAP HANA

En el desarrollo de ABAP en SAP HANA, debemos distinguir dos escenarios:

Implementaciones independientes de la base de datos: por ejemplo, utilizando Open SQL y ABAP CDS.

Implementaciones que utilizan funciones específicas de SAP HANA: por ejemplo, SQL nativo y HANA CDS.

En el primer caso, no tenemos que considerar nada especial desde la perspectiva de la logística del software.

Utilizamos SAP HANA como cualquier otra base de datos, pero nos beneficiamos directamente de la alta velocidad de procesamiento de SAP HANA en muchos escenarios.

Nuestros desarrollos son ejecutables en todos los sistemas de bases de datos soportados por SAP.

Al usar las funciones nativas de SAP HANA, inicialmente se aplican las mismas implicaciones que las habituales si definimos partes de una aplicación específicamente para un sistema de base de datos (por ejemplo, a través de SQL nativo, Hints otras técnicas).

AUDIO ACLARATIVO: Al diseñar la aplicación debemos considerar las siguientes preguntas, ¿existen sistemas con un sistema de base de datos diferente en nuestro entorno de trabajo o en el entorno del cliente? ¿Cuán fundamentales son las funciones específicas de la base de datos para nuestra aplicación?, ¿Está involucrada la calidad central de la aplicación?, ¿El desarrollo en SAP Hana se llamará únicamente a través de aplicaciones basadas en ABAP o también a través de otros canales?.

Es difícil dar una recomendación general sobre cuándo tiene sentido utilizar una implementación de base de datos específica. Será necesario realizar un análisis del caso.

Para la optimización de rendimiento de una aplicación ABAP existente, es recomendable que procedamos inicialmente utilizando herramientas estándar.

Las siguientes pautas nos proporcionan ayuda en este punto:

Primero Open y luego Native

Preferiblemente debemos utilizar las vistas de Open SQL y CDS antes de implementar SQL nativo, vistas de SAP HANA o procedimientos de base de datos.

Las funciones abiertas se integran de manera óptima con el entorno de desarrollo ABAP y el tiempo de ejecución de ABAP.

El servidor de aplicaciones ABAP comprueba exhaustivamente sus objetos de desarrollo, y no necesita ningún usuario adicional para la base de datos SAP HANA.

Primero ABAP CDS y luego HANA CDS

Debemos utilizar los procedimientos de la base de datos ABAP en lugar de los procedimientos de la base de datos SAP HANA.

Los objetos de desarrollo gestionados por ABAP AS se vinculan de forma óptima con la gestión del ciclo de vida ABAP.

Podemos sincronizar fácilmente los procedimientos de la base de datos ABAP con otros objetos ABAP y transportarlos.

---

2.3 | Las recomendaciones para la migración

Brindaremos algunos consejos para tener en cuenta al migrar un sistema existente a SAP HANA.

Una regla básica es que las aplicaciones ABAP son totalmente compatibles.

Pero igualmente debemos tener en cuenta algunos puntos importantes:

Código ABAP dependiente de la base de datos

Si usamos código ABAP dependiente de la base de datos en los desarrollos existentes, debemos probarlo como en cualquier migración de datos y ajustarlo para la base de datos SAP HANA si es necesario.

Un ejemplo de esto es la utilización de SQL nativo a través de la declaración EXEC SQL o los hints de base de datos; estas posiciones en el código deben verificarse.

Si bien los hints de la base de datos ya no se ejecutan en la nueva plataforma cuando se migra a SAP HANA, siempre será necesaria una comprobación exacta para el SQL dependiente de la base de datos, ya es muy probable que ocurran errores a menos que intervengamos.

Los Hints de la base de datos, cuyo objetivo generalmente es forzar la ejecución de un indice y dividir la carga de trabajo, no solo que no funcionan en SAP HANA sino que no son necesarios debido a la nueva arquitectura de la base de datos HANA.

Conversión tablas de pool y cluster

Al convertir las tablas cluster y pool en tablas transparentes, pueden surgir problemas si confiamos en un ordenamiento implícito en nuestros desarrollos.

Esto se debe a que en las tablas cluster y pool, la interfase de la base de datos (DBI) siempre realiza un ordenamiento implícito.

Este ordenamiento se pierde después de la conversión a una tabla transparente porque aquí no se agrega ORDER BY automático en la declaración. Por lo tanto, el acceso a las tablas pool y cluster debe analizarse con respecto a su ordenamiento durante una migración a SAP HANA.

El Inspector de código nos proporciona la verificación Find Select for Pool/Cluster Tab without ORDER BY de modo que podamos encontrar rápida y fácilmente estos puntos críticos en nuestros desarrollos ABAP.

Comportamiento del ordenamiento

Si no especificamos ORDER BY en la declaración SQL SELECT, la secuencia en la que se leen los registros de la tabla base de datos es impredecible.

Pueden ocurrir cambios en el comportamiento de ordenación implícita para las tablas transparentes existentes.

En las bases de datos orientadas a filas se accede a las tablas a través de un índice primario o secundario. Aquí, los datos a menudo se leen en la secuencia deseada porque se leen desde la base de datos en la secuencia almacenada allí cuando se usa un índice.

Con SAP HANA el ordenamiento implícito no esta garantizado ya que no es una característica documentada de Open SQL.

Tal como mencionamos anteriormente debemos utilizar la adición ORDER BY si deseamos que los datos se seleccionen en un orden determinado.

Esta regla se aplica en particular a SAP HANA porque los datos están orientados a columnas, no hay un índice secundario y los datos se pueden leer en paralelo.

Por lo tanto, los lugares del código ABAP en donde nos encontremos con esta situación implican un error de programación que debemos corregir independientemente de la migración a SAP HANA.

AUDIO ACLARATIVO: Pueden ocurrir problemas cuando asumimos que un ordenamiento determinado es llevado a cabo en la secuencia de un programa ABAP. Este es el caso por ejemplo, de cuando trabajamos con tablas internas y ejecutamos la edición Binary Search, la cual tiene como requisito que la tabla interna se encuentre previamente ordenada por el campo o campos a partir de la cual se realizará la búsqueda binaria. Podemos encontrarnos con sorpresas en la lista de salida de datos si de repente no aparecen en el orden de clasificación deseado. En conclusión no debemos confiar en los ordenamientos implícitos, si necesitamos una clasificación específica de los datos cuando accedemos a una base de datos, debemos utilizar la división Order By explícitamente.

3 | Las pautas de performance

A continuación proporcionaremos recomendaciones de rendimiento para desarrollar aplicaciones ABAP en SAP HANA, contestaremos las preguntas más importantes y frecuentes relacionadas con SAP HANA y describiremos las reglas más importantes y cualquier cambio en el contexto de SAP HANA.

Reglas de oro para la programación de bases de datos

Existe un conjunto de 5 reglas cuyo objetivo es optimizar la programación de las bases de datos. Estas son:

1. Mantener el conjunto de resultados lo más pequeño posible.

2. Mantener el conjunto de datos transferido lo más pequeño posible.

3. Reducir el número de ejecuciones de consulta.

4. Minimizar el esfuerzo de búsqueda.

5. Reducir la carga en la base de datos.

En lo que resta de esta lección analizaremos en detalle las 5 reglas de oro y particularmente nos enfocaremos en como estas reglas cambian gracias a SAP HANA.

---

3.1 | Mantener el conjunto de resultados lo más pequeño posible

La primera regla de oro recomienda que mantengamos el conjunto de resultados (es decir, el número de filas seleccionadas) lo más pequeño posible al leer datos de la base de datos.

Podemos minimizar el conjunto de resultados utilizando varias medidas:

Usando una cláusula WHERE

En ABAP, el número de registros de datos transferidos se controla mediante la condición WHERE.

Debemos leer solo los registros de datos que realmente necesitamos. Podemos no utilizar la condición WHERE solo si se requieren todos los registros para cada acceso.

No utilizar la cláusula WHERE es particularmente problemático para las tablas de base de datos que aumentan con el tiempo porque los volúmenes crecientes de datos se transfieren con el tiempo.

Trabajando con la cláusula HAVING

El uso de la cláusula HAVING proporciona otra opción para reducir las filas seleccionadas.

Se utiliza junto con la cláusula GROUP BY para seleccionar solo ciertos grupos haciendo restricciones a las filas agrupadas, por ejemplo, en los valores agregados.