✒️SAP / El debug del sistema SAP Por Gabriela Munoz

Lección 9. El debug del sistema SAP

Ya sea que trabajemos como consultores funcionales o técnicos, una de las tareas que con más frecuencia vamos a realizar consiste en la búsqueda y corrección de errores, tanto en transacciones Z nuevas, como en transacciones viejas Z, que se encuentran funcionando en el ambiente de producción, como también en el código estándar del sistema SAP.

Dentro del mundo de la programación, se conoce a los errores de programas como Bugs. Los bugs, se producen debido a errores de sintaxis en el código de los programas, como un código de programación incompleto, errores en la lógica de aplicación, entre otros motivos.

Al proceso de encontrar y eliminar errores de software se lo conoce como Debug, también llamado Debugging o en español simplemente Depuración.

Muchas personas afirman que el termino bug fue creado por Grace Hopper, una famosa desarrolladora de la marina estadounidense que creo el lenguaje de programación conocido como Flow-matic. Aunque este lenguaje no haya sido muy utilizado, sirvió como base para COBOL.

Esta versión de la historia cuenta que Grace estaba intentando encontrar el problema en su computador, hasta que descubrió que era causado por un insecto muerto. Sería entonces este el origen del termino bug, que en ingles significa insecto.

La segunda versión es más antigua y tiene una conexión con Thomas Edison, inventor de la lámpara eléctrica. Ella cuanta que, en el 1878, Edison buscaba el origen de un problema en la lectura de su fonógrafo, y finalmente encontró que era un insecto.

Si hablamos del termino debug, este fue usado por primera vez por Glenford J. Myers en 1976 en su libro Fiabilidad del software.

¿Para qué sirve el debug en SAP?

Su objetivo es encontrar errores que pueden impedir que códigos de los programas ABAP funcionen de forma adecuada. Algunos errores se detectan a simple vista, pero para resolver otros vamos a necesitar ejecutar la transacción o el programa y saber exactamente cuáles son los valores que van tomando las variables internas del mismo. De esta forma es posible determinar lo que está ocurriendo dentro del código fuente y obtener sugerencias de acciones para realizar mejoras.

Realizar el debugg de los programas y transacciones, es una de las partes mas importantes del procesos de desarrollo de software, ya que todo el desarrollo debe pasar por una prueba unitaria, realizada por el consultor tecnico ABAP, y una prueba funcional, realizada por el consultor funcional de SAP antes de ser entregado al usuario el producto. Una de las tareas principales de los consultores tecnicos ABAP, consiste en realizar pruebas unitarios de las nuevas funcionalidades Z que se crean o de aquellas ya existentes que se modifican, por lo que es indispensable saber hacer el debugg de estos objetos.

Si bien no es indispensable que los consultores funcionales de SAP sepan realizar un debug, lo cierto es que en el mercado laboral de hoy en día, se valora ampliamente a aquellos analistas funcionales que cuentan con este conocimiento, ya que en ocasiones, cuando estamos trabajando en un proyecto de implementación o de mantenimiento de SAP, tenemos que realizar múltiples tareas y si un consultor funcional sabe realizar un debug, sin dudas va a existir un mejor trabajo en equipo con el o los consultores técnicos ya que el nivel de entendimiento sobre lo que hay que hacer será mayor y eso traerá como consecuencia que los tiempos de trabajo se acorten y la calidad del producto final también sea mejor.

El entorno de depuración de SAP

Dentro del entorno de desarrollo de SAP se encuentra esta útil herramienta que es el entorno de depuración. El debugger es una de las herramientas más poderosas que tiene SAP para el análisis y la solución de problemas.

Se utiliza para ejecutar programas paso a paso y durante el proceso se puede verificar la lógica, inspeccionar el contenido de variables de programa, las tablas internas, las variables del sistema, las áreas de memoria, etc. Para poder realizar el debugging en ABAP vamos a necesitar, por un lado, contar con conocimientos básicos sobre la estructura de los programas y las sentencias ABAP y por otro lado, saber utilizar la herramienta, es decir el debugger.

Sin dudas que cuanto más conocimiento técnico tengamos sobre la lectura de los programas y las sentencias ABAP, entonces más fácil nos va a resultar el análisis con el debugger.

La estructura de los programas y las sentencias

Dentro del mundo ABAP se pueden crear distintos tipos de programas u objetos. Los más comunes son:

· Reportes

· Programas de dialogo

· Formularios

· Batch Input

· User exits

· Field exits

· Funciones y RFC

Para aprender a hacer el debugging nos vamos a concentrar en los llamados Reportes.

Un reporte es un programa que consiste en una serie de instrucciones y palabras calve cuyo objetivo es procesar datos de entra o datos que se obtienen de las tablas del sistema y mostrar los resultados del procesamiento por pantalla.

Los reportes se crean, modifican y visualizan en el editor ABAP a través de la transacción SE38. También mediante la SE80 correspondiente al navegador de objetos.

A continuación, vamos a ver un ejemplo de un reporte muy sencillo y a partir de él vamos a explicar cada uno de los conceptos que necesitamos saber para poder hacer el debugging, sin sumergirnos de lleno en los detalles de la programación.

El nombre de nuestro reporte de prueba es Z_PRUEBA_EVENTOS.

La idea de este reporte es sumar las variables V_CAMPO1 y V_CAMPO2 almacenando la sumatoria en V_SUMA y finalmente imprimir en pantalla V_SUMA.

Los reportes tienen una estructura que siempre se repite y es la siguiente:

1. Comienzan con la palabra clave REPORT seguida del programa

2. Luego vienen las declaraciones de las variables que se usan en el programa

3. A continuación, vamos a ver la declaración de los eventos que se ejecutan en el programa

Un evento en un programa SAP es una etiqueta que identifica una sección del código dentro de un programa. La selección del código asociada con un evento, comienza con un nombre de evento y termina cuando el siguiente nombre de evento se encuentra. Los nombres de eventos son palabras reservadas, es decir palabras que tienen un significado particular dentro del lenguaje de programación. No podemos crear nuevos eventos, solamente podemos usar los que ya existen.

Los eventos que se ejecutan en nuestro programa de prueba son:

1. Initialization

Es el primer evento que se ejecuta y se usa para inicializar o blanquear el contenido de las variables de un programa.

Dentro de este evento, en nuestro programa de prueba, borramos el contenido de la variable V_SUMA e iniciamos la variable V_CAMPO1 con el valor 10 y la variable V_CAMPO2 con 20.

2. Start of selection

Este evento se usa para realizar el procesamiento central del programa, tal como puede ser realizar la selección de los datos, el procesamiento de un archivo, realizar operaciones aritméticas, etc.

Dentro de este evento, en nuestro programa de prueba, realizamos la suma de las variables V_CAMPO 1 y V_CAMPO2 y el resultado lo almacenamos en V_SUMA.

3. End of selection

Este evento se procesa cuando se termina el procesamiento central del programa, es decir cuando luego del evento Start of selection. Contiene las últimas sentencias que se ejecutaran en el programa. En general, se lo usa para realizar la impresión de listados por pantalla.

Dentro de este evento, en nuestro programa de prueba, imprimimos en pantalla el contenido de la variable V_SUMA.

No importa el orden en el que se escriban los eventos dentro de un programa ABAP ya que existe un orden establecido por ABAP y ese será el orden en el que se ejecutaran los eventos.

Finalmente, si ejecutamos nuestro programa de prueba, veremos la salida por pantalla del reporte.

vamos a ver en la pantalla el listado de salida con el resultado de la sumatoria de las variables.

El debugger ABAP

Es muy importante saber usar el debugger ya que en programación las cosas funcionan si y solo si son perfectas.

En ABAP tenemos disponibles dos versiones, una vieja y una nueva. Nosotros usaremos la nueva, por eso primero vamos a chequear que esta funcionalidad este correctamente configurada para nuestro usuario de SAP.

Para ello dentro de la transacción SE38, mientras estamos viendo nuestro programa de pruebas, vamos a ir al menú Utilidades / Opciones. Luego seleccionamos Editor ABAP / Dubugging y elegimos la opción F.debugging nueva y hacemos clic en el botón de la tilde verde.

Ahora bien, antes de comenzar a depurar vamos a ver el concepto de Breakpoint.

También llamado punto de parada, es un stop que podemos colocar en alguna línea del código del programa, de modo que, al ejecutarlo, la ejecución se detenga en ese punto.

Existen 2 tipos de breakpoint:

· Breakpoints de sesión: duran mientras dure la sesión actual de SAP, es decir, para aplicaciones que se lancen dentro de la misma entrada al sistema.

· Breakpoints externos: son válidos para cualquier aplicación que se ejecute en el sistema. Tienen una validez de dos horas.

Para colocar en nuestro programa un breakpoint vamos a seleccionar la línea del programa en donde deseamos interrumpir el procesamiento y hacemos clic en alguna de las dos opciones de breakpoints disponibles.

A continuación, se muestra el icono del breakpoint a la izquierda de la línea del código y en la parte inferior de la pantalla, dentro de la barra de estado, se visualiza el texto sesión de breakpoint fijada.

Vamos a hacer el debugging presionando la tecla F8 o haciendo clic en el icono ejecutar.

A continuación, se abrirá un nuevo modo de SAP, donde vamos a ver la siguiente pantalla con la ejecución de nuestro programa de pruebas detenida en el punto o línea del código donde colocamos el breakpoint.

Para avanzar en la depuración disponemos de los siguiente 4 iconos:

El icono Paso a paso o la tecla F5, ejecutaremos paso a paso es decir sentencia a sentencia o línea a línea.

El icono ejecutar o la tecla F6, ejecutaremos subrutina a subrutina sin entrar en el contenido de cada una. Una subrutina o procedimiento es un bloque de código ABAP que ha sido modularizado en una rutina para hacer más legible el código de un programa lo cual hará más simple el mantenimiento futuro del programa.

El icono retornar o la tecla F7, retornamos a la rutina de nivel superior de la rutina actual en ejecución.

El icono Continuar o la tecla F8, continuaremos la ejecución hasta el final del programa.

Vamos a hacer clic tres veces en el icono Paso a paso de modo que la ejecución de nuestro reporte se detenga en la siguiente línea del código. Una vez allí, hacemos clic en las variables V_CAMPO1 y V_CAMPO2 y V_SUMA de modo de poder ver el contenido almacenado en las variables en la parte derecha de la pantalla.

Mientras estamos ejecuntando el debugging de un programa, podemos crear un Watchpoint el cual funciona igual que un Breakpoint, es decir, nos permite detener la ejecucion de un programa en un punto determinado, co la diferencia de que los Watchpoints no se activan hasta que una variable que le indiquemos, adquiera un valor determinado. Otra diferencia con los Breakpoints, es que los Watchpoints solo pueden colocarse en un programa cuando lo estamos ejecutando, miengtras que los Breakpoints los podemos crear o colocar con solo visualizar el programa. En nuestro progrsma de prueba podriamos crear un Watchpoint para la variable V_SUMA de modo que la ejecucion del programa se detenga cuando esta variable tenga el valor 30.

Si hacemos clic nuevamente en el icono Paso a paso, vamos a ver que luego de la suma de las variables V_CAMPO 1 y 2, el contenido que se muestra a la derecha de la pantalla para la variable V_SUMA se ha actualizado.