✒️ABAP / Las herramientas de ABAP para asegurar la calidad del código Por Candela Calzada

Unidad n°1: Introducción a SAP y a ABAP
Lección n°13: La herramientas de ABAP para asegurar la calidad del código

Cuando desarrollamos en ABAP tenemos que asegurarnos que el código tenga buena sintaxis, seguridad, buen rendimiento, entre otros. Es por ello que ABAP brinda varias herramientas útiles para aumentar la calidad de nuestros desarrollos. Estas son:

• La verificación ampliada del programa (trans. SLIN): esta herramienta hace una verificación completa que incluye las interfaces de los procedimientos externos (si el número y el tipo de parámetro de la interfaz es correcto, si el programa se encuentra activado, si se usan sentencias ABAP obsoletas, etc.)
  Esta verificación es estática. No puede eliminar todas las circunstancias que podrían dar lugar a errores cuando se ejecuten.
  Como resultado de la verificación, veremos errores, advertencias o mensajes sobre cada una de las verificaciones hechas.
  También se puede acceder a esta por el menú de la trans. SE38 (desde el editor ABAP).
• El inspector de código (trans. SCI): se usa para comprobar los objetos del repositorio ABAP. Con él podemos verificar objetos individuales o en conjunto para el rendimiento, la seguridad, la sintaxis y el cumplimiento de las convenciones de nombres.
  Con el inspector se puede definir inspecciones que con la ayuda de variantes de verificación, examinan ciertos conjuntos de objetos.
  Como resultado, recibimos mensajes de información, mensajes de advertencia o mensajes de error sobre diferentes propiedades de los objetos examinados.
  También se puede acceder a esta por el menú de la trans. SE38 (desde el editor ABAP).

La verificación ampliada del programa (trans. SLIN):

El objetivo de las verificaciones más comúnmente usadas son:

• Interfaces PERFORM/FORM: están agrupados los tests que verifican las llamadas de subrutinas PERFORM externas y las definiciones FORM.
  Se hacen las sig. verificaciones para las PERFORM externas:
  Si la definición FORM existe en el programa indicado.
  Si el programa que contiene la definición FORM llamada existe y no es un include.
  *Include: palabra clave del sist. que se usa para la declaración de programas con el objetivo de modularizar los programas ABAP
  Si coincide la cantidad de parámetros actuales con los formales.
  Si coinciden las categorías de los parámetros USING, CHANGING y TABLES.
  *USING: para pasar parámetros de entrada de cualquier tipo de dato, incluido tablas internas.
  *CHANGING: para pasar parámetros de salida de cualquier tipo de dato, incluido tablas internas en subrutinas.
  *TABLES: para pasar como parámetro en subrutinas a tablas internas.
  Si los parámetros actuales y los formales son compatibles.
  Si un literal se transfiere a un parámetro estructurado o en un parámetro de categoría CHANGING.
  
  Verificaciones para las definiciones FORM:
  Si para una definición FORM existe una PERFORM.
  Si existen parámetros FORM sin tipo.
  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.
  *RAISING: palabra reservada que se usa dentro de los módulos de funciones para disparar una excepción.
• Interfases CALL FUNCTION: aquí están agrupados los tests que verifican la llamada y la definición de módulos de funciones.
  Se verifica:
  Si en un módulo de funciones existe el grupo de funciones correspondiente y no tiene errores.
  Si existen los módulos de funciones llamados.
  Si se transfieren todos los parámetros necesarios.
  Que no se transfieran parámetros desconocidos.
  Si los parámetros tienen la categoría correcta (IMPORT, EXPORT, TABLES, EXCEPTION).
  Si los parámetros actuales y los formales son compatibles.
  Si para EXCEPTION's se realiza un tratamiento SY-SUBRC.
  *SY-SUBRC: variable del sistema que devuelve un código de retorno luego de la ejecución de una sentencia ABAP.
  Si la cláusula RAISING intercepta todas las excepciones correctamente.
  Si un módulo de funciones está identificado como obsoleto.
  
  En grupos de funciones se verifica en las definiciones de módulos de funciones:
  Si un módulo de funciones contiene una entrada en la tabla base de datos TFDIR.
  Si para cada EXCEPTION existe un comando RAISE y 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 USERT EXIT'S
  Se hacen las verificaciones:
  Si existe un código de trans. en la tabla de base de datos TSTC, que es la tabla de códigos de trans. de SAP.
  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.
  Si un report llamado mediante SUBMIT tiene el tipo.
  *SUBMIT: se usa para la ejecución de programas ABAP.
  Si los programas llamados son correctos sintácticamente.
  Si todos los parámetros SUBMIT indicados mediante WITH están definidos en el report.
• STATUS GUI y barra de títulos:
  Hace las verificaciones:
  Si el STATUS GUI está definido.
  *STATUS GUI: se usa para proporcionarle al usuario un amplio rango de funcionalidades en la pantalla.
  Si el TÍTULO está definido.
• Message: aquí se agrupan los tests que verifican cuestiones relativas a los mensajes que se muestran en pantalla de los programas.
  Las verificaciones son:
  Si los mensajes dirigidos están definidos en la tabla base de datos T1002.
  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.
  Si la sentencia MESSAGE necesita un texto explicativo, se verifica si existe el texto explicativo para, si el texto explicativo para MESSAGE está activado, si el texto explicativo para MESSAGE está obsoleto.
  *MESSAGE: se usa para ejecutar mensajes en los programas.
• Cadenas de caracteres:
  Contiene las verificaciones:
  Si en un string falta el elemento de texto.
  Si el string en el texto fuente contiene caracteres no permitidos.
  Si strings diferentes con mismo ID de elemento de texto.
  Si un símbolo de texto no se usa.
  Si existe un texto de selección superfluo.
• Propiedades del campo: contiene las sig. verificaciones:
  Si existe una ayuda de búsqueda no definida.
  Si existen campos no usados o leídos.
  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.
  Si el nombre de campo contiene un guion como parte del nombre.
• Sentencias superfluas:
  Si el programa contiene sentencias BREAKPOINT.
  Si el programa contiene un flujo de control dependiente de usuario (si se usa en una condición la variable del sistema SY-UNAME).
  Si existen sentencias trace (como para el análisis de tiempo de ejecución o el comando SYNTAX-TRACE ON).
  Si una sentencia consta solo de un punto.
  Si tras las sentencias EXIT, RETURN, STOP, RAISE o SUBMIT... AND RETURN existen otras sentencias.
• Sentencias problemáticas: se verifica:
  Si las mismas sentencias WHEN aparecen dos veces en una sentencia CASE-ENDCASE.
  Si la 1era sentencia detrás de la sentencia CASE no es una sentencia WHEN.
  Si existen programas direccionados con la sentencia INCLUDE y si son del tipo I.
  Si se llama a la sentencia FREE MEMORY.
  Si existen nombres que empiezan por "%_" ya que están reservados para fines internos.
  Si la sentencia RAISE está fuera de un grupo de funciones.
  Si existe una sentencia WRITE TO que puede reemplazarse por MOVE TO.
  Si existe una declaración STOP en un módulo o módulo de funciones.
  Si existe un tratamiento de excepciones vacío.
  Si un campo se asigna a sí mismo.
  Si un string se compara con un campo C que tiene al final espacios en blanco.
• Sentencias obsoletas: en este test se verifica que en el programa no se usen sentencias ABAP clasificadas por SAP como obsoletas, ya que a futuro dejarán de funcionar.

El inspector de código:

Conceptos básicos del inspector de códigos:

• Variante de verificación: define las reglas que se aplicacrán, las verificaciones que se hacen 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 están asociadas directamente con una identificación de usuario específico.
  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: defina una combinación de variante de verificación y conjunto de objetos (que verificaciones se aplicarán a que objetos de desarrollo).

VIDEO:

Conceptos básicos a saber

• Variante de verificación: define las reglas que se aplicarán, las comprobaciones que se harán y las config. de esas comprobaciones.
• Conjunto de objetos (Object set): define los objetos de desarrollo que se incluirán.
• Inspección en el contexto de inspector de código: combinación de variantes de comprobación y conjuntos de objetos, es decir, que comprobaciones deben aplicarse a qué objetos de desarrollo.
• Diferencia entre variantes de verificaciones locales y globales:
  Los globales están disponibles para todos los usuarios.
  Los locales están asociados directamente con un ID de usuario específico.
  SAP proporciona una variante de verificación global con el nombre "DEFAULT".
  Esto se usa para los objetos que se verifican en el menú contextual de programas, clases, etc.
  Para nuestro nombre de usuario si creamos una variante de verificación local con el nombre DEFAULT, el sistema usará esto en lugar de la variante de verificación global.
• Pasos para usar el inspector de código:
  1. Clic en en "Code inspector".
  2. Veremos abajo de todo la variante de verificación con el nombre DEFAULT (verificación estándar del sist.) que podemos usarla como base para copiarla y generar nuestra propia verificación
  3. Clic en "Visualizar".
  4. Veremos las verificaciones que tiene tildado DEFAULT.