SAP Debugging para funcionales

Barcelona, Junio de 2010

everis.com
Índice

1. Objetivos del Curso

2. Transacciones del entorno de desarrollo
3. Estructura de la programación
4. Debugging
5. Búsqueda de campos técnicos en screens
6. Edición de registros en tablas de BBDD
7. Gestión de Dumps
8. Notas OSS
9. Foros
Índice

1. Objetivos del Curso

2. Transacciones del entorno de desarrollo
3. Estructura de la programación
4. Debugging
5. Búsqueda de campos técnicos en screens
6. Edición de registros en tablas de BBDD
7. Gestión de Dumps
8. Notas OSS
9. Foros
Objetivos del Curso
El objetivo del presente curso es dotar a los Consultores Funcionales asistentes de las herramientas
mínimas para poder investigar cualquier incidencia de carácter técnico mediante la herramienta de
Debugging.

Aspectos teóricos:
 Transacciones de la programación
 Estructura de la programación

Herramientas prácticas:
 Debugging
 Búsqueda de campos técnicos en screens
 Edición datos tablas por debugging
 Gestión de Dumps

Herramientas de consulta:
 Notas OSS
 Foros
Índice

1. Objetivos del Curso

2. Transacciones del entorno de desarrollo
3. Estructura de la programación
4. Debugging
5. Búsqueda de campos técnicos en screens
6. Edición de registros en tablas de BBDD
7. Gestión de Dumps
8. Notas OSS
9. Foros
Transacciones del entorno de desarrollo
SE11: Diccionario de Datos

El diccionario de datos nos permite definir/modificar/consultar elementos asociados a la organización de la

Base de Datos dentro del sistema:
Transacciones del entorno de desarrollo
SE11: Diccionario de Datos

Tabla

Estructura de campos que almacenará registros en la base de datos.

Su estructura viene representada un conjunto de elementos de datos.
Algunos de los elementos de datos serán declarados como claves: La combinación de valores conformada
por los campos clave de la tabla será única.
Transacciones del entorno de desarrollo
SE11: Diccionario de Datos

Tabla vs Estructura

Tabla: N-dimensional. Matriz

Estructura: 1-dimensional

CAMPO1 CAMPO2 CAMPO3 CAMPO4 CAMPO5

K K K
K K K
K K K
K K K
K K K

K K K
Transacciones del entorno de desarrollo
SE11: Diccionario de Datos

Tipo de Datos: Elemento de datos

Particularización de un dominio: básicamente permite la introducción de la descripción

*Se pueden modificar los textos de un elemento de datos estándar desde la transacción CMOD sin
modificar el propio elemento de datos. (Menú->Pasar a ->Ampliaciones Globales->Palabras clave-
>modificar)
Transacciones del entorno de desarrollo
SE11: Diccionario de Datos

Dominio

Permite determinar las características técnicas de un campo así como definir un ámbito de valores.
Es la unidad mínima de representación de un elemento de la base de datos.
Transacciones del entorno de desarrollo
SE16/SE16N: Consulta de Datos de tablas

El sistema habilita estas dos transacciones para consultar el contenido de datos de una tabla.
En función de cómo haya sido declarada una tabla, se podrá modificar su contenido.
Transacciones del entorno de desarrollo
SE38: Editor ABAP

Transacción para crear/modificar/visualizar, principalmente, los programas.

Existen distintos tipos de programa en función de lo que se quiera desarrollar:
 Report: Programa de uso general (listados, modificación BBDD, ejecución de procesos…)
 Include: Espacio no ejecutable que se usa para encapsular el código de forma ordenada
 Modulpool: Programa con gestión de varias ventanas
 Grupo de funciones: Espacio no
ejecutable donde definir distintas
funciones relacionadas funcionalmente
entre si.
 Pool X: Aglomeración de
sentencias/definiciones a usar en
programas
Transacciones del entorno de desarrollo
SE37: Biblioteca de funciones

Transacción para la creación/modificación/visualización de módulos de función.

Un módulo de función es un proceso que puede ser ejecutado des de cualquier programa.
Las funciones pueden ser llamadas remotamente (RFC) des de otros sistemas.
Transacciones del entorno de desarrollo
ST22: Visor de Dumps

Transacción que permite visualizar los Dumps que han aparecido en el sistema.
Un Dump es una herramienta que ofrece SAP donde se proporciona información referente a la causa y
punto de la ejecución de un error “controlado” por el sistema.
Transacciones del entorno de desarrollo
SE93: Transacciones

Transacción para la creación/modificación/visualización de transacciones del sistema.

A nivel de debugging, útil para saber qué programa está siendo llamado desde una transacción.
Índice

1. Objetivos del Curso

2. Transacciones del entorno de desarrollo
3. Estructura de la programación
4. Debugging
5. Búsqueda de campos técnicos en screens
6. Edición de registros en tablas de BBDD
7. Gestión de Dumps
8. Notas OSS
9. Foros
Estructura de la Programación

La ejecución de un proceso debe entenderse como un conjunto de instrucciones que se ejecuta de forma
lineal.

Que la ejecución de las instrucciones sea lineal no significa que su codificación lo sea. La codificación
sigue una estructuración que permite la reutilización, la compresión y la comprensión de los procesos.

Esta estructuración se realiza en distintos niveles, principalmente, los siguientes:

EJEMPLO: ZCURSO
Estructura de la Programación
Programas / Includes
Los programas (SE38) permiten la agrupación de subrutinas o definiciones de variables de forma
ordenada y diferencial.

Por lo general los programas tienen includes que son partes de código más pequeñas y se agrupan en
base a la naturaleza del código incluido.
Estructura de la Programación
Subrutinas
Una subrutina es una herramienta de
modularización del código que, idealmente,
agrupa el código asociado a una funcionalidad y
que puede ser llamada, dentro de un mismo
programa, tantas veces como se quiera.

La llamada a la subrutina se realiza mediante la

sentencia PERFORM y las instrucciones de la
subrutina se encuentran entre las sentencias
FORM/ENDFORM.

Una subrutina puede tener parámetros de

entrada y de salida que pueden serc tablas,
estructuras o variables.
Aquellos parámetros declarados en su interior
sólo son vigentes dentro de la subrutina durante
esa ejecución.

Una subrutina, pues, es como una función pero

que puede ser ejecutada únicamente dentro de
un mismo programa, mientras que la función
puede ser llamada desde distinto programas.
Estructura de la Programación
Subrutinas
Una subrutina es una herramienta de
modularización del código que, idealmente,
agrupa el código asociado a una funcionalidad y
que puede ser llamada, dentro de un mismo
programa, tantas veces como se quiera.

La llamada a la subrutina se realiza mediante la

sentencia PERFORM y las instrucciones de la
subrutina se encuentran entre las sentencias
FORM/ENDFORM.

Una subrutina puede tener parámetros de

entrada y de salida que pueden serc tablas,
estructuras o variables.
Aquellos parámetros declarados en su interior
sólo son vigentes dentro de la subrutina durante
esa ejecución.

Una subrutina, pues, es como una función pero

que puede ser ejecutada únicamente dentro de
un mismo programa, mientras que la función
puede ser llamada desde distinto programas.
Índice

1. Objetivos del Curso

2. Transacciones del entorno de desarrollo
3. Estructura de la programación
4. Debugging
5. Búsqueda de campos técnicos en screens
6. Edición de registros en tablas de BBDD
7. Gestión de Dumps
8. Notas OSS
9. Foros
Debugging

El debugging nos permite avanzar por el código de un proceso y comprobar paso a paso las instrucciones
que se van ejecutando.

Ventajas del debugging para funcionales:

 Ayuda a entender a nivel básico las distintas instrucciones

 Ofrece posibilidades para detectar incidencias
 Requiere de experiencia para descartar caminos.
No es lo mismo debuggear un estándar que un programa desarrollado por un consultor.
 Ayuda a adquirir un conocimiento funcional de lo que se está haciendo
Debugging
Conocimiento técnico básico a nivel de instrucciones
Las instrucciones básicas en la programación en ABAP IV son las siguientes:

Selección de datos Append: Inserta un registro en una tabla interna

Delete: Elimina un registro de una tabla interna / del

diccionario

Insert: Añade un registro en una tabla interna / del

Loop/Endloop diccionario

Modify: Modifica un registro de una tabla interna / modifica

o inserta un registro de una tabla del diccionario

Update: Modifica un registro de una tabla del diccionario

IF/ENDIF Perform: Llamada a una subrutina

Call function: Llamada a una función

Message: Llamada a un mensaje

If / Else / ElseIf / Endif: Establecen condiciones que

delimitan la ejecución del código
Debugging
Conocimiento técnico básico a nivel de instrucciones
Case / When / Endcase If / Else / ElseIf / Endif: Establecen condiciones que
delimitan la ejecución del código

Check: Si no se supera la condición, no continúa la

ejecución de la subrutina / evento del programa / función

Raise: En funciones, determina un mensaje de error

controlado
Do/Endo
Continue: Dentro de un Loop o un Do, el programa va la
siguiente “vuelta de ejecución”.

Exit: Dentro de un Loop o un Do, el programa sale del

Loop o el Do.

Read: Lectura de un registro de una tabla interna

Debugging
Conocimiento técnico básico a nivel de instrucciones
SAP tiene un conjunto de variables que determina datos internos de los procesos .Las básicas:

SY-DATUM: Fecha del sistema

SY-UZEIT: Hora del sistema

SY-TABIX: Registro de una tabla interna que se está leyendo en un Loop o un Read.

SY-SUBRC: La variable más importante. Indica si una instrucción se ha realizado con éxito o no. Por
ejemplo, si un SELECT no encuentra ningún registro, devolverá SY-SUBRC = 4. El valor de éxito es el “0”

En el debugging de funciones, el valor de SY-SUBRC nos devuelve, en caso de ser distinto a “0”, el valor
de RAISE (error controlado en el desarrollo de la función):
Debugging
Conocimiento técnico básico a nivel de instrucciones
SY-UCOMM: Acción del usuario. Por ejemplo, un botón tiene un código de función. Las acciones se
controlan en el espacio PAI de las screens o en el evento “AT USER-COMMAND” en reports. Cualquier
acción por parte del usuario es controlada por el sistema, desde un click al mouse hasta el “enter” del
teclado.

El listado completo de variables del sistema que ofrece SAP, junto a sus descripciones, puede visualizarse
en la estructura SYST:
Debugging
Conociendo la Herramienta
F5: Avance a la siguiente instrucción

F6: Salta la llamada a una función o subrutina o

método (Si no encuentra un BreakPoint)

F7: Sale de la presente función o subrutina o

método hasta la instrucción siguiente a su
ejecución (si no encuentra un BreakPoint)

F8: Avanza hasta un BreakPoint o finaliza el

debugging.

Creación de un Watchpoint. Tras F8, el debugging

parará cuando el valor del campo introducido en el
Watchpoint se modifique.
Debugging
Conociendo la Herramienta

1. Sentencia que se ejecutará a continuación

2. Valor de variable capturada (tabla interna). Mediante doble click al nombre de la variable es
importada al listado.

3. Tablas internas. Mediante doble click al nombre de la tabla interna se navega a dicha pestaña

4. Estructuras. Mediante doble click al nombre de la estructura se navega a dicha pestaña

5. Pestaña donde se almacenan todos los break-points y watchpoints

6. Valor de variable capturada (variable)

Debugging
Conociendo la Herramienta

Tablas internas

El nombre de la tabla y entre [ ] el número del registro nos permite ver los valores de los campos de ese
registro de la tabla.

Desde el Debugger se puede bajar a excel el contenido de la tabla interna, modificar valores, eliminar registros,
añadir registros, etc… (siempre que dispongamos de permisos) En el entorno productivo esta opción debería
estar restringida.
Debugging
Conociendo la Herramienta

Gestión de BreakPoints

Los BreakPoints suponen un punto donde el debugger parará. Se pueden fijar de distintas formas:

 En el código de un programa o en debugger. Mediante click en la línea (desactivación también

mediante click)

 En el Código:
Debugging
Conociendo la Herramienta

Gestión de BreakPoints

 Mediante el menú “BreakPoint” del debugger: Esta opción nos permite poner el BreakPoint
cuando se ejecuta un comando específico, por ejemplo la sentencia “MESSAGE” o la sentencia
“CALL FUNCTION”. El sistema automáticamente pondrá un BreakPoint en todos los puntos
donde se ejecute esa sentencia y parará en ese punto (por ejemplo en todas las sentencias
MESSAGE; muy útil, siguiendo el ejemplo, para encontrar porqué aparece un mensaje de error).

La opción nos permite introducir, en caso de conocer el detalle, un breakpoint a la llamada a una
función específica o una subrutina.
Debugging
Conociendo la Herramienta

Gestión de WatchPoints

La pestaña WatchPoints permite modificar o eliminar los WatchPoints fijados en el sistema por
usuario/sesión.
Debugging
Conociendo la Herramienta

Pestaña Llamadas

La pestaña Llamadas permite visualizar la secuencia de llamadas a subrutinas, funciones,

métodos, etc por los que ha pasado el debugger hasta llegar al punto actual. Mediante dobleclick
permite navegar al punto de llamada, aunque la ejecución continuará des del punto donde se ha
parado.
Esta opción es muy útil a la hora de seguir de donde procede un valor que se está modificando en
un punto, o establecer BreakPoints en el mismo debugger para que pare en un punto de interés
anterior en la siguiente ejecución de prueba.
Debugging
Conociendo la Herramienta

Finalización del debugging

Para salir del debugging existen dos opciones:

 Mediante el menú Debugging se puede seleccionar la opción “Debugging off” que ignorará
todos los BreakPoints. Con F8 el proceso avanzará hasta su finalización.

 En la realización de tests de pruebas a menudo no se quiere finalizar el proceso puesto que

este implica un cambio en la base de datos o sistema. Si no se ha llegado a ese punto crítico y
se quiere salir del debugger. En ese caso, en el menú Debugging se puede seleccionar la
opción “Finalizar”.
Debugging
Descarte de Caminos
La modularización del código en fragmentos funcionales representados en subrutinas o llamadas a
funciones nos puede evitar de recorrer todas las instrucciones de un proceso. Si se identifica que una
subrutina no va a representar lo que estamos buscando, la herramienta de debugging nos permite saltar
su ejecución.
Generalmente los códigos estándar están extremadamente modularizados a la par que interconectados
con lo que la elección de caminos se hace más difícil.

El conocimiento de cómo se programa puede permitirnos buscar el mejor punto de inicio para el
debugging. Dada una transacción estándar, podemos empezar desde una de sus Screens o a partir de la
ejecución de una acción, en vez de desde la introducción de, por ejemplo, el número de un pedido.

La ejecución de un LOOP de 500 entradas implica el paso de 500 veces por el mismo código. Puede ser
útil, una vez recorrido una vez el LOOP, buscar el ENDLOOP para continuar el proceso. Atención, un
LOOP puede incluir subrutinas, con lo que la identificación de un LOOP en debugging no siempre es
trivial.

Es interesante asegurar lo ya descartado mediante break-points. Si el debugging “se escapa” se puede

volver al punto asegurado.
Índice

1. Objetivos del Curso

2. Transacciones del entorno de desarrollo
3. Estructura de la programación
4. Debugging
5. Búsqueda de campos técnicos en screens
6. Edición de registros en tablas de BBDD
7. Gestión de Dumps
8. Notas OSS
9. Foros
Búsqueda de campos técnicos en screens

Una herramienta muy útil para obtener información sobre la programación del sistema y establecer el inicio
de un camino de debugging consiste en situarse sobre un campo de una pantalla y mediante la ayuda (F1)
navegar a los datos técnicos del campo:
Búsqueda de campos técnicos en screens

Ejemplo: Vamos a buscar la descripción técnica del campo Cl. Documento en la FBL3N
Búsqueda de campos técnicos en screens

Ejemplo: Accediendo a la ayuda (F1) se observa que hace referencia a una estructura, no a una tabla
Búsqueda de campos técnicos en screens

Alternativas:

- Buscar tabla similar a la estructura. SE11 y *

- Referencia de utilización
- Debuggear
- Buscar una rutina que ponga selección
- Buscar una función que tenga relación con lo que se busca
- Buscar llamada a la función REUSE_ALV_GRID_DISPLAY
- Buscar llamada a una pantalla CALL SCREEN
Búsqueda de campos técnicos en screens

Ejemplo: Accediendo a la ayuda (F1) se observa que hace referencia a una estructura, no a una tabla
Debuggear un pop-up

En ocasiones nos encontramos ante una situación en la que no podemos debuggear un proceso ya que
salta un pop-up. Para ello existe una pequeña herramienta de mucha utilidad.
Índice

1. Objetivos del Curso

2. Transacciones del entorno de desarrollo
3. Estructura de la programación
4. Debugging
5. Búsqueda de campos técnicos en screens
6. Edición de registros en tablas de BBDD
7. Gestión de Dumps
8. Notas OSS
9. Foros
Transacciones del entorno de desarrollo
SE16 / SE11: Edición de datos

Para desarrolladores, existe la posibilidad de modificar el contenido de la tablas bloqueadas a la

modificación mediante debugging (SE16/SE11).

Activar el debugging desde el detalle de una

línea (/h) + “Enter” . A continuación modificar la
variable “code” con los posibles valores que se
ven en el código.
Transacciones del entorno de desarrollo
SE16n : Edición de datos

También existe la posibilidad de modificar el contenido de la tablas bloqueadas mediante el debugger

1.Se hace /H en la ejecución de la

selección
2. Se modifica el valor de las variables
GD-EDIT y GD-SAPEDIT. Deben tener
el valor X
3. Se accede en modo modificación
Transacciones del entorno de desarrollo
SE16n : Edición de datos

También existe la posibilidad de modificar el contenido de la tablas bloqueadas con la instrucción

“&SAP_EDIT” (SE16N/UASE16N). Se puede deshabilitar esta función con la Nota 1420281.

¡¡Alternativa si &SAP_EDIT no esta

habilitado !!

1.Activamos el debugging antes de

ejecutar para mostrar los datos.

2. Ejecutamos i creamos un break-point

en el MF SE16N_INTERFACE.

3.F8 , Cuando la ejecución se detenga

en el MF modificamos el parámetro
“I_EDIT” con una X i seguimos con la
ejecución.

4. La opción de edición ya debería

aparecer activa.

*SAP_NO_CHECK desactiva la comprobación de clave foránea.

Índice

1. Objetivos del Curso

2. Transacciones del entorno de desarrollo
3. Estructura de la programación
4. Debugging
5. Búsqueda de campos técnicos en screens
6. Búsqueda de uso de elementos del diccionario en programas
7. Gestión de Dumps
8. Notas OSS
9. Foros
Gestión de Dumps

Un Dump es una herramienta que ofrece SAP donde se proporciona información referente a la causa y
punto de la ejecución de un error “controlado” por el sistema.

La información que aparece en un Dump siempre se organiza según el siguiente esquema:

Gestión de Dumps

A destacar, entre la información proporcionada, los siguientes puntos:

 Análisis de Errores: nos describe el motivo por el cual el sistema ha fallado.

 Notas para corregir errores: Nos da indicaciones sobre qué debe realizarse para resolver el error

 Detalle del código fuente: Nos muestra el punto del código que ha provocado el error. A menudo el error
está en esa línea de código, aunque otras veces puede suceder que el error venga de una línea
anterior.

Además, el Dump nos permite navegar al código fuente y visualizar los valores de las variables en el
momento de la ejecución.

Accediendo al histórico de dumps se pueden visualizar estos valores pero de una manera más limitada.
Gestión de Dumps
Índice

1. Objetivos del Curso

2. Transacciones del entorno de desarrollo
3. Estructura de la programación
4. Debugging
5. Búsqueda de campos técnicos en screens
6. Búsqueda de uso de elementos del diccionario en programas
7. Gestión de Dumps
8. Notas OSS
9. Foros
Notas OSS

Las notas OSS son “parches” que ofrece SAP sobre sus sistemas.
Estos parches provienen de consultas realizadas por los Consultores a SAP o mediante la detección
proactiva de SAP de errores en sus sistemas.
Periódicamente SAP proporciona releases que actualizan los errores del sistema.

Ante la detección de problemas en el estándar de SAP se pueden buscar notas relacionadas que hayan
ya reportado ese error y dispongan de solución o, en caso de no encontrar la solución, abrir una nota de
consulta a SAP.
Las notas de consulta en general las cobra SAP al cliente y para ello hace falta un código de usuario y
contraseña propios de la instalación del cliente y su permiso para realizar la consulta. El precio va ligado a
la criticidad que se dé a la consulta.

Con un usuario/contraseña de cualquier cliente se puede acceder a las notas del portal de SAP para su
consulta.

Una de las rutas de acceso a las notas OSS es a través de la web “help.sap.com” y el menú “other portals”
Notas OSS

Una de las rutas de acceso a las notas OSS es a través de la web “help.sap.com” y el menú “other portals”
Notas OSS

La web ofrecerá campos donde establecer criterios de búsqueda y ofrecerá un listado de resultados:
Notas OSS

Al acceder a una nota obtendremos una descripción detallada de en qué consiste y las soluciones
propuestas para cada versión de SAP, así como notas relacionadas.
Notas OSS

Las notas pueden ser informativas o pueden implicar cambios en la codificación del sistema. En caso de
modificaciones en el sistema, algunas de ellas serán manuales (caso en que se deberá obtener un código
de permiso de modificación del estándar también llamado clave de desarrollador ) o podrán aplicarse
mediante la transacción SNOTE.
Índice

1. Objetivos del Curso

2. Transacciones del entorno de desarrollo
3. Estructura de la programación
4. Debugging
5. Búsqueda de campos técnicos en screens
6. Búsqueda de uso de elementos del diccionario en programas
7. Gestión de Dumps
8. Notas OSS
9. Utilidades