✒️ABAP La performance en ABAP

LA PERFORMANCE EN ABAP: en ABAP existen lo que en programación se denomina buenas y malas prácticas, ya sea porque afectan al rendimiento o la performance de los programas o porque afectan a otros factores que son determinados como ser la reutilización y el mantenimiento de código. Cuando hablemos de performance nos estaremos refiriendo al análisis del desempeño y el rendimiento del programa ABAP.

Dentro de ABAP podemos decir que la performance de un programa tiene que ver con 3 aspectos fundamentales que son los siguientes:

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

- El tiempo de procesamiento de los accesos a las tablas de la base de datos.

- El tiempo de procesamiento del sistema SAP.

De estos 3 tiempos, el que debemos tener en cuenta en primer lugar, cuando evaluamos la performance, es el “tiempo de procesamiento de los accesos a las tablas de la base de datos”, ya que este es el que más recursos consume y por consiguiente es el que más tiempo requiere. “A partir del lanzamiento de la base de datos en memoria SAP HANA, la relevancia del tiempo de procesamiento de la base de datos disminuyó considerablemente.”

Luego en importancia sigue el “tiempo de procesamiento de la lógica ABAP existente en el programa”, es decir una vez que recuperemos los datos de las tablas de la base de datos, 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, nos vemos indirectamente afectados por el tiempo de procesamiento del sistema SAP, es decir imaginemos por ejemplo la situación en la que en el ambiente de SAP en que estamos trabajando, se está ejecutando un mega proceso en cuestiones de peso y que todo el rendimiento del sistema se vea afectado por esta situación.

EN ABAP contamos con una herramienta ú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 transacción estándar SE30.

LAS BUENAS Y LAS MALAS PRÁCTICAS EN EL ACCESO A LA BASE DE DATOS: las prácticas más habituales de los programadores ABAP o la más relevantes que producen más impacto en el tiempo de procesamiento de la base de datos:

- EVITAR el SELECT *: cuando se realiza el SELECT a una tabla de base de datos tenemos que evitar el *, si es que no vamos a necesitar recuperar todos los campos de la tabla, ya que si lo hacemos estaremos recuperando campos de las tablas bases de datos que no vamos a utilizar. Ej: se especifica cada uno de los campos de la tabla base de datos que deseamos recuperar:

SELECT dni nombre_ape estado_usu (campos de la tabla)

FROM ztabla_usuarios (nombre de la tabla)

INTO TABLE ti_usuarios. (nombre de la tabla interna)

- EVITAR EL SELECT ENDSELECT: cuando seleccionamos registros de una tabla base de datos en SAP, tenemos la posibilidad de ejecutar la sentencia SELECT ECDSELECT, que a diferencia de la sentencia SELECT, realiza un bucle que inicia con SELECT y finaliza con ENDSELECT y dentro del bucle se puede realizar el procesamiento del registro recuperado de la tabla base de datos, por lo tanto, es mala práctica utilizar SELECT ENDSELECT, por lo que se recomienda utilizar SELECT INTO TABLE.

- EVITAR EL SELECT SIN WHERE: un SELECT sin condiciones, es decir, sin la cláusula WHERE, devuelve todos los registros de la tabla base de datos. En general esto indica que se ha producido un error de programación, es decir nos olvidamos de escribir el WHERE, aunque también en casos muy específicos podría ser necesario ejecutar el SELECT sin condiciones. Sin duda que cuando la tabla base de datos tenga una cantidad considerable de registros, este SELECT será la causa de un problema grave de rendimiento. Ej de un select normal:

SELECT dni nombre_ape estado_usu (campos de la tabla)

FROM ztabla_usuarios (nombre de la tabla)

INTO TABLE ti_usuarios. (nombre de la tabla interna)

Ej de un SELECT CON WHERE:

SELECT dni nombre_ape estado_usu (campos de la tabla)

FROM ztabla_usuarios (nombre de la tabla)

INTO TABLE ti_usuarios. (nombre de la tabla interna)

WHERE dni EQ nombre_ape AND estado_usu IN fecha

“Importante especificar condiciones de comparación, debemos evitar también incluir condiciones por el negativo, es decir condiciones con NE, ya que desde el punto de vista del rendimiento son mucho más costosas a nivel base de datos”.

“Es una mala práctica de programación utilizar SELECT sin especificar condiciones mediante la cláusula WHERE, en casos muy puntuales de esos que se presentan, puede ser necesario tener que recuperar todos los registros de una tabla base de datos sin especificar condiciones, es decir, se debe evitar utilizar SELECT sin especificar condiciones mediante WHERE”

- EVITAR EL SELECT DENTRO DE UN LOOP: se ha hecho muy común encontrar uno varios SELECT dentro de un LOOP-ENDLOOP, es decir mientras recorremos una tabla interna vamos a seleccionar para cada uno de los registros, diferentes registros en otras tablas bases de datos ejecutando la sentencia SELECT SINGLE. Es una mala práctica de programación ejecutar un SELECT dentro de un LOOP-ENDLOOP. En todos los casos esta situación puede reemplazarse ejecutando un SELECT FOR ALL ENTRIES.

- EVITAR UTILIZAR LAS SENTENCIAS INSERT, UPDATE, MODIFY Y DELETE DENTRO DE UN LOOP: estas sentencias impactan en las tablas de la base de datos, aplica la misma lógica que aplicamos anteriormente sobre su ejecución dentro de un ciclo LOOP-ENDLOOP. No es recomendable acceder a una tabla base de datos a través de un bucle ya que esto provocaría un problema de rendimiento a medida que nuestra tabla vaya creciendo en cantidad de registros, por lo que para acceder a tablas en bases de datos se recomienda trabajar con tablas internas e impactar a las tablas una sola vez fuera de los ciclos LOOP-ENDLOOP.

- SELECT MÁS SELECT VS JOIN: esto es recomendable cuando deseamos seleccionar datos de o más tablas bases de datos. Ante esta situación tenemos 2 posibilidades, la primera de ellas consiste en realizar un SELECT a la primera tabla base de datos y luego al momento de realizar el segundo SELECT, implementar la cláusula FOR ALL ENTRIES para utilizar los registros obtenidos de la primera tabla base de datos como condición en la selección. Si es necesario podemos realizar un JOINs entre tres o más tablas bases de datos relacionadas y recuperar en él todos los campos que necesitemos y de esta forma estamos optimizando aún más el rendimiento.

LAS BUENAS Y MAS PRÁCTICAS EN LA LÓGICA DE PROCESAMIENTO ABAP: nos vamos a concentrar en las más relevantes, es decir aquellas que producen más impacto en el tiempo de procesamiento de la lógica ABAP.

- READ TABLE BINARY SEARCH: cuando 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 deseemos 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. Si se trabajan con datos que se encuentran en memoria la lectura se va a realizar de manera secuencial, es decir, registro a registro, por lo que desde el punto de vista de la performance la solución se denomina “lectura binaria” en lugar de una lectura secuencial, la cual es un algoritmo de búsqueda que encuentra la posición de un valor en una tabla interna ordenada, dividiendo el espacio de búsqueda en dos y comparando el valor buscado con el elemento en el medio de la tabla interna, si no son iguales entonces la mitad en la cual el valor no está, es eliminada y la búsqueda continua en la mitad restante utilizando el mismo procedimiento hasta que se encuentre el valor buscado, esta forma de búsqueda es ampliamente más eficiente que la forma secuencial.

Para poder 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 lo que deseamos buscar.

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

“Siempre que ejecutemos la sentencia READ TABLE debemos optimizarla para poder implementar la búsqueda binaria y de esta forma reducir ampliamente los tiempos de procesamiento de la lógica ABAP.

- EVITAR REALIZAR UN LOOP ENDLOOP DENTRO DE OTRO LOOP ENDLOOP: otro error muy común a nivel de rendimiento que encontramos en muchos programas ABAP consiste en realizar un LOOP-ENDLOOP y dentro de este ejecutar otro LOOP-ENDLOOP.

- LOOP CHECK VS LOOP WHERE: cuando trabajamos con el ciclo LOOP-ENDLOOP tenemos básicamente dos opciones para establecer condiciones. La primera de ellas es escribir las condiciones dentro del ciclo, es decir dentro del LOOP-ENDLOOP podemos utilizar 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 nos evita recorrer o leer cada uno de los registros antes de descartarlos.

La otra opción que tenemos es filtrar los registros que vamos a procesar directamente dentro del LOOP-ENDLOOP especificando una o varias condiciones dentro del WHERE. Esta opción es ampliamente superior ya que evita recorrer cada uno de los registros tal como pasa con la alternativa anterior. Es decir, el LOOP-ENDLOOP con WHERE es el doble de performance que ejecutar un LOOP-ENDLOOP más CHECK.

- OLVIDARNOS WHEN OTHERS EN LA SENTENCIA CASE: una situación muy común que suele suceder hasta al programador ABAP más experimentado consiste en olvidarse la opción WHEN OTHERS cuando se trabaja con la sentencia CASE-ENDCASE. Sucede que al ejecutar pruebas unitarias o funcionales ninguna de las opciones especificadas dentro de la sentencia CASE-ENDCASE se ajusta a los datos con lo se ejecuta el programa y esto produce errores no esperados en la ejecución o un DUMP. Para evitar estos errores siempre que ejecutemos un CASE-ENDCASE debemos escribir la alternativa WHEN OTHERS.

- APPEND DE UNA TABLA INTERNA EN OTRA TABLA INTERNA: cuando trabajamos con tablas internas, una situación común que a menudo se presenta consiste en agregar los registros de una tabla interna a otra tabla interna, siendo ambas tablas internas del mismo tipo. Aquí tenemos 2 alternativas para llevar a cabo esta lógica, la primera de ellas es recorrer la tabla interna 1 y dentro del LOOP-ENDLOOP realizar un APPEND de cada uno de los registros de la tabla 2.

La otra alternativa que tenemos es utilizar a sentencia APPEND LINES OF, en una sola línea para copiar el contenido de una tabla interna a la otra. La alternativa de ejecutar la sentencia APPEND LINES es 7 veces más performante que la opción de recorrer la tabla interna 1 y agregar cada registro a la tabla interna 2. Es decir siempre se debe utilizar APPEND LINES OF para agregar el contenido de una tabla interna a la otra.

- INSERT DE UNA TABLA INTERNA EN OTRA TABLA INTERNA: otra situación muy común que se presenta cuando trabajamos con tablas internas consisten en insertar el contenido de una tabla interna en otra tabla interna, a partir de determinada posición, siendo ambas tablas internas del mismo tipo. Aquí tenemos 2 alternativas para llevar a cabo esta lógica, la primera de ellas es recorrer la tabla interna 1 y dentro del LOOP-ENDLOOP realizar un INSERT de cada uno de los registros a la tabla interna 2, en determinada posición.

La otra alternativa que tenemos es utilizar la sentencia INSERT LINES OF, en una sola línea para insertar el contenido de una tabla interna a la otra en una posición determinada. AL ejecutar esta sentencia INSERT LINES OF es 11 veces más performante que la opción de recorrer la tabla interna 1 a la tabla interna 2 en una posición determinada.

- EL BORRADO DE REGISTROS DUPLICADOS DE UNA TABLA INTERNA: otra situación que se presenta muy a menudo cuando trabajamos con tablas internas es borrar registros duplicados de una tabla interna. Aquí tenemos 2 alternativas para llevar a cabo esta lógica y para ambas alternativas necesitamos tener ordenada la tabla interna por el campo o los campos por los que vamos a determinar si la tabla interna tiene registros duplicados. La primera alternativa consiste en realizar la comparación de forma manual, recorriendo cada uno de los registros de la tabla interna y preguntando en cada uno de ellos si el registro el igual al anterior, en cuyo caso será borrado.

La otra alternativa que tenemos es utilizar la sentencia DELETE ADJACENT DUPLICATES, la cual borra todos los registros duplicados de una tabla interna, comparando los campos que especificamos luego de COMPARING. Al ejecutar esta alternativa con 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: otra situación que se presenta al trabajar con tablas internas consiste en tener que copiar el contenido de una tabla interna a otra tabla interna, siendo ambas tablas internas del mismo tipo. Aquí tenemos 2 alternativas para llevar a cabo esta lógica, la primera de ellas consiste en borrar el contenido de la tabla interna 2, luego recorrer la tabla interna 1 y agregar cada registro de la tabla interna 1 en la tabla interna 2.

La otra alternativa que tenemos es utilizar la asignación TABLA_INTERNA_1[] = TABLA_INTERNA_2[], la cual es sola línea pisa el contenido existente en la tabla interna 1 con el contenido de la tabla interna 2. Tenemos así que al utilizar la asignación TABLA_INTERNA_1[] = TABLA_INTERNA_2[] es 38 veces más performante que la opción de agregar registro por registro en la tabla interna 2.

- COMPARACIÓN DE TABLAS INTERNAS: otra situación que ocurre muy a menudo se presenta cuando trabajamos con tablas internas consiste en tener que comparar 2 tablas internas para poder determinar si su contenido es el mismo en ambas tablas internas. Aquí tenemos 2 alternativas para llevar a cabo esta lógica, la primera de ellas consiste en realizar la comparación de las tablas internas en forma manual, recorriendo una de las tablas internas y leyendo el contenido de la otra tabla interna.

La otra alternativa que tenemos es utilizar dentro de un IF-ENDIF la asignación TABLA_INTERNA_1[] = TABLA_INTERNA_2[], la cual en sola línea determina si el contenido si el contenido existente en la tabla interna 1 es igual al contenido de la tabla interna 2. La alternativa de ejecutar la sentencia IF TABLA_INTERNA_1[] = TABLA_INTERNA_2[] es 13 veces mas performante que la opción de realizar la comparación de ambas tablas internas de forma manual.

Importante tener presente que en ABAP podemos auditar a nivel de malas prácticas para el acceso a base de datos y la lógica del procesamiento, esto se realiza a través del inspector del código TX SCI y el chequeo extendido del código a través de la TX SLINK, lo cual es ideal aplicar a cada nuevo programa que se cree en la empresa o cada vez que se modifique un programa, esto garantizará que no se utilicen códigos que impacten en el rendimiento de los mismos.