✒️ABAP / Las herramientas de ABAP para asegurar la calidad del código Por Cyntia Ramirez
ABAP Las herramientas de ABAP para asegurar la calidad del código
Las herramientas de ABAP para asegurar la calidad del código
Herramientas importantes para el programador ABAP:
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.
La verificación ampliada del programa es solo una verificación estática.
Se verifican:
- 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 textos.
- Si existen problemas de semántica.
- Si existen advertencias de sintaxis.
Resultado de la ejecución de la verificación ampliada del programa:
El inspector de código: Podemos acceder a través de la transacción SCI.
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.
Resultado de la ejecución del inspector de código:
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.
Acceso desde el menú del editor ABAP:
Transacción SLIN
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.
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.
Si para una definición FORM existe una llamada 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.
Si en un módulo de funciones existe el grupo de funciones correspondiente y no contiene errores.
Si existen los módulos de funciones llamados.
Si se transfieren todos los parámetros necesarios.
Se verifica que no se transfieran parámetros desconocidos.
Si los parámetros tienen la categoría correcta (IMPORT, EXPORT, TABLES,
Si los parámetros actuales y los parámetros formales son compatibles.
Si para EXCEPTION's se realiza un tratamiento SY-SUBRC.
Si la cláusula RAISING intercepta todas las excepciones correctamente.
Si un módulo de funciones está identificado como obsoleto.
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 si para cada comando RAISE aparece una EXCEPTION.
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.
Se verifica si el STATUS GUI está definido.
Se verifica si el TÍTULO está definido.
Se verifica si los mensajes dirigidos están definidos en la tabla base de datos T1002.
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 verífica si existe
Se verifica si en un string falta el elemento de texto.
Si el elemento de texto no definido.
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 utiliza.
Si existe un texto de selección superfluo.
Se verifica si existe una ayuda de búsqueda no definida.
Si existen campos no utilizados o no 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.
Si el programa contiene sentencias BREAKPOINT
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.
Si existen sentencias trace, por ejemplo, para el análisis de tiempo de ejecución (SET RUN TIME..) o el comando SYNTAX-TRACE ON.
Si una sentencia consta sólo de un punto.
Si tras las sentencias EXIT, RETURN, STOP, RAISE o SUBMIT .. AND RETURN existen otras sentencias.
Se verifica si las mismas sentencias WHEN aparecen dos veces en una sentencia CASE-ENDCASE.
Si la primera 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 |
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 un literal numérico en una posición de cálculo, por ejemplo ADD TO.
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
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 contiene al final espacios en blanco.Conceptos básicos relativos al inspector de código:
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 globales que están disponibles para todos los usuarios y variantes de verificación locales están asociadas 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: Define una combinación de variante de verificación y conjunto de objetos, es decir, qué verificaciones se aplicarán a qué objetos de desarrollo.
Ejemplo de como ejecutar el inspector de código con la variante de verificación global DEFAULT. Menú Programa/ Verificar/ Code Inspector
Resultado de la ejecución del inspector de código
Podemos ver las verificaciones que se incluyen dentro de la variante de verificación DEFAULT.
Nos permite visualizar la variante DEFAULT
Los que tengan la marca de selección son aquellos que están incluidos en la variante de verificación DEFAULT.
Para corregir el error que nos muestra el inspector de código reemplazamos el texto por el símbolo de texto.
Ejecutamos nuevamente el inspector de código para comprobar que no hay error..
 
 
 
Sobre el autor
Publicación académica de Cyntia Vanesa Ramirez, en su ámbito de estudios para el Curso SAP ABAP.
Cyntia Vanesa Ramirez
Profesión: Encargada de Comercio - Argentina - Legajo: DQ51G
✒️Autor de: 20 Publicaciones Académicas
🎓Cursando Actualmente: Curso SAP ABAP
Certificación Académica de Cyntia Ramirez






Disponibilidad Laboral: FullTime


















