✒️ABAP / La performance en ABAP Por Lisimaco Prieto Herrera

La performance en ABAP

En ABAP existe lo que en programación se denomina buenas y malas prácticas, ya sea porque afectan al rendimiento o la performance d los programas o porque afectan a otros factores que son determinantes como son la reutilización y el mantenimiento del código.

En esta ocasión nos vamos a concentrar en la performance de los programas. Es decir haremos referencia al análisis y desempeño y rendimiento de los programas ABAP.

En ABAP podemos decir que la performance de un programa tiene que ver con 3 aspectos fundamentales:

El tiempo de procesamiento de la lógica ABAP existente en el programa.

El tiempo de procesamiento de los accesos a las tablas BD.

El tiempo de procesamiento del sistema SAP.

De estos 3, el primero a tener en cuenta, cuando evaluamos la performance es el tiempo de procesamiento de los accesos a las tablas BD, ya que este e el que más recursos consume y por consiguiente es el que más tiempo requiere.

A partir del lanzamiento de la BD Sen memoria SAP HANA, la relevancia del tiempo de procesamiento de la BD disminuyó considerablemente.

En segundo lugar sigue el tiempo de procesamiento de la lógica ABAP existente en el programa, es decir una vez que recuperamos los datos de las tablas BD, debemos procesarlos mediante una lógica determinada y producir una acción en el sistema o una salida por pantalla o ambas.

Y por último, indirectamente nos vemos afectados por el tiempo de procesamiento del sistema SAP, es decir imaginemos por ejemplo la situación en la que en el ambiente SAP en que estamos trabajando, se está ejecutando un mega proceso de peso y que todo el rendimiento del sistema se ve afectado por esta situación.

En ABAP contamos con una herramienta muy útil que nos permite evaluar cómo se distribuye el tiempo de procesamiento de un programa.

Nos referimos al Análisis de tiempo de ejecución correspondiente a la tarnsacción SE30 tal como evemos en la siguiente imagen:

En la pantalla inicial de la transacción seleccionamos la opción Programa, completamos el nombre del programa que deseamos evaluar, en este caso el programa ZTEST_SELECT_USUARIOS, este programa es un reporte que realiza un SELECT a la tabla BD de usuarios ZTABLA_USUARIOS y luego muestra los registros por pantalla mediante un reporte ALV y por último hacemos clic en el botón Evaluar, tal como vemos en la siguiente imagen:

Como resultado de la ejecución de la transacción vamos a visualizar la siguiente gráfica en donde podemos claramente visualizar cuál es la distribución del porcentaje de los tiempos de procesamiento entre la lógica ABAP, la BD y el sistema.

Como conclusión decimos:

Cuanto mas alto sea el porcentaje de procesamiento de la BD en comparación a los otros 2 porcentajes entonces los tiempos del programa se irán a las nubes.

La situación ideal es que el porcentaje de procesamiento de la lógica ABAP sea lo más alto posible y el porcentaje d procesamiento de la BD sea lo más bajo posible.

Para lograr este objetivo es importante tener bien claro que prácticas son desaconsejadas y cuales son recomendadas, de modo de poder apuntar a realizar programas de alta calidad, que funciones perfectamente en el ambiente productivo, donde las tablas BD contienen millones de registros y cada micro segundo cuenta.

Las buenas y las malas prácticas en el acceso a la BD

Vamos a analizar a continuación las buenas y las malas prácticas en el acceso a la BD. Dentro de este aspecto podrámos mencionar muchas prácticas habituales de los programadores ABAP por lo que nos vamos a concentrar en las más relevantes, es decir aquellas que producen más impacto en el tiempo de procesamiento de la BD.

Evitar el SELECT *

Cuando realizamos un SELECT a una tabla BD tenemos que evitar usar el *, si es que vamos a necesitar recuperar todos los campos de la tabla, ya que si lo hacemos estaremos recuperando campos de las tablas BD que no vamos a usar.

En lugar de usar el * en el SELECT debemos especificar cada uno de los campos de la tabla BD que deseamos recuperar.

Pensemos que si la tabla BD a la cual le estamos realizando SELECT * tiene pocos campos o columnas entonces el impacto en el rendimiento será bajo. Pero si estamos hablando de una tabla con mas de 100 campos y con millones de registros almacenados entonces está simple diferencia en la forma de realizar el ELECT impactará profundamente en el rendimiento.

Esta situación empeora cuando se agregan nuevos campos o columnas en la tabla BD ya que los datos de estas nuevas columnas también serán recuperados al ejecutarse el SELECT *.

Es una muy mala práctica de programación usar SELECT *.

En muchas casos los programadores ABAP usan SELECT * ya que les resulta más rápido esto que escribir cada de los campos que se desean recuperar de la tabla BD.

En conclusión, nunca usar SELECT *, siempre especificar los campos que se desean recuperar.

Evitar el SELECT ENDSELECT

Cuando seleccionamos registros de una tabla BD en SAP, tenemos la posibilidad de ejecutar la sentencia SELECT ENDSELECT, que a diferencia de la sentencia SELECT, realiza un bucle que incia con SELECT y finaliza con ENDSELECY y dentro del bucle se puede realizar el procesamiento del registro recuperado de la tabla BD.

Veamos un ejemplo:

Cuando trabajamos en instalaciones de SAP que ya tienen sus cuantos años o cuando vemos código estándar del sistema SAP, vamos a notar que en muchas ocasiones se usa la sentencia SELECT ENDSELECT.

La sentencia SELECT ENDSELECT es ampliamente desaconsejada debido a que la performance de la sentencia SELECT INTO TABLE es ampliamente superior.

Ejemplo:

Como se ve en la imagen anterior, ejecutar SELECT INTO TALBE es 8 veces mas performante que ejecutar la sentencia SELECT ENDSELECT.

E una mala práctica de programación usar SELECT ENDSELECT.

En casos muy pero muy puntuales, puede llegar a ser necesario usar SELECT ENDSELECT.

Conclusión evitar el uso de SELECT ENDSELECT, en su lugar usar SELECT INTO TABLE.

Evitar el SELECT sin WHERE.

Un SELECT sin condiciones, es decir sin la cláusula WHERE, retorna todos los registros de la tabla BD. Esto indica que se producido un error de programación, es decir nos olvidamos de escribir WHERE, aunque también en casos muy específicos podría ser necesario ejecutar SELECT sin condiciones.

Ahora bien si la tabla BD tiene una cantidad considerable de registros, este SELECT generaría un gran problema de rendimiento.

Ejemplo:

En contrapartida cuando ejecutamos un SELECT en donde especificamos condiciones lo ideal es que las condiciones sean lo más especificas posibles, es decir sería perfecto en cuanto a rendimiento que las condiciones incluyan los campos que forma parte de la clave de la tabla BD, ya que de esta forma el acceso alos registros resultantes sería mucho más rápido que sni no se especifican estos campos en las condiciones.

Debemos evitar también incluir condiciones por el negativo, es decir condiciones NE, ya que desde el punto de vista del rendimiento son mucha más costosas a nivel BD.

Es una mala práctica usar SELECT sin especificar condiciones mediante la cláusula WHERE.

Se debe evitar el uso de esa sentencia sin la cláusula WHERE.

Evitar el SELECT dentro de un LOOP

Una práctica que es muy común y que encontramos a menudo en muchos programas ABAP consiste en ejecutar uno o varios SELECT dentro de un LOOP. Es decir mientas recorremos una tabla interna vamos a seleccionar para cada uno de los registros, diferentes registros en otras tabas BD con la sentencia SELECT SINGLE.

eJEMPLO

Desde el punto de vista del rendimiento es una muy mala práctica ya que si la tabla interna que estamos recorriendo tiene 1.000.000 de registro entonces si o si vamos a ejecutar 1.000.000 de veces los SELECT que se encuentran dentro del LOOP-ENDLOOP.

Y empeora si los SELECT dentro del LOOP.ENDLOOP, no buscan en las tablas B con los campos claves de la mismas.

La solución es recuperar en tablas internas, la información que se pueda., antes de ejecutar el LOOP-ENDLOOP. Y así acceder a la información de estas mediante la sentencia READ TABLE.

Para recuperar todos los registros de una tabla BD que tengan relación con los de una tabla interna, se usa la adición FOR ALL ENTRIES dentro del SELECT:

Es una mala práctica ejecutar SELECT dentro de LOOP-ENDLOOP.

La solución es ejecutar fuera la sentencia SELECT FRO ALL ENTRIES.

Conclusión: No ejecutar SELECT dentro de LOOP-ENDLOOPEE

Evitar usar las sentencias INSERT, UPDATE MODIFY y DELETE, las cuales impactan en las tablas BD, aplica la misma lógica que explicamos anteriormente sobre ejecución dentro de un ciclo LOOP-ENDLOOP.

Ejemplo:

No es recomendable acceder a una tabla BD a través de un bucle ya que esto provocaría un problema de rendimiento

Para evitar esto se debe trabajar con tablas internas.

Ejemplo:

SELECT más SELECT vs JOIN

Cunado se necesita seleccionar datos de dos a más tablas BD. Par esto se presentan dos posibilidades:

1.- Consiste en realizar SELECT a la primera tabla BD y luego al momento de realizar el segundo SELECT, implementamos la sentencia SELECT FOR ALL ENTRIES donde usamos los registros encontrados en el primer SELECT.

Ejemplo:

A nivel de rendimiento la opción anterior no es la óptima ya que estamos realizando dos SELECT diferentes cuando podemos optimizar realizando una sola selección.

La otra opción que tenemos disponible es realizar un JOIN entre ambas tablas BD.

Si es necesario podemos realizar un JOIN entre tres o más tablas BD.

Las buenas y las malas prácticas en la lógica de procesamiento ABAP

Vamos a analizar a continuación las buenas y las malas prácticas en la lógica de procesamiento ABAP. Dentro de este aspecto podríamos mencionar muchas prácticas habituales de los programadores ABAP por lo que nos vamos a concentrar en las más relevantes, es decir en aquellas que producen más impacto en el tiempo de procesamiento de la lógica ABAP.

READ TABLE BINARY SEACH

Cundo leemos un registro de una tabla interna que se encuentra en memoria, mediante la sentencia READ TABLE, el sistema internamente para encontrar el registro que deseamos leer, tiene que leer secuencialmente todos los registros de la tabla interna, comenzando por el primero de ellos, hasta llegar al registro que coincide con las condiciones de búsqueda.

Ejemplo:

Piense como sería el proceso para leer el último registro.

Ahora bien existe una alternativa que desde el punto de vista de la performance es la óptima y consiste en ejecutar lo que denomina una lectura binaria en lugar de una lectura secuencial.

Para ejecutar una lectura binaria tenemos dos condiciones:

La tabla interna debe estar ordenada en forma ascendente es decir de menor a mayor por el campo o campos por los que deseamos buscar.

Debemos agregar la cláusula BINARY SEARCH al final de la sentencia READ TABLE.

Ejemplo:

Siempre que ejecutamos la sentencia READ TABLE obtenemos optimizarla para poder implementar la búsqueda binaria y de esta manera reducir ampliamente los tiempos de procesamiento de la lógica ABAP.

Evitar realizar LOOP-ENDLOOP dentro de otro LOOP-ENDLOOP

Otro error muy común a nivel de rendimiento que encontramos en mucho programas ABAP consiste en realizar LOOP-ENDLOOP y dentro de este otro LOOP-ENDLOOP.

Ejemplo:

Suponga este proceso con 2 tablas internas de 10.000 registros cada una. En el pero de los casos se procesaría 100.000.000 de registros.

Podemos mejor ampliar la lógica ABAP que acabamos de mencionar si por un lado usamos condiciones primero de los ciclos LOOP-ENDLOOP y por otro lado en lugar de ejecutar el segundo LOOP-ENDLOOP, ejecutamos READ TABLE con BINARY SEARCH, para lo cual debemos ordenar previamente la tabla interna de forma ascendente por el campo o los campos por los cuales vamos a buscar.

Ejemplo:

LOOP CHECK vs LOOP WHERE

Cuando trabajamos con el ciclo LOOP-ENDLOOP tenemos básicamente 2 opciones para establecer condiciones.

La primera de ellas consiste en escribir las condiciones dentro del ciclo, es decir dentro del LOOP-ENDLOOP podemos usar la sentencia IF-ENDIF o la sentencia CHECK para filtrar los registros que vamos a procesar. Lo malo de esta opción es que no evita recorrer toda la tabla.

La otra opción que tenemos es filtrar los registros que vamos a procesar dentro del LOOP-ENDLOOP especificando una o varias condiciones dentro de la cláusula WHERE. Esta es ampliamente superior ya que evita recorrer cada uno de los registros tal como sucede con la primera opción.

Veamos a continuación la performance de ambas alternativas que tenemos para filtrar los registros que recorremos con LOOP-ENDLOOP.

Tal como vemos en la imagen anterior, ejecutar LOOP-ENDLOOP con WHERE es el doble de performante que ejecutar un LOOP-ENDLOOP más CHECK.

Olvidarnos WHEN OTHERS en la sentencia CASE

Una situación muy común que les suele suceder hasta a los programadores ABAP mas experimentados consiste en olvidarse la opción WHEN OTHERS cuando se trabaja la sentencia CASE-ENDCASE.

Ejemplo:

A simple vista podríamos llegar a pensar que olvidarnos de esta opción es totalmente irrelevante, ya que cuando realizamos las pruebas unitarias y las funcionales o de sistemas, siempre la lógica siguió el camino de alguna de las opciones que escribimos dentro del CASE-ENDCASE.

Siempre se use la sentencia CASE-ENDCASE se debe incluir la alternativa WHEN OTHERS.

APPEND de una tabla interna en otra tabla interna

Cuando se trabaja con tablas internas, una situación muy común se presenta al tratar de agregar registros de una tabla interna en otra tabla interna, siendo ambas tablas internas del mismo tipo.

Se presenta cuando se hace un LOOP-ENDLOOP de la primera tabla interna y dentro de este se realiza un APPEND de cada uno de os registros a la tabla interna 2.

La otra alternativa es usar la sentencia APPEND LINES OF, en una sola línea para copiar el contenido de una tabla interna a la otra.

Ejemplo:

Tal como vemos en la imagen anterior la alternativa de ejecutar la sentencia APPEND LINES OF es 7 veces más performante que la opción de recorrer la tabla 1 y agregar cada registro a la tabla 2.

INSERT de una tabla interna en otra tabla interna

Tal como vemos en la imagen anterior la alternativa de ejecutar la sentencia INSERT LINES OF es 11 veces más performante que la opción de recorrer la tabla interna 1 e insertar cada registro a la tabla interna 2 en una posición determinada.

El borrado de registros duplicados de una tabla interna

Tal como se observa en la imagen anterior la alternativa de ejecutar la sentencia DELETE ADJACENT DUPLICATES es 8 veces más performante que la opción de realizar la comparación y el borrado de forma manual.

Copiar tablas internas

Tal como vemos en la imagen anterior la alternativa de ejecutar la sentencia tabla_interma1[] = tabla_interna2[] es 38 veces más performante que la opción de agregar registro por registro en la tabla interna2.

Comparación de tablas internas

Como se observa la ejecución de la sentencia IF tabla_interna1[] = tabla_inerna2[] es 13 veces más performante que la opción de realizar comparación de ambas tablas internas de forma manual.