1. La performance en ABAP
En ABAP existe lo que en programación se denominan buenas y malas prácticas, Ya sea porque afectan al rendimiento o a la performance de los programas o porque afectan a otros factores que son determinantes como ser de reutilización y el mantenimiento del código.
Cuando hablamos de performance nos estamos refiriendo al análisis de desempeño y el rendimiento del programa ABAP.
Dentro de ABAP podemos decir que la performance de un programa tiene que ver con tres 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 de 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 recurso que más consume y por consiguiente es el que más tiempo requiere.
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 de sistema SAP.
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 de transacción estándar SE30.
En la pantalla inicial de la transacción seleccionamos la opción Programa, completamos el nombre dell programa que deseamos evaluar y por último hacemos clic en el botón Evaluar.
Como resultado de la ejecución de la transacción vamos a visualizar la 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 base de datos y el sistema.
Como conclusión podemos decir que:
- Cuanto más alto sea el porcentaje de procesamiento de la base de datos en comparación a los otros dos 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 de procesamiento de la base de datos sea lo más bajo posible.
- Para lograr este objetivo es importante tener bien claro que prácticas son desaconsejadas y cuáles son recomendadas, de modo de poder apuntar a realizar programas de alta calidad, que funcionen perfectamente en el ambiente de productivo, donde las tablas de la base de datos contienen millones de registros y cada micro segundo cuenta.
2. Las buenas y las malas prácticas en el acceso a la base de datos
Vamos a analizar a continuación las buenas y las malas prácticas en el acceso a la base de datos. 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 base de datos.
2.1 Evitar el SELECT *
Cuando realizamos un SELECT a una tabla base de datos 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 base de datos que no vamos a utilizar.
En lugar de utilizar el * en el SELECT debemos especificar cada uno de los campos de la tabla base de datos que deseamos recuperar.
Pensemos que si la tabla base de datos 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 SELECT impactará profundamente en el rendimiento.
Esta situación empeora cuando se agregan nuevos campos o columnas en la tabla base de datos 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 muchos 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 base de datos.
En conclusión, nunca usar SELECT *, siempre especificar los campos que se desean recuperar.
2.2 Evitar el SELECT ENDSELECT
Cuando seleccionamos registros de una tabla base de datos en SAP, tenemos la posibilidad de ejecutar la sentencia SELECT ENDSELECT, 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 de registro recuperado la tabla base de datos.
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.
Es importante que sepamos que la utilización de la sentencia SELECT ENDSELECT está ampliamente desaconsejada debido a que la performance de la sentencia SELECT INTO TABLE es ampliamente superior.
Es una mala práctica de programación usar SELECT ENDSELECT.
En casos muy pero muy puntuales, puede ser necesario tener que utilizar SELECT ENDSELECT.
En conclusión, evitar utilizar el SELECT ENDSELECT, en su lugar utilizar SELECT INTO TABLE.
2.3 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.
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 base de datos, ya que de esta forma el acceso a los registros resultantes sería mucho más rápido que si no se especifican estos campos en las condiciones.
Debemos evitar también incluir condiciones por el negativo, es decir condiciones con NE, ya que desde el punto de vista de 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 pero muy puntuales, puede ser necesario tener que recuperar todos los registros de una tabla base de datos sin especificar condiciones.
En conclusión, evitar utilizar el SELECT sin especificar condiciones mediante WHERE
2.4 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-ENDLOOP. Es decir, mientas recorremos una tabla interna vamos a seleccionar para cada uno de los registros, diferentes registros en otras tablas base de datos con la sentencia SELECT SINGLE.
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.
La situación empeora aún más si los SELECT que se ejecutan dentro del LOOP-ENDLOOP no acceden en las tablas base de datos con los campos claves de la mismas.
La solución a esta problemática consiste en recuperar en causas internas, antes del LOOP-ENDLOOP, todos los registros que vamos a necesitar de las tablas base de datos y luego dentro del LOOP-ENDLOOP acceder a los mismos en memoria a través de la sentencia READ TABLE.
Para recuperar todos los registros de una tabla base de datos que existan o tengan relación con los registros existentes en una tabla interna, vamos a ejecutar la adición FOR ALL ENTRIES dentro del SELECT, en donde se recuperan todos los registros de las tablas base de datos a memoria.
Es una mala práctica de programación ejecutar un SELECT dentro de LOOP-ENDLOOP.
En todos los casos esta situación puede reemplazarse ejecutando un SELECT FOR ALL ENTRIES.
En conclusión, no ejecutar SELECT dentro de LOOP-ENDLOOP.
2.5 Evitar utilizar las sentencias INSERT, UPDATE, MODIFY y DELETE dentro de un LOOP.
Con las sentencias las sentencias INSERT, UPDATE, MODIFY y DELETE, las cuales impactan en las tablas base de datos aplica la misma lógica que explicamos anteriormente sobre 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, el cual puede ser pequeño para una nueva aplicación con una tabla base de datos que contiene pocos registros, pero con el tiempo, los datos se añadiran a esta tabla, el tamaño va a crecer, el bucle se va a hacer más largo y los problemas de rendimiento graves comienzan a aparecer.
Para evitar utilizar las entencias de actualización de tablas bases de datos dentro de bucles debemos trabajar con tablas internas e impactar en las tablas bases de datos una única vez fuera de los ciclos LOOP-ENDLOOP.
Es una mala práctica de programación ejecutar un INSERT, UPDATE, MODIFY o DELETE detro de un LOOP-ENDLOOP.
En todos los casos esta situación puede reemplazarse almacenando los cambios a realizarse en tablas internas e impactar una única vez en la tabla base de datos fuera del LOOP-ENDLOOP.
En conclusión, no ejecutar INSERT, UPDATE, MODIFY o DELETE detro de un LOOP-ENDLOOP.
2.6 SELECT más SELECT vs JOIN
A menudo se presenta la necesidad de seleccionar datos de dos o más tablas bases de datos. Ante esta situación tenemos dos posibilidades, la primera de ellas consiste en realizar 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.
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 bases de datos.
Si es necesario podemos realizar un JOIN entre tres o más tablas bases de datos y recuperar en el todos los campos que necesitamos y de esta forma estamos optimizando aún más el rendimiento.
Es una bueba práctica de programación utilizar JOINs al momento de tener que seleccionar datos de tablas bases de datos relacionadas.
En conclusión, evitar utilizar el realizar SELECT más SELECT con FOR ALL ENTRIES.
3. Las buenas y las malas prácticas en la lógica de procesamiento ABAP
3.1 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 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.
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 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.
3.2 Evitar realizar un 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.
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 un registro.
Es una mala práctica de programación ejecutar un LOOP-ENDLOOP dentro de otro LOOP-ENDLOOP.
En todos los casos esta lógica puede reemplazarse utilizando condiciones en el primer LOOP-ENDLOOP y ejecutando un READ TABLE con BINARY SEARCH.
En conclusión, no ejecutar LOOP-ENDLOOP dentro de otro LOOP-ENDLOOP.
3.3 LOOP CHECK vs LOOP WHERE
Cuando trabajamos con el ciclo LOOP-ENDLOOP tenemos básicamente dos 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 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 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 sucede con la alternativa anterior.
Es una mala práctica de programación filtrar los registros a procesar dentro de un LOOP-ENDLOOP mediante las sentencias CHECK o IF-ENDIF.
En conclusión, ejecutar LOOP-ENDLOOP especificando las condiciones dentro del WHERE para filtrar los registros a procesar.
3.4 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.
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 ABAP siguió el camino de alguna de las opciones que escribimos dentro del CASE-ENDCASE.
Para evitar estos errorers escribir siempre que escribamos un CASE-ENDCASE debemos escribir la alternativa WHEN OTHERS.
Es una mala práctica de programación escribir CASE-ENDCASE sin especificar la alternativa WHEN OTHERS ya que puede llevar a situaciones inesperadas o dumps.
En conclusión, escribir siempre la alternativa WHEN OTHERS dentro de un CASE-ENDCASE.
3.5 APPEND de una tabla interna en otra tabla interna
Cuando trabajamos con tablas internas, una situación muy común que a menudo se presenta consiste en agregar los registros de una tabla interna en otra tabla interna, siendo ambas tablas internas del mismo tipo.
Aquí tenemos dos 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 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.
Es una mala práctica de programación agregar el contenido de una tabla interna a otra recorriendo la tabla interna 1 y agregando registro por registro a la tabla interna 2.
En conclusión, siempre utilizar la sentencia APPEND LINES OF para agregar el contenido de una tabla interna a otra.
3.6 INSERT de una tabla interna en otra tabla interna
Otra situación común que a menudo se presenta cuando gtrabajamos con tablas internas consiste 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 dos 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 de la tabla interna 2, en determinada psosició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 otra en una posición determinada.
Es una mala práctica de programación insertar el contenido de una tabla interna a otra recorriendo la tabla interna 1 e insertando registro por registro en una posición determinada de la tabla interna 2.
En conclusión, siempre utilizar la sentencia INSERT LINES OF para insertar el contenido de una tabla interna a otra en una posición determinada.
3.7 El borrado de registros duplicados de una tabla interna
Otra situación común que a menudo se presenta cuando trabajamos con tablas internas consiste en borrar los registros duplicados de una tabla interna.
Aquí tenemos dos alternativas para llevar a cabo esta lógica y para ambas opciones 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 es 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 tablas interna, comparando los campos que especificamos luego del COMPARING.
En conclusión, la utilización de la sentencia DELETE ADJACENT DUPLICATES para borrar registros duplicados de tablas internas es una excelente práctica de programación.
3.8 Copiar tablas internas
Otra situación común que a menudo se presenta cuando trabajamos 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 dos 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 con el contenido de la tabla interna 2.
La otra alternativa que tenemos es utilizar la asignación tabla_interna_1[] = tabla_interna_2[], la cual en una sola línea pisa el contenido existente en la tabla interna 1 con el contenido de tabla interna 2.
En conclusión, la utilización de la asignación tabla_interna_1[] = tabla_interna_2[] para copiar el contenido de una tabla interna a otra tabla interna es una excelente práctica de programación.
3.9 Comparación de tablas internas
Por último, una situación común que a menudo se presenta cuando trabajamos con tablas internas consiste en tener que comparar dos tablas internas para poder determinar si su contenido es el mismo en ambas tablas internas.
Aquí tenemos dos alternativas para llevar a cabo esta lógica, la primera de ellas consiste en frealizar 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 una sola línea determina si el contenido existente en la tabla interna 1 es igual al contenido de la tabla interna 2.
En conclusión, la utilización de la sentencia IF tabla_interna_1[] = tabla_interna_2[] para comparar si el contenido de dos tablas internas son iguales es una excelente práctica de programación.