✒️ABAP / Las herramientas de ABAP para asegurar la calidad del código Por Gustavo Rondon Hernandez

1 | Las herramientas que nos proporciona ABAP para asegurar la calidad del código

Cuando escribimos programas en ABAP es decir cuando desarrollamos en ABAR ya sea que estemos creando un programa nuevo o estemos modificando un programa ya existente, necesitamos generar código de calidad; y con esto nos referimos a que tenemos que crear código ABAP que cumpla con las cuestiones relativas al rendimiento, la sintaxis, la seguridad, la obsolecencia y el cumplimiento de convenciones de nombres o estándares, entre otras varias cuestiones importantes más.

Para ayudarnos a cumplir con estos requisitos ABAP nos proporciona de varias herramientas muy útiles.

Particularmente dos de estas herramientas son sumamente importantes para el programador ABAR ya que con su aplicación vamos a aumentar en gran medida la calidad de nuestros desarrollos. Ellas son:

La verificación ampliada del programa: a la cual podemos acceder a través de la transacción SLIN.

La verificación ampliada del programa realiza una verificación completa que incluye las interfaces de los procedimientos externos llamados desde el programa, por ejemplo, verificando si el número y el tipo de los parámetros de la interfaz en una llamada de procedimiento externo es correcto.

La verificación ampliada del programa es solo una verificación estática. No se pueden eliminar todas las circunstancias que podrían dar lugar a situaciones excepcionales o errores en tiempo de ejecución.

Por ejemplo: cualquier declaración en la que se especifiquen argumentos dinámicamente como el contenido de campos o en la que llamen a procedimientos dinámicamente, no se puede verificar estáticamente.

También se verifica entre otras cuestiones si el programa se encuentra activado; si se utilizan sentencias ABAP obsoletas, si se utilizan textos harcodeados en el programa en lugar de utilizar elementos de texto, si existen problemas de semántica, si existen advertencias de sintaxis, entre otras verificaciones más.

Como resultado de la verificación visualizamos errores, advertencias o mensajes sobre cada una de las verificaciones realizadas al programa analizado.

El inspector de código: al cual podemos acceder a través de la transacción SCI.

El inspector de código es una herramienta que se utiliza para comprobar los objetos del repositorio ABAP

Con el inspector de código podemos verificar objetos individuales o conjuntos de objetos para el rendimiento, la seguridad, la sintaxis y el cumplimiento de las convenciones de nombres.

En el inspector de código podemos definir inspecciones que con la ayuda de variantes de verificación, examinan ciertos conjuntos de objetos.

Como resultado de una inspección, recibimos mensajes de información, mensajes de advertencia o mensajes de error sobre diferentes propiedades de los objetos examinados.

También podemos acceder a la verificación ampliada del programa y al inspector de código a través del menú de la

transacción SE38, es decir desde el editor ABAP, mientras estamos visualizando o modificando un programa.

Tan beneficioso es la utilización de estas dos herramientas para la generación de código ABAP, que las empresas que ponen especial atención a la generación de código ABAP de calidad, utilizan estas dos herramientas como obligatorias dentro del proceso de desarrollo: es decir que luego de la generación o la modificación de un programa ABAP será obligatorio para el programador ejecutar estas dos herramientas de modo que se compruebe y que quede documentado, que el desarrollo cumple con las cuestiones relativas al rendimiento, la sintaxis: la seguridad, la obsolecencia, los estándares, etc.

"La etapa de desarrollo de software que realiza un programados ABAP en su día a día esta compuesta por la programación y la realización de pruebas unitarias y la documentación. La programación como su nombre lo indica consiste en la creación de un programa u objeto ABAP nuevo o la modificación de un programa u objeto ABAP existente en el sistema. Las pruebas unitarias son pruebas básicas que realiza el programador ABAP para verificar que el programador cumple con los requisitos básicos que motivaron su creación o modificación. La documentación consiste en documentar de alguna forma ya sea en word que se sube en un sistema documental o de otra forma que los cambios realizados al sistema cumplen con los requisitos que motivaron esos cambios, es en esta etapa de la documentación en donde en muchas empresas se le solicita a los programadores ABAP que documenten la ejecución del inspector de códigos y de la verificación ampliada del programa de modo de asegurarse que ambos chequeos no existen errores visibles "

1.1 | La verificación ampliada del programa

Cuando ejecutamos la transacción SLIN vamos a visualizar la siguiente pantalla de selección en donde podemos configurar la verificación que vamos a realizar:

Veamos a continuación cuál es el objetivo de las verificaciones más comúnmente utilizadas que ofrece la verificación ampliada del programa.

Interfases PERFORM/FORM:: aquí están agrupados los tests que verifican las llamadas de subrutinas PERFORM externas y las definiciones FORM:

Se realizan las siguientes verificaciones para las llamadas PERFORM externas:

Se verifica si la definición FORM existe en el programa indicado.

Se verifica si el programa que contiene la definición FORM llamada existe y no es un include.

Se verifica si coincide la cantidad de parámetros actuales con los parámetros formales.

Se verifica si coinciden las categorías de los parámetros USING, CHANGING y TABLES.

Se verifica si los parámetros actuales y los parámetros formales son compatibles.

Se verifica si un literal se transfiere a un parámetro estructurado o en un parámetro de la categoría CHANGING

Se realizan las siguientes verificaciones para las definiciones FORM:

Se verifica si para una definición FORM existe una llamada PERFORM

Se verifica si existen parámetros FORM sin tipo.

Se verifica si las excepciones que pueden producirse mediante PERFORM llamado externo o CALL FUNCTION en una definición FORM, aparecen en la cláusula RAISING de FORM.

Interfases CALL FUNCTION: aquí están agrupados los tests que verifican la llamada y la definición de módulos de

funciones.

Se realizan las siguientes verificaciones:

Se verifica si en un módulo de funciones existe el grupo de funciones correspondiente y no contiene errores.

Se verifica si existen los módulos de funciones llamados.

Se verifica si se transfieren todos los parámetros necesarios.

Se verifica que no se transfieran parámetros desconocidos.

Se verifica si los parámetros tienen la categoría correcta (IMPORT, EXPORT, TABLES, EXCEPTION).

Se verifica si los parámetros actuales y los parámetros formales son compatibles.

Se verifica si para EXCEPTION's se realiza un tratamiento SY-SUBRC.

Se verifica si la cláusula RAISING intercepta todas las excepciones correctamente.

Se verifica si un módulo de funciones está identificado como obsoleto.

En los grupos de funciones se verifica en las definiciones de módulos de funciones:

Se verifica si un módulo de funciones contiene una entrada en la tabla base de datos TFDIR.

Se verifica si para cada EXCEPTION existe un comando RAISE y si para cada comando RAISE aparece una EXCEPTION.

Interfases programa externas: aquí se agrupan los tests que verifican las llamadas de las sentencias CALL TRANSACTION, LEAVE TO TRANSACTION, CALL DIALOG, SUBMIT y USER EXITs.

Se realizan las siguientes verificaciones:

Se verifica si existe un código de transacción en la tabla de base de datos TSTC, que es la tabla de códigos de transacciones de SAP

Se verifica si existe un módulo de diálogo en la tabla de base de datos TDCT, que es la tabla de módulos de diálogo.

Se verifica si un report llamado mediante SUBMIT tiene el tipo.

Se verifica si los programas llamados son correctos sintácticamente.

Se verifica si todos los parámetros SUBMIT indicados mediante WITH están definidos en el report.

STATUS GUI y barra de títulos:

Realiza las siguientes verificaciones

Se verifica si el STATUS GUI está definido.

se verifica si el TÍTULO está definido.

Message: aquí se agrupan los tests que verifican cuestiones relativas a los mensajes que se muestran en la pantalla de los programas.

Este test contiene las siguientes verificaciones:

Se verifica si los mensajes dirigidos están definidos en la tabla base de datos TI 002.

Se verifica si la cantidad de parámetros transferidos con WITH coincide con la cantidad de parámetros formales en el mensaje o en el texto explicativo correspondiente.

Se verifica si la sentencia MESSAGE necesita un texto explicativo: se verifica si existe el texto explicativo para MESSAGE, si el texto explicativo para MESSAGE está activado, si el texto explicativo para MESSAGE está obsoleto.

Cadenas caracteres:

Este test contiene las siguientes verificaciones:

Se verifica si en un string falta el elemento de texto.

Se verifica si el elemento de texto no definido.

Se verifica si el string en el texto fuente contiene caracteres no permitidos.

Se verifica si strings diferentes con mismo ID de elemento de texto.

Se verifica si un símbolo de texto no se utiliza.

Se verifica si existe un texto de selección superfluo.

Propiedades del campo:

Este test contiene las siguientes verificaciones:

Se verifica si existe una ayuda de búsqueda no definida

Se verifica si existen campos no utilizados o no leídos.

Se verifica si el nombre de campo es idéntico a un tipo predefinido pero tiene otro tipo. El nombre de campo es idéntico a un nombre de operador.

Se verifica si el nombre de campo contiene un guion como parte del nombre.

Sentencias superfluas:

Este test contiene las siguientes verificaciones:

Se verifica si el programa contiene sentencias BREAKPOINT

Se verifica si el programa contiene un flujo de control dependiente de usuario, es decir si se utiliza en una condición la variable del sistema SY-UNAME.

Se verifica si existen sentencias trace, por ejemplo, para el análisis de tiempo de ejecución (SET RUN TIME.) o el comando SYNTAX-TRACE ON.

Se verifica si una sentencia consta sólo de un punto.

se verifica si tras las sentencias RETURN, STOP, RASE 0 SUBMIT AND RETURN existen otras sentencias.

Sentencias problemáticas:

Este test contiene las siguientes verificaciones:

Se verifica si las mismas sentencias WHEN aparecen dos veces en una sentencia CASE-ENDCASE.

Se verifica si la primera sentencia detrás de la sentencia CASE no es una sentencia WHEN.

Se verifica si existen programas direccionados con la sentencia INCLUDE y si son del tipo l.

Se verifica si se llama a la sentencia FREE MEMORY

Se verifica si existen nombres que empiezan por "0/0_" ya que están reservados para fines internos.

Se verifica si la sentencia RAISE está fuera de un grupo de funciones.

Se verifica si existe un literal numérico en una posición de cálculo, por ejemplo ADD '1

Se verifica si existe una sentencia WRITE TO que puede reemplazarse por MOVE TO.

Se verifica si existe una declaración STOP en un módulo o módulo de funciones

Se verifica si existe un tratamiento de excepciones vacío.

Se verifica si un campo se asigna a sí mismo.

Se verifica si un string se compara con un campo C que contiene al final espacios en blanco.

Sentencias obsoletas: en este test se verifica que en el programa no se estén utilizando sentencias ABAP clasificadas por SAP como obsoletas ya que a futuro estas sentencias van a dejar de funcionar por lo que el programa ABAP en donde se encuentran también dejará de funcionar tal como lo hace hasta ahora.

Vamos a tomar como ejemplo nuestro primer programa ABAB el cual creamos en la lección "Mi primer programa ABAP" en esta misma unidad y le vamos a ejecutar la herramienta de verificación ampliada del programa.

Agregamos una verificación más a las verificaciones que vienen tildadas por defecto, tildamos "Cadenas caracteres" y vamos a ejecutar la herramienta.

A continuación vemos en la pantalla el reporte de salida que arroja la verificación ampliada del programa en donde se ve un error y tres advertencias para la verificación "Cadenas caracteres".

Si hacemos clic en el botón Vis.resutt.(todos) de la barra de herramientas vamos a visualizar todos los errores que arrojó la herramienta.

Reflexiones: De todos los mensajes que arroja la verificación ampliada del programa debemos prestarle particular atención a los errores que son los que sin duda valen la pena corregir.

Aquí el error nos indica que al tener el programa un texto entre comillas simples entonces dicho texto no se puede traducir a otros idiomas por lo que la forma de corregir esto es crear un elemento de texto y particularmente un símbolo de texto. Para ello vamos al menú Pasar a I Elementos de texto I Símbolos de texto.

Creamos el símbolo de texto 001 con el texto "Este es mi primer programa Abap", luego activamos el símbolo de texto creado y por último hacemos clic en el botón BACK de la barra de herramientas estándar para ir a modificar el código fuente del programa.

Reemplazamos el texto entre comillas simples por el símbolo de texto y activamos el programa.

Volvemos a ejecutar la verificación ampliada del programa para comprobar que con el cambio que realizamos se corrigió el error.

Agregamos una verificación más a las verificaciones que vienen tildadas por defecto, tildamos "Cadenas caracteres" y vamos a ejecutar la herramienta.

Y por último verificamos que la herramienta ya no arroja más errores.

1.2 | El inspector de código

Existen ciertos conceptos básicos relativos al inspector de código que debemos definir antes de ver con un ejemplo como se utiliza esta poderosa herramienta. Estos conceptos son los siguientes:

Variante de verificación: define las reglas que se aplicarán, las verificaciones que se realizarán y la configuración de esas verificaciones.

Existen variantes de verificación locales y globales. Las variantes de verificación globales están disponibles para todos los usuarios. Las variantes de verificación locales están asociadas directamente con una identificación de usuario específico.

Sabias que: SAP proporciona una variante de verificación global con el nombre "DEFAULT".

Conjunto de objetos: define los objetos de desarrollo que se incluirán.

Inspección: define una combinación de variante de verificación y conjunto de objetos, entre otras palabras, qué verificaciones se aplicarán a qué objetos de desarrollo.

Vamos a ejecutar el inspector de código con la variante de verificación global DEFAULT desde el menú Programa / Verificar / Code Inspector.

El resultado de la ejecución muestra un error, cero advertencias y cero mensajes de información. El error nos indica que al tener el programa un texto entre comillas simples entonces dicho texto no se puede traducir a otros idiomas por lo que la forma de corregir esto es crear un elemento de texto y particularmente un símbolo de texto.

Antes de corregir el error y volver a ejecutar el inspector de código quiero que veamos las verificaciones que se incluyen dentro de la variante de verificación DEFAULT que acabamos de utilizar, para ello hacemos clic en el botón Code Inspector de la barra de herramientas.

Aquí dentro de las variantes de verificación vamos a hacer clic en el botón de las caritas de modo que pase a global: luego escribimos DEFAULT y hacemos clic en visualizar. Desde aquí podemos crear, modificar, copiar o borrar una variante de verificación.

A continuación vamos a visualizar el listado de tests y particularmente los que tengan la marca de selección son aquellos que están incluidos en la variante de verificación DEFAULT.

"Si abrimos y desplegamos cada una de las carpetas de los text vamos a ver que dentro de cada carpeta hay muchos text que podemos tildar y destildar nosotros podríamos crear nuestra propia variante de verificación así como existe la variante de verificación en default para ello lo ideal sería copiar la variante default y modificarla cuando hablamos de modificarla nos referimos tildar los text que consideremos que tenemos que imprimir y a destildar aquellos text que deseamos quitar"

Para corregir el error que nos muestra el inspector de código reemplazamos el texto entre comillas simples por el símbolo de texto y activamos el programa.

Volvemos a ejecutar el inspector de código para comprobar que con el cambio que realizamos se corrigió el error.

Y finalmente comprobamos que la herramienta ya no detecta más errores.