✒️ABAP La performance en ABAP

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 la performance de los programas o porque afectan a otros factores que son determinantes como ser la reutilizaciòn y el mantenimiento del còdigo.

En esta ocasiòn nos vamos a concentrar en la performance de los programas.

Cuando hablamos de performance nos estamos 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ò mucho.

Luego sigue en importancia el tiempo de procesamiento de la lògica ABAP existente en el programa.

Por ùltimo el tiempo de procesamiento del sistema SAP.

El Anàlisis de tiempo de ejecuciòn correspondiente a la transacciòn estàndar SE30 nos permite evaluar como se distribuye el tiempo de procesamiento de un programa.

Conclusiones:

✔ 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 seràn muy grandes.

✔ 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 cuales son recomendadas, de modo de poder apuntar a realizar programas de alta calidad, que funcionen perfectamente en el ambiente productivo, donde las tablas de la base de datos contienen millones de registros y cada micro segundo cuenta.

Buenas y malas pràcticas en el acceso a la base de datos

Vamos a analizar a continuaciòn las buenas y malas pràcticas en el acceso a la base de datos. Dentro de este aspecto podrìamos mencionar muchas pràcticas habituales de los programadores ABAP.

✔ Evitar el SELECT*: cuando realizamos un SELECT no tenemos que utilizar el * si no vamos a necesitar recuperar todos los campos de la tabla. Nunca usar el SELECT*, siempre especificar los campos que deseamos recuperar.

✔ Evitar el SELECT ENDSELECT: en su lugar usar SELECT INTO TABLE, es màs eficiente.

✔ Evitar el SELECT sin WHERE

✔ Evitar el SELECT dentro de un LOOP

✔ Evitar utilizar las sentencias INSERT, UPDATE, MODIFY, y DELETE dentro de un LOOP

✔ SELECT màs SELECT vs JOIN

Las buenas y malas pràcticas en la lògica de procesamiento ABAP

1 READ TABLE BINARY SEARCH

Siempre que ejecutemos la sentencia READ TABLE debemos optimizarla para poder implementar la bùsqueda binaria y de esta forma reducir los tiempos de procesamiento de la lògica SAP. La alternativa òptima consiste en ejecutar una lectura binaria en lugar de una lectura secuencial. Para poder hacerlo:

✔ La tabla interna debe estar ordenada en forma ascendente por los campos que deseamos buscar

✔ Debemos agregar la clàusula BINARY SEARCH al final de la sentencia READ TABLE:

2 Evitar realizar un LOOP ENDLOOP dentro de otro LOOP ENDLOOP: Esta lògica puede reemplazarse tal como describimos utilizando condiciones en el primer LOOP-ENDLOOP y ejecutando un READ TABLE con BINARY SEARCH.

3 LOOP CHECK vs LOOP WHERE: 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. Hay que ejecutar LOOP-ENDLOOP especificando las condiciones dentro del WHERE para filtrar los registros a procesar.

4 Olvidarnos WHEN OTHERS en la sentencia CASE: hay que escribir siempre la alternativa WHEN OTHERS dentro de un CASE-ENDCASE.

5 APPEND de una tabla interna en otra tabla interna: Es una muy mala pràctica de programaciòn agregar el contenido de una tabla interna a otra; hay que utilizar siempre la sentencia APPEND LINES OF para agregar el contenido de una tabla interna a otra.

6 INSERT de una tabla interna en otra tabla interna: es una muy 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.

Hay que usar siempre la sentencia INSERT LINES OF para insertar el contenido de una tabla interna a otra en una posiciòn determinada.

7 Borrado de registros duplicados de una tabla interna: hay dos alternativas ;

✔`la primera de ellas 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.

✔ la otra consiste en utilizar la sentencia DELETE ADJACENT DUPLICATES, que borra todos los registros duplicados de una tabla interna, comparando los campos que especificamos luego de COMPARING.

La sentencia DELETE ADJACENT DUPLICATES para borrar registros duplicados de tablas internas es una buena pràctica de programaciòn.

8 Copiar tablas internas: para copiar el contenido de una tabla interna a otra tenemos dos alternativas.

✔ Se borra 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.

✔ Usamos la asignaciòn tabla_interna_1â–¯ = tabla_interna_2â–¯, la cual en sola lìnea pisa el contenido existente en la tabla 1 con el contenido de la tabla interna 2. Esta alternativa es mucho màs veloz y por lo tanto, es una mejor pràctica de programaciòn.