✒️ABAP La performance en ABAP

El performances refiere a el análisis del desempeño y el rendimiento del programa ABAP. En este análisis existe los siguiente 3 aspectos fundamentales:

* El tiempo de procesamiento de la lógica del programa.
* El tiempo de procesamiento de los accesos a las tablas de las bases de datos.
* El tiempo del procesamiento del sistema ABAP.

De estos 3 tiempos, el que más recursos consume es el tiempo de procesamiento de los accesos a las tablas de bases de datos, luego esta el procesamiento de la lógica y finalmente el procesamiento del sistema ABAP.

Para este análisis contamos con la transacción SE30 que evaluar cómo se distribuye el tiempo de ejecución y procesamiento del programa.

Para ello al ingresar se indica el nombre del programa y se pulsa el botón Evaluar. Lo que nos mostrará como se distribuye el porcentaje de los tiempos de procesamiento de lógica ABAP, la base de datos y el sistema.

La situación ideal sería entonces que el porcentaje más alto de procesamiento sea la lógica ABAP y el más bajo sea el de la tabla base de datos. Para ello se debe cuidar de las buenas practicas de programación.

Buenas y malas prácticas en el acceso a bases de datos.
A continuación veremos las prácticas mas relevantes y que producen un mayor impacto en el tiempo de procesamiento de la base de datos.

* Evitar el SELECT*: Esta sentencia SELECT* recupera TODOS los datos de la tabla llamada o indicada, en lugar de llamarlo todos, se sugiere especificar qué datos se requieren recuperar, así:
FORM seleccionar_datos.
REFRESH ti_usuarios.
SELECT dni nombre_ape estado_usu
FROM ztabla_usuarios
INTO TABLE ti_usuarios.

* Evitar el SELECT ENDSELECT: La sentencia SELECT ENDSELECT genera un bucle para procesar registros recuperados de otra tabla base de datos, sin embargo en mas performante utilizar el SELECT INTO TABLE.

* Evitar el SELECT sin WHERE: Al usar la sentencia SELECT sin la condición, se procesan o llaman TODOS los registros de la tabla base de datos, sin embargo lo ideal es usar el WHERE con la mayor cantidad de especificaciones posibles, para reducir así el procesamiento al necesario. Se sugiere también evitar condiciones negativas o con uso de NE.

* Evitar el SELECT dentro de un LOOP: El ejecutar uno o varios SELECT dentro de un LOOP ENDLOOP, va a generar que se seleccione cada registro mientras se recorre la tabla. Es posible usar un SELECT SINGLE con condiciones especificas que seleccionará el primer caso que aplique. O es posible recuperar en tablas internas todos los registros necesario y luego dentro del LOOP acceder a ellos desde la sentencia READ TABLE, recuperando todos los registros de dicha tabla base de datos se ejecuta adicionalmente FOR ALL ENTRIES dentro del SELECT para recuperar los registros de la base de datos a memoria.

* Evitar utilizar las sentencias INSERT, UPDATE, MODIFY y DELETE en un LOOP: Realizar esto dentro del LOOP ya que generará una tabla más larga y requerirá más recurso, en cambio se recomienda realizar el uso de estas sentencia al final o fuera del LOOP.

* SELECT más SELECT vs JOIN: Cuando se requiere tomar datos de varias tablas bases de datos no se recomienda usar SELECT tras SELECT, sino la sentencia JOIN la veces necesarias. Así:

START-OF-SELECTION.
REFRESH ti_tabla
SELECT tl~carrid tl~connid t2~dldate t2~planetype tl~countryfl
INTO CORRESPONDING FIELDS OF TABLE ti_tabla
FROM spfli AS tl INNER JOIN sflight AS t2
ON tl~carrid = t2~carrid
AND tl~connid = t2~connid.

Buenas y malas prácticas en lógica de procesamiento ABAP.
A continuación veremos las prácticas mas relevantes y que producen un mayor impacto en el tiempo de procesamiento de la lógica ABAP.

* READ TABLE BINARY SEARCH: Cuando se busca un registro en una tabla mediante la sentencia READ TABLE la búsqueda se realiza de manera secuencial, sin embargo la búsqueda binaria genera una partición de la tabla, buscando en mitades, lo que ofrece un mayor rendimiento en dicha tarea. Para implementarla la el campo de búsqueda en la tabla interna debe estar ordenada ascendente o descendentemente y agregar la clausula BINARY SERCH al final del READ TABLE, así:
SORT ti_proveedores ASCENDING BY nombre.
READ TABLE ti_proveedores INTO wa_proveedores WITH KEY nombre = 'Ariel' BINARY SEARCH.

* Evitar el LOOP ENDLOOP dentro de otro LOOP ENDLOOP: Realizar LOOPS dentro de otro LOOP genera una búsqueda exponencial de registros, por lo que se sugiere usar el condicional WHERE y la búsqueda binaria, para optimizar el procesamiento, así.
SORT ti_usuarios ASCENDING BY nombre.
LOOP AT ti_proveedores INTO wa_proveedores WHERE dni > '50000000'.
READ TABLE ti_usuarios INTO wa_usuario WITH KEY dni = wa_proveedores-dni BINARY SEARCH.

* LOOP CHECK vs LOOP WHERE: Al buscar dentro de un LOOP si bien se pueden utilizar como filtro las sentencias CHECK e IF-ENDIF, estas no se recomiendan ya que se leerán todos los registros, sin embargo lo optimo es implementar el WHERE con las condiciones especificas.

* Olvidar WHEN OTHERS en la sentencia CASE: En el condicional CASE-ENDCASE es muy importante especificar el caso en el que no se encuentre ninguno de los casos indicados, ya que de lo contrario el sistema arrojara un error o llevar a situaciones inesperadas. Esto implementando la alternativa WHEN OTHERS.

* APPEND de una tabla interna en otra tabla interna: Cuando se hace necesario agregar registros de una tabla interna a otra ti del mismo tipo, la peor opción es tomar el contenido de una tabla en un LOOP llevando registro a registro la información a la otra tabla. En dicho caso es más optimo usar la sentencia APPEND LINES OF en una sola línea para llevar el contenido de una tabla a otra; así:
APPEND LINES OF itab1 TO itab2.

* INSERT de una tabla interna en otra tabla interna: Cuando se hace necesario insertar registros de una tabla interna a otra ti del mismo tipo, la peor opción es insertar registro por registro de unta tabla a otra, es sin embargo optimo insertar el contenido en una posición determinada de una tabla a otra a través de la sentencia INSERT LINES OF, así:
INSERT LINES OF itab1 INTO itab2 INDEX i.

* Borrado de registro duplicados de una tabla interna: Cuando se requiere corroborar y eliminar si una tabla tiene registros duplicados. Para ello principalmente será necesario tener los campos a examinar ordenados. Dónde la peor opción sería verificar registro por registro si el primer registro se parece al siguiente y si así es borrarlo, sin embargo es posible usar la sentencia DELETE ADJACENT DIPLICATES junto con COMPARING para comparar los campos que sean especificados en dicho proceso, así:
DELETE ADJACENT DUPLICATES FROM itab COMPARING K.

* Copiar tablas interna: Cuando se hace necesario copiar registros de una tabla interna a otra ti del mismo tipo, la peor opción es borrar el contenido de una tabla para pasar la información de la otra allí, es sin embargo optimo asignar ti_1 [] = ti_2 [], pisando el contenido de una tabla a otra.

* Comparación de tablas internas: Cuando se hace necesario comparar 2 tablas internas para determinar si su contenido es el mismo, la peor forma es realizarlo de manera manual, sin embargo existe una forma optima de llevar a cabo esta tarea mediante in IF-ENDIF dentro del cual se asignará las tablas y en una sola línea se determinará si existe una duplicidad, así:
IF i_tab1 [] = i_tab2 [].
" ...
ENDIF.

Existen 2 herramientas que nos ayudan para evitar la utilización de malas practicas, estas son el inspector de código SCI y el chequeo extendido SLIN. Idealmente tras realizar un código o al editar un programa existente se deben ejecutar ambas para asegurar la optimización de los procesos.

Agradecimiento:

Ha agradecido este aporte: Jaime Gomez Arango