Unidad Modularización es como un shell en que podemos escribir código.
Permite segregar un grupo de lineas de código del resto, y lo ejecutamos en un momento determinado. Las lineas de codigos dentro de una modularización actua como un mini-programa que puede llamarse desde otro programa.
ABAP/4 Ofrece tres tipo de unidades de modulariación.
- Events
- Subroutines
- Function modules
Usar unidades de modularización para eliminar código redundante en su programa y hacer mas facil leerlo. Por ejemplo, suponemos que tenemos una serie de sentencias que forman una direccion de correo, y necesita formar direcciones de correo en distintos lugares de su programa. En lugar de euplicar el codigo en su programa, es una buena idea escribir el código en una unidad de modularización y llamarla cuando necesite formar una direción.
Pese a su apariencia, los programas ABAP/4 estan orientados a eventos. Una buena forma de entender ABAP/4 es entender bien los eventos.
Un evento es una etiqueta que identifica una seccion de codigo. La ssecion de codigo asociada con un evento, comienza con un nombre de evento y termina cuando el siguiente nombre de evento se encuentra.En el ejemplo siguiente, los nombres de eventos son : inicializacion, start-of-selection, y end-of-selection. Los nombres de eventos son palabras reservadaas. No podemos crear nuevos eventos, solamente podemos usar los que ya existen.
Ejemplo:
report ztx1701.
initialization.
write / '1'.
start-of-selection.
write / '2'.
end-of-selection.
write / '3'.
Etiquetas repetidas
Una etiqueta de evento puede estar repetida, y entonces el codigo de las dos etiquetas pertenecen al mismo evento ejecutandose en el orden escrito.
etiqueta1.
sentencias "primero se ejecutan estas
etiqueta2.
sentencias.
etiqueta1.
sentencias" y luego estas
Un driver program es un programa que controla otro (driven) programa. SAP suministra driver programas con el R/3 system. Nosotros tenemos que suministar el driven (lanzado) programa. Cuando ejecutamos el programa, el driver programa es el primero que se lanza y entonces llama a los eventos de nuestro programa..
Esto pasa con todos los programas que escribimos en ABAP/4, pero es posible que no lo supieramos hasta ahora. Lea este parrafo cuidadosamente. Lo repetimos una vez mas, cuando ejecutamos nuestros programas, un driver programa comienza primero y controla nuestro programa llamando a los eventos que hay escritos en el.
EL código asociado con un evento es ejecutado por una sentencia del driver programa. Los eventos son lanzados por el driver programa en una predefinida y predecible secuencia.
El orden en que escribimos los eventos en el programa ABAP no es importante, aunque es util escribirlos mas o menos en orden.
Un bucle o condición tiene que estar siempre completamente dentro de un evento. O dicho de otra forma, Un bucle o condición no puede tener una etiqueta de evento en su ambito.
Varios eventos ABAP.
ABAP/4 Eventos
| Category | Events |
| Driver | initialization
at selection-screen
start-of-selection
get
end-of-selection |
| User | at line-selection
at pfn
at user-command |
| Program | top-of-page
end-of-page |
Los Driver eveventos son lanzados por el Driver programa. Los Eventos de usuario son desencadenados por el usuario a traves de la interfaz de usuario. Los eventos de programa son desencadenados dentro del programa.. En este capítulo se detalla el uso de la inicialización, puesta en marcha de la selección, y al final de su selección. Tenga en cuenta que algunos de estos eventos se producen entre el comienzo de la selección y al final de su selección.
Si escribimos sentencias ejecutables sin etiqueta de evento, se adjudican por defecto a start-of-selection.
Orden de eventos lanzados por el Driver Program
- Primero lanza el evento initialization si existe.
- Muestra la pantalla de seleccion del programa (si existe)..
- Lanza el evento start-of-selection event, (recordar que es el evento por defecto en el programa ABAP). Si no hay codigo para ejecutar, no hace nada.
- Lanza el evento end-of-selection si existe.
- Muestra la lista de salida al usuario(output list).
Consideraciones epeciales cuando se usa write en eventos El sistema de eventos tiene dos inusuales efectos en la sentencia write.
- Si el programa tiene una pantalla de selecion y ponemos una sentencia write en cualquier evento de antes de start-of-selection, no veremos el ouput de el. Por ejemplo si tenemos una sentencia statement en el programa, una pantalla de seleción es creada para el programa para permitir al usuario entrar parametros. Si escribimos write en inicializacion, no veremos la salida de este write.
- Un nuevo evento siempre empieza una nueva linea en el output Por ejemplo si ponemos un write en start-of-selection, un write en end-of-selection empezará con una nuevalinea. Podemos usar la sentencia skip to linea para saltarnos este problema.
Lanzando top-of-page
¿como top-of-of page es lanzado en relacion a otros eventos?.
Si el programa no tiene una selection screen, la primera sentencia write ejecuta el top-of-page. Si el programa tiene una selection screen, es posible que top-of-page sea lanzado dos veces:
- Por el write ejecutado antes de la selection screen.
- Por el primer write despues de selection screen es mostrado.
Solamente si escribe alguna sentencia inusual en top-of-page deberá tener cuidado con este doble lanzamiento de eventos.
Si se ejecuta dos veces top-of-page, el write del primero sá descartado. Hay que tener cuidado
- No se puede ver los writes antes de la seleccion. Por lo que no suele escribirse la sentencia write en estos casos.
- Como solamente se suele escribir sentencias write en top-of-page, esta duplicación no hace daño.
Se puede salir de un evento en cualquier momento con las siguientes sentencias:
At this time, please review the function of the check statement (presented in Chapter 10, "Common Control Statements").
Exit y check son sentencias que se usan dentro de un bucle, en tal caso, no tienen nada que ver con el evento.
Exit y check escritos fuera de un bucle, tienen que ver con eventos.
Check
Si el resultado de check es true, se sale del evento y el programa sigue su curso.
Stop
end-of-selection. se sale del evento y el programa sigue su curso.
fuera de end-of-selection. Se sale del evento y se ejecuta el evento end-of-selection.
Exit
En eventos anteriores a start-of-selection, se sale del evento y el programa sigue su curso.
En start-of-selection y eventos posteriores
----------top-of-page. se sale del evento y el programa sigue su curso.
----------------resto de eventos. Termina el report y muestra el output list.
Consejos:
No usar stop en los siguientes eventos:
initialization,
at selection-screen output,
top-of-page, Se produce short dump
end-of-page. Se puede perder salida(si usa write).
Tecnicamente,stop puede funcionar bien en top-of-page y end-of-page si nos abasstenemos de poner sentencias write en el end-of-sselection. Es más seguro de evitar por completo dentro de estos eventos.
sy-subrccheck, exit, y stop nocambian el valor de sy-subrc. Si hace falta podemos asignar nuestro propios valores.
Miremos mas de cerca los eventos en un report que tiene una selection screen (Recordar que la sentencia parameters genera una pantalla de selección).
Cuando el usuario ejecuta el report, el conductor(driver) lanza la inicialización y muestra la pantalla de selección. Cuando el usuario presiona el botón de ejecutar, el conductor lanza el resto de eventos y el programa termina mostrando al usuario la lista de salida. El usuario entonces presiona el boton Retorno(back), para volver, el conductor restaura el proceso comenzando al principio de la lista de eventos, comenzando por el evento inicialización y El usuario ve el la pantalla de seleción. Sin embargo hay alguna diferencia cuando ocurre la restauración.
La pantalla de seleción tiene una copia (propia) de las variables que se muestran en el. La primera vez que se ejecuta el report y el programa conductor toma el control despues de terminar la inicializacion,
guarda en su copia los valores de las variables que corresponden a la pantalla de seleción y los muestra . El usuario entonces puede modificar los campos. Cuando el usuaro pulsa el boton de ejecución, el conductor
guarda en su copia los valores de las variables de la pantalla de selección a parte de guardar los datos en las variables del programa.
Sin embargo la primera copia(la de despues de la inicialización)
solamente ocurre la primera vez que ejecutamos el programa, por lo que al usuario se le muestra los últimos valores introducidos.
Una subrutina es una sección de código reutilizable. Es como un mini-programa que puede ser llamado desde otro punto de su programa. Dentro de el, se pueden definir las variables, ejecutar declaraciones, calcular los resultados, y escribir salida. Para definir una subrutina, se utiliza la sentencia form para indicar el comienzo y la sentencia endform para terminarla. El nombre de una subrutina no puede exceder los 30 caracteres.
Para llamar una subrutina, usamos la
sentencia perform.
Hay dos tipos de subrutinas.
- Subrutinas internas.
- Subrutinas externas.
Las definiciones de subrutinas suelen normalmente escribirse al final del programa , despues de todos los eventos.
La sentencia form define el fin del evento precedente y el principio de una subrutina. Las subrutinas no pueden anidarse dentro de eventos.
Sintaxis de la sentencia form.
form s [tables t1 t2 ...]
[using u1 value(u2) ...]
[changing c1 value(c2) ...].
---
endform.
donde:
- s es el nombre de la subrutina
- t1, t2, u1, u2, c1, y c2 son parámetros.
- tables permite pasar tablas internas como parámetros
- La opción value no puede ser usada con tables.
- La opción value, puede ser aplicada a variables via using o changing.
- --- represents any number of lines of code.
The following points apply:
- Los parámetros son opcionales.
- Hay que respetar el orden.Siempre las tablas primero, luego las using y luego las changing.
- No puede haber mas de una opcion tables , using y/o changig Each addition can only be specified once.
- No usar comas para separar parámetros.
- No se permiten tables de databases.
- Una subrutina puede llamar a otra/s subrutinas.
- Esta soportada la Recursividad. Una subrutina puede llamarse a si misma. Y una subrutina puede llamar a la subrutina que le ha llamado.
- No se pueden anidar subrutinas (No podemos definir subrutinas dentro de otras subrutinas.)
Syntax for the perform Statement
perform s
[tables t1 t2 ...]
[using u1 u2 ...]
[changing c1 c2 ...].
perform n of s1 s2 s3 ...
[tables t1 t2 ...]
[using u1 u2 ...]
[changing c1 c2 ...].
- s, s1, s2, s3, son nombres de subrutinas.
- n is un numerico valor (si vale 1, se ejecutara s1, si vale 2, se ejecutara s2.......)
- tables, using, and changing son opcionales
- La opción value() no puede usarse con perform.
Podemos salir de una subrutina con cualquiera de estas sentencias
Exit y check dentro de un bucle no tienen efecto en una subrutina.
- check and exit Salen de la subrutina y continua con la sentencia que sigue al perform que llamó a la subrutina
- stop sale de la surutina y va directamente al end-of-selection evento.????
check, exit, y stop no modifican el valor de sy-subrc.
Variables globales.
Una variable global es una que es definida fuera de una subrutina usando la sentencia tables o data. Se puede acceder a ellas en cualquier punto del programa dentro o fuera de eventos y subrutinas. Una buena práctica es escribir la definiciones de las variables globales al principio del programa antes de cualquier linea de codigo ejecutable.
Variables localesUna variable local es una variable que que se defina dentro de una subrutina usando las sentencias
local,
data o
statics. Estas variables decimos que son locales a la subrutinas.
Una variable definida con la sentencia local, es accesible por las subrutinas llamadas por la subrutina en la que están definidas las variables. Son inicializadas(se crea una copia) cada vez que se llama a la subrutina.
Las variables definidas localmente con la sentencia data, son inicializadas(se crea una copia) cada vez que se llama a la subrutina, pero al contrario de las creadas con Local, no son visibles por las subrutinas llamadas.
Las variables definidas con statics son creadas una sola vez, por lo que su valor persiste. No son visibles por las subrutinas llamadas.
Visivilidad global versus Sentencia local.Una variable global es visible para todo el programa pero ¡ojo! solamente a partir del punto donde se ha definido.
Una variable creada con la sentencia local en una subrutina, es visible por cualquier otra subrutina llamada por esta. ¡aunque la subrutina llamada esté escrita antes de la definición de la variable.!
Es una de las muchas razones de no escribir globales dentro de una subrutina.
Definiendo una tables Work Area con local.
Las variables definidas usando la sentencia tables son siempre globales . Pero no parece que haya motivos para escribir una sentencia tables dentro de una subrutina.
Para definir una local tabla wrok area dentro de una subrutina, usaremos local en lugar de tables.La sintaxis es la misma, y es visible por las subrutinas llamadas.
Siempre que coincidan en nombre una variable local y otra global, siempre tiene preferencia la local, por lo que las variables globales se hacen invisibles cuando hay una variable local con el mismo nombre.
Defining Data
Las variables definidas con la sentencia data en el comienzo del programa son globales. Las definiciones data en una subrutina, son locales a la subrutina. La memoria es asignada para estas variables cuando la subrutina es llamada, y liberada cuando la subrutina termina. Lo mismo que las variables definidas usando local, los valores de data locales se pierden cuando la subrutina termina.
La variables locales cradas con la sentencia statics no se pierden ni se liberan cuando se termina la subrutina. La sintaxis de static es la misma que la sentencia data. La memoria de variables estáticas es asignada la primera vez que se llama y se conserva al fin de la subrutina. Sin embargo, una variable estática es solo visible dentro de la subrutina. La siguiente vez que la subrutina es llamada, la variable vuelve a ser visible ysu valor es el mismo que la ultima vez que se retorno la subrutina.
Los parámetros son variables,tablas,constalntes,literales... que se pasan de unas subrutinas a otras.
Son los que se definen en la sentencia form con una de estas opciones: tables,changing,using.
Son las variables,tablas,cosntantes.... que se pasan a la subrutina en la sentencia perform.
Tipado de los parámetros formales.En la sentencia form hemos visto, que los parametros se escriben uno detras de otros separados por espacios.
Si además ponemos el tipo, se llaman
parámetros tipados.
Ejemplo de form con parámetros sin tipar.
form s1 using p1 p2 p3 p4.
Ejemplo de form con parámetros tipados.
form s1 using p1 type c p2 type i p3 type d p4 type t.
Pasando field strings como parámetros.Podemos pasa field strings (estructuras) como parámetros de este modo:
Donde x es un field string o una estructura o tabla del diccionario.
Paso por referencia,valor,resultado.Hay tres formas de pasar los valores a una subrutina.
- Paso por referencia.
- Paso por valor.
- Paso por valor y resultado.
La sintaxis de la sentencia form determina como pasan las variables. El perform no puede cambiar la forma de paso .
forma de paso de variables a subrutinas. | Addition | Method |
| using v1 | Por referencia |
| changing v1 | Por referencia
|
| using value(v1) | Por valor
|
| changing value(v1) | Por valor y resultado.
|
Por defecto, los valores se pasan por referencia.
LOS PARÁMETROS CON LA OPCIÓN CHANGING SOLO DIFIEREN DE LA OPCIÓN USING CUANDO SE PASA POR VALOR . UN CHANGING SIEMPRE PUEDE CAMBIAR DE VALOR AUNQUE SE PASE CON LA OPCION VALUE.
xxx
