MASTER DE SAP

TAW12_1

1
Unidad 2: Programación de pantallas
Principios de programación de pantallas
Fortalezas de las pantallas
Las pantallas permiten introducir y visualizar pantallas. Unas de sus fortalezas es que se
combinan con el diccionario de ABAP para permitir chequear la consistencia de los
datos que los usuarios deben introducir.
Las pantallas permiten crear dialogos user-friendly con botones, tabstrip controls, table
controls, y otros elementos gráficos.

Pantallas en dialogos de programas

Si vemos un dialogo de programa simple con un selection screen como su pantalla

inicial y una pantalla para visualizar la información del registro seleccionado.
Cuando comienza el programa, el sistema carga su contexto y prepara el espacio en
memoria para los objetos de datos del programa. Se visualiza la selection screen.
El usuario selecciona el dato en la selection screen y da a ejecutar.
En un bloque de procesamiento, el programa lee los datos de la bd. Para hacer esto, le
pasa información sobre el dato pedido a la bd. La bd llena una estructura con el registro
requerido.
El procesamiento lógico llama después a la pantalla. Esto lanza un bloque de
procesamiento enlazado a la pantalla llamadao PBO. Un a vez que se ha procesado el
PBO, el dato se transfiere a una estructura que sirve como interfaz para la pantalla.
Luego se transfiere a la pantalla y se visualiza.
Cualquier acción de usuario sobre la pantalla, devuelve el control al sistema de
ejecución. Los campos de la pantalla son transportados en un estructura que sirve de
interfaz entre la pantalla y el programa, y el sistema de ejecución lanza otro bloque de
procesamiento enlazado a la pantalla, que se llama PAI y que se procesa siempre
después de la interacción del usuario.

2
Elementos de pantalla
Atributos

Los elementos de pantalla text field, input/output field, status icon, group box, radio
button, checkbox y pushbuttons tienen atributos generales, atributos de diccionario,
atributos de programa y atributos de visualización.
Los elementos subscreen, tabstrip control, y table control tienen atributos generales y
atributos especiales.
Se pueden dividir los atributos de un elemento en:
-Atributos definibles estáticamente que no se pueden cambiar dinámicamente.
-Atributos definibles estáticamente que si se pueden cambiar dinámicamente.
-Atributos que solo pueden cambiar dinámicamente.

Procesamiento de pantalla
Pantallas
Las pantallas son objetos definibles que se pueden usar para visualizar o introducir
información a través de input y output fields, listas y demás.
Están formadas por un dialogo entre el usuario y el programa ABAP.

Definiendo y manejando pantallas

Una pantalla consiste en una imagen de pantalla y un flujo lógico. Es un programa que
controla la manera en la que la imagen de pantalla se procesa.
Las pantallas tienen 4 componentes: la mascara de pantalla, los atributos de pantalla, la
lista de elementos y el flujo lógico. El flujo lógico contiene el código de flujo lógico.
Las pantallas son contenedores para otros elementos de pantalla.

3
Atributos

Cada pantalla tiene unos atributos de administración que especifican el tipo, tamaño, y
la pantalla subsecuente.
Los atributos de administración Program y Screen number identifican la pantalla por su
número y el programa que les corresponde.
Los números mayores de 9000 estan reservados para clientes de SAP System. De 1000
a 1010 para el mantenimiento de pantallas de las tablas del diccionario ABAP y
pantallas de selección estándar de programas ejecutables.
El tipo de pantalla identifíca el proposito de la pantalla. Otros atributos especiales de la
pantalla y sus componentes dependen de este atributo.
El next screen permite especificar la pantalla que se debe procesar después de la
pantalla actual en una secuencia fija.

Creación de pantallas
Cuando se crean pantallas se debe:
-Dar atributos generales de la pantalla.
-Diseñar el layout.
-Dar atributos a los campos.
-Escribir el flujo lógico.

Atributos de pantalla

4
Para crear una pantalla desde el object navigator, se crea un nuevo desarrollo con tipo
screen. Se posiciona en screen y se hace clic al botón derecho del ratón.
El object navigator abre el screen painter.
Cuando se crea una pantalla, primero hay que introducir sus atributos. Se mete el
número de pantalla, un texto corto, y el tipo de pantalla. Normalmente el tipo normal.
Se puede especificar la siguiente pantalla en next screen.
Si se pone 0 para la siguiente pantalla, el sistema sigue el procesamiento desde el punto
en el que la pantalla ha sido llamada una vez que se termina de procesar.
También se puede crear una pantalla llamando a CALL SCREEN <nnn> en el editor
ABAP y haciendo doble clic en el <nnn>.

Layout
El editor gráfico provee una manera fácil de definir los elementos de pantalla.
Solamente se escogen y se posicionan donde se quieran en la pantalla.
Para eliminarlo se escoge y se da a delete.
Se pueden mover los elementos con drag&drop.

La lista de elementos
Para permitir dar valores a los atributos de los elementos de las pantallas, el screen
painter contiene una lista de elementos con seis vistas. También se pueden mostrar
todos los atributos para un único elemento desde cualquier lista de atributos. Tambien
se pueden mantener ls atributos para un elemento desde el layout utilizando la función
attributes.
En el screen painter, se trabaja con tipos de datos externos. Estos se corresponden con
tipos de datos del diccionario ABAP. Para campos que se han elegido que estan
definidos en el diccionario, el sistema visualiza el tipo de datos externo en la columna
format. Para elementos que no tienen una referencia al diccionario, hay que introducir el
tipo de datos externo.

Flujo lógico

En el flujo lógico se escriben las llamadas a MODULE. Los módulos son componentes
del mismo program SAP. Contienen sentencias ABAP que se quieren ejecutar.
Se puede crear un módulo haciendo doble clic sobre el nombre en el editor de flujo
lógico.

5
Para crear un módulo desde el object navigator, se elige el módulo de desarrollo PBO o
PAI.
Se puede llamar al mismo modulo desde más de una pantalla. Si el procesamiento
depende del número de pantalla, se puede obtener el número de la pantalla actual desde
el campo sy-dynnr.
Los módulos que se llaman desde el PBO tienen que estar definidos con la sentencia
MODULE…..OUTPUT. Las del PAI con MODULE……INPUT.

Visibilidad de datos

Hay varios procesadores de software participando en el procesamiento de las pantallas

de un programa. El procesador DYNP controla el flujo lógico y prepara los datos para
ser visualizados en pantalla.
Se trabaja con los campos globales del programa con el modulo. Los campos globales
son creados en el TOP include usando sentencias declarativas, por ejemplo : TABLES o
DATA.
Los campos que son reconocidos por el sistema desde la lista de elementos son usados
para recuperar los datos para visualizarlos por pantalla., y también para transportar los
cambios del usuario. Esto ocurre automáticamente cuando cogemos los campos del
diccionario o del programa en el layout editor.

Intercambio de datos: Pantallas – programas ABAP

6
Para poder comunicar una pantalla y su programa ABAP, los campos en la pantalla y
los correspondientes campos en el programa tienen que tener el mismo nombre.
Después de haber procesado todos los módulos en el PBO, el sistema copia el contenido
del campo en el ABAP work area a su correspondiente campo en el screen work area.
Antes de haber procesado el primer modulo en el PAI, el sistema copia el contenido de
los campos en el screen work area a sus correspondientes campos en el ABAP work
area.
Hay que utilizar nuestras propias estructuras (como SDYN_CONN) para transportar
datos entre la pantalla y el programa ABAP. Esto asegura que el dato a transportar
desde la pantalla al programa y viceversa es exactamente el dato que se desea.

Modificaciones dinámicas en pantalla

Atributos estáticos modificables dinámicamente

En el comienzo del PBO, el sistema de ejecución lee los atributos modificables creados
estáticamente y dinámicamente para cada elemento de pantalla en la pantalla actual en
una tabla de sistema con el tipo de línea SCREEN.

Modificación de atributos dinámicamente

Los cambios dinámicos a los atributos de un elemento de pantalla son temporales.

7
La tabla de sistema SCREEN

La tabla de sistema con tipo de linea SCREEN se llama tabla de sistema SCREEN.
Cuando se procesa una pantalla, la SCREEN system table contiene una entrada para
cada elemento creado en la Screen painter para esa pantalla.

Inicializando la Screen system table

La Screen system table se inicializa al comienzo del PBO para la pantalla actual. Para
hacer esto el sistema copia los atributos definidos estáticamente de cada uno de los
elementos de la pantalla en la tabla.
Luego se pueden cambiar dinámicamente en el PBO con estas sentencias:
LOOP AT SCREEN
……
MODIFY SCREEN .
ENDLOOP.
Para hacer esto, se utiliza la estructura SCREEN, que se crea automáticamente por el
sistema y se llena con los valores de cada linea sucesiva en la tabla del sistema. Los
atributos set tienen valor 1 y los que no 0. Para cambiar la tabla de sistema se usa
MODIFY SCREEN con el loop.

8
Para encontrar el elemento cuyos atributos se quieren modificar se puede usar un LOOP
en la pantalla y preguntar uno de los siguientes campos: SCREEN-NAME O SCREEN-
GROUP1 hasta SCREEN-GROUP4.

La modificación de group attribute

Se pueden modificar los atributos de varios elementos simultáneamente en tiempo de

ejecución, incluyendo estos en un grupo de modificación en el screen painter. Se
asignan todos los elementos que se quieren cambiar con un paso de procesamiento a un
grupo en el screen painter. Para hacer esto se introduce un nombre de grupo a cada uno
de los elementos en uno de los grupos de GROUP1 a GROUP4.
Se puede incluir cada elemento en hasta 4 grupos de modificación. Se puede elegir
cualquier secuencia de tres caracteres para el nombre del grupo. Se pueden asignar
elementos a un grupo tanto en el screen painter como en la lista de elementos.

Modificando atributos dinámicamente

Hay que programas las modificaciones en el PBO. Se usa un loop a través de la pantalla
para cambiar los atributos de un elemento o un grupo. (LOOP AT SCREEN
WHERE…. Y READ TABLE SCREEN no se soportan)
Para activar y desactivar atributos se le da el valor 1 o 0 y se guarda con MODIFY
SCREEN.
Los elementos que se han definido estáticamente en el screen painter como invisible no
se pueden reactivar con SCREEN-ACTIVE =1. Sin embargo los atributos que se han
definido estaticamente como visibles, se pueden hacer invisibles con SCREEN-
ACTIVE =0. Esto tiene el mismo efecto que (SCREEN-INVISIBLE=0, SCREEN-
INPUT =0 Y SCREEN OUTPUT =0).

9
Secuencia de pantallas
Determinar la siguiente pantalla
Para transacciones complejas quizá sea necesario utilizar varias pantallas. La pantalla
inicial se determina cuando se crea la transactio code. Cada pantalla determina su next
screen.
El atributo next screen se introduce estáticamente en los atributos de pantalla. En tiempo
de ejecución se pueden controlar usando SET SCREEN <nnn>.

Secuencias de pantallas estáticas

Se puede establecer una secuencia estática de pantallas introduciendo el valor next

screen de los atributos de pantalla.
Si se introduce 0 como next screen, el sistema continua procesando desde el punto en el
que la pantalla se inició, una vez que termina el procesamiento de esta.

Usando next screen dinámicamente

Con la sentencia SET SCREEN <nnn> se da valor temporalmente al next screen.

El next screen se procesa aunque el procesamiento de la pantalla actual termine, o
cuando se termina usando LEAVE SCREEN.
Para especificar el next screen y abandonar la pantalla actual en un solo paso:
LEAVE TO SCREEN <nnn>

10
Insertando secuencias de pantallas
Se pueden insertar secuencias de pantallas. Esto añade una nueva capa a la pila.
Se añade una secuencia de pantalla utilizando CALL SCREEN <nnn>.

Insertando secuencias de pantallas dinámicamente

Para interrumpir el procesamiento de la pantalla actual e iniciar una nueva pantalla se

usa CALL SCREEN <nnn>.
En el programa el sistema construye una pila. La pila tiene que ser destruida antes de
finalizar el programa.
Para volver a la pantalla que llama se puede usar SET SCREEN 0. LEAVE SCREEN. O
LEAVE TO SCREEN 0.
De esta manera se termina el programa y se retorna al punto donde se llama. También se
puede terminar el programa con la sentencia LEAVE PROGRA.

Llamando a un dialog box dinámicamente

En la CALL SCREEN, se puede usar STARTING AT y ENDING AT para especificar

la posición y el tamaño de la pantalla que se llama. La pantalla a la que se llama con el
CALL SCREEN tiene que definirse como modal dialog box.

11
Si se omite ENDING AT, el tamaño del dialog box se determina por used size en los
atributos de pantalla. El sistema determina después el tamaño del dialog box utilizando
el atributo Ocupied size.
Si se usa el ENDING AT, el sistema visualiza como mucho el dialog box que entra en
el espacio disponible. Si no entra por completo se muestran las scrollbars.

Ventanas coordinadas (window coordinates)

La posición de comienzo para cada ventana del sistema SAP es la esquina superior
izquierda.
Left_col, upper_row, right_col y lower_row se pueden utilizar para la segunda pantalla
llamada.

Posicionando el cursor dinámicamente

Cuando el sistema visualiza una pantalla, automáticamente se posiciona el cursor en el

primer input field. Se puede poner en cursor position donde se quiere que aparezca.
También se puede hacer a través del módulo PBO. Para posicionar el cursor:
SET CURSOR FIELD objectname OFFSET positio.

12
Unidad 3: Interfaz del programa
Visión general
La barra de estado del GUI como se ve en la figura se compone de la barra del menú, de
la estándar y de la propia de la barra de aplicación. Cada pantalla se compone de 1 o
más GUI status. Los elementos del GUI status permiten al usuario elegir funciones
usando el ratón.
Los menús son elementos de control que permiten al usuario elegir que funciones se van
a procesar por una aplicación. También pueden contener submenús. System y help
aparecen en todas las pantallas de sap. Nos e pueden ni cambiar ni ocultar sus
funciones.
La barra de aplicaciones contiene iconos de funciones usadas frecuentemente. La barra
estándar es la misma en todas las aplicaciones del Sistema R/3. Permite utilizar
funciones frecuentes. Se utilizan las function keys para asignar funciones a estas.

Todos los programas GUI de barras de títulos y estado conforman el interfaz de usuario.

GUI Title (barra de títulos)

Existen 3 maneras de crear un título:

En la lista de objetos en Object Navigator.

En la ventana gráfica (layout).

En el editor de ABAP.
Un título como mucho 20 caracteres. Se pueden usar variables en los títulos que se
modifican dinámicamente en tiempo de ejecución con el carácter &. Ejemplo: SET
TITLEBAR <nombre_del_título> WITH &1.
La variable de sistema sy-title contiene el título actual en ejecución. El título permanece
hasta que se cambia. Las barras de título también se las conoce como ‘GUI titles’.

13
Status
Un estado (‘status’) es una referencia a una barra de un menú, a ciertas asignaciones de
teclas (key assignments) y a una barra de aplicaciones. Un único componente (como una
barra de menú) puede ser utilizado por más de un GUI. Los GUI status son objetos de
programa en ABAP que se pueden visualizar en pantallas y listas. Se debería configurar
un status para cada pantalla de la aplicación
La barra de menús está hecha de menús individuales. Las asignaciones de teclas (keys)
y las barras de aplicaciones son subobjetos de la configuración de las funciones de una
tecla (‘function key settings’).
Se puede crear una configuración de una barra de aplicación para una tecla individual
eligiendo el menú path GUI-1. Las funciones hay que asignarlas a una tecla (‘function
key’) antes de asignarlas a un botón. Cada status contiene una sola barra de
aplicaciones.
Todos los menús y asignaciones de teclas hacen referencia a todos los interfaces
(interface function list). Estas funciones están en la ayuda F4.
Una función dentro de un status puede estar activa o inactiva.

Funciones

Las funciones se identifican por un código. El atributo ‘function type’ determina el

propósito de la función. Los posibles valores de este campo son:

‘ ’(espacio en blanco), E, P: Para botones y barras de título.

S y H: reservados para uso interno de SAP.

T: código transaccional.
Las funciones se pueden crear con textos estáticos o dinámicos. Si el texto es estático se
le puede asignar un icono, y éste se muestra en lugar del texto. El texto estático se
utiliza cuando se asigna la función a una entrad de menú. Si además del icono se quiere
mostrar el texto hay que introducir este en el atributo Icon text.
El atributo fastpath es para especificar las letras a pulsar para llamar a una función del
menú bar sin utilizar el ratón.

Configuración de function key (function key settings)

Es asignar por ejemplo la F3 para que vuelva a atrás.

14
Las funciones se pueden asignar a function keys individuales o a botones. Una
‘function key setting’ se compone de la (key) tecla y el botón correspondiente de la
application toolbar.
Las asignación de keys se dividen en grupos:

Function keys reservadas: no se puede modificar la función a la que están asignadas
(las de la barra estándar). Se pueden activar y desactivar su función, pero no cambiar
iconos y texto asignados.

Function keys recomendadas.

Function keys de asignación libre.
Las funciones asignadas a function keys también se pueden asignar a botones en la
application toolbar.
Una application toolbar puede tener hasta 35 botones. Se pueden agrupar los botones
visualmente, mediante separadores verticales. Se puede controlar la visualización de las
funciones inactivas en la toolbar: Goto → Attributes → Pushbotton settings.

Menús y barras de menú

Un menú puede contener hasta 15 entradas y 3 niveles de profundidad. Posibles
entradas son funciones, separadores y menus (menus en cascada). El tercer nivel solo
funciones y separadores.
El menú de tipo ‘Include menu’ puede hacer referencia a otros menús en otros
programas. En este caso hay que especificar el nombre del programa y el status desde el
que se quiere incluir. Los include menus son accesibles solo usando el menú bar.
Una barra de menús puede contener hasta 8 diferentes menús. 6 se pueden asignar
libremente por el usuario y 2 son fijados por SAP (system y help).

Creando un GUI status

El tipo de status indica los atributos técnicos del status. Se puede elegir entre status de
diálogo (para pantalla completa) y status de cuadro de diálogo (para dialog box
modales). Los menús contextuales son colecciones especiales de funciones que se
muestran con un clic derecho del ratón.
Se puede crear un status creando enlaces a componentes ya existentes o uno creado
desde 0. En uno propio hay que crearse tus propias barras de menú, funciones, etc…
Los cambios solo afectan a ese status.

15
En la técnica de enlazar con otras aplicaciones hay que crear barras de menús, barras de
aplicaciones y asignaciones de teclas como elementos independientes. Entonces creas tu
propio status y lo referencias al menú, barra de aplicaciones o función del teclado que
quieras. Esta técnica es particularmente efectiva para asegurar la consistencia en
grandes aplicaciones que tienen varios status.

Asignación de function keys

En la configuración de keys se asignan funciones individuales a las teclas (keys) de

función (F1-F12) y a botones.
La configuración de teclas puede tener diferentes tipos (pantalla, dialog box, list y lista
en dialog box).
Se pueden asignar funciones a teclas de distintos tipos (reservadas, recomendadas o
asignadas libremente). Las teclas reservadas aparecen en barras estándar en pantallas y
listas.
Cuando una función es importante, se puede asignar a un botón de la toolbar de
aplicación. La toolbar de aplicación puede tener hasta 35 botones.

Barra estándar (standar toolbar): Asignación automática

Cuando se asigna una función a una barra estándar se asigna automáticamente a una
tecla de función reservada.

Barra de aplicación (aplication toolbar)

Solo se puede utilizar una función en la barra de aplicaciones si está asignada a un
function key.

16
Si se asigna un icono a una función con un texto estático (atributo ‘nombre del icono’),
el sistema muestra el icono en vez del texto estático en la barra de aplicaciones. Para
mostrar texto adicional al botón introducirlo en el campo ‘texto del icono’. Para insertar
un separador en la application toolbar, se utiliza el insert menú en el Menu painter.

Barra de menú (menu bar)

Una entrada del menú puede ser una función, un separador u otro menú (menús en
cascada). Para añadir una función a un menú hay que introducir su código de función en
la columna de la izquierda. Si la función ya existe en la lista de funciones y tiene texto
asignado, se inserta automáticamente en el campo del texto.
Para añadir un separador, usar el Insert menu, rellenar el campo de texto de la función
(‘function text field’) un signo ‘-’. Para crear un submenú hay que insertar su nombre en
la parte derecha de la entrada del menú.

17
Visualización de estándars

Para asegurar la consistencia de datos hay que reutilizar los objetos ya creados (menús,
barra de aplicaciones, etc…). Cuando se asigna funciones a teclas reservadas en la barra
estándar, hay que incluirlas también en los estándares del sistema SAP. Esto hace que el
programa sea más fácil de usar y mantener.

Incluir elementos existentes

Utilizando el editor gráfico (layout) se pueden incluir configuraciones clave (‘key

settings’), barras de aplicaciones o barras de menús que ya se han definido previamente.
Si hay más de una barra de aplicación definida en el key setting, se puede elegir la más
apropiada.
Inicialmente todas las funciones están inactivas. Solo hay que activar aquellas que sean
relevantes en el status actual.
Cuando creas una nueva función se puede decidir si todos los status que referencian al
mismo objeto se deben cambiar a la vez (los cambios en un objeto se propaguen a todos
los que referencian).

18
Utilizando un GUI status
Procesando el Function Code

Cuando el usuario llama a una función del tipo ‘ ’(espacio blanco), usando una entrada
de menú o function key, el sistema coloca el código de función en campo OK_CODE
de la pantalla.
Para poder ejecutar el campo en un evento PAI debes asignar un nombre al campo que
se inserta entonces en la lista de elementos del editor gráfico (layout). Hay que crear
también un campo con el mismo nombre en el programa de ABAP.
Para que no haya pasos inesperados en la ejecución del programa hay que inicializarlo
en el programa de ABAP con el mismo nombre El valor inicial se transporta
automáticamente al command field correspondiente en el PBO

Alternativas para el procesamiento de command field

Se puede inicializar un command field en el PAI o en PBO. Lo más sencillo en meterlo

al final del PBO, en el que un campo del mismo nombre en ABAP es inicializado.
¡OJO!: no se pueden hacer las 2 cosas; sino hay error.
Otro método es copiar el OK_CODE explícitamente a un campo similar y luego
inicializarlo.

19
Unidad 4: Elementos de pantalla de
salida
Campos de texto (text fields)
Un campo de texto es un área rectangular en la pantalla en la que el sistema muestra
texto. Normalmente contienen etiquetas a otros elementos que no se pueden cambiar ni
mover en tiempo de ejecución. Son solamente para visualizar. Se muestran en un sitio
fijo.
Pueden contener líneas, iconos u otros elementos estáticos. Pueden contener caracteres
alfanuméricos pero no pueden empezar con _ o ?. Si se utiliza un texto para un radio
button o un check box, se puede especificar la ubicación (izquierda o derecha).
Si el campo consta de más de una palabra usar caracteres bajos (_) como separadores. El
sistema interpreta los espacios en blanco como separador de 2 campos distintos.
Los campos de texto se pueden traducir. Pueden aparecer en el idioma de logeo.

Atributos

En tiempo de ejecución se puede cambiar el tamaño (atributo ‘visible lenght’) y los

atributos ‘bright’ o ‘invisible’ para mostrar u ocultar el campo. Para hacer esto utilizar
los campos SCREEN-LENGHT, SCREEN-INTENSIFIED, y SCREEN-INVISIBLE (o
SCREEN-ACTIVE).

20
Creación de campos

Se pueden crear campos de texto de una de estas formas:

-Directamente en el editor gráfico (layout).
-Con un texto que acompañe al dato (‘data element’) del diccionario ABAP.
Cuando se utiliza campos de estructuras del ABAP Dictionary en la pantalla, el sistema
normalmente visualiza el elemento de dato y la plantilla (template) para el input/output
field en la pantalla.

Ocultando un text field dinámicamente

Se puede ocultar un texto en tiempo de ejecución. Si haces un texto oculto en tiempo de
ejecución que esta dentro de un cuadro, el cuadro tampoco se muestra.

Atributos modificables dinámicamente

Cuando se procesa el módulo PBO, la tabla de sistema con el tipo de línea SCREEN se
inicializa por el entorno de ejecución y se llena con atributos estáticos desde el Screen
Painter.

21
Para ocultar un text fiel en tiempo de ejecución se modifica la tabla de sistema. Se usa
un LOOP AT SCREEN….MODIFY SCREEN. ENDLOOP

Para hacer el campo invisible también se puede usar: SCREEN-INVISIBLE=1 o

SCREEN-ACTIVE=0.

Modificaciones dinámicas en la pantalla

Para dinámicamente ocultar un campo de texto, se puede llamar a un módulo en el PBO

que marque como invisible el atributo del campo.
Para esto se pone SCREEN-ACTIVE = 0.
¡OJO!: SCREEN es una tabla interna y no soporta sentencias como LOOP AT SCREEN
WHERE… y READ TABLE SCREEN.

Iconos de estado (status icons)

Un ‘status icon’ es un campo de salida que contiene un icono. El icono relevante se
elige en tiempo de ejecución. Son predefinidos en el sistema y tiene entre dos y cuatro
caracteres.

Atributos

22
Son campos especiales que muestran iconos. El sistema marca los atributos ‘campo de
salida’ y ‘bidimensional’ y no se pueden cambiar. El tipo de datos por defecto es char.
Se pueden modificar dinámicamente los atributos longitud visible, marcado
(‘intensified’) e invisible.

Creación de un status icon

Solo se puede definir un campo de status en el editor gráfico (layout).

En el programa ABAP hay que definir un campo con el mismo nombre que el campo
screen usando el campo ‘texto’ de la estructura ‘icons’. En tiempo de ejecución este
campo contiene el nombre del icono que quieres mostrar.
En tiempo de ejecución se puede asignar el icono al campo usando el módulo de
función ICON CREATE.

Se selecciona el icono a mostrar en el código ABAP. Antes de mostrar la pantalla, hay

que encontrar el nombre técnico del icono. Se consigue esto llamando al módulo en el
PBO.

23
Se consigue el nombre técnico que quieres mostrar con la función ICON_CREATE.
Hay que pasarle el nombre del icono que quieres mostrar y esté te devuelve el nombre
técnico.

Grupos de cajas

Se pueden agrupar los elementos que pertenecen a un grupo (un grupo de campos o
botones). Se les puede asignar un titulo.

Atributos

Se les puede cambiar los atributos ‘longitud visible’ e ‘invisible’. En tiempo de

ejecución si la caja solo contiene elementos invisibles y el atributo ‘runtime
compression’ esta marcado, no se muestra ni la caja.

Creación
Se puede definir un grupo de elementos desde el layout. Debe tener nombre y
encabezamiento.
Se puede cambiar el texto dinámicamente. Para ello hay que activar el atributo ‘output
field’ y crear una variable global en el programa ABAP con el mismo nombre.

24
SECCIÓN: PROGRAMMING USER DIALOG
Unidad 5: Screen elements de input/output
Input/Output fields
Un input field es un elemento de pantalla rectangular en el cual el usuario introduce
datos. Puede tener chequeos automáticos de los valores introducidos en ellos que los
relacione con sus data type. Los input field creados con referencia a los ABAP
Dictionary fiels pueden tener chequeos de consistencia de datos (foreign key check, y
value sets).

Un outpu field es un elemento de pantalla rectangular en el cual el sistema muestra

texto u otros datos.

Ambos son conocidos como templates (plantillas).

Atributos
Los input/output fields tienen los siguientes atributos:

Los atributos marcados en naranja se pueden cambiar temporalmente usando la

SCREEN system table.

No es posible activar todas las combinaciones de los atributos. Esto depende del
formato del input/output field.

Crear input/output fields

Hay dos formas de crearlos:
• Introduciéndolos directamente en el layout editor.

25
 • Usando una plantilla del diccionario ABAP: Botón Dict/Program fields.

Si se quiere utilizar el contenido de un input/output field en un programa ABAP, se

debe declarar el campo de forma global usando la sentencia DATA o TABLES.

Valores por defecto en la memoria SAP

Se pueden guardar valores en la memoria SAP usando un parámetro ID, el cual esta
disponible para todas las sesiones tanto internas como externas.

El parámetro SET copia el contenido del campo correspondiente en la memoria del

sistema SAP en el PAI processing block.

El parámetro GET copia el contenido del campo correspondiente desde la memoria

SAP al final del PBO processing block, mostrándolo por el campo correspondiente.

Se puede unir un input/output field a un área de una memoria SAP en el diccionario

ABAP.

Cuando se usa un input/output field que esta definido en el diccionario ABAP, su

parámetro ID se muestra en el atributo Parameter ID en la Screen Painter.

Los atributos del parámetro SET y del parámetro GET (SPA y GPA en la tabla)
permiten habilitar las funciones de dichos parámetros de forma separada.

Field Input checks automáticos

Después de que una pantalla es mostrada pero antes de que se procese el modulo PAI, el
sistema automáticamente chequea los valores que el usuario a introducido en la ventana
(Field input checks).

El primer chequeo garantiza que se hayan rellenado todos los campos.

El sistema puede llevar a cabo chequeos de foreign key solo si un screen field hace
referencia a un ABAP Dictionary field para el cual una check table ha sido definida.

La función de ayuda F4 siempre esta activa.

26
Field Input checks con Error Dialog

Si los chequeos automáticos de los field input son insuficientes, el usuario puede
programar los suyos propios en el PAI event. Para ello se usa la sentencia FIELD con
la adición MODULE.

Si un error o warning meesage ocurre durante el modulo, el sistema muestra la ventana

otra vez pero sin procesar el PBO module.

Si se quiere asegurar que mas de un campo esta preparado para un error dialog (chequeo
de grupo de campos), el usuario debe listar todos los campos que desee chequear en la
sentencia FIELD con el MODULE, e incluir ambos en el bloque CHAIN …
ENDCHAIN.

Se puede incluir campos individuales en mas de un bloque CHAIN … ENDCHAIN.

27
Si un usuario confirma un warning message, el sistema reiniciara el PAI processing
alter la sentencia MESSAGE donde se lanzan los errores.

Categorías de Dialog Message

Los mensajes están divididos en seis categorías:

• A (Termination): El proceso termina y el usuario debe reiniciar la transacción.
• X (Exit): Como el mensaje A, pero con un dump MEESSAGE_TYPE_X.
• E (Error): El proceso es interrumpido, y el usuario debe corregir la entrada.
• W (Warning): El proceso es interrumpido y el usuario puede corregir la entrada.
• I (Information): El proceso es interrumpido, pero continúa cuando el usuario
confirma el mensaje.
• S (Success): Se muestra información en la siguiente ventana.

La sentencia FIELD y el Data Transport

El sistema transporta los datos de los screen fields en los ABAP fields con el mismo
nombre en el PAI processing block. Primero, transporta todos los campos que no
aparecen en la sentencia FIELD. Estos campos son transportados cuando el sistema
procesa dicha sentencia.

Si un error o warning message ocurre en un modulo perteneciente a una sentencia

FIELD, los valores en curso de todos los campos de una misma estructura CHAIN son
automáticamente transportados de vuelta a sus correspondientes screen fields.

28
Condicional Module Calls
Los field input checks normalmente requieren acceso a la base de datos. Evitando esto
cuando sea posible, se mejorara el rendimiento del programa.

Normalmente para poder abandonar una pantalla se deben rellenar todos los campos
obligatorios. Esto es un problema, porque si un usuario se mete por equivocación en una
ventana, y no conoce el conjunto de valores de entrada que satisfaga los input checks,
no podría salir de ella. Se debe permitir que un usuario pueda salir de una pantalla sin
necesidad de que los field check tengan lugar.

Para proteger al usuario de la perdida de los datos que el a metido si sale de la ventana
involuntariamente, se utilizan security prompts (indicaciones de seguridad).

Execution on Input
Si se utiliza ON INPUT en una sentencia MODULE que se encuentra dentro de la
sentencia FIELD, solo se llama al modulo si el contenido del campo es diferente a su
valor inicial.

Dentro de un bloque CHAIN, se debe usar ON CHAIN-INPUT. En este caso, se llama

al modulo si al menos el contenido de un screen field del bloque CHAIN ha cambiado
respecto a su valor inicial.

Se puede usar el ON INPUT solo si la sentencia MODULE esta contenida en la

sentencia FIELD.

29
Execution on Change
Si se usa ON REQUEST en una sentencia MODULE que se encuentra dentro de la
sentencia FIELD, se llama al modulo solo si el usuario introduce un nuevo valor en ese
campo.

Dentro de un bloque CHAIN, se debe usar ON CHAIN-REQUEST. En este caso, se

llama al modulo si el usuario cambia el contenido de al menos un de los screen field del
bloque CHAIN.

Se puede usar el ON REQUEST solo si la sentencia MODULE esta contenida en la

sentencia FIELD.

30
Evitando los Field Input checks
El module con la adicion AT EXIT-COMMAND es procesado antes que los field input
checks automaticos. Solo se puede usar el AT EXIT-COMMAND con un modulo por
cada ventana. No puede estar asociado con la sentencia FIELD.

Navegación: Targets
Con las funciones Back y Cancel : desde ventanas del mismo nivel que la
ventana inicial, se vuelve a la ventana inicial; desde ventanas que contienen información
de detalles, se vuelve a la ventana que llamo a la ventana actual. La función Cancel
difiere de la Back es su dialog behavior.

La función Exit retornar a donde la processing unit fue llamada.

31
Navegación: Single-Screen Transaction

Back sale de la transacción en curso y vuelve al calling program.

Exit sale de la transacción en curso y vuelve al calling program.

Las funciones Exit y Back se diferencian en su dialog behavior para prevenir la perdida
de input data.

Cancel muestra otra vez la pantalla con los data fields inicializados y permite al usuario
seleccionar nuevos objetos.

Navegación: Dialogs

Si el usuario introduce datos en la ventana (sy-datar = X), se puede evitar perderlos

accidentalmente usando una security prompt (indicación de seguridad) predefinida.

32
Para las funciones Exit y Cancel, primero se envía un dialog box al usuario para que lo
acepte y rechace. Despues (en el caso de la función Exit), el sistema chequea los input
en la ventana. La función en cuestión debe ser de tipo E.

En el caso de la función Back, los input checks se hacen antes de mostrar el dialog box.

Input help
Input help (F4 help) muestra al usuario una lista de posibles valores de entrada para un
screen field. Además de las posibles entradas, se puede mostrar información adicional
relevante sobre las entradas. El input help normalmente esta definido en el diccionario
ABAP.

Si un campo tiene un input help, el botón de posibles entradas aparecer en la derecha. El

botón esta visible si se pasa el cursor sobre el campo.

Dropdown boxes ayudan a los usuarios a elegir una entrada de un pull-downl list que
contiene las posibles entradas.

Para crear un dropdown boxes para un input fild se debe:

• Fijar el atributo Downdown a List box.
• Cambiar el atributo Visible Length para mostrar la longitud del texto descriptivo.
• Fijar el atributo Value list a ‘ ‘ para usar valores del diccionario ABAP.
• Si se requiere, fijar la function code para la selección. Esta functon code lanza el
PAI; se puede interpretar la function code usando el campo OK_CODE.
El atributo visible lenght del campo determina la width (anchura) del campo y de la
selection list. Se debe cambiar el width de un campo cuando se convierte este a
dropdown box.

33
Los valores son automáticamente llenados usando el search help asignado al ABAP
Dictionary field. El ABAP Dictionary field debe tener un search help (check table) con
dos columnas o una tabla de valores fijos.

Grupos de Checkboxes y Radio button

Los radio buttons permiten al usuario elegir solo un elemento de un grupo de campos.
En este caso, cuando el usuario selecciona uno, todos los demás son automáticamente
deseleccionados.

Los checkboxes permiten al usuario elegir uno o más elementos de un grupo de

campos.

Atributos
A los checkbox y a los radio buttons se les debe poner un nombre.

Se puede mostrar texto e icono junto a ellos. El texto esta contenido en el atributo Text.
Para mostrar un icono se debe introducir el nombre de dicho icono en el atributo Icon
name.

Se puede cambiar dinámicamente los atributos Input field y Invisible usando el

SCREEN system table.

34
Crear un Checkbox
Los checkbox se crean en el editor de la Screen Painter. Se debe seleccionar el objeto
checkbox de la lista de objetos y colocarlo en la pantalla. Se le debe asignar un nombre a
cada checkbox. En el programa ABAP, crear un campo con el mismo nombre, tipo C, y
longitud 1.

Si un checkbox no esta seleccionado, su valor es initial.

Se le puede asignar una functioncode y function type. Cuando un usuario selecciona

uno, el PAI event es lanzado y la function code es asignada al command field
(OK_CODE).

35
Crear un Radio Button Group
Pasos para crear un radio button:
• Crear el radio button como elemento individual. Elegir radio button de la lista
de objetos y colocarlo en la pantalla. Se le debe asignar un nombre a cada radio
button. En el programa ABAP, crear un campo con el mismo nombre, tipo C, y
longitud 1.
• Se puede combinar una colección de radio buttons en un radio button group.
Para ello, se debe seleccionar los radio button del layout edit, botón derecho,
elegir Edit > Group > Radio button group > Define.

Si un radio button no esta seleccionado, su valor es initial.

Se puede asignar una function code y function type al radio button group. Cuando el
usuario selecciona un radio button, el PAI event es lanzado y la function code es
asignado al command field (OK_CODE).

Se puede asignar una function code a un radio button después de tener definido un radio
button group. El sistema asigna la misma function code a todos los radio button del
grupo.

El código de la imagen sirve para comprobar que radio button o checkbox se ha

seleccionado.

36
Pushbuttons
Los pushbuttons son input filds para el command field (OK_CODE).

Usar pushbuttons en la data area de una ventana para mostrar o esconder información.

Si un pushbutton esta relacionado con un único campo o con un pequeño grupo de

campos, hay que asegurarse de que el pushbutton este los mas cerca posible de ellos. Si
la función esta relacionada con un grupo, hay que dejarlo claro mediante un group box
(cuadro de grupo).

Si varios pushbutton están relacionados con una tabla mostrada en la pantalla,

colocarlos debajo de ella formando un fila horizontal, lo mas juntos posibles, con una
línea blanca entre ellos y la tabla.

Cuando el usuario elige un pushbutton, el sistema llama al programa que contiene dicha
función. En este punto, el control del programa pasa a un work process en la application
server, que proceso el PAI processing block.

Atributos
Los pushbuttons pueden contener texto (atributo Text), un icono, o ambos. Se puede
especificar un icono estáticamente o dinámicamente, usando el function module
ICON_CREATE.

Se puede cambiar dinámicamente los atributos visible lenght, ouput field y visible
usando el SCREEN system table.

Se puede cambiar el texto de un pushbutton dinámicamente. Para ello, se fija el atributo

Output field en la Screen Painter como activo, y se crea un global field con el mismo
nombre en el programa ABAP. Como el Screen Painter field y el program field tienen el

37
mismo nombre, cualquier cambio en el contenido del campo será inmediatamente
visible en la ventana.

Crear y procesar pushbuttons

Pasos para crear un pushbutton:
• Crear a pushbutton: Elegir el objeto pushbutton de la lista de elementos de la
Screen Painter, colocarlo en la pantalla, y asignarle un nombre. Introducir una
function code para el pushbutton en el atributo Function code. Este será asignado
automáticamente al OK_CODE field cuando el usuario elija un pushbutton en la
ventana.
• Activar el command field (OK_CODE field): Se debe dar al campo un nombre
en la lista de elementos del Screen Painter, y se debe declarar un identically-
named field en el programa ABAP con referencia al system field sy-ucomm.

Si el usuario elige un pushbutton que tiene una function type ‘ ‘ (space), se procesa el
PAI event.

Si el usuario elige un pushbutton que tiene una function type E, el sistema procesa un
modulo AT EXIT-COMMAND. Esto ocurre antes del field transport automatico y los
field input checks. Después del modulo AT EXIT-COMMAND, el sistema continua
procesando la pantalla normalmente.

38
Unidad 6: Subscreens y Tabstrip Controls
Subscreens

 Un área subscreen es un área rectangular en la pantalla, en la cual se puede alojar

otra pantalla en tiempo de ejecución. Subscreen areas no puede contener otro
elemento de pantalla. Para usar un subscreen, creas una segunda pantalla (con el
tipo de subscreen) y la muestras en el área del subscreen que has definido en la
pantalla principal.
 Una subscreen es una pantalla independiente la cual se muestra dentro de otra
pantalla. Podrías usar una subscreen como forma de mostrar un grupo de objetos
desde la pantalla principal en ciertas circunstancias, pero no en otras. Se puede usar
esta técnica para mostrar u ocultar campos extras de la pantalla principal,
dependiendo de las entradas de usuario que se hallan hecho.
 Un segundo uso para los subscreen es que los diferentes programas pueden usar el
mismo subscreen. Para esto, debes ejecutar otros programas de pantalla dentro del
principal programa.
 Puedes incluir más de una subscreen en una sola pantalla principal. Puedes también
determinar subscreens dinámicamente en tiempo de ejecución.
 Puedes hacer uso de las subscreens en las siguientes circunstancias:
o Mejoramientos de pantalla (screen exits)
o Dentro de otros objetos de pantalla (tabstrip controls)
o En las modificaciones
o En trasacciones web.

39
Atributos

 Si la subscreen es mas larga que el área de la subscreen que la ha llamado, el sistema

muestra solo lo que cabe dentro de la pantalla, empezando por la esquina superior
izquierda. Sin embargo, se puede utilizar el atributo scrollable para asegura eso, si la
pantalla es muy grande, entonces el sistema muestra los scrollbars.
 Los atributos de resizing son los que indican si el área de subsreen puede ser
ajustado tanto vertical como horizontalmente.
 El atributo Context menú te permite asignar un menú context-sensitive a los campos
de salida de subscreen.
 Las siguientes restricciones se aplican a las subscreens:
o CALL SUBSCREEN no son permitidas dentro de un LOOP y ENDLOOP o
dentro de CHAIN y ENDCHAIN.
o Un subscreen no debe tener campos OK_CODE.
o Los nombres de los objetos no deben contener un modulo con la sentencia
AT EXIT-COMMAND.
o No puedes usar las sentencias SET TITLEBAR, SET PF-STATUS, SET
SCREEN, o LEAVE SCREEN.

40
Creando un subscreen area

 Para crear una area subscreen, escoge desde la lista de objetos del Screen Painter y
colócala en la pantalla.
 En el campo Object text, introduce un nombre al área de subscreen. Lo necesitarás
para identificar el área cuando llames al subscreen.

Llamada a subscreen

 Para usar una subscreen, debes llamarla en ambas secciones, tanto en el PBO y en el
PAI del flow logic de la pantalla principal. La sentencia CALL SUBSCREEN

41
 <subarea> le dice al sistema que ejecute los bloques del PBO y del PAI para los
componentes del PBO y PAI de la pantalla principal.

Caso especial: Visibilidad de datos

 Los campos que se usan dentro del flow logic son campos globales de tu programa
ABAP, estos campos deben ser declarados en el TOP include de tu programa.

Subscreens desde programas externos

 Si la subscreen no esta dentro del programa principal, el dato global del programa
principal no esta disponible en la subscreen y los datos de la pantalla no serán
transferidos de regreso al programa. Debes programar la transferencia de datos por
tu mismo (por ejemplo, usando un módulo de funciones que exporta e importa
datos, con la sentencia MOVE en el código de la subscreen).

42
Encapsulación en function groups

 Si quieres utilizar subscreens en las pantallas de diferentes programas, encapsula las

subscreens en un function group y utiliza function modules para transportar datos
entre el programa en el cual quieres usar las subscreen y la function group.
 Pasas datos entre el programa que llama y la function group usando interfaces de
functions modules.
 Esta técnica es usada por clientes de subscreens.

Subscreen en function groups: Secuencia de llamada

 Usas functions modules para transporta datos entre el programa que llama y la
function group
 Para declarar los datos desde el programa que llama a la subscreen desde la function
group, usa un module antes de la llamada de la subscreen. Esta llama un function
module la cual la cual hace la interfaz de datos requerida para la function group.
 La llamada de la function group debe ocurrir antes de la llamada de la subscreen.
Esto asegura que los datos sean conocidos en la function group antes que el
PROCESS BEFORE OUTPUT sea ejecutado.

43
 La secuencia es reservada en el modulo PAI de la pantalla que llama. Puedes llamar
al bloque PROCESS AFTER INPUT de la subscreen antes que llames a la function
module para pasar los datos desde la function group y regresarlos al programa que la
llama.

Subscreens en function group: Transporte de datos

 Los datos desde el programa que llama están disponibles globalmente en la function
group, debes transferir los parámetros desde la function module en los data fields
globales de la function group.
 La function module que usa la transferencia de datos desde el programa que llama
dentro de la function group debe copiar los parámetros de interface en los datos
globales en una function group.

Tabstrip controls
Screen Elements: Tabstrip Controls

 Un Tabstrip te provee un uso amigable de mostrar diferentes componentes de una

aplicación en una sola pantalla y permitir al usuario navegar entre ellos.
 Controles Tabstrip son una forma fácil de simplificar aplicaciones complejas.
Puedes usar controles tabstrip donde tengas diferentes componentes de una
aplicación que forma una unidad lógica. Por ejemplo, podrías tener un juego de
datos principales que mantienen una constante, mientras, por debajo quieres mostrar
datos de otros juegos.
 No debes usar tabstrip si:
o Si necesitas cambiar el ambiente de la pantalla (menus, pushbuttons, header
data y mas) mientras proceses los componentes de la aplicación.
o Los componentes deben ser procesados en cierto orden. Los controles
Tabstrip son diseñados para permitir a los usuarios que naveguen libres entre
los componentes.

44
 o Los componentes son procesados dinámicamente, eso es, la entrada de un
usuario en un tab page causar que aparezca otro tab page de repente.
 Controles tabstrip son compatibles con los procesos de entrada batch.
 Un control tabstrip consiste de páginas individuales con un tab page y un tab title.
 Si el control tabstrip contiene muchas páginas, no es posible por todos los tab titles
mostrarlos de una sola vez. En este caso, un scrollbar te permite revisar a través de
los tab pages restantes. En la esquina superior derecha se encuentra este pushbutton.
Si el usuario selecciona este pushbutton, una lista de todos los tab titles es
desplegada. El tab title activo es marcado con un check.

Elementos de página

• Un page element consiste de un tab title, un área subscreen y de un subscreen.

• De un punto de vista técnico, los sistemas manejan los tab titles como pushbuttons.
• El contenido de los page elements son mostrados usando la técnica de subscreen. Se
asigna un subscreen area a cada page element por lo cual entonces puedes llamar a
una subscreen.

Atributos
• Adicionalmente, los atributos en general, Object name, Starting position, y static
size, los controles tabstrip tienen atributos especiales.

Creación de un tabstrip
• Para crear un tabstrip debes seguir los siguiente 3 pasos:
o Define un tab area
o Define el tab titles y si es necesario más tab titles.
o Asigna una subscreen area a cada page element.

45
TABSTRIP AREA

• Para crear un tabstrip control area, escoje Tabstrip control desde la lista de objetos
del Screen Painter y ponlo en el screen. Fija la esquina izquierda del table control
area y arrastra el objeto al tamaño requerido.
• Asigna un nombre al tabstrip control en el atributo Object name. Necesitas este
nombre para identificar tu tabstrip control
• En tu programa ABAP, usa las sentencias de CONTROLS para declarar un objeto
con el mismo nombre. Usa el TABSTRIP como tipo.
• El tipo TABSTRIP es definido en el pool de tipos CXTAB. El campo ACTIVETAB
contiene el function code de la tab title de la tabstrip actual. Los otros campos son
reservados para usos internos.
• El número por defecto de tab pages por cada tabstrip es de 2.

46
TAB TITLE

• Técnicamente, tab titles son tratados en la misma forma que los pushbuttons. Tienen
un nombre, un texto, un fuction code, y un function type. Cada uno lo ingresas a los
siguientes campos Name, Text, FctCode y FctType respectivamente.
• Un tab title puede tener el function type ‘’ (spacio) o P si el function type es
‘’(espacio), el bloque PAI es disparado cuando los usuarios escogen y el function
code del tab title es puesto en el campo de comando. Si el function type es P, el
usuario puede desplazarse entre diferentes tab pages del mismo tipo sin disparar el
bloque de proceso del PAI. Si quieres que tu control tabstrip tenga más de 2 páginas,
debes crear más tabtitles. Para hacer esto, escoje el pushbutton desde los objetos de
lista en el Screen Painter y ponlo en el área del tab title.

TABSTRIP SUBSCREENS

• Debes asignar un subscreen area a cada página

• El subscreen area asignado al tab page es automáticamente ingresado como
Referente object (en el Diccionario de atributos) por el tab title de la página.
• Para asignar un subscreen area a uno o más tab pages, escoge el tab title relevante en
la pantalla del editor, escoge el objeto Subscreen, y ponlo en el tab page.
• Alternativamente, puedes asignar una sola pantalla a muchos tab pages ingresando
el nombre de las subscreen areas directamente en el campo Reference object de los
atributos de los tab pages relevantes.

47
Scrolling locally in Tabstrip controls

 Si tienes asignadas diferentes áreas subscreen a casa page element en un tabstrip

control, puedes desplazarte entre las páginas localmente al frente.
 Para esto, debes enviar todos los subscreens al frente y cuando envíes la screen
principal misma. Todos los tab titles en el control tabstrip deben tener también la
función tipo P.
 Cuando te desplaces entre los diferentes page elements, no hay comunicación entre
la presentación y aplicación del servidor.
 Cuando el usuario escoge un function en la pantalla dispara un triggers PAI, el
sistema procesa el bloque PAI de todos los subscreen también. Esto significa que
todos los campos checks están siendo ejecutados.
 Desplazamientos locales en los controles tabstrip son más apropiados para mostrar
transacciones.
PROGRAMACIÓN

 Para programar que un control tabstrip se desplace localmente en el frente, debes:

o Asignar un area subscreen separada de cada tab page.
o Llama todas las subscreens desde el flow logic

48
 o Asigna la función type P para todos los tab titles
 El sistema oculta cualquier page element de los subscreen que no tengan elementos
para ser mostrados.
 Si no hay page elements que contengan elementos a ser mostrados, el sistema oculta
el tabstrip completo.

Scrolling en tabstrip controls

 Si todos los page elements comparten una sola subscreen area, el programa analiza
el function code que ha escogido en el tab title para determinar que pantalla será
mostrada.
 Hay dos pasos en este proceso:
o En el bloque de PAI, el programa determina cual page element necesita ser
activo basado en el tab title elegido por el usuario.
o Cuando el bloque PBO es procesado de nuevo, el programa muestra las
pantallas correspondientes.
 Durante este proceso, el sistema verifica solo los campos que se mostraran en la
subscreen.

49
PROGRAMACIÓN

 Si quieres que el programa procese el desplazamiento en un tabstrip control, debes

cumplir los siguientes requerimientos:
o Todos los tab pages deben compartir un área común.
o Todos los tab titles deben tener la función code type ‘’(espacio).
o En el flow logia, debes usar la variable para llamar la pantalla que será
mostrada en el subscreen area.
 El bloque PBO debe contener un módulo antes que la subscreen sea llamada, en el
cual puedes poner el nombre de la subscreen en la variable correspondiente. Debes
asignar un valor inicial al campo que la screen es procesada por primera vez. (antes
de que el usuario haya tenido la oportunidad de cambiar el tab title).
 Puedes ocultar un tab page en tiempo de ejecución configurando el correspondiente
tab title a inactivo usando la tabla de sistema SCREEN (SCREEN-ACTIVE = 0).
Debes hacer esto antes de procesar el control tabstrip por primera vez para asegurar
que el entorno de la pantalla se mantiene constante.

50
Creando tabstrip controls usando el wizard

 Puedes usar el Tabstrip Control Wizard como ayuda para crear los tabstrip control e
insertarlos en screens en un programa. El Asistente te ayuda a través de todo el
proceso. Puedes regresar a configuraciones anteriores en cualquier momento. Los
programas objetos son creados hasta el final de pantalla solo cuando se completa el
proceso. El asistente crea no solo el tabstrip sino también los componentes
correspondientes en el flow logia, junto con los modules relevantes, subrutinas, y
necesarias definiciones de datos.
 En Adición al tabstrip control en la screen y al correspondiente flow logic, los
siguientes objetos son creados si estos no existieran:
o El programa principal y la pantalla para el tabstrip juntos con el flow logia
o Subscreens vacías para cada control page del tabstrip.
o Includes para definición de datos, PBO módulos, PAI módulos, y sentencias
INCLUDE para los includes.
 Todos los objetos son puestos en la lista de objetos inactivos.

51
Unidad 7: Table controls
Table control
El table control es un área en la pantalla en la que el sistema muestra datos en forma
tabular. Este es procesado usando un bucle. La primera línea del table control es la línea
de cabecera, que se distingue por un separador gris.

En un table control, se pueden utilizar elementos de tabla, palabras clave, plantillas,

check boxes, radio buttons, radio button groups, y botones. Una línea podría tener hasta
255 columnas; cada columna tiene un titulo.

Características

Se pueden visualizar o insertar líneas individuales de datos estructuradas usando table

control.
Características:
-Tabla cuya dimensión se puede cambiar para visualizar y editar datos.
-El usuario o el programa puede cambiar la anchura y posición de la columna.
-Se pueden seleccionar las filas.
-Chequeo de columnas para lineas marcadas.
-Las cabeceras de columnas también sirven como botones para marcar columnas.
-Scrollbars
-Se puede configurar cualquier número de key columns.
-Los atributos de las celdas son variables en tiempo de ejecución.

52
Table settings

Los usuarios pueden guardar las variantes de visualización para table controls.

Acciones en table controls

Contienen acciones que se controlan en el servidor de presentación:
-Scrolloing horizontal
-Intercambio (swapping) de columnas.
-Cambio de anchura de columnas.
-Selección de columnas.
-Selección de líneas.
El bloque de procesamiento PAI se lanza cuando se hacel scroll vertical y cuando se
guarda la configuración del usuario.

Creación de un table control

Atributos

Además del nombre, posición inicial en la pantalla y tamaño estático, también poseen
atributos especiales.
Los campos STEPL Y LOOPC de la estructura syst contienen información de
procesamiento loop utilizado con los table controls.
Se utiliza el tipo Entry table para introducir datos. Selection table si solo es para
seleccionar y transferir entradas o si la tabla existe solo en modo de visualización.

53
Creación
Cuando se crea un table control, hay que crear:
-Un table control area.
-Table control fields (campos del table control)

Creando un table control area

Para crear un table control area, se escoge el objeto table control en la lista del Screen
painter.
En el atributo Name, se le asigna un nombre al table control. En el programa ABAP se
declara una estructura con el mismo nombre, que contiene los atributos que se pueden
cambiar dinámicamente del table control.
La sentencia CONTROLS declara un objeto de datos con el tipo TABLEVIEW. En
tiempo de ejecución el objeto (my_control , del ejemplo) contiene los atributos
estáticos de la table control.
La adición de USING SCREEN determina que valores iniciales de que pantalla son
usados para el table control.
Para refrescar un table control a sus valores inicialesREFRESH CONTROL <ctrl.>
FROM SCREEN <scr>.

Campos

54
Se crean los campos en un table control usando la función Dict/Program fields. Esto
envuelve los siguientes pasos:
-Introducir el nombre de la estructura cuyos campos se quieren utilizar.
-Elegir los campos a utilizar y dar a ok.
-Hacer clic en el table control area. El sistema coloca todos los campos en el table
control.

Columna de selección (Selection column)

Cuando se crea un table control, el sistema propone automáticamente uno con columna
de selección.
Este se comporta como un checkbox. Tiene que tener longitud 1 y tipo de datos CHAR.
Hay que introducir el nombre de campo en los atributos del table control.
El selection column es un campo usado para el transporte entre la pantalla y el programa
ABAP.

Atributos en tiempo de ejecución

Los atributos de un table control se guardan en tiempo de ejecución en una estructura
declarada como CONTROLS. Se pueden dividir en atributos generales y atributos de
columna.
Atributos generales: Contienen información acerca de las propiedades de la table
control (como number of fixed columns…)
Los atributos de columna son almacenados en una tabla interna. Cada columna consiste
en los atributos de la estructura SCREEN, posición de columna, indicador de selección,
indicador de visibilidad y anchura visible de la columna.

55
Estructura

Se puede modificar una table control dinámicamente modificando el contenido de los

campos en la estructura de la table control declara en el programa.
Los campos de la estructura de la table control también proveen información de la
interacción de usuario con la table control. Por ejemplo se puede usar el campo
seleccionado (selected) para determinar si un usuario ha seleccionado una columna
determinada.

Procesando un table control

Se leen los datos de la base de datos y se almacenan en una tabla interna. El sistema
llena el table control a través de esta tabla interna.

56
Aplicaciones

Antes de visualizar los datos desde un internal table en un table control, hay que llenar
primero la tabla. No se hace en cada evento PBO, solo cuando los campos clave
cambian. (La primera linea marcada en el ejemplo).
Se usa DESCRIBE TABLE para encontrar el número de entradas en la internal table y
guardar este número de líneas en el campo lines de la table control.
Solo hay un work area para procesar las lineas en un table control. Por esto se necesita
un LOOP…ENDLOOP, tanto en el PBO y el PAI para cada table control.
En el PAI, se necesita pasar los cambios realizados en el table control.

Llenado de table control

3 pasos:
-El sistema se mete en un bucle a través de las líneas del table control. Cada línea se
procesa una a una.
- Para cada línea, el sistema coloca la línea de la tabla interna en el work area de
la tabla interna.
-Para cada línea, el sistema copia el dato desde el work area de la interna table a
línea relevante de la table control.

57
Código

En el flujo de lógica, la sentencia LOOP AT comienza el bucle a través de la tabla de la

pantalla, y lee la línea de la tabla interna correspondiente a la línea actual, situandola en
el wa_itab.
Los campos de la table control tienen la misma estructura y nombre que estos en el
work area. El sistema puede tranportar datos entre el programa y la pantalla
automáticamente.
Si no se utiliza la misma estructura para los campos de la table control y la work area de
la tabla interna, hay que llamar a un bucle que mueva los datos desde el work area a los
campos de pantalla (MOVE-CORRESPONDING wa-itab TO).

Tranporte de campo en el PBO

Cuando se utiliza un table control en la pantalla, la secuencia de transporte de campos

automática cambia.
En el PBO los datos se transfieren desde el programa a la pantalla después de cada
pasada en el loop. El resto de campos de la pantalla se llenan como siempre al final del
PBO

58
Cambiando el contenido de un table control
Para transferir valores que han cambiado desde el table control a la internal table:
-El sistema se mete en un bucle a través de las líneas del table control.
-Para cada línea, el sistema copia el dato de la línea actual del table control a los campos
con nombre identico en el work area de la tabla interna.
-Transporta el contenido del work area a la línea correspondiente de la tabla interna.

Código

El bloque loop procesa un bucle a través da las líneas de la tabla en la pantalla.

Si los campos en la pantalla tienen el mismo nombre que los campos de la tabla interna,
hay que retornar los datos desde el work area de la internal table al cuerpo de la tabla.
Se hace esto usando el campo <control>-current_line.
Si no tienen el mismo nombre, se tiene que copiar los datos en la work area de la tabla
interna. También se puede usar <control>-current_line para hacer esto.

Tranporte de campos en el PAI

59
En el PAI, todos los campos de la pantalla que no estan asociados a un table control y
que no se listan en la sentencia FIELD se tranportan de vuelta al work fields en el
programa ABAP.
El contenido de la table control se transporta línea a línea al correspondiente work area
en el programa ABAP en un loop apropiado.
Los campos que estan en la sentencia FIELD se transportan directamente antes de esa
sentencia.

Creación de table controls con el wizard

Se puede utilizar el table control wizard para ayudar a crear un table control e insertar
este en la pantalla de un programa. Los objetos de programa son creados en la pantalla
final, cuando se completa el proceso. El wizard también crea las sentencias en el flujo
lógico, junto con los modulos y subrutinas y las definiciones de datos necesarias.

Técnicas adicionales
Cambiando table control

Se pueden modificar los atributos de un table control sobrescribiendo el contenido del

campo de la estructura creada en la sentencia CONTROLS.
Para cambiar los atributos de las celdas individuales temporalmente, se cambia la tabla
SCREEN en el módulo PBO que se procesa entre un LOOP y ENDLOOP.
En tiempo de ejecución solo se pueden cambiar los atributos configurados estáticamente
mediante la llamada a un módulo llamado desde un LOOP a través del table control.

60
Cambiando atributos de un table control

Se puede cambiar un table control dinámicamente modificando el contenido de los

campos de su estructura.
Se puede usar el campo seleccionado para determinar cuando un usuario ha
seleccionado una columna particular.

Si se quiere cambiar atributos de las columnas en un table control, hay que cambiar las
entradas en la tabla <control>-cols. La tabla no tiene cabecera. Esto implica crear una
work area especifica.
Los campos de la estructura del table control proveen información de interacción de
usuario con la tabla de control. Se puede usar el campo selected para determinar si el
usuario ha seleccionado una columna concreta.

Field atributes (Atributos de los campos)

Durante el loop para procesa el table control en el PBO, el system program copia
algunos atributos de las columnas de la estructura del table control a la tabla de sistema
SCREEN. El programa copia las partes de la línea COLS que también se llaman
SCREEN-<fname>.

61
Cambiando atributos de campos temporalmente

Es posible cambiar lso atributos de los campos de un table control temporalmente. Estos
cambios son solo efectivos cuando se esta procesando la pantalla actual.
Para cambiar atributos temporalmente, se llama a un módulo desde el loop del table
control, en las que se cambian los atributos para dicha línea.
Se utiliza el LOOP AT SCREEN….ENDLOOP.

Ordenando table controls

Se pueden ordenar fácilmente por una columna concreta, usando los atributos del table
control, wa_cols-selected y wa_cols-screen-name.
Se pueden usar criterios de ordenación usando procesamientos de string. Asegurarse de
que wa_cols-screen-name contiene el nombre del campo en pantalla y no la columna de
la internal table.

62
Posición del cursor

El parámetro LINE en la sentencia GET o SET se refiere a sy-stepl.

Se calcula la línea de la internal table que corresponde a la línea seleccionada del table
control de la siguiente manera: line=<ctrl.>-top_line+cursor position -1.
La sentencia GET CURSOR devuelve el código de retorno: sy-subrc = 0: El cursor esta
en el campo, sy-subrc = 4: No esta en el campo.
Se puede situar el cursor en un campo particular del table control. Se usa el parámetro
line.
SET CURSOR FIELD nombre campo LINE linea.
Se pueden usar los parámetros OFFSET Y LINE a la vez.

63
Unidad 8: Context Menus
Context Menu
Los context menus son atajos para las funciones que se utilizan a menudo.
Cuando un usuario selecciona un objeto del context menú, un mecanismo de evento
llama a una subrutina concreta en la aplicación. Esto entrega una referencia de menú
(menu reference) a la subrutina. El programa utiliza esta referencia para crear el menú
que se visualiza. Se pueden utilizar menús definidos con el Menu Painter o menús
dinámicos.
Después de que el usuario ejecute una función del menú, el programa de aplicación
recupera el control y reacciona a la introducción del usuario.
Los context menus son asignados a output fields. Cuando se asigna un context menu a
un box, una table control o pantalla, todos los output fields subordinados que no tienen
context menú asignado, lo heredan.

Creación de context menú

Se puede crear un context menú desde el object navigator. Hay que posicionarse en el
GUI status. Inmediatamente el Object navigator abre el Menu painter.
También se puede crear directamente en el menú painter.
El context menú es un GUI status especial. Se le asigna un nombre, texto breve y se
elige como tipo context menú.

64
Se les puede enlazar con cualquier function code y function text. Se pueden usar las
funciones que se proveen en la interfaz.
La técnica de enlazar, asegura context menus consistentes en aplicaciones grandes.
Reglas para diseñar context menus:
-No utilizar funciones que no se pueden encontrar en otro lugar en el sistema.
-Evitar utilizar mas de dos niveles en la jerarquía.
-No usar más de 10 entradas.
-Usar separadores para estructurar.
-Ubicar sentencias de objetos específicos en el comienzo del menú.

Enlazar Objetos de pantalla

Hay que crear una función de llamada. Se llama ON_CTMENU_<name>.

Se le puede asignar una rutina callback a los input/output fields, text fields y los status
icons. Los checkbox, radio buttons y pushbuttons no tienen su propia rutina callback,
pero pueden herendar el context menú de los box o de las pantallas.
Si se asigna una callback a un table control, se lanza para todos los campos del table
control que no tienen su propia callback.

65
La rutina se hace de la siguiente manera:
FORM ON_CTMENU_<nombre> USING p_menu TYPE REF TO cl_ctmenu.
Definición
ENDFORM.

Se define la estructura cargando estaticamente un menu definido o pasando una

instancia de la clase cl_ctmenu.

Usar context menú

Se hace clic en el botón derecho del ratón y este lanza el callback correspondiente.
Se utiliza el método estático load_gui_status de la clase cl_ctmenu para cargarlo.

Modificar context menus dinámicamente

La clase cl_ctmenu provee varios métodos que se pueden utilizar para ajustar el context
menú en tiempo de ejecución. A estos métodos se les llama con callback.

66
Unidad 9: Listas en pantallas
Creando un list buffer

Se llena las listas en el buffer mendiante la sentencia WRITE en el PBO o el PAI. Se

pueden programar listas propias y cabeceras de columnas mediante el evento TOP-OF-
PAGE. Este evento se lanza cuando se crea una nueva página en la list buffer con
NEW-PAGE.
Se puede mandar la salida a la impresora con la sentencia NEW-PAGE PRINT ON.
La visualización de la lista se procesa al final de la pantalla, en la cual se ha programado
LEAVE TO LIST-PROCESING en el PBO o PAI.

Visualización en pantalla

67
Para crear la visualización de una lista en pantalla, hay que usar LEAVE TO LIST-
PROCESING. SET PF-STATUS SPACE asegura la lista se visualiza con el GUI status
estándar para las listas.
Una vez que la lista se ha procesado y se ha ejecutado el LEAVE, la lista se visualiza en
la pantalla 120.
Después del LEAVE se trata de procesar el PBO de la pantalla que le ha llamado, pero
si ponemos AND RETURN TO SCREEN <scr> podemos hacer que se proceso el de
otra pantalla.
Si se incluye SUPRESS DIALOG en un modulo PBO, la pantalla actual no se visualiza.

Listas en cajas de diálogos modales

Si se quiere visualizar una lista en un dialog box con una transacción, hay que llamar a
la pantalla, pero hay que incluir la sentencia SUPRESS DIALOG en su PBO.
Para volver a la pantalla que le ha llamado cuando se deje la lista, al LEAVE se le
añade AND RETURN TO SCREEN 0.

68
Appendix
Transaction variants
son una referencia a un conjunto de screen variants. Se pueden crear n screen variants,
la transaction variant se basa en esas screen variant.

Opciones

A la hora de crearlos distinguimos dos tipos:

• Standard variant
• Cualquier número de transaction variants.

La Standard variant se ejecuta con el código de la transacción no hace falta ningún

código adicional.

Creación
Para crear una transaction variant, se elige ToolsAccelerateSAP Pesonalization 
Transaction variant.

Cuando creamos la variante seleccionamos la transacción de la cual queremos crear la

variante dándole un nombre único a esta última.

Con el GOTO del menú se elige si se quiere crear una client-specific o cross-client
transaction variant.

Se elige el botón de crear.

Screen variants
Es un objeto independiente del repositorio con un único nombre. Su nombre se
construye de esta manera:
• Nombre de la variante
• Mandante
• Screen number
Se puede especificar que campos se pueden copiar o no en la screen variant.

69
GuiXT
Es una herramienta que permite diseñar las screens de una manera flexible. Se pueden
seleccionar ficheros GuiXT de la máquina local. También se pueden importar scripts
creados en la máquina local y exportarlos.

Script lenguage
Se puede cambiar el layout de una pantalla con el scrip lenguaje usado por GuiXT.
podemos:
• Mover objetos
• Insertar screens
• Insertar pushbuttons
• Insertar value helps
• Eliminar elementos de la screen

Arrancando transaction variants

Opciones para arrancar transaction variants:
• Test enviroment
• Transaction code
• Desde el user menú

Las transaction variant se pueden introducir en el menú mediante el mantenimiento del

menú o de los roles que hacen que se muestre uno u otro contenido en el menú.

Creación de variant transaction

Para empezar una transaction variant desde un menú, se tiene que crear un transaction
code de tipo variant transaction.
Se puede insertar un transaction variant en un menú manteniendo:
-Un role
-Un area menú.

70
Orientación a objetos
La orientación a objetos consiste en tener los datos y la funcionalidad residente en una
misma clase. De esta clase se crean las instancias llamadas objetos que contienen tanto
los atributos y las funciones definidas en su clase.
Un objeto consiste de dos capas:
Parte publica: todo el contenido que esta en esta parte es accesible desde fuera.
Parte privada: solo las funciones propias del objeto pueden acceder y/o
modificar los atributos privados del objeto.

En una clase hay dos partes, la parte donde se definen los métodos y los atributos. Y la
parte donde se implementan. A la hora de crear un objeto se debe crear una variable de
referencia a el objeto type ref to class. Y después con el comando create object se crea
el objeto en si.
Llamada a un metodo de una clase: con call method ref -> function o ref -> function.

Implementación de controles
Controlo framework

Principios de control processing.

• Generar el control e integrarlo con la screen.
• Uso de métodos para el paso de información entre el servidor de aplicación y de
presentación.
• Control de eventos.

El container control provee espacio para mostrar otros controles en la pantalla. Los hay
de diferentes tipos.

Creando un custom container:

La creación de un custom container se hace mediante el editor de layout. A la hora de
crear la instancia se debe definir una variable que haga referencia a la clase
cl_gui_custom_container. Para después instanciar el objeto apropiado en el pbo. Hay
que asegurarse de que solo se crea una instancia por pantalla.

71
Comunicación con controles
Llamadas a métodos
Si se llama a un metodo de control de un enjoySAP en el programa ABAP, este ultimo
pasa el control al control framework. El metodo llama al correspondiente objeto Gui.

Eventos
Un objeto puede cambiar su estado lanzando un evento que podran gestionar otros
objetos. El programa que lanza el evento no sabe quien lo gestionara.
Si desde un objeto gui se lanza un evento al front end, el CFW se encarga de que llegue
al objeto que lo gestiona.

Fuentes de información
Search help

Requerimientos del F4:

• A la hora de mostrar los datos se ha de tener en cuenta el contexto.
• El input help debe mostrar un dialogo donde se muestre la información de las
posibles opciones.
• Los input helps tienen que determinar los valores que se pueden ofrecer al
usuario. Cuando se determinan los posibles valores, las restricciones
resultantes del contexto hay que tenerlas en cuenta.
• Cuando se selecciona un valor hay que retornarlo al campo de búsqueda.
En ocasiones un input template (plantilla de selección) tiene más información
sobre el campo de búsqueda. El contenido de estos campos deben ser
actualizados.

72
El internal behaviour del search help describe el proceso del F4. este contiene el
selection method, que es el que sustrae los datos para mostrarlos y el dialog behaviour,
que describe la iteración con el usuario.

Un search help describe el proceso de un input help. Para que pueda funcionar, se
necesita un mecanismo que asigne el search help al campo ( field ). A esto se le llama
search help connection.

Los parámetros de un search help pueden ser de entrada import o de salida export.

Asignación de search help

Existen tres mecanismos para enlazar un search help a un campo del diccionario
ABAP:
1-Un search help se puede enlazar directamente a un campo de una estructura o
tabla.
2-Si un campo tiene asociado un check table, el contenido de esta es automáticamente
mostrado como posibles valores.
3-Es posible asociar un search help a un data element. Así estará disponible el search
help para aquellos campos que sean del tipo data element.

Si existe más de un mecanismo se selecciona el search help en base a que este más
arriba en la jerarquía. El orden sería: para un campo directamente, check table,
para un data element.

También se pueden definir directamente en la pantalla, pero el problema o

desventaja es que no se reutiliza.

Mecanismos de input help

Sap R/3 contiene un amplio rango de mecanismos con los cuales se pueden definir
input helps. Es posible utilizar mas de uno de estos en un campo en particular.
Ademas del input help se puede definir un screen help, una ventaja de esto es que no se
puede reutilizar automáticamente.
Se puede añoadir un search help a un screen help en el screen painter.
Nunca se debe de utilizar input checks programados en el flor logia.

73
Unidad 11: Actualizando bases de datos
con Open SQL
En ABAP se puede utilizar tanto Open SQL como SQL nativo para realizar
actualizaciones de base de datos.
El acceso a la bd con SQL nativo permite usar comandos especificos de la base de
datos.
Los comandos de Open SQL no son específicos de la bd. Se convierten en sentencias
SQL a través del database interface y se pasa a la base de datos. No hay que ajustar los
programas que utilizan Open SQL.
Otra ventaja es que se pueden utilizar buffers en tablas locales para que se haga una
lectura más rapida. Los datos se leen del buffer después de realizar las configuraciones
de tabla pertinentes.
Solo incluyen sentencias de tipo DML (Manipulation). No hay comandos de DDL
(Definition) porque se incluyen en el diccionario.
Solo hay que utilizar SQL nativo si alguna función particular que no esta en Open SQL
se necesita.

Target quantity and return values

Se pueden procesar una o mas filas utilizando comandos SQL. Comandos que procesan
más de una fila dan un mejor rendimiento que si se procesa de una en una (excepción:
MODIFY).
Si se enmascaran (mask) selecciones de fila (where <field> like ‘<mascara de
búsqueda>’, ‘_’ enmascara un solo carácter y % un string de cualquier longitud.
Todas las sentencias devuelven si se ha ejecutado con éxito. SY-SUBRC. Si vale 0
entonces ha ido bien. Cualquier otro valor significa que ha habido error.
SY-DBCNT el número de registros sobre los que se ha llevado a cabo la operación de
base de datos.
Los comandos de Open SQL no realizan ningún chequeo de autorización automático.
Hay que ejecutarlos explícitamente.

Accediendo a tablas específicas de cliente

Si no se utiliza la adición de CLIENT SPECIFIC, no se permite la especificación de
cliente en la WHERE y los registros sobre los que se actua son del cliente actual.
Si se quieren procesar datos de otro mandante, hay que especificar la adición de
CLIENT SPECIFIC, y el mandante deseado en la WHERE.
Si no se pone el cliente con la adición de CLIENT SPECIFIC, se accede a todos los
mandantes (clientes).

74
Creación de un solo registro

Para inserta un nuevo registro en la bd, se utiliza el comando INSERT INTO <dbtab>
VALUES <wa>. Para esto primero se rellena el wa. Esta estructura tiene que ser del
mismo tipo que las lineas de la tabla.
El campo cliente (mandante) del wa solo se tiene en cuenta cuando se utiliza la
especificación de CLIENT SPECIFIC. Sino se inserta en el cliente actual.
Las filas también se pueden insertar utilizando vistas. Pero la vista se tiene que crear en
el diccionario con el maintenance status “read and change” y solo pueden contener
campos de tabla.
Códigos que retorna:
-0OK.
-4No se ha insertado porque ya existe una fila con la misma clave.
Sintaxis alternativa: INSERT <dbtab> [CLIENT SPECIFIC] FROM wa.

Creación de varios registros

75
Se puede utilizar el comando INSER <dbtab> FROM TABLA <itab>. La tabla interna
que se especifica tiene que tener el mismo tipo de línea que la tabla de la base de datos.
El campo cliente solo se tiene en consideración con CLIENT SPECIFIC.
Si es posible crear las líneas SY-SUBRC = 0. Sino toda la operación de inserción se
descarta. Si hay error SY-SUBRC = 4. SY-DBCNT contiene el número de filas
insertadas satisfactoriamente.
Con ACCEPTING DUPLICATE KEYS para que pueden haber duplicados.

Cambiar un único registro

Para cambiar registros, el comando UPDATE.

Variante 1: El registro que contiene la clave de wa, se actualiza por wa. El campo
mandante se tiene solamente en cuenta si se especifica CLIENT SPECIFIC. El wa tiene
que tener la misma estructura que el registro a cambiar.
Variante 2: El registro especificado en la WHERE es el que se cambia. Solo los campos
que se especifican son los que se cambian con SET. En la WHERE hay que especificar
todos los campos clave para esta versión.
En la SET se permiten operaciones simples para campos numéricos: f=g, f=f+g, f=f-g.
Las filas se pueden cambiar utilizando vistas. Pero tienen que estar creadas en el
diccionario y que seand “read and change”.
Las dos variantes retornan estos códigos:
-0ok
-4No se ha podido cambiar la fila porque ya existía fila con esa clave.

76
Cambiar varios registros (con condición)

Si hay que realizar los mismos cambios a diferentes filas.

Se utiliza la cláusula WHERE. Para especificar mandante se utiliza CLIENT
SPECIFIC.
En la SET se especifican los campos a cambiar y son posibles ciertos cálculos para
campas numéricos.
Retorna los siguientes códigos:
-0 ok
-4 No se cambia ninguna línea.
SY-DBCNT es el número de filas que han sido cambiadas.

Cambiando registros con tablas internas

Se pueden realizar cambios de varios registros especificando una tabla interna que tenga
la misma estructura que la tabla y los registros que se tienen que cambiar.
El mandante para tenerlo en cuenta hay que especificarlo.
Puede retornar:
-0 ok
-4 como mínimo una fila no se ha podido cambiar, el resto si.
SY-DBCNT es el número de filas que han sido cambiadas.

77
Modificando un/ varios registros

Este comando es específico de SAP.

-Si el registro existe actua como una UPDATE
-Si no existe, actua como una INSERT
Se pueden procesar uno o varios registros. También se pueden utilizar vistas, pero han
de ser “read and change”.
Posibles valores que retorna:
-0 se ha procesado (insert/update)
-4 El registro procesado o al menos uno de la tabla interna ha fallado. El resto de
registros se procesan correctamente.
SY-DBCNT el número de registros procesados.

Borrando un único registro

Mediante el comando DELETE se permite eliminar un registro de la base de datos. En

la where hay que especificar la clave primaria. Se puede especificar el cliente y se
pueden utilizar vistas, pero tiene que ser de “read and change”.
Si devuelven:
-0 la línea se ha borrado,
-4 no se ha borrado porque no existe en la bd.
Sentencia alternativa: DELETE <dbtab> [CLIENT SPECIFIC] FROM <wa>. El wa
tiene que tener la misma estructura que el registro de la tabla y se tiene que llenar con
los campos clave del registro que se debe eliminar antes de llamar a la delete. El campo
mandante de wa solo se tiene en cuenta si se utiliza CLIENT SPECIFIC.

78
Borrando varios registros con condiciones

Se puede utilizar el where para eliminar varios registros. Hay posibilidad de especificar
el mandante.
Para eliminar todos los registros: DELETE FORM <dbtab> WHERE campo LIKE ‘%’
Códigos que retorna:
-0 se ha eliminado como mínimo un registro.
-4 no se ha eliminado porque el registro especificado no existe.
SY-DBCNT especifica el número de registros eliminados.

Borrando varios registros con tabla interna

Si se quieren eliminar varios registros se puede hacer con una tabla interna en el
comando DELETE. Solo se tiene en cuenta el mandante si se añade CLIENT
SPECIFIED.
Códigos que retorna:
-0 todas las líneas se han borrado.
-4 Como mínimo una línea no se ha borrado; las otras si
SY-DBCNT especifica el número de registros eliminados.

79
Restaurando el estado previo de la base de datos

Si se devuelve un código diferente de 0 se puede restaurar el estado antes de intentar

realizar el cambio. Se realiza esto con un rollback de base de datos.
Dos maneras de hacer rollback:
-Mandando un mensaje de diálogo de terminación (MESSAGE A)
-Usando ROLLBACK WORK
El resto de tipos de mensaje no causan un rollback de la base de datos.
La sentencia rollback work, no termina el programa. En este caso, hay que tener
cuidado porque el contexto no se ha peseteado en el programa actual.

80
Unidad 12: LUWs y arquitectura
cliente/servidor
Unidad lógica de trabajo SAP (SAP LUW)
Una SAP LUW conssite en cambios en SAP R/3 que lógicamente permanecen juntos.
Estos cambios se llevan a cabo completamente o no se llevan a cabo. El principio del
todo o nada.
En general una transacción de negocio no se lleva a cabo por una única LUW.

Database LUW

Una database LUW consiste en cambios que se ejecutan cuando el estado de la base de
datos se cierra (Commit de base de datos).
Con un database LUW, siempre es posible volver al estado anterior de la misma,
mediante un rollback. Se utiliza la rollback para restaurar el estado de la bd si ha habido
algún error.
Una vez que se da el commit, no es posible descartar el database LUW actual, ya no es
posible volver al estado anterior a este.
En ABAP, mediante los comandos COMMIT WORK y ROLLBACK WORK se
implementa explícitamente los rollback y commit de bd. También hay situaciones en las
que se dan commits implícitamente.
Si se da un error durante el procesamiento de una SAP LUW, debería ser posible volver
a un estado consistente de bd.
Siempre que se de un cambio de pantalla, se lanza un commit de bd implicito. Sin
embargo, debería ser posible mediante una transacción meter bruscamente (bundle) las
entradas de un usuario que forman una SAP LUW mediante una DB LUW y escribir
estos en la base de datos.

81
Arquitectura cliente/servidor de un sistema R/3

Un sistema SAPBasado en arquitectura cliente/servidor de tres capas.(bd, aplicación

y presentación).
La arquitectura de tres capas, implica que un número elevado de usuarios con PC´s de
bajo coste se pueden mapear en un número pequeño de procesos de trabajo, de alto
rendimiento, en el servidor de aplicación. Cada proceso de trabajo en el servidor de
aplicación es asignado a un proceso de trabajo en un servidor de base de de alto
rendimiento.
Distribuir las peticiones de usuario a work process significa que clientes individuales en
el servidor de presentación son asignados a work process por un periodo particular. Un
work process, usa otro work process en la base de datos. Una vez que el work process
ha procesado la entrada del usuario en un dialog step, se elimina el usuario del work
process.
La arquitectura de tres capas es más escalable, donde la presentación y la aplicación
corren en un servidor. Además el número de usuarios de la bd es menor que el número
de usuarios activos del sistema. Esto es positivo en el comportamiento de la bd.

DB commits implicitos
Antes de que cada pantalla se visualice, el work process actual se libera en el servidor
de aplicación. Esto libera el work process de la bd y se lanza un db commit implicito.
Casos que se dan commits implicitos:
-Cuando el sistema visualiza una pantalla.
-Cuando el sistema manda un dialog message.
-Cuando hay tanto RFC asíncronas como síncronas.
-Con CALL TRANSACTION y SUBMIT.

82
Unidad 13: Concepto de bloqueos
(Locks)
¿Por qué utilizar bloqueos?

Si varios usuarios están intentando acceder a los mismos recuersos, hay que encontrar
una manera de sincronizar esos accesos para proteger la consistencia de los datos.
Mediante esto, los usuarios piden un bloqueo antes de acceder a datos críticos. Es
importante liberar el bloqueo tan pronto como sea posible para no entorpecer al resto de
usuarios.

Bloqueos de base de datos no son suficientes

El DBMS bloquea físicamente las líneas de la tabla que se leen con intención de ser
cambiadas. El resto de usuarios que intentan acceder a estas líneas deben esperar a que
se libere el bloqueo.
Al final de un database LUW, con cada DB commit, el sistema de bd libera todos los
bloqueos realizados durante la DB LUW.
En SAP un database lock se libera cuando se visualiza una nueva pantalla. Sin embargo,
los database locks no son suficiente si los datos se coleccionan mediante varias pantallas
y los respectivos registros de datos deben de ser bloqueados durante este tiempo.

83
Bloqueos lógicos

Para mantener bloqueos durante una serie de pantallas, el sistema SAP R3 tiene una
tabla global de bloqueos (global lock table) en el servidor de aplicación, el que se puede
utilizar para realizar bloqueos lógicos para entradas de tablas.
El bloqueo de tabla y el enqueue work process respectivo, manejan el bloque de tabla
(lock table) en un servidor de aplicación único definido del sistema SAP.
También se pueden utilizar los bloqueos lógicos para bloquear registros que todavía no
existen. Esto es apropiado, por ejemplo, cuando se meten nuevas líneas y no es posible
hacerlo con la ayuda de los database locks.

Objetos de bloqueo SAP

Se realiza un bloqueo lógico en la lock table llamando a un módulo de bloqueo (lock

module). Estos function modules se crean cundo automáticamente cuando se activa un
objeto de bloqueo relacionado a una tabla. Cuando se llama al lock module, los
bloqueos lógicos se hacen para las entradas en dicha tabla.
Se mantienen los lock objects en el diccionario. Deben empezar por EY o EZ los de los
clientes. Cuando se crea solo es necesario especificar la tabla para la que se hace. Sin
embargo, se pueden especificar otras tablas secundarias que tienen una relación de

84
foreign key con la tabla primaria. De esta manera se pueden bloquear los registros en
ambas tablas.
El lock module creado contiene como parámetros de entrada los lock parameters que
son contenidos en el objeto de bloqueo. Estos lock parameters son usados para
comunicar al lock module que registros tienen que tener un bloqueo lógico en la tabla
de bloqueo. El sistema propone para estos parámetros los nombres de los campos que
pertenecen a la clave primaria.
Cuando se define un objeto se puede definir el modo (E, X o S).

Generando lock modules

Cuando un objeto de bloqueo se activa correctamente, el sistema genera

automáticamente dos function modules (uno para bloquear y otro para liberar) las
entradas especificadas en el objeto.
Tiene la siguiente convencion de nombres:
-ENQUEUE_objeto
-DEQUEUE_objeto

Realizando bloqueos lógicos y liberándolos

Un bloqueo lógico se realiza cuando se llama a un lock module. Esto escribe un bloqueo
en la lock table.
Solo se puede crear un bloqueo si no existe un bloqueo en la tabla de bloqueos para ese
registro.
Si hay error se lanza una excepción. Por eso dependiendo del return code, el sistema
puede reaccionar de diferente manera.
Si un programa termina, los bloqueos lógicos se eliminan automáticamente. Esto se da
si, se tienen mensajes de tipo A / X, con sentencias LEAVE PROGRAM y LEAVE
TRANSACTION o si el usuario introduce /n en el command field.

85
Llamando a lock modules

Usando los parámetros import de la función ENQUEUE que corresponde a los campos
clave en la respectiva tabla, se determinan los registros que se van a bloquear. Estos
parámetros import se llaman lock parameters.
Si no se puede realizar el bloqueo correctamente (sy-subrc <> 0) hay que lanzar un
mensaje .
Al final del dialog program, se puede utilizar el DEQUEUE para eliminar los bloqueos.
No lanzan excepciones los DEQUEUE, si no existe el bloqueo no tiene efecto.
Si se quiere eliminar todos los bloqueos, se utiliza la función DEQUEUE_ALL.
Se aplican la siguientes reglas cuando se llama a un function module con respecto al
parámetro mandante:
-Si el parámetro no se especifica, solo el mandante actual.
-Si se especifica, solo se bloquean los registros de ese mandante.
-Si se especifica con SPACE, el bloqueo se aplica a todos los mandantes.
Para visualiza la tabla de bloqueos se utiliza la transacción SM12.

Parámetros en un módulo ENQUEUE

86
Usando el lock container

Si se utiliza el lock container, se pone en _collect = ‘X’. Esto tiene el efecto de que las
peticiones de bloqueo se almacenan en un contenedor local.
Se puede mandar el contenido del contenedor al lock management (gestor de bloqueos)
con el function module FLUSH_ENQUEUE.
Si uno de los bloqueos del contenedor no se puede crear, el function moduel lanza una
excepción de FOREIGN_LOCK. En este caso ninguno de los bloqueos del contenedor
se llevan a cabo y el contenido del contenedor permanecerá para intentos posteriores.
Se puede eliminar el contenido utilizando el function module RESET_ENQUEUE.

Modo de bloqueo

Efecto de los modos de bloqueo (otros usuarios)

87
Si se tienen bloqueos, y otros intentan realizar bloqueos sobre los mismos registros, se
actua de la siguiente manera:
-Si existen bloqueos de E o X se rechazan bloqueos de cualquier tipo.
-Si es de tipo S, se permite bloqueo de tipo S. El resto se rechazan.

Efecto de los modos de bloqueo (Mismo programa)

Si se intenta bloquear un dato más de una vez durante la ejecución del programa:
-Si el bloqueo es de tipo E, se aceptan E y S para el mismo dato.
-Tipo X, se rechazan todos los bloqueos.
-Tipo S, se permiten E y S para ese registro.

Realizando bloqueos y liberándolos

Pasos que se tienen que dar:

-Poner bloqueo para los datos a procesar.
-Si el bloqueo se pone bien, se lee de bd.
-Cambiar los datos de programa y actualizar los cambios en bd.
-Liberar bloqueo.

88
De este modo te aseguras que los cambios se realicen bajo los bloqueos y que los datos
que se leen, han sido cambiados consistentemente.

Peligro de utilizar los bloqueos incorrectamente

Si no se utiliza la secuencia existe el peligro de que el programa lea datos de la base de
datos que estan bloqueados por otro programa y se este procesando. Esto implica que el
dato que se este leyendo no este actualizado.

89
Unidad 14: Organizando actualizaciones
de base de datos
Cambios desde el programa directamente
Escala de tiempo
Si la transacción ejecuta actualizaciones de base de datos, se deben realizar las
actualizaciones en único paso de dialogo. Esta es la única forma de asegurarse que se
cumple el principio de todo o nada.

Flujo de datos
Si se ejecutan actualizaciones del programa de dialogo, hay que salvar los datos que se
quieren cambiar en el global program data hasta que se realicen los cambios en la base
de datos.

Bloqueos

Si se actualiza la bd directamente desde el programa, el programa tiene que poner y

liberar los bloqueos.

90
Cambios desde el programa con subrutinas retrasadas
Escala de tiempo

Las actualizaciones de bd se pueden ejecutar juntas usando una técnica de subrutinas

especiles: PERFORM subrutina ON COMMIT.
Esta sentencia registra la subrutina que se ha especificado. Esta no se ejecuta hasta que
el sistema realice el siguiente commit work.
Si las actualizaciones se encapsulan en subrutinas, se pueden separar de la lógica del
programa y reubicar al final del proceso de LUW.
Cada una de las subrutinas registradas solo se ejecuta una vez por LUW. Las llamadas
se pueden hacer más de una vez, pero la subrutina solo se ejecuta una vez.
Las PERFORM ON COMMIT anidadas lanzan un error de ejecución a partir de la
versión 4.6.
La sentencia COMMIT WORK hace que se ejecuten las subrutinas registradas una tras
otra y lanza un commit de base de datos.
Si hay un error, se puede lanzar un mensaje de tipo A, pero primeramente hay que
restaurar el estado de la base de datos, mediante un mensaje de tipo A.
Las subrutinas de PERFORM ON COMMIT no tienen que tener interfaz. Trabajan con
datos globales, es decir, los valores de los objetos de datos en el punto en el que se
ejecuta la subrutina.

Actualizaciones utilizando técnicas específicas

Principio update
Las técnicas de update permiten separar los diálogos de usuario de los cambios de base
de datos. Ambos se ejecutan por diferentes programas, que se ejecutan en diferentes
procesos de trabajo.
El usuario utiliza el dialog program para ejecutar dialogos. Cuando los datos
introducidos se pasan, se lanza un update program que actualiza el correpondiente dato
en la base de datos.
En programas update no corren dialogos.

91
Proceso

Paso 1: El programa de dialogo recibe el dato actualizado por el usuario y lo escribe en

un log table especial. Los datos contenidos en el se escriben en bd posteriormente.
Un programa de dialogo puede escribir varias entradas en la log table. Estas entradas
representan un LUW, es decir, se ejecutan en la bd todas o ninguna.

Paso 2: El programa de dialogo cierra el paquete lógico de datos que se ha escrito en la

log table. Informa al sistema que hay un paquete para actualizar.

92
Paso 3: Un programa base lee los datos asociados al LUW desde el log table y se lo
provee al update program.

Paso 4: El update program acepta la transferencia de datos a este y actualiza las entradas
de la base de datos

93
Paso 5: Si el update program se ejecuta bien, el programa base elimina todas las
entradas para la LUW del log table. Si se da un error, las entradas en la log table
continuan pero marcadas como erroneas. Si se da error, se puede notificar vía email.
La transacción SM13 para monitorizar las peticiones de actualización.

Implementación técnica
Módulos update
La implementación técnica del concepto de update, requiere, en adición al programa que
monitoriza el dialogo de usuario, un programa update que tiene que ser implementado
como un function module especial (update module).
Estos módulos tienen una interfaz para transferir información. Solo incluyen parámetros
importing y tables. Los parámetros export y las excepciones se ignoran. Los módulos de
función contienen las sentencias de actualización de la base de datos.

Escribiendo/cerrando peticiones

94
Se pueden crear peticiones de update desde el dialogo del programa llamando a las
funciones de actualización pertinentes. Se utiliza la adició IN UPDATE TASK. Con
esto la función no se ejecuta inmediatamente, pero se escribe en el log table.
Todas las peticiones de actualización se almacenan en una SAP LUW bajo la misma
clave de actualización.
Solo cuando se ejecuta una COMMIT WORK se cierra la unidad. Se informa al sistema
que hay un paquete para ser procesado.

Descartando peticiones
A veces es necesario descartar todas las peticiones de cambio. Este es el caso cuando se
termina una transacción.
Para descartar los cambios se utiliza ROLLBACK WORK o un mensaje de tipo A.
El ROLLBACK WORK no afecta al contexto del programa, se mantienen los objetos
de datos sin cambiar y no se resetean.

Proceso

La tarea de un módulo de update es pasar las peticiones para las actualizaciones de base
de datos a la bd y para evaluar sus códigos de retorno.
Si se quiere lanzar un db rollback en el módulo de actualización, se emite un mensaje de
tipo A. Esto también termina el proceso del SAP LUW actual. La entrada de log
correspondiente al SAP LUW se marca con un flag conteniendo un error. El mensaje de
terminación también mete en el log.
Se puede utilizar la transacción SM13 para examinar el log.
El sistema envía un mail al usuario, diciendole que el LUW de actualización ha
terminado. Para esto como se ha mencionado con anterioridad, hay que configurar los
parámetros del perfil rdisp/vbmail y rdisp/vb_mail_user_list.
En un módulo de actualización no se pueden utilizar las sentencias COMMIT WORK o
ROLLBACK WORK.

95
Poniendo bloqueos en el update

Si se tienen bloqueos configurados en el programa de dialogo que trabaja con la técnica

de update y estos bloqueos se han configurado usando _socope = 2, se pueden pasar en
la tarea (task) de actualización en el COMMIT WORK. Después de esto, no son ya
accesibles desde el programa de dialogo.
No hace falta liberar los bloqueos explícitamente en los módulos de actualización
porque el programa base al final del proceso de actualización libera los bloqueos
automáticamente.
Esta liberación automática se lleva a cabo si hay un error, es decir, si uno de los
módulos de actualización termina y hace rollback del LUW a través de un mensaje de
dialogo de terminación.
Si los modulos de actualización permiten que las peticiones de actualización fallidas se
reprocesen, las tablas de bd deberían ser diferentes en el momento de reprocesar la
actualización. El reprocesamiento se lleva a cabo sin bloqueos, porque estos han sido
eliminados automáticamente por la tarea de actualización si ha habido error.
Por ejemplo el reprocesamiento es adecuado cuando una actualización no se ha llevado
a cabo satisfactoriamente por un overflow (desbordamiento) del espacio de la tabla.

Modos de actualización
Actualización asíncrona
En actualizaciones asíncronas, el programa de diálogo y el programa de actualización se
ejecutan separadamente.
-El programa de diálogo escribe las peticiones de cambio en el log table y cierra la
LUW con un COMMIT WORK.
-La actualización iniciada por el COMMIT WORK procesa la petición de cambio. El
programa de dialogo continua. El sistema no espera a que termine la actualización.
-El programa de actualización se ejecuta en un proceso de trabajo especial.
Las actualizaciones asíncronas son prácticas en transacciones en las que las
actualizaciones de bd se llevan a cabo en un tiempo largo y el tiempo de respuesta de
cara al usuario es importante.
Las actualizaciones asíncronas es la técnica estándar utilizada en procesamiento de
diálogo.
Se puede implementar la log table VBLOG como un fichero de cluster en el sistema o
reemplazar este con las tablas VBHDR, VBMOD, VBDATA y VBERRROR.

96
Actualización síncrona
Si se tiene una actualización síncrona que se lanza a través de un COMMIT WORK
AND WAIT, el programa de diálogo espera hasta que la actualización termina para
seguir procesando el programa.
Se utiliza este tipo de actualización si el programa depende de los resultados de la
actulización.
Se puede saber si el procesamiento de actualización ha sido bueno con SY-SUBRC.
Durante la fase de espera, el programa de diálogo esta en un estado “rolled out”
(enrollado). Esto quiere decir que el proceso de trabajo de diálogo respectivo se libera
para un uso posterior. Cuando se completa la actualización, el sistema vuelve a asignar
un proceso de trabajo de dialogo libre para un procesamiento posterior.

Actualización local

En actualizaciones locales, las funciones de actualización se ejecutan en el mismo

preoceso de diálogo usado por el programa de diálogo. El procesamiento del programa
de diálogo continúa cuando la actualización se completa.
Para tener módulos de actualización ejecutandose localmente, se tiene que usar la
sentencia SET UPDATE TASK LOCAL antes de escribir la petición. Se cierra la
petición que se ha escrito con un COMMIT WORK, y este se va a procesar en el mismo
proceso de diálogo.
Después de que la actualización local se procese correctamente, se inicia un DB commit
explícitamente y el programa de diálogo continua.
Si hay un error y se lanza un mensaje de terminación por uno de los módulos de
actualización, el sistema ejecuta automáticamente un DB rollback para descartar los
cambios en la LUW actual y el programa de diálogo termina visualizando un mensaje
de terminación.
Las peticiones de cambio no se escriben en la tabla VBLOG, pero se mantiene en
memoria. Es más rapido que las actualizaciones síncronas o asíncronas, pero la
desventaja es que permanece en el uso exclusivo de un proceso de trabajo. Las
actualizaciones locales son apropiadas solamente en modo batch.
SET UPDATE TASK LOCAL es posible solamente si no habían peticiones creadas
para la LUW actual. Esta sentencia solo vale hasta el siguiente COMMIT WORK.

97
Actualizaciones V1 y V2
Tipos
Dos tipos de módulos de actualización: V1 y V2. Solo si las peticiones V1 se ejecutan
correctamente, se procesan las peticiones V2. Las V2 son actualizaciones de
estadísticas…
Las V1 se pueden reiniciar o no. Si ocurre un error, se pueden reiniciar a mano usando
la transacción SM13. Se hace esto después de eliminar el error. Las V2 se pueden
reiniciar siempre después de un error.
Las V2 tienen una opción collective run. Las actualizaciones correspondientes no se
llevan a cabo tras la V1, pero solo si se ha llamado al collector program RSM13005.

Generando peticiones V1 y V2
Las actualizaciones V1 crean peticiones en la tabla VBLOG para actualizaciones
síncronas y asíncronas. Para actualizaciones locales, las peticiones V1 se retienen en
memoria.
Las peticiones V2 se almacenan siempre en la tabla VBLOG.

Ejecución de actualización

Las peticiones V1 se procesan en procesos de trabajo de actualización V1 como DB

LUW independientes. Si la actualización V1 se ejecuta correctamente, el sistema
elimina las peticiones V1 y todos lo bloqueos pasados en la tarea de actualización,
ejecuta un DBCommit y lanza la actualización V2.
Las peticiones V2 son ejecutadas en procesos de trabajo V2. También forman una DB
LUW independiente. Si no hay procesos de trabajo de V2 en el sistema, se ejecutan por
la V1. Si todas las V2 se ejecutan correctamente, se eliminan de VBLOG y el sistema
ejecuta un DB commit. Se ejecutan sin bloqueos.
Si un V1 termina con un mensaje de terminación, todos los bloqueos pasados en la tarea
de actualización son eliminados, se ejecuta una DB rollback, se envía un mail y las V1
son marcadas como incorrectas en la tabla VBLOG con el mensaje de terminación. No
se lanzan las V2.
Si la V2 termina con un mensaje, el sistema lanza un DB rollback. Todas los cambios
de la V2 se deshacen y las peticiones V2 se marcan en el VBLOG como incorrectas con
el mensaje de terminación.

98
Poniendo bloqueos en la actualización

Si los bloqueos se crean con _SCOPE = 2 se transfieren a la tarea de actualización V1

en el COMMIT WORK (AND WAIT). Al final de la V1 se eliminan automáticamente,
independientemente de que se termine satisfactoriamente o con error.
Las entradas de bloqueo no tienen que ser eliminadas.
Las V2 siempre se ejecutan sin bloqueos. Porque se eliminan en la V1.

Notas de optimización para cambios de bd

Bloqueos de base de datos lo más cortos posible
Cada vez que se cambia algo en la bd, el registro a cambiar, se bloquea fisicamente por
la bd hasta el final de la LUW actual.
Sin embargo es una buena idea mantener los bloqueos el menor tiempo posible. Esto es
porque las lecturas no están permitidas durante el bloqueo.
Reglas convenientes:
-Crear primero una entrada de tabla. Su bloqueo de bd interfiere lo mínimo a otros
usuarios.
-Realizar table updates que no son críticos para la ejecución. Como norma, estas tablas
son accedidas simultáneamente por pocos usuarios.
-Siempre cambiar tablas que representan recursos centrales en el sistema con una
LUW.

99
Perform on commit en la actualización

Las rutinas form no se ejecutan hasta que se ha terminado de procesar el último módulo
de actualización.

100
Unidad 15: Procesamiento de LUW
complejas
Runtime arquitectura and storage acces by programs
called within programs
Llamadas síncronas

Hay dos maneras de llamar a otro programa ABAP sincronamente.

-El proceso del programa que se llama, se inserta.
“Call function”, “call transaction”, “submit program and return”.
-El programa llamador se interruMpe y se inicia el programa al que se llama.
“Submit program”, “leave to transaction t_code”.
Se puede usar “submit program” y “submit program and return” para empezar
programas ejecutables (tipo “l” o “Executable program”).
Call transactio y leave to transaction llaman a transacciones.

Llamadas asíncronas de function module

Los function modules también se pueden llamar asincronamente para ejecutar procesos
en paralelo. Para esto la llamada tiene que tener la adición de STARTING NEW TASK
task_name.

101
Las llamadas de function modules asincronas son procesadas en paralelo con indepencia
del programa llamador.
Se pueden recibir las salidas de la función (RECEIVE RESULTS FORM FUNCTION)
en una fase de procesamiento posterior al programa lamador.
Los modulos de función que se llaman con STARTING NEW TASK tienen que
marcarse como remote-capable modules.

Logical memory level mode

Pueden haber varias sesiones externas para un user session. Pueden haber varias
sesiones internas para cada sesión externa.
Se puede utilizar la SAP memory y la ABAP memory para pasar datos entre diferentes
programas.
Cada sesión SAP tiene una SAP memory que puede ser accedida desde el resto de
modos de la sesión. La SAP memory sirve como area de almacenamiento para valores
de campo y se retiene durante la sesión. Es apropiado para transferir datos entre las
external sessions.
Cada external session tiene una ABAP memory. El acceso a la ABAP memory es solo
posible desde la internal session respectiva. Es un área de almacenamiento para
variables internas de programa que se pueden pasar entre las internal sessions de una
external session. Cuando se cierra una external session, la ABAP memory se libera.

102
Llamadas sincronas a function modules

Cuando un function module es llamado, el correspondiente function group se carga en

la internal session y se procesa la function module llamada. El proceso del programa
llamdor se interrumpe y continua cuando el function module se ejecuta.
El function group cargado, y los objetos de datos globales en este se mantienen en la
internal session hasta que termina el programa llamador.

Submit and return /call transaction

El programa llamado usando CALL TRANSACTION o SUBMIT AND RETURN se

ejecuta en una internal session nueva que contiene el contexto de programa.
Después de que el programa llamado se ejecuta, se borra la internal session y se
continua procesando el programa llamador.
El programa llamado puede acabar prematuramente con la sentencia LEAVE
PROGRAM.

103
Submit

Si el programa se llama con un SUBMIT, el contexto del programa llamador se borra de

la internal session actual y se carga la del programa llamado para su procesamiento.

Leave to transaction

La sentencia LEAVE TO TRANSACTION elimina todas las internal session de la

esxternal session actual y abre una internal session nueva para el procesamiento de la
transacción llamada.
Se inicializa la memoria ABAP. Esto implica que no se puedan pasar datos al programa
llamado a través de las ABAP memory.

104
Llamadas asincronas a function modules

Los modulos de función que han sido llamados asincronamente son procesados en el
mismo servidor de aplicación en una nueva sesion abierta. El procesamiento se lleva a
cabo en paralelo.
Se pueden recibir las salidas de la función (RECEIVE RESULTS FROM FUNCTION).

Transferencia de datos entre el programa llamador y el

programa llamado
Transferencia de datos entre programas
Hay diferentes maneras de pasar datos a un programa llamado:
-A través de la interfaz del programa llamado.
-ABAP memory
-SAP memory
-Tablas de bd.
-Ficheros en el servidor de presentación o el servidor de aplicación.

Transferencia a través del interfaz

105
Los módulos de función tienen una interfaz para pasar datos entre el programa llamador
y el propio módulo de función.
Si se llama a un programa ABAP que tienen una selection screen estándar, se pasan los
valores a los input fields en la selection screen. Hay dos opciones:
-Se puede introducir una variante para la llamada (La adición a SUBMIT, USING
SELECTION-SET.
-Se pueden introducir los valores actuales para los input fields de la selection screen
durante la llamada.

Submit….With

La adición al SUBMIT de VIA SELECTION-SCREEN se usa para empezar el

programa llamado visualizando esta selection screen. Si no se especifica esta adición, el
sistema ejecuta el programa sin procesar el selection screen. Sin embargo se pueden
pasar los valores para los inputs fields de la selection screen con la adición WITH.
Si se utiliza el pattern para introducir el SUBMIT, el sistema lista todos los elementos
del selection screen del programa que se ha de llamar usando la adición WITH.

Transferencia de datos a través de ABAP Memory

Usando la sentencia EXPORT TO MEMORY ID, se copia la variable del programa a la

ABAP memory. El id identifica unicamente a la variable.
Una export a la misma ID sobrescribe el valor actual.

106
El las variables de origen y destino tienen que tener el mismo formato en el programa de
lectura y escritura.
La sentencia FREE MEMORY ID <id> borra respectivamente el data cluster.
La sentencia FREE MEMORY sin la adición de ID borra toda la ABAP memory de la
external session actual.
Se puede usar IMPORT APRA leer variables en el data cluster.

Transferencia de datos a través de la memoria SAP

Usando el object navigator, se puede definir parameter IDs para el sistema SAP R/3. El
parámetro ID no tiene que tener mas de 20 caracteres.
Usando la sentencia SET PARAMETER ID, se pueden dar valores a la SAP Memory de
la sesión actual para el parámetro especificado. Este valor se puede leer por todos los
programas de la misma sesión utilizando el GET PARAMETER ID.
Un parámetro en una SAP memory también se le puede dar valor a través de una
entrada de un usuario en un campo de la pantalla. Para esto el campo de la pantalla,
tiene que estar definido a través de un elemento de datos que esta enlazado con el
parameter ID respectivo. Las funciones SET deben ser activadas en las propiedades del
campo de la pantalla.
Un input field de una pantalla puede visualizar al el valor de ese parámetro en la SAP
memory como entrada propuesta. Se tienen que dar los siguientes prerrequisitos:
-El input field de la pantalla tiene que estar definido a través del elemento de datos que
esta enlazado al correspondiente parameter ID.
-Las funciones GET de los campos de la pantalla estan activados.
-El programa solicita el campo de pantalla solo con el valor inicial.
De esta manera los programas y las pantallas pueden intercambiar datos a través de la
SAP memory durante la misma sesión.

107
Valores por defecto a través de la SAP memory

El ejemplo muestra como dar valores por defecto a las input fields de una transacción
llamada por un programa. En este sentido se puede ejecutar la transacción sin
visualizar la pantalla inicial. (AND SKIP FIRST SCREEN).
Se tienen que dar los prerrequisitos indicados anteriormente.

LUW logia in Program-Controlled program calls

SAP LUWs en llamadas a programas sincronos

Los modulos de función se ejecutan en la misma SAP LUW como los programas que
les llaman.
Los programas que se utilizan usando SUBMIT AND RETURN, CALL
TRANSACTION, SUBMIT o LEAVE TO TRANSACTION se ejecutan en una LUW
separada.
Si se ejecuta una SUBMIT AND RETURN y CALL TRANSACTION, la LUW del
programa llamador continua hasta que se completa el programa llamador. Las LUW del
programa llamador y llamado se ejecutan en independientemente uno de otro. Ocurre lo
siguiente:
-Los cambios directos de líneas se actualizan a la bd en cada cambio de pantalla.

108
-Los flags de update y calls utilizando PERFORM ON COMMIT requieren un
COMMIT WORK separado en el correspondiente SAP LUW.
Si se usan SUBMIT y LEAVE TO TRANSACTION, la SAP LUW del programa
llamador termina.

SAP LUWs para CALL TRANSACTION

Si se llama a transacciones con llamadas anidadas, cada transacción necesita su propia

COMMIT WORK porque cada transacción mapea su propia SAP LUW.
Lo mismo se hace para programas ejecutables que se llaman utilizando SUBMIT
program AND RETURN.
Un db commit implicito o explicito en la transacción llamada también actualiza todos
los cambios completados del programa llamador.

Modo de llamada en Call transaction

Si una transacción se llama desde un programa usando CALL TRANSACTION,

también se puede tener la transacción ejecutada sin user dialog (en background). Para
esto hay que utilizar una internal table en formato batch-input, usando la adición
USING. Esta tabla contiene la pantalla de la transacción llena. También se debe de
especificar el MODE con el valor N (no visualizar).

109
Otros valores de MODE: A visualizar y E visualizar solo en caso de error.
Usando el call parameter UPDATE, se puede sobrescribir el modo de actualización por
defecto para la transacción que se llama, que normalmente es asincrona. Posibles
valores para UPDATE: A asincrona, S sincronía y L local.

SAP LUWs en llamadas a funciones asincronas

Un módulo de función que ha sido llamado asincronamente se ejecuta en una sesión

separada y crea su propia SAP LUW.
El procesamiento del programa llamador se interrumpe; Después de que la function
module se ha lanzado, el procesamiento continua. Esto significa que los flags de
actualización registrados y las subrutinas PERFORM ON COMMIT son retenidas.
Las llamadas a módulos de función asincronas, lanzan un db commit implicito en el
programa llamador.

Habilidad para acumular bloqueos para llamadas a programas

Si se tiene un bloqueo de tipo E se pueden tener bloqueos adicionales de tipo E en el

mismo programa o modulo de función que se ha llamado asincronamente.
Sin embargo no se pueden poner bloqueos adicionales a los existentes desde un
programa llamado utilizando SUBMIT AND RETURN o CALL TRANSACTION.

110
Cualquier intento de bloqueo desde los programas se rechaza con la excepción
FOREIGN LOCK.
Si se tiene un programa llamado utilizando SUBMIT o LEAVE TO TRANSACTION,
el programa llamador termina inmediatamente. Todos los bloqueos que se han puesto
hasta el momento se borran automáticamente.
Las peticiones de bloqueos del mismo usuario desde sesiones diferente, se tratan como
si fuesen de diferentes usuarios.

Implementación de diferentes llamadas a programas

111
Unidad 16: Asignación de números
Asignación de números
Durante la asignación de números los business objects son asignados a intervalos de
números específicos.
Se llevan a cabo externamente o internamente. Con asignación externa, el usuario
introduce un número que es chequeado por el sistema para ver si ha sido reservado para
una asignación externa. Con la asinganción interna, el sistema asigna directamente un
número a un business object. Hay diferentes rangos de números para la asignación
interna y externa.
Cuando se asignan números hay que poner atención a regulaciones legales y criterios
específicos de aplicación.
Paraa asignar números sin problemas se necesita un range object, un range interval bien
mantenido y acceso a estos dos desde la aplicación.

Objetos Number range

El mantenimiento de objetos number range esta en el menú de desarrollo junto con otras
herramientas. (Transacción SNRO).
Los nombre deben empezar por Y o Z.
Se pueden organizar de acuerdo a los subobjetos.
Si se quieren organizar en función del año fiscal, hay que seleccionar el campo to-year
flag.
La longitud de los números no se puede meter directamente. Hay que introducir un
dominio de tipo NUMC o CHAR y una longitud hasta 20.
Si se mete un código de transacción en el campo number range transaction, hay que
mantener el intervalo para este rango cuando se llama al código.
En el campo Warning% hay que introducir un valor entre 0.1 y 99.9. Esto lanza un
warning cuando quedan menos números para asignar que ese porcentaje.

112
Number range intervals

Los number range intervals se componen tanto de números o caracteres alfanuméricos.

A un number range se le pueden asignar múltiples intervalos, especialmente cuando los
objetos se organizan por año fiscal.

Subobjetos

Los objetos de number range se pueden dividir en subobjetos.

Se pueden organizar los documentos por ejemplo : de acuerdo al código de la compañía
o las reservas de vuelos de acuerdo a la aerolínea.
Cuando se define un subobjetos, hay que declarar el data element correspondiente.
El data element de los subobjetos, tienen que referenciar a un value table y pueden tener
un campo con longitud hasta 6.

113
Getting numbers (de un internal number range)

Cuando se asignan números internamente, hay que llamar al módulo de función

NUMBER_GET_NEXT para determinar el siguiente número que esta disponible.
Si se ha pedido más de un número usando el import parameter QUANTITY, el export
parameter QUANTITY el número de los números asignados, mientras que el export
parameter NUMBER muestra el último número asignado.
Si se asigna el último número del intervalo, la asignación de números comienza por el
principio del intervalo otra vez.
El código de retorno:
-SPACE: Asignación correcta.
-1: Asig correcta, pero hay muchos números estan disponibles en el area crítica.
-2: Asig ok. Se acaba de asignar el último número disponible.
-3: Se han pedido más números de los disponibles.

Check number (en el external number range)

Se usa el módulo de función NUMBER_CHECK para chequear los números externos.

El número chequeado no se marca por el módulo de función como asignado.
Los returncodes:
-SPACE: Número con el intervalo especificado.
-X : Número fuera del intervalo especificado.

114
Getting number range information

Se usa el módulo de función NUMBER_GET_INFO para coger la información sobre el

range number intervals.
Esta información se transfiere a una estructura usando el parámetro INTERVAL. El
parámetro tiene la estructura NRIV.

Accediendo a la tabla NRIV sin buffer

El dato para el number range se almacena en la tabal NRIV. En esta tabla, existe una
entrada para cada number range.
Si un objeto number range no se ha utilizado buffer, el sistema lee directamente de la
base de datos cada vez que se asignan nuevos números.
Ventajas:
-Asignación de números sin huecos.
-Secuencia cronológica de números.

Desventajas:
-Bloqueos de bd.
-Posibles efectos de multiplicación.

115
En el módulo de función NUMBER_GET_NEXT, se utiliza la sentencia SELECT
SINGLE….FOR UPDATE, para acceder a la tabla NRIV. Esto bloquea la tabla
relevante en la bd hasta que se completa el LUW actual.
Esto puede implicar un tiempo de espera considerable cuando múltiples programas,
piden números al mismo number range.

Acceso a través de Number range buffer (estándar)

Se puede mejorar la realización considerablemente utilizando buffer para los number

range. Se transfiere la responsabilidad al servidor de aplicación.
El buffer se rellena con un nuevos números cuando se han asignado todos los números.
Se determina cuantos números se almacenan en el buffer durante el mantenimiento de
objetos number range.
Con este tipo de buffering, el servidor de aplicación, solo tiene que leer directamente de
la bd después de que se hayan asignado todos los números del paquete actual. Esto
permite mejorar la ejecución.
El módulo de función NUMBER_GET_NEXT ofrece la opcion de ignorar el buffer si
se desea. (Parámetro IGNORE_BUFFER).
Los servidores de number range, son unidades lógicas en el application server que se
ejecutan con su propia LUW. Pueden haber huecos en la asignación de números por
rollbacks o errores de red.

116
Acceso paralelo a number range

Se permite el acceso paralelo a varios servidores. La serialización surge para cada uno
de estos servidores individuales.
Todos los números son asignados. No hay huecos. Los números no se asignan en orden.

Usando functio groups para manejar number ranges

Para procesar objetos number range, los number range, y grupos, módulos de función
adicionales permite editar dialogos, acceso a bd, y otras tareas.
Hay cinco grupos de function groups.
Si solo se esta interesado en utilizar las funciones estándar, solo se necesita el function
group SNR3.

117
Unidad 17: Creando change documents
Principio de creación change documents

Si se quieren registrar (log) las actualizaciones en tablas de aplicación usando change

documents, hay que asegurarse en el programa de aplicación que las actualizaciones se
ejecuten tanto en las tablas de aplicación como en la tabla de change document (con la
misma LUW).
Los change document se esciben usando unos módulos de función especiales que se
generan usando una transacción de mantenimiento. Hay que usar el módulo de
actualización para escribir el change document en el programa con la LUW que
contiene los datos para las tablas de aplicación que se quieren actualizar.
Hay que transferir el siguiente dato al módulo de actualización que escribe el change
document:
-El application data antes de que se cambie por el programa.
-El application data actualizado en el programa.
-El administration data para la cabecera del documento.

118
Para poder registrar (log) los cambios a un business object en un change document, se
tiene que definir un objeto change document en el sistema.
Hay que incluir las tablas correspondientes.
El sistema después crea un módulo de creación de documento así como dos Include
programs con las definiciones de objetos de datos. Esto se da durante la generación o
cuando se llama al módulo de creación de documento.
Los dos include programs se incluyen en el programa de aplicación y hace que los
change documents sean escritos cuando ciertos requerimientos se cumplan.
Si se llama a un módulo de creación de documento, este crea un documento solo si un
campo relevante del documento cambia en el registro de aplicación.
Los change documents se almacenan en el cluster CDCLS.

Estructura de un change document

La cluster CDCLS contiene las estructuras CDHDR (cabecera), CDPOS (item del
documento) PCDHDR (planned change document: header) y PCDPOS (planned change
document: ítems).
Los números de change document se generan automáticamente cuando se crea un
change document.
Un change document consiste en general document data y una document header con sus
document ítems.
El general document data incluye:
-Object class: Nombre del objeto change document usado.
-Object ID: En la creación del documento, se puede decidir el nombre del documento.
-Change number: Número asignado automáticamente al documento.
Un document header contiene el nombre de la changed table, la persona que cambia el
documento, la fecha y hora etc. Un document header contiene varios document ítems.
Un document item consiste en la clave del registro cambiado, el nombre del campo
cambiado, y los valores viejos y nuevos del campo. Cada document item describe el
campo cambiado en el registro cambiado.
Cuando se llama al modulo de creación de documento, se crea un documento solo si al
menos un campo relevante del documento ha cambiado en el registro de aplicación.
Solo los cambios para estos campos se registran como document ítem.

119
Creación de un objeto change document
Para crear un change document primero hay que definir un objeto change document.
Desde el menú de SAP se elige ToolsABAP WorkBenchDevelopmentFurther
tools change documents (transacció SCDO).
El nombre tiene que empezar por Y o Z.
El objeto change document incluye todas las tablas relevante para los cambios
realizados.
Tiene que haber nuevos valores en cada uno de los work areas listados de las tablas.
Para cada work area de tabla, hay que especificar una estructura interna que contiene el
registro viejo cuando se le llama después.

Generando un módulo y la llamada de creación de documento

Hay que especificar el nombre de un functio group para almacenar los módulos de
función.
También pide una abreviación para asignar los nombres de las partes de programas
(includes) generados.
Después de la generación se tiene un Include program con las definiciones de datos
globales para la aplicación de programa. Tambien se tieen un include para cuando se
llama al modulo de generación de documento, que también habra que incluir en el
programa. Después habra que incluir la llamada en el sitio apropiado en el programa.

120
Estructura de los includes generados

En el ejemplo FZBOOKCDT:
-Contiene una declaración global de datos.
-Declaración de datos específicos del objeto de cambio.
En FZBOOKCDC se contiene la llamada para el modulo de creación de documento.
En la aplicación hay que incluir los dos includes y llamar a la rutina form para la
creación de documento en el lugar adecuado.

Uso de includes en programas de aplicación

121
Visualización de change documents

El programa SAP RSSCD100 demuestra como evaluar los change documents.

Function groups para procesar change documents

Los módulos de función de SAP estan disponibles para todas las tareas requeridas en el
procesamiento de change documents.
Se agrupan juntas en 6 function groups.
Los módulos de función del grupo SCD0 se llaman por el document function module
que se ha generado específicamente para el objeto.

122
APENDICE
Autorization Checks
Para asegurar que los datos del sistema SAP están protegidos contra accesos
desautorizados y que cada usuario puede acceder solo a los datos para las cuales tiene
autorización explicita, el application Developer debe implementar authorization object
en cada una de las aplicaciones del programa.

Pare ello se debe desarrollar un application-related authorization model para determinar

que autorizaciones debe ser chequeada durante las acciones de un usuario. Se debe crear
el authorization object y la authorization, y asignarlos al usuario con un authorization
profile. El application Developer debe asegurarse que este authorization check se
completa antes de que la acción requerida por el usuario es llevada a cabo.

Authorization Object / Authorization

Un authorization object tiene un máximo de 10 campos, los cuales no son evaluados

(valuated).

Un authorization es un authorization object con valuated fiel. Se puede crear diferentes

authorization para un authorization object.

Existen authorizations que puede ser agrupadas en un authorization profile. Un

authorization profile debe contener todas las authorizations que son requeridas para
ejecutar ciertas tareas.

Para crear authorization fields, authorization objects, authorization se debe ir a

ToolsABAP WorkbenchDevelopmentOther ToolsAuthorization objects.

Authorization Checks

123
En el application program, se debe llevar a cabo chequeos antes de la ejecucion de las
tareas requeridas por el caller. Para ello, se debe usar la sentencia AUTHORITY-
CHECK. Se especifica un authorization object junto con los campos a evaluar.

Si se quiere chequear si existe una autorización particular y que el contenido de los

authorization fields no importa, en vez de FIELD <value>, se escribe DUMMY después
del authorization field.

Si el caller tiene la correspondiente authorization, el campos sy-subrc devolverá el

código 0, en caso contrario devolverá un 4. Basándose en el valor devuelto se deberá
decidir en el programa como se quiere proceder.

El uso de autorización checks evita los típicos errores que ocurren a causa de errores
sintácticos o incluso por un incorrecto chequeo del resultado.

Authorization Checks para Transacciones

Pasos a llevar a cabo:
1. Cuando comienza una transacción, el sistema automáticamente chequea si el
código de transacción especificado es conocido, esto es, si esta marcado en la
tabla TSTC y si esta bloqueado (lock).
2. El sistema chequea si el caller tiene la autorización para llamar a la transacción,
esto es, si tiene el correspondiente authorization para el authorization object
S_TCODE.
3. El sistema Chequea si el caller tiene asignado la default authorization para la
transacción. Esto es especificado en Transaction/Default Authorization en la
definición de la transacción y almacenado en la tabla TSTCA.
4. Solo cuando todos los chequeos son correctos podrá empezar la transacción. De
otra forma, el proceso se terminado con un error message.

SAP Buffers

124
SAP database table puede ser almacenadas en el nivel application server. Los objetivos
del buffering son:
• Reducir el tiempo necesario para acceder a los datos con los accesos a lectura: Se
puede acceder más rápidamente a los datos de la application server que a los de la
base de datos.
• Reducir la carga en la base de datos: Leyendo los datos desde los application
server buffers se reduce el número de accesos a la base de datos.

A las buffered tables se acceden exclusivamente a través de la database interface.

Cuando el sistema ejecuta un comando Native SQL, este atraviesa la database interface,
por lo que no usa la table buffer. No es conveniente utilizar sentencias Native SQL para
tablas que son almacenadas.

Actualizar los SAP Buffers

Si una tabla esta almacenada en varios application Server, se retrasa la sincronización de

los otros buffers y se lanza como se explica a continuacion:
• Cuando se cambia datos en la base de datos de uno de los application server, el
cambio es registrado en una tabla DDLOG en la base de datos. Los application

125
 Server leen es tabla a intervalos de tiempo. Si un application Server encuentra una
entrada relevante, se marca el contenido de su buffer como no puede ser
actualizado (“no longer up-to-date”).
• El siguiente acceso a lectura a los datos del buffer es llevado a cabo por la
database interface en la base de datos. Se actualiza el buffer al mismo tiempo.

El tiempo entre los accesos a lectura a la tabla DDLOG puede ser fijados usando el
profile parameter //rdisp/bufreftime.

Tipos de buffers
Hay tres tipos de buffers:
• Resident buffering (full buffering): Se carga toda la tabla en el table buffer
cuando se accede a la tabla por primera vez.
• Generic buffering: En technical settings, se debe especificar una generic key
para la tabla en el diccionario. Esta key es utilizada para dividir el contenido de la
tabla en generic areas. Las entradas de la generic area son cargada en el table
buffer. Las tablas dependientes de mandante usan este tipo de buffer para cada
cliente.
• Single-record buffering: La base de datos solo lee un único registro, y lo
almacena en el table buffer.

Native SQL
Native SQL permite llevar a cabo operaciones en la base de datos que superan el
comando estandar Open SQL. Contiene todas las sentencias estaticas de la data
definition language (DDL) y el data manipulation language (DML) de la relational
database system.

En un programa ABAP, la sentencia EXEC SQL-ENDEXEC encapsula el comando

Native SQL. La database table no tiene que estar declarada en el diccionario para llevar
a cabo comandos Native SQL.

Cluster Tables
Data Cluster
Un data cluster es una combinación de data objects. Los data objecs son campos,
structured field, tablas internas, y complex structured derivados de estos. Se procesa los
data clusters usando los comandos EXPORT, IMPORT y DELETE. Los data cluster
pueden ser almacenados en cluster databases.

Un cluster database, en el diccionario, se subdivide en application areas de acuerdo a

un criterio y usa data cluster relacionados lógicamente. Dentro de la application area, se
identifica un cluster usando un ID (cluster ID).

Export

126
La tabla INDX es una cluster database para propósitos generales. Las cluster database
deben ser creadas como transparent tables en el diccionario y deben tener una estructura
estandarizada.

Para un EXPORT, hay que especificar en una lista los data objects de su cluster.

Para llevar a cabo el export, hay que especificar el cluster database y la application area
dentro del cluster database. Para identificar el cluster se usa el cluster ID. Si se quiere
definir el nombre de un data object en el cluster que es diferente en otro programa, hay
que usar la adición FROM. Los data objects puede ser listados en cualquier orden.

La sentencia TABLES declara una application area para la cluster database al comienzo
del programa.

No se puede exportar las header lines de una tabla interna.

Import
Para una IMPORT, se necesita listar solo un subconjunto de los data objects del cluster
en cualquier orden. Si se quiere definir el nombre de un data object en el programa que
es diferente en el cluster, se usa la adicion TO.

Después del IMPORT, el sistema devuelve un codigo (sy-subrc).

La estructura de los campos, estructuras, y tablas internas a importar deben

corresponder con las estructuras de los objetos exportados a la dataset. Si no es el caso,
se producirá un error en tiempo de ejecución. El objeto se debe importar con el mismo
nombre con el que se exporta.

DELETE siempre borrara todo el cluster. No se puede borrar un data object individual
dentro del cluster. Devuelve un código.

127
ABAP Cluster Database

Pasos para crear una cluster database:

− Definir una database table como una tabla transparente en el diccionario. Esta
tabla representara a la cluster database.
− Construir la table estructure como se muestra en la imagen anterior.
− El campo MANDT puede ser omitido.
− Los campos RELID, SRTF2, CLUSTR, CLUSTD y el cluster ID se llenan
automáticamente cuando se hace EXPORT.
− Tener user-defined fields llenos antes del EXPORT:
− Elegir los field names para el cluster ID y sus campos.
− Calcular la longitud de la parte usada para el data cluster: la longitud total de la
estructura menos la longitud de los seis primeros campos.

Key del Database Table INDX

La base de datos INDX es un ejemplo de database table en el cual se puede almacenar
data clusters. Esta instalado en el sistema por defecto y tiene un key lenght de 31 bytes.

128
La key consiste de un client, area, cluster ID, y numero de registros posterior. El cluster
ID tiene por defecto una longitud de 22 bytes, pero en una cluster database puede tener
cualquier longitud.

La estructura de la database INDX a menudo incluye campos opcionales para

administrar información. Se usa la sentencia SELECT para acceder a la key y a los
administration fields. El sistema suministra los administration inforamtion fields solo si
se rellenan antes del EXPORT usando la sentencia MOVE.

Cluster tables y Transparent tables

Las cluster database contienen el cluster data en la forma deseada.

La estandarización requiere que los datos de varias tablas sean seleccionados en

transparent tables. La ventaja de esto es que se pueden leer objetos individuales desde
varias tablas y linkar cada una de las otras. En cluster tables, sin embargo, solo se puede
leer los datos de un cluster, y no es posible linkar los datos en otro cluster.

El acceso a cluster tables requiere conocer el cluster ID y la application area. Solo

devuelve un cluster ID. Por el contrario, las transparent tables devuelven más de un
cluster.

Cluster tables:
• Solo contiene datos del cluster
• Menos accesos para grandes cantidades de datos
• Datos heterogéneos
• Técnicas flexibles
• No es posible linkar los datos.
• Los accesos requieren el cluster ID y la application area
• Los accesos solo devuelven un cluster

Transparente tables:
• Muchos accesos a los datos almacenados en varias tablas.
• Los datos pueden ser linkados y evaluados.
• Selección con cualquier condición lógica.

SAP Locks
Update y Lock Durations: _SCOPE = 1
Para _SCOPE = 1, el dialog program contiene los locks (bloqueos) que han generado.
Los locks permanecen en conjunto hasta que son liberados, usando el function module
DEQUEUE_<object>, o implícitamente al final del programa. Esto incluye las
sentencias LEAVE PROGRAM, LEAVT TO TRANSACTION <ta>, y SUBMIT
<program>, y el termination message (mensaje tipo A).

Si la transacción usa asynchronous update, la actualizacion del programa no garantiza

que los datos que van a ser cambiados no esten bloqueados por otro usuario. Por esta
razon, no se debe usar _SCOPE = 1 para asynchronous updates.

129
Update y Lock duration: _SCOPE = 3
Si se usa asynchronous update y se quiere asegurar que los locks generador en el dialog
program permanecen mas tiempo que la V1 update function module esta activa, se
puede usar _SCOPE = 3. En este caso, el lock es compartido entre el dialog program y
el update program.

Los locks generados con _SCOPE = 3 deben ser eliminados tanto por el dialog program
como por el update program.

BAPI Transaction Model

Una Business Application Programming Interface (BAPI) funciona como un gateway
proporcionando accesos a sus business data y processes.

Una BAPI es una interfaz bien definida para procesos y datos de una business
application system, implementada como un método de un objeto en el Business Object
Repository (BOR).

130
Un objeto en el BOR puede tener muchos métodos, de los cuales uno o más están
implementados como BAPIs.

Las BAPIs pueden tener varias funciones, entre ellas: generar un objeto, consultar
atributos de un objeto, y cambiar atributos de un objeto.

El Role de las BAPIs

Una BAPI es una interfaz que puede ser usada por varias aplicaciones, como por
ejemplo: Internet Application Components, SAP R/3 component formation, y
VisualBasic/JAVA/C++.

Propiedades de la BAPI
• Son orientadas a objetos.
• Stable interface: La interfaz de una BAPI es “frozen” (congelada).
o Libera function module para los clientes.
o Linka data elements a los interface parameter.
• Puede ser usada internamente y externamente.
• No contienen presentation layer: Los resultados se visualizan externamente por
cada caller.
• Siempre se llama a las BAPIs de forma sincronía. Hay una excepción en donde se
les llama de forma asíncrona, via ALE en un IDoc.
• Implementan los database changes a traves de update task.
• En vez del COMMIT WORK, ahora se debe usar
BAPI_TRANSACTION_COMMIT y BAPI_TRANSACTION_ROLLBACK.

BAPI Transaction Model para Release 3.1

Las BAPIs realizan por si mismas el comando COMMIT WORK, es decir, una BAPI
es sincronía con un LUW o transaction. Esto se muestra en la documentación, y es la
única manera de que el usuario pueda encontrar donde están los COMMIT WORK.

131
BAPI Transaction Model para Release 4.0

El Commit control debe ser eliminado de las writing BAPIs, en otras palabras, de las
BAPIs que causan los cambios de base de datos. Se debe llamar al RFC-capable
function module BAPI_TRANSACTION_COMMIT.

BAPI Transaction Model para Release 4.6

En la transaction model usada para desarrollar BAPIs, una transacción representa una
processing unit o logical unit of work (LUW).

Las operaciones que cambien la base de datos deben ser realizadas por el update task.

Para cerrar LUW processing iniciados por la BAPI call, se usa el function module
BAPI_TRANSACTION_COMMIT.

COMMIT WORK y ROLLBACK WORK

COMMIT WORK
• Acciones en la base de datos:

132
 o Se realiza un commit con todas las actualizaciones que se han hecho
durante el dialog step en curso.
o Todos los database locks son liberados.
o Todos los databse cursors abiertos son cerrados (incluso si están abiertos
usando WITH HOLD).
• Update son lanzadas (CALL FUNCTION IN UPDATE TASK)
o COMMIT WORK no espera al final del update
o COMMIT WORK espera al final del update.
o Para un local update: ejecución inmediata de los update modules.
• Los locks (_SCOPE = 2):
o No se liberan si no surge ninguna update requests
o Son transferidos al update y liberados cuando esta acaba.

ROLLBACK WORK
• Los DB LUW (DB Rollback) en curso son terminados
o Se deshacen todos los cambios hechos en el dialog step en curso.
o Todos los locks son liberados.
o Se cierran todos los cursores abiertos.
• Los datos en el SAP LUW correspondiente son eliminados:
o Se rechaza el registro de los update modules registrados con CALL
FUNCTION IN UPDATE TASK.
o Lo mismo se aplica a las subrutinas registradas con PERFORM ON
COMMIT.
o No se ejecutan los function modules que fueron registrados por
transactional o queued RFC (CALL FUNCTION IN BACKGROUND
TASK).
• Los SAP locks son liberados (_SCOPE = 2).

Acciones que un ROLLBACK WORK no lleva a cabo

• Deshacer actualizaciones a las que se les hizo commit antes.
• Deshacer actualizaciones de tablas internas y otros data obejcts.
• Resetear valores en calcultaed ‘context’.
• Deshacer cambios hechos por operating system files.
• Deshacer acciones que fueron ejecutadas durante RFCs sincronas.

133