NEXUS02 E0 NO02 00 GG Normativa Desarrollo ABAP 00.06

Normativa de desarrollo ABAP (NO02)
Proyecto: Modernizacin y externalizacin de los

Sistemas de Informacin Corporativos (EconmicoFinanciero, Compras, Logstica y Contratacin Pblica)
de la Comunidad de Madrid
Nombre del fichero:
302056063.doc
Versin n.:
00.06
Fecha versin:
03/10/2013
Preparado por:
Javier Carrero Snchez
Fecha de preparacin:
06/09/2011
Revisado por:
AC&A
Fecha de revisin:
14/12/2011
Estado de aprobacin:
APROBADO
Fecha de aprobacin:
14/12/2011
Modernizacin y externalizacin de los Sistemas de

Informacin Corporativos (Econmico-Financiero,
Compras, Logstica y Contratacin Pblica) de la
Comunidad de Madrid
Normativa de desarrollo ABAP
Historial de la versin (si procede)

Versin n
Fecha de
la versin
Realizada por
Descripcin
Elaboracin del documento
27/11/2011
Re-elaboracin del documento
00.03
30/11/2011
Correccin del documento
00.04
14/12/2011
Correccin del documento.
00.01
06/09/2011
00.02
- Usuarios OSS
- Nomenclatura de objetos
00.05
14/12/2011
Correccin del documento 00.04
20.00
14/12/2011
AC&A
Cambio del estado del documento.
00.06
03/10/2013
Aadir cambios del documento PRO03
INDICE
1
OBJETO DEL DOCUMENTO............................................................................................... 6
ESTNDARES DE DESARROLLO......................................................................................7
2.1
METODOLOGA DE DESARROLLO......................................................................................7
2.1.1
Estilo del cdigo fuente........................................................................................... 7
2.1.2
Sangrados en todas las sentencias......................................................................15
2.1.3
Resaltar palabras clave........................................................................................15
2.1.4
Una sentencia en cada lnea................................................................................15
2.1.5
Usar lneas en blanco para separar sentencias o grupos de sentencias..............16
ESTILO DE PROGRAMACIN.......................................................................................... 17
3.1
NOMENCLATURA DE LOS OBJETOS.................................................................................17
3.2
CONVENCIN EN LA NOMENCLATURA DE OBJETOS..........................................................18
3.2.1
3.3
Cuadro resumen de nomenclatura de objetos......................................................18

ASPECTO DEL CDIGO FUENTE......................................................................................22
3.3.1
Estructura del cdigo fuente.................................................................................22
3.3.2
Uso de comentarios..............................................................................................23
3.3.3
Sangrados en todas las sentencias......................................................................24
3.3.4
claves
Usar siempre la funcin PRETTY PRINTER con la opcin de resaltar palabras

24
3.3.5
Una sentencia en cada lnea................................................................................24

Pgina 2 de 84

Comunidad de Madrid
3.3.6
Usar lneas en blanco para separar sentencias grupo de sentencias................25
3.3.7
Limitacin del n de lneas en cada bloque de proceso (Modularizacin)............25
3.4
3.4.1
Cuadro resumen de declaraciones.......................................................................26
3.4.2
Declaracin globales............................................................................................26
3.4.3
Declaracin locales..............................................................................................28
3.5
PANTALLA DE SELECCIN Y DYNPROS............................................................................30
3.5.1
Nomenclatura....................................................................................................... 30
3.5.2
Aspecto................................................................................................................. 30
3.6
PARMETROS EN LAS SUBRUTINAS................................................................................31
3.6.1
Nomenclatura....................................................................................................... 31
3.6.2
Parmetros con TABLES, USING y CHANGING..................................................31
3.7
DECLARACIN DE TIPOS, VARIABLES Y CONSTANTES.......................................................25
MDULOS DE FUNCIN................................................................................................. 32
3.7.1
Nomenclatura....................................................................................................... 33
3.7.2
Parmetros........................................................................................................... 33
3.7.3
Programacin....................................................................................................... 33
3.8
LITERALES EN PROGRAMAS........................................................................................... 34
3.9
EXCEPCIONES.............................................................................................................. 35
NORMAS DE DESARROLLO............................................................................................ 36
4.1
CONTROLAR CDIGO DE RETORNO (SY-SUBRC)..............................................................36
4.2
LIMPIAR VARIABLES....................................................................................................... 36
4.3
VARIABLES GLOBALES................................................................................................... 36
4.4
TABLAS INTERNAS......................................................................................................... 36
4.5
LIBERAR MEMORIA........................................................................................................ 37
NORMATIVA DE USUARIOS DE OSS...............................................................................38
CONCEPTOS IMPORTANTES........................................................................................... 39
6.1
CLASES DE DESARROLLO / PAQUETES...........................................................................39
6.2
CONCEPTO DE TRANSACCIN UNIDAD LGICA DE TRABAJO (L.U.W)...........................40
RENDIMIENTO................................................................................................................... 43
7.1
RECOMENDACIONES GENERALES...................................................................................43
7.1.1
Acceso a la base de datos....................................................................................43
7.1.2
Clculo y procesos............................................................................................... 43
7.2
MEJORAS EN LA PROGRAMACIN...................................................................................44
7.2.1
Instrucciones SQL Interfase.................................................................................44
7.2.2
El WHERE en SELECT........................................................................................ 48
7.2.3
Modificacin e insercin de datos.........................................................................48
7.2.4
Tratamiento de cadena de caracteres..................................................................49

Pgina 3 de 84

Comunidad de Madrid
7.2.5
Tratamiento de tablas internas.............................................................................49
7.2.6
Llamadas a subrutina...........................................................................................56
7.2.7
Comparacin de caracteres..................................................................................57
7.2.8
Sentencias IF o CASE.......................................................................................... 57
7.2.9
Sentencias DO..ENDDO, WHILE..ENDWHILE....................................................58
7.2.10
Tratamiento de FIELD-SYMBOLS........................................................................58
7.2.11
Manejo de variables y tipos..................................................................................58
7.3
7.3.1
Tratamiento de modos internos............................................................................60
7.3.2
Actualizacin de bases de datos..........................................................................60
7.3.3
ndices de BD....................................................................................................... 60
7.3.4
Tablas transparentes en Memoria Intermedia (MI)...............................................62
7.3.5
Utilizacin de tablas internas................................................................................65
7.4
MEJORAS BASADAS EN EL SISTEMA................................................................................60
PROCESAMIENTO EN PARALELO.....................................................................................67
7.4.1
Prerrequisitos....................................................................................................... 67
7.4.2
Mdulos de funcin y sentencia ABAP.................................................................67
7.4.3
Manejo de los recursos con grupos de servidores RFC.......................................68
7.4.4
Mensajes y excepciones.......................................................................................68
7.4.5
Autorizaciones...................................................................................................... 69
VERIFICACIONES DEL CODE INSPECTOR.....................................................................70

8.1
ANLISIS DE CONDICIN WHERE PARA SELECT..........................................................70
8.2
ANLISIS DE CONDICIN WHERE PARA UPDATE Y SELECT........................................70
8.3
SENTENCIAS SELECT QUE SE LEEN EN MEMORIA INTERMEDIA DE TABLAS.......................70
8.4
SENTENCIAS SELECT CON CHECK POSTERIOR...........................................................71
8.5
SELECTS EN LOOPS................................................................................................... 71
8.6
MODIFICACIN EN LOOPS.............................................................................................. 71
8.7
LOOPS ANIDADOS......................................................................................................... 71
8.8
OPERACIONES NO EFICIENTES EN TABLAS INTERNAS.......................................................71
8.9
TRASPASOS DE PARMETROS NO EFICIENTES.................................................................72
8.10
EXIT NINGUNA SENTENCIA EN LOOP SELECTENDSELECT...................................72
8.11
SENTENCIAS CRTICAS.................................................................................................. 72
8.12
ACCESOS DINMICOS Y ESPECFICOS EN SELECT.........................................................72
8.13
ACCESOS DINMICOS Y ESPECFICOS EN INSERT, UPDATE, MODIFY Y DELETE........72
8.14
VERIFICACIN TRATAMIENTO SY-SUBRC.......................................................................73
8.15
VERIFICACIN DE SINTAXIS............................................................................................ 73
8.16
VERIFICACIN DE PROGRAMAS AMPLIADA.......................................................................73
8.16.1
Interfases PERFORM/FORM...............................................................................73
Pgina 4 de 84

Comunidad de Madrid
8.16.2
Interfases CALL FUNCTION................................................................................74
8.16.3
Test SUBMIT vs.interfase report...........................................................................74
8.16.4
Verificaciones de consistencia de dynpro.............................................................74
8.16.5
Verificacin de tablas Load...................................................................................75
8.16.6
Autorizaciones...................................................................................................... 75
8.16.7
Status-PF incorrectos........................................................................................... 76
8.16.8
IDs parmetro SET/GET incorrectos....................................................................76
8.16.9
Instrucciones MESSAGE incorrectas...................................................................76
8.16.10
Verificar textos.................................................................................................. 76
8.16.11
Operaciones en campos..................................................................................76
8.16.12
Propiedades de campos...................................................................................77
8.16.13
Verificar plurilingismo.....................................................................................77
8.16.14
Verificaciones de paquetes..............................................................................77
8.16.15
Sentencias superfluas......................................................................................77
8.16.16
Sentencias peligrosas......................................................................................78
8.16.17
Mensajes de adv.o ampl.estructura..................................................................78
8.16.18
Sentencias obsoleta......................................................................................... 78
ANEXO1 - FUNCIONALIDADES DEL PROYECTO NEXUS02.........................................79
10
ANEXO2 FUNCIONALIDADES DEL PROYECTO NEXUS03....................................80
11
ANEXO3 - PLANTILLA DE CODIFICACIN DE PROGRAMAS ABAP.......................82
Pgina 5 de 84

Comunidad de Madrid
Objeto del documento
El objetivo del presente documento es describir las normas, buenas prcticas, nomenclatura para hacer
los desarrollos tcnicos a medida de forma homognea y ptima.
El presente documento se entregar a cada integrante del equipo tcnico de implantacin.
Pgina 6 de 84

Comunidad de Madrid
Estndares de desarrollo
2.1
Metodologa de desarrollo
En esta metodologa, se presentan una relacin de puntos que permitirn unificar el modo de trabajo para
los desarrollos a medida que se creen durante el proyecto. Adems de la homogeneizacin, los objetivos
que se pretenden son:
Establecer una nomenclatura clara y homognea para los desarrollos locales.
Establecer las pautas que permitan el desarrollo de calidad, buscando la eficiencia, rendimiento y
optimizacin.
Marcar los modelos de documentacin, compresibles y fciles de buscar.
Poner en marcha un procedimiento de control de calidad de los programas, antes de que estos
nuevos desarrollos sean transferidos a los entornos productivos.
2.1.1
ESTILO DEL CDIGO FUENTE
Se necesitan establecer una serie de pautas que hagan que los programas, y cualquier desarrollo en
general, sea lo ms comprensible y homogneo posible, de manera que todos los integrantes del equipo
desarrollen con un estilo comn.
Como norma general, hay que hacer lo posible por escribir un cdigo fuente fcil de leer, claro y conciso.
Para ello, ser suficiente con seguir las recomendaciones que se detallan a continuacin.
2.1.1.1
Estructura del cdigo fuente
El cdigo lo estructuraremos en estos cuatro grandes bloques, que adems deben seguir el orden que se
indica:
1.
Declaraciones globales de variables y tipos.
2.
Pantalla de seleccin (en el caso de programas tipo report).
3.
Proceso principal.
4.
Subrutinas y mdulos.
2.1.1.2
Documentacin cabecera de programas
La cabecera de los programas debe estar documentada conforme se indica en las plantillas de
codificacin ABAP:
Existe una plantilla de codificacin ABAP para Nexus02, ver documento NEXUS02-E0-ABAP00-GGPlantilla Programa ABAP-VF.01.txt
Existe una plantilla de codificacin ABAP para NEXUS03, ver documento NEXUS03-R0-ABAP00-GGPlantilla Programa ABAP-VF.01.txt.
Pgina 7 de 84

Comunidad de Madrid
*---------------------------------------------------------------------------------------------------------*
*
*
* ID_PROGRAMA: ZPAAAATxxxxxxxxxxxxxx
*
*
*
* TIPO DE PROGRAMA:
*
*
*
* DESCRIPCIN:
*
*
*
*
*
*
*
* AUTOR: USUARIO SAP Y NOMBRE Y APELLIDOS
*
*
*
* FECHA DE CREACIN: dd.mm.aaaa
*
*
*
*---------------------------------------------------------------------------------------------------------*
* CHEQUEOS DE AUTORIZACIN
*
*
*
* Objetos de autorizacin campos ABAP
*
*
*
*
*
*
*
*---------------------------------------------------------------------------------------------------------*
*
*
* HISTORIAL DE CAMBIOS
*
*
*
* FECHA
DESCRIPCION
AUTOR MARCA CODIGO S.Desk
*
* ----------------- ------------------------- -------- ------------ ------------ ------------------- *
* dd/mm/aaaa
usuario
*
*
*
*
*
*
*
* dd/mm/aaaa
usuario
*
* ...
...
*
*----------------------------------------------------------------------------------------------------------*
Bloque 1 Las primeras lneas del programa se destinan al nombre del programa, ttulo, fecha de
creacin y autor.
Bloque 2 Descripcin de la funcionalidad del programa, lo ms detallada posible dejando claro el
objetivo.
Bloque 3 Relacin de los principales controles de autorizacin.
Bloque 4 Versiones, cdigo de la modificacin, fecha, motivo y descripcin de las modificaciones
realizadas en el programa.
2.1.1.3
Introduccin de comentarios
Todo programa debe incluir comentarios:
Utilizar la plantilla de codificacin de programas ABAP como ejemplo para los comentarios.
Los comentarios o documentacin se deben poner siempre por encima de las instrucciones.
En la plantilla de codificacin ABAP estn definidos todos los tipos de sentencias que se tiene
que documentar/explicar, para que el cdigo sea ms legible.
Pgina 8 de 84

Comunidad de Madrid
Describir la funcionalidad de cada una de las partes del cdigo con el objetivo de facilitar la
comprensin del mismo, principalmente, para el desarrollador que deba incluir en el futuro
modificaciones. Los comentarios deben ser claros y concisos, utilizando los trminos estndar de
SAP.
Eliminar partes del cdigo que no se quiere que estn activas en una versin del documento.
Identificar modificaciones o cambios realizados en las distintas versiones de los programas.
Son parte fundamental del entendimiento del cdigo por lo que habr que utilizarlos.
Los comentarios han de ser lo ms concisos posible, y orientados a mejorar la comprensin del
desarrollo.
No deben incluir nombres propios, ni comentarios graciosos o jocosos; hay que tener en cuenta
que los desarrollos se los queda el cliente.
No enmarcar los comentarios dentro de marcos hechos con caracteres muy vistosos o cargantes
a la vista; buscamos crear un cdigo fuente claro y agradable a la vista.
Los comentarios deben estar convenientemente sealizados:
Con un * en la primera columna si toda la lnea es comentario.
Con una (comilla doble) cuando se aade un comentario a continuacin del cdigo en una
lnea.
Para modificaciones que ocupen ms de una lnea se comentar de la siguiente manera:

o
La siguiente lnea nos indicara el inicio de la modificacin (*>)

*>USUARIO_SAP DD/MM/AA CDIGO_DE_LA MODIFICACIN
INSERT D030L-TYPE INTRO HEADER.
SELECT * FROM D030L WHERE
La siguiente lnea nos indicara el fin de la modificacin (*<)

*< USUARIO_SAP DD/MM/AA VERSIN_DESARROLLO
2.1.1.4
Modificaciones de programas
Al realizar modificaciones de programas que ya estn en productivo, en la mayora de los casos, estos
cambios debern estar soportados por versiones de diseos tcnicos. Slo se contemplan excepciones
en caso de tener que generar versiones intermedias de desarrollos para subida a entornos, en los que
estn contenidas unas modificaciones debidas a unos diseos y otras no. En este caso, se indicar
claramente qu modificaciones contiene la versin y cules excluye.
Ej.: En un desarrollo se ha generado una ltima versin en la que se est desarrollando una ampliacin
funcional aprobada por la Consejera y que se encuentra documentada en una versin del Diseo
Funcional. En paralelo y antes de completar este desarrollo/pruebas de aceptacin, se identifica una
incidencia en Produccin que hace necesario subir de forma inmediata una correccin de este desarrollo.
En este caso, se creara una nueva versin del desarrollo, en la que se incluyeran las correcciones para
Produccin, pero se extrajeran los cambios de la versin anterior de la ampliacin.
Pgina 9 de 84

Comunidad de Madrid
Para que todos estos cambios queden perfectamente documentados y evitar que se produzcan errores o
inconsistencias en la gestin de las versiones de los desarrollos, se seguirn las pautas que se indican
en los siguientes apartados.
2.1.1.4.1
En la cabecera
Se indicar en el apartado de HISTORIAL, para cada una de las versiones del desarrollo, el cdigo de la
modificacin, la referencia a su motivo/contenido del cambio (diseo tcnico con la versin del
documento), su autor (usuario SAP) y fecha de realizacin.
El cdigo de la modificacin, tendr el siguiente formato:
CCCCPPNN
CCCC Equipo de desarrollo del implantador que ha realizado la modificacin. Podrn existir diferentes
equipos que desarrollen por: mantenimiento, evolutivos de programas pertenecientes al proyecto actual
correspondiente a educacin u otros proyectos a futuro que puedan implementarse dentro del sistema.
EIP1
Equipo de implantacin 1
EMT1
Equipo de mantenimiento 1
PP Indicar el motivo de la modificacin del programa

CV
Cambio de versin
CO
Correccin del programa
LI
Tareas de limpieza del cdigo obsoleto
MF
Mejora de la funcionalidad del programa
AF
Ampliacin funcional
NN Se trata de un nmero secuencial que ser asignado a cada modificacin y que se utilizar en
todos los objetos que deban modificarse en conjunto.
*---------------------------------------------------------------------------------------------------------*
Pgina 10 de 84

Comunidad de Madrid
*
*
*
*
*
* FECHA
DESCRIPCION
AUTOR MARCA CODIGO S.Desk
*
* ----------------- ------------------------- -------- ------------ ------------ ------------------- *
* dd/mm/aaaa
usuario
*
*
*
*
*
*
*
* dd/mm/aaaa
usuario
*
* ...
...
*
*----------------------------------------------------------------------------------------------------------*
DD/MM/AAAA ser la fecha en la cual se comienza la modificacin del programa.
2.1.1.4.2
En el cdigo del programa (modificaciones en general)
Enmarcando cada uno de los fragmentos de cdigo modificados, se incluirn los comentarios:
* Inicio modificacin CCCCPPNN USUARIO SAP DD/MM/AA
* Fin modificacin CCCCPPNN USUARIO SAP DD/MM/AA
Dejar la ltima versin correcta y la versin inmediatamente anterior comentada. Aunque dejara siempre
los literales de * inicio de modificacin CCCCPPNN y * fin de modificacin CCCCPPNN de todas las
modificaciones que hubieran existido en el cdigo para mantener la coherencia con el historial de cambio
de la cabecera del programa.
De esta forma, puede resultar muy difcil de mantener si surge un cambio de funcionalidad radical
respecto a lo que esta planteado en el programa. Se puede producir una difcil lectura y actualizacin del
cdigo. En estos casos, en la cabecera se indicar el documento donde surge el cambio de funcionalidad
y se permitir no aadir los comentarios de * inicio de modificacin y * fin de modificacion en el resto del
cdigo.
2.1.1.4.3
En el cdigo del programa (aplicacin de notas OSS)
Debe utilizarse la transaccin SNOTE, lo cual facilita el control de SAP en futuros cambios de versin y/o
instalacin de parches, el propio SAP interpretar mediante la utilizacin de esta transaccin, que es la
implementacin de una nota OSS.
En caso de que la nota deba ser implementada manualmente, ser enmarcado cada uno de los
fragmentos de cdigo modificados, y se incluirn los comentarios:
* Inicio aplicacin nota OSS n nnnnn CCCCPPNN USUARIO SAP DD/MM/AA
* Fin aplicacin nota OSS n nnnnn CCCCPPNN USUARIO SAP DD/MM/AA
Dentro del bloque no se borrarn, en ningn caso, las sentencias de la versin original: se
comentarn con un asterisco (*) en la primera columna.
Las lneas que se eliminan se marcarn al final de la lnea con el comentario nnnnn - - - >
Las lneas que se aaden se marcarn al final de la lnea con el comentario nnnnn < - - -
Pgina 11 de 84

Comunidad de Madrid
Cuando se aplica una nota a travs de la transaccin SNOTE, no se podr incluir ese comentario, debido
a que SAP realiza automticamente el cambio y no deja modificar el cdigo del programa.
El consultor tcnico de los equipos tendr acceso al registro de los objetos para la implementacin de
notas OSS y as, disponer ms eficientemente del cdigo de registro. El administrador de sistemas
despus de haber aplicado la Nota OSS deber enviar un correo electrnico a CCSAP (AC&A) indicando
la nota que se ha aplicado en el sistema. Ver documento: NEXUS-Gestin de parches y notas OSS.doc.
2.1.1.5
Documentacin de excepciones a la normativa
Es necesario reflejar en comentarios dentro del cdigo fuente aquellos puntos en los que no es posible
cumplir la normativa de codificacin ABAP. Si adems la lnea en la que se produce el incumplimiento
reporta un error/warning en Code Inspector ser necesario utilizar el pragma (#EC) correspondiente.
El programador debe redactar la justificacin por la que no puede seguir la normativa. Esto se puede
realizar de dos formas:
De manera similar a la documentacin de las modificaciones. Es decir, se utilizar un bloque

especfico en la cabecera del programa llamado EXCEPCIONES A LA NORMATIVA en el que
se debe incluir el cdigo del chequeo que se incumple (si procede de Code Inspector), su
justificacin, autor, fecha y etiqueta identificativa que permite ubicar la excepcin en el punto del
cdigo en que se produce.
La etiqueta identificativa o marca del punto del cdigo tiene la siguiente codificacin:
CCCCENnn
CCCC Equipo de desarrollo del implantador que ha implementado el cdigo y justificado la
lnea.
EN Es un valor fijo que indica Excepcin a la normativa
NNSe trata de un nmero secuencial.
*----------------------------------------------------------------------------------------------------------*
*
*
* EXCEPCIONES A LA NORMATIVA
*
*
*
* FECHA
DESCRIPCION
AUTOR MARCA CODIGO
*
* ----------------- ------------------------- -------- ------------ -----------*
* dd/mm/aaaa
usuario
*
*
*
*
*
*
*
* dd/mm/aaaa
usuario
*
* ...
...
*
*----------------------------------------------------------------------------------------------------------*
El enmarcando de cada uno de los fragmentos de cdigo afectados por la excepcin se realizar
de forma similar a las modificaciones:
* Inicio Excepcin normativa CCCCENnn

* Fin Excepcin normativa CCCCENnn
Cuando una excepcin se aplica en varios puntos del cdigo no ser necesario repetir la lnea en
el bloque de cabecera utilizando la misma etiqueta identificativa en los diferentes enmarcados de
cdigo.
Pgina 12 de 84

Comunidad de Madrid
La justificacin se incluye como comentario en la lnea inmediatamente superior a la lnea del

incumplimiento.
La lnea o lneas de comentario relativas a la justificacin debern llevar la palabra reservada
"PRAGMA:" permitiendo identificar que el comentario se refiere al pragma.
Algunas lneas de ejemplo quedaran de la siguiente forma:
* Se recupera los valores a
* asignar a Modo de adquisicin
* PRAGMA: No se dispone de ningn campo clave de esta tabla.
SELECT * INTO CORRESPONDING FIELDS OF TABLE L_T_MOAD "#EC CI_NOFIELD
FROM ZFFIAA_T_MOAD
WHERE COD <> SPACE.
..
..
..
* Se busca el expediente
* administrativo en la tabla EKKO
* para la sociedad seleccionada
* PRAGMA: No se dispone de datos para los campos
* PRAGMA: clave de EKKO
SELECT SINGLE /IECI/EXP_ADM INTO L_EXP "#EC CI_NOFIELD
FROM EKKO
WHERE /IECI/EXP_ADM = P_EXP AND
BUKRS = G_S_VALORES-BUKRS.
Como se ve en el ejemplo anterior si la justificacin al pragma ocupa ms de una lnea sera

necesario repetir la etiqueta PRAGMA.
Pgina 13 de 84

Comunidad de Madrid
2.1.1.5.1.1
Declaracin de PRAGMA de forma reiterada
Ahora si se usa de forma reiterada un pragma con una misma justificacin se podr hacer referencia a la
marca declarada en la seccin EXCEPCIONES A LA NORMATIVA de la cabecera:
*-------------------------------------------------------------------------------------- *
**
* EXCEPCIONES A LA NORMATIVA *
**
* FECHA DESCRIPCION AUTOR MARCA CODIGO *
* ------- ----------------------------------- -------- ------------ ------------ *
* No se dispone de ningn campo clave GR01E01 *
* de esta tabla. * * No se dispone de datos para los campos GR01E02 *
* clave de EKKO *
**
*-------------------------------------------------------------------------------------- *
* PRAGMA: GR01E01
SELECT * INTO CORRESPONDING FIELDS OF TABLE L_T_MOAD "#EC CI_NOFIELD
FROM ZFFIAA_T_MOAD
WHERE COD <> SPACE.
* PRAGMA: GR01E02
SELECT SINGLE /IECI/EXP_ADM INTO L_EXP "#EC CI_NOFIELD
FROM EKKO
WHERE /IECI/EXP_ADM = P_EXP AND
BUKRS = G_S_VALORES-BUKRS.
2.1.2
SANGRADOS EN TODAS LAS SENTENCIAS
Sangrar el cdigo fuente es la forma ms fcil y cmoda de conseguir un cdigo fcilmente

legible.
Los sangrados se han de hacer de manera que resalten siempre las palabras clave, as como las
opciones de cada una.
Pgina 14 de 84

Comunidad de Madrid
2.1.3
Alinear verticalmente las opciones de palabras clave, los parmetros de un FORM o PERFORM,
las declaraciones de datos, etc.; de manera que el cdigo tenga un cierto orden vertical.
RESALTAR PALABRAS CLAVE
Usar siempre la funcin PRETTY PRINTER con la opcin de resaltar palabras clave en creacin de
desarrollos. Esta funcionalidad del editor de ABAP, es muy til y se puede usarla con asiduidad. No utilizar
en el caso de modificaciones sobre desarrollos.
2.1.4
UNA SENTENCIA EN CADA LNEA
Una sentencia ABAP por lnea de cdigo lo hace infinitamente ms legible.

Forma errnea:
DATA: g_contador TYPE 1, g_fecha TYPE datos.
g_fecha= sy-datos.
DO.
ADD 1 TO g_contador. ADD 1 TO g_fecha.
IF g_contador > 10. EXIT. ENDIF. IF g_fecha >
20110101. EXIT. ENDIF.
WRITE: / g_contador. g_fecha. ULINE.
ENDDO.
Forma correcta:
DATA: g_contador TYPE 1,
g_fecha TYPE datos.
g_fecha= sy-datos.
DO.
ADD 1 TO g_contador.
ADD 1 TO g_fecha.
IF g_contador > 10.
EXIT.
ENDIF.
IF g_fecha > 20110101
EXIT.
ENDIF.
WRITE: / g_contador. g_fecha.
ULINE.
ENDDO
Pgina 15 de 84

Comunidad de Madrid
2.1.5
USAR LNEAS EN BLANCO PARA SEPARAR SENTENCIAS O GRUPOS DE SENTENCIAS
Si no usamos lneas en blanco entre grupos de sentencias, apelmazamos el cdigo y por lo tanto lo
hacemos difcil de leer.
Tambin se pueden utilizar los comentarios como modo de separacin. No olvidemos que su uso est
recomendado.
Pgina 16 de 84

Comunidad de Madrid
Estilo de programacin
3.1
Nomenclatura de los objetos
El nombre de un objeto debe darnos informacin acerca de a qu clase de desarrollo o mdulo pertenece,
cul es su cometido, su tipo, etc.
En general se seguirn las siguientes normas a la hora de nombrar los objetos:
La clase de desarrollo debe especificar el mdulo de SAP al que hace referencia, siendo
recomendable indicar tambin el submdulo. Este conocimiento vendr reflejado en la
especificacin funcional correspondiente.
Los nombres de los objetos que se vayan a crear, han de comenzar con el mismo nombre que la
clase de desarrollo a la que pertenecen, a no ser que el responsable tcnico diga lo contrario, o
imposibilidades de longitud de nombres lo impidan.
Hay que respetar las normas de nomenclatura de SAP, pero intentando que se adapten al punto
anterior.
Utilizar los guiones bajos _ para los nombres de los objetos. Aportan claridad. No extenderse
gratuitamente.
Ante cualquier duda, ser el responsable tcnico del proyecto quien marque las pautas a seguir.
El nombre del objeto lo establecer el responsable que realice el diseo tcnico conceptual
(DO06).
Slo se registrarn los nombre tcnicos de objetos que el responsable del documento considere
relevantes para el desarrollo y que el programador debe respetar, con el fin de evitar la posible
duplicidad de nombres entre distintos documentos. Se consideran relevantes los indicados en la
tabla posterior.
Los nombres de objetos que el responsable tcnico no considere relevantes, quedarn a criterio
del programador, siguiendo las normas de codificacin y no ser necesario su registro.
Como norma general, en caso de objetos compuestos por otros objetos, solo se registrar el
nombre del objeto principal y no de sus componentes. Por ejemplo, en el caso de un module pool
solo se registrar el module pool principal y no sus includes debido a que se forman a partir del
nombre del programa principal.
Los objetos que gener automticamente el sistema quedarn excluidos del registro y de la
normativa de nomenclatura, al igual que los objetos importados desde otros sistemas (parches,
rdenes de transporte, fusin de sistemas).
Se crear una aplicacin propia para el registro de los objetos que residira en el sistema ERP de
desarrollo. La aplicacin tendr las siguientes caractersticas:
Chequeo de la duplicidad de nombres y tipos de objeto.
Posibilidad de incluir varios objetos al mismo tiempo.
La longitud del nombre de los objetos se adecua a la permitida por SAP.
Los objetos relevantes que se registrarn se indican en la tabla de nomenclatura posterior.
El responsable tcnico introducir el tipo de objeto y el nombre del mismo. Durante la grabacin
del registro, se chequear la nomenclatura del objeto de acuerdo con las reglas de nombres
permitidos y tambin, realizar el chequeo de la longitud del nombre del objeto por tipo de objeto.
El nombre ser dado por el responsable tcnico y no ser la aplicacin quin lo proponga. Pero
si se verificar que el nombre sea univoco.
El objeto ir asociado al proyecto y rea funcional correspondiente segn la normativa fijada.

Pgina 17 de 84

Comunidad de Madrid
3.2
Convencin en la nomenclatura de objetos
ZPAAAATxxxxxxxxxxxxxxxxxxxx
Z- Para todos los objetos.
P- Identificador del Proyecto: F - Nexus02, R - Nexus03.
AAAA Funcionalidad (mdulo SAP). Ver el Anexo1 y Anexo2 de este documento
T Tipo de programa:
W workflow.
R report.
I Interface.
C - Conversin de datos.
E User Exit.
D BADI.
P BAPI.
F Formulario.
x Texto libre
3.2.1
CUADRO RESUMEN DE NOMENCLATURA DE OBJETOS
OBJETO
BASE DE
DATOS
LGICA
BATCH Y
BATCH INPUT
Long.
Max.
12
Nomenclatura
Comentarios
NO
XXX
ZPAAAAexxxxxx
Reserva
cdigo
e - (P) pruebas - (R)

real
NO
Pgina 18 de 84

Comunidad de Madrid
OBJETO
CLASE DE
DESARROLLO
TRANSACCIO
NES
OBJETO DE
Long.
Max.
Nomenclatura
Comentarios
Reserva
cdigo
30
ZPAAAAxxxxxxxxxxx..xxxx
20
ZPAAAAxxxxxxxxxxxxxxx
S
Para nombrar los
objetos de bloqueo se
usa normalmente los
primeros dos
caracteres EZ o EY.
NO
16
EZPAAAAxxxxxx.xxxx
30
ZPAAAAxxxxxx.xxxxx
NO
30
ZPAAAAxxxxxxxxx
NO
ZPxx
NO
MATCHCODE
ID
0-9
NO
ESTRUCTURA
DICCIONARIO
30
ZPAAAAxxxxxxxxxxx
NO
REA DE
MENSAJES
20
ZPAAAAxxxxx.xxxxx
000-999
40
ZPAAATxxxxx..xxxxxxx
BLOQUEO
DOMINIO
ELEMENTO
DE DATOS
MATCHCODE
OBJETOS
NMERO DE
MENSAJE
NO
PROGRAMA
EJECUTABLE
(Para
ejecutables
on-line)
PROGRAMA
MODULE
POOL
(Se llama a
travs de una
transaccin)
40
SAPMZPAAAAxxxxxx..xxxxx
Includes del modulo:
MZPAAAAxxx.xxxxTOP Datos global
MZPAAAAxxx.xxxxONN Modulo
PBO
MZPAAAAxxx.xxxxINN Modulo PAI
MZPAAAAxxx.xxxxFNN - Subrutinas
Solo se
reservar el
cdigo para el
module pool
principal, no
para los
includes del
modulo
Pgina 19 de 84

Comunidad de Madrid
OBJETO
Long.
Max.
PROGRAMAS
DE INFOTIPOS
MP9NNN00
GRUPO
FUNCIN
26
ZPAAAAxxxxxx..xxxxx
NO
MDULO DE
FUNCIONES
30
Z_PAAAAxxxxx..xxxxx
NO
16
ZPAAAAxxxxxxxxx
SI
10
ZPxxxxxxxx
NO
10
ZPxxxxxxxx
NO
Zxx
NO
NOMBRES DE
TIPO
30
ZPAAAAxxxxxx.xxxxxxxxxxx
NO
SAPSCRIPTS/
SMARTFORMS
16 / 30
TABLA
TRANSPAREN
Nomenclatura
Comentarios
Reserva
cdigo
TE
TABLAS
POOL
TABLAS
CLSTER
NDICES DE
TABLAS
ZPAAAAxxxxxxxxxxxx
PROYECTOS
DE
AMPLIACIN
ZPAAAAxxx
ZPAAAAxxxxx
NO
Xxx
NO
Xxx
NO
OBJETO DE
AUTORIZACI
N
TTULO
BARRA
SPA/GPA
PARMETRO
VARIANTES
10
14
xxxxxxxxxxxxxxx (va asociado el report)

CUS&_PAAAAxxx
Para crear una

variante que pueda
ser transportada
simplemente
debemos crearla con
un nombre que
empiece por CUS&
NO
Pgina 20 de 84

Comunidad de Madrid
OBJETO
Long.
Max.
Nomenclatura
Comentarios
Reserva
cdigo
ESTRUCTURA
S APPEND
30
ZPAAAAxxxxxxxxx (Nombre de la
tabla que contiene la estructura
APPEND)
NO
NOMBRES DE
LOS CAMPOS
DE
ESTRUCTURA
S APPEND
30
ZZPxxxxxx.xxxx
NO
10
Pendiente
*este tema lleva el

equipo de seguridad
NO
30
Pendiente
*este tema lleva el

equipo de seguridad
NO
PERFIL DE
AUTORIZACI
N
ROL DE
AUTORIZACI
N
VISTAS
(VIEWS)
AYUDA DE
BSQUEDA
HELP VISTAS
(VIEWS)
16
ZPAAAAxxxxxxxxxxxxxxxxxxxxxx
NO
16
ZPAAAAVHxxxxxxxx (tambien puede ser

lo anterior)
NO
10
TIPOS DE
DISPOSITIVOS
IMPRESIN
ZPWXXXXXX
ZPIxxxxx
ZPFxxxxx
FORMATO DE
PGINA DE
IMPRESIN
30
TIPO DE
OBJETO
WORKFLOW
ZPAAAAVVxxxxxxxxx
Los valores de la VV, sern los
siguientes:
V_ -> Vista BBDD
VA -> Vista de actualizacion
VS -> Vista de supresin
VH -> Vista de ayuda
NO
NO
NO
Pgina 21 de 84

Comunidad de Madrid
OBJETO
AMPLIACIN
PARA
INFOTI
POS
Long.
Max.
Nomenclatura
Comentarios
Reserva
cdigo
NO
ZPNNNN00
EXCEPCIONES A
LA NORMA:
GENERACIN
CLASE
AUTOMTIC
A POR
SAP DEL
NOMBRE
EN LAS
SIGUIENTE
S CLASES
DE
IMPLEMENT
ACIN:
ZPCLAAAAXXXXXXXX
SI
BADI:
ZCL_IM_P
AAAAXXX.
..XXXX
EXCEPCIN:
ZCX_PAA
AAXXXXXX
X
INTERFASE
ZPIFAAAAXXXXXXXX
SI
GRUPO TIPOS
ZPXXX
NO
3.3
Aspecto del cdigo fuente
Hay que hacer lo posible por escribir un cdigo fuente fcil de leer, claro y conciso. Para ello, se han de
seguir las siguientes pautas:
3.3.1
ESTRUCTURA DEL CDIGO FUENTE
El cdigo se estructura en estos cuatro grandes

bloques, que adems deben seguir el orden que se
indica:
1.
Declaraciones globales de variables y tipos.

Pgina 22 de 84

Comunidad de Madrid
2.
Pantalla de seleccin (en el caso de programas tipo Report)
3.
Proceso
4.
Subrutinas y mdulos
3.3.2
USO DE COMENTARIOS
Los comentarios han de ser lo ms concisos posibles, y orientados a mejorar la compresin del
desarrollo
No deben incluir nombres propios, ni comentarios graciosos o jocosos; hay que tener en cuenta
que los desarrollos se los queda el cliente
No enmarcar los comentarios dentro de marcos hechos con caracteres muy vistosos o cargantes
a la vista; buscamos crear un cdigo fuente claro y agradable a la vista.
Pgina 23 de 84

Comunidad de Madrid
SANGRADOS EN TODAS LAS SENTENCIAS
Sangrar el cdigo fuente es la forma ms fcil y

cmoda de conseguir un cdigo fcilmente
legible.
Los sangrados se han de hacer de manera que

resalten siempre las palabras clave, as como
las opciones de cada una.
Alinear verticalmente las opciones de palabras

clave, los parmetros de un FORM o
PERFORM, las declaraciones de datos de
manera que el cdigo tenga un cierto orden
vertical
3.3.3
USAR SIEMPRE LA FUNCIN PRETTY

PRINTER CON LA OPCIN DE RESALTAR
PALABRAS CLAVES
Esta herramienta del editor de ABAP, es muy til y se usar con asiduidad.
3.3.4
UNA SENTENCIA EN CADA LNEA
Una sentencia ABAP en cada lnea de cdigo lo hace infinitamente ms legible.
Pgina 24 de 84

Comunidad de Madrid
3.3.5
USAR LNEAS EN BLANCO PARA SEPARAR SENTENCIAS GRUPO DE SENTENCIAS
Si no se usan lneas en blanco entre grupos de sentencias, apelmazamos el cdigo y por tanto, se hace
difcil de leer.
3.3.6
LIMI
TACI
N
DEL
N
DE
LNEAS EN CADA BLOQUE DE PROCESO
(MODULARIZACIN)
Muchas lneas de cdigo dentro de una rutina, evento hace que un programa se vuelve muy complejo,
difcil de seguir y entender. Para evitar esto, hay que intentar cumplir siempre estos puntos:
Cada bloque de proceso (Evento de programa, FORM, mtodo de una clase, mdulo de
funcin) no deber tener tantas lneas de cdigo que haga difcil su lectura y comprensin.
Cada bloque de proceso tendr un mximo de lneas, que se pueden establecer en base a lo
siguiente:
3.4
100 lneas por bloque.
Las lneas que quepan en 3 avances de pgina.
Esta limitacin implica el uso de la modularizacin del cdigo, prctica que hay que llevar a cabo
continuamente, as como aprovechar esta modularizacin para reutilizar cdigo ya escrito.
Declaracin de tipos, variables y constantes
Las sentencias declarativas, se han de ejecutar todas juntas y al principio de cada programa, subrutina,
evento, etc., de manera que no existan declaraciones entre sentencias ejecutables.
Las declaraciones seguirn este orden:
1.
Tipos
2.
Tipos de tabla interna
3.
Tablas internas
4.
reas de trabajo de las tablas internas (Work Areas)
5.
Variables
6.
Constantes
Dentro de los programas; los tipos de datos, variables y constantes, pueden ser globales y locales.
Pgina 25 de 84

Comunidad de Madrid
3.4.1
CUADRO RESUMEN DE DECLARACIONES
Como norma general, todos la declaraciones globales empezarn por G_ y todas las
declaraciones locales empezarn por L_.
Comenzaran por:
Declaraciones
SO_
PG_
G_
L_
R_
GD_
SL_
G_O_
L_O_
G_CL_
L_CL_
SELECT-OPTIONS
PARAMETERS
Variables globales
Variables locales
Rango
Campos de Dynpro
Datos estticos
Objeto global
Objeto local
Clase Global
Clase local
3.4.2
3.4.2.1
DECLARACIN GLOBALES
Tipos
Como norma general han de comenzar siempre con GTYPE_, para indicar que son globales al
programa.
Si lo que se est declarando es un tipo de tabla interna, entonces dependiendo del tipo de tabla interna,
ha de comenzar siempre por:
3.4.2.2
TIPO DE TABLA
NOMENCLATURA
STANDARD
GTYPE_T_
SORTED
GTYPE_TS_
HASHED
GTYPE_TH_
Variables, tablas internas, work areas y constantes
Como normal general han de comenzar siempre con G_, para indicar que son globales al programa.
Si lo que se esta declarando es una tabla interna, entonces dependiendo del tipo de tabla interna ha de
comenzar siempre por:
TIPO DE TABLA
NOMENCLATURA
STANDARD
G_T_
SORTED
G_TS_
HASHED
G_TH_
RANGES
G_R_
Las variables que se utilicen como work areas de las tablas internas se han de identificar con las letras
WA seguido del nombre de la tabla interna de la que son work area:
Pgina 26 de 84

Comunidad de Madrid
NOMBRE DE TABLA
NOMENCLATURA
G_T_TAB1
G_WA_T_TAB1
G_TS_TAB2
G_WA_TS_TAB2
G_TH_TAB3
G_WA_TH_TAB3
G_R_RANGGO1
G_WA_R_RANGO1
Si lo que se est declarando es una constante, entonces esta ha de comenzar por GC_.
De esta manera, desde cualquier punto del programa sabremos que estamos usando una variable global.
*&------------------------------------------------------*
*&
Report ZPTAAANNNNNxxxxx
*&------------------------------------------------------*
*
text
*-------------------------------------------------------*
REPORT ZPTAAANNNNNxxxxx .
* 1. Tipos Globales
*-----------------TYPES: BEGIN OF gtype_persona,
pernr
TYPE pernr_d,
nombre
TYPE pad_vorna,
apellido_1
TYPE pad_nachn,
apellido_2
TYPE pad_nach2,
END OF gtype_persona,
gtype_contador
TYPE i.
* 2. Tipos de tabla interna globales

*----------------------------------TYPES: gtype_ts_persona
TYPE SORTED TABLE OF gtype_persona
WITH UNIQUE KEY pernr,
gtype_t_paises
TYPE STANDARD TABLE OF t005.
* 3. Tablas internas globales
*---------------------------DATA: g_ts_persona
TYPE gtype_ts_persona,
g_t_paises
TYPE gtype_t_paises.
*4. reas de trabajo globales de las tablas internas (Work Areas)

*---------------------------------------------------------------DATA: g_wa_ts_persona
TYPE gtype_persona,
g_wa_t_paises
TYPE t005.
* 5. Variables globales
*---------------------DATA: g_contador
TYPE i,
g_salir_del_programa
TYPE flag.
* 6. Constantes globales
*----------------------CONSTANTS: gc_marcado
TYPE c VALUE 'X',
gc_desmarcado
TYPE c VALUE ' '.
Pgina 27 de 84

Comunidad de Madrid
3.4.3
3.4.3.1
DECLARACIN LOCALES
Tipos
Como norma general han de comenzar siempre con la letra LTYPE_, para indicar que son locales a una
subrutina, mtodo
Si lo que se est declarando es un tipo de tabla interna, entonces, dependiendo del tipo de tabla interna
ha de comenzar siempre por:
3.4.3.2
TIPO DE TABLA
NOMENCLATURA
STANDARD
LTYPE_T_
SORTED
LTYPE_TS_
HASHED
LTYPE_TH_
Variables, tablas internas, work areas y constantes
Como norma general han de comenzar siempre con L_, para indicar que son para indicar que son
locales a una subrutina, mtodo
Si lo que se est declarando es una tabla interna, entonces dependiendo del tipo de tabla interna ha de
comenzar siempre por:
TIPO DE TABLA
NOMENCLATURA
STANDARD
L_T_
SORTED
L_TS_
HASHED
L_TH_
Las variables que utilicemos como work area de las tablas internas se han de identificar con las letras
WA seguido del nombre de la tabla interna de la que son work area:
NOMBRE DE TABLA
NOMENCLATURA
G/L_T_TAB1
L_WA_T_TAB1
G/L_TS_TAB2
L_WA_TS_TAB2
G/L_TH_TAB3
L_WA_TH_TAB3
Si lo que se est declarando es una constante, entonces sta ha de comenzar por LC_.
Pgina 28 de 84

Comunidad de Madrid
*&---------------------------------------------------------------------*
*&
Form Rutina
*&---------------------------------------------------------------------*
*
text
*----------------------------------------------------------------------*
FORM rutina.
* 1. Tipos locales
*----------------TYPES: BEGIN OF ltype_direccion,
direccion
TYPE pad_stras,
poblacion
TYPE pad_ort01,
codigo_postal
TYPE pstlz_hr,
END OF ltype_direccion,
ltype_flag
TYPE c.
* 2. Tipos de tabla interna locales

*---------------------------------TYPES: ltype_t_direccion
TYPE STANDARD TABLE OF ltype_direccion.
* 3. Tablas internas locales
*--------------------------DATA: l_ts_persona
TYPE gtype_ts_persona,
l_t_paises
TYPE gtype_t_paises.
*4. reas de trabajo locales de las tablas internas (Work Areas)
*--------------------------------------------------------------DATA: l_wa_ts_persona
TYPE gtype_persona,
l_wat_direccion
TYPE ltype_direccion.
* 5. Variables locales
*--------------------DATA: l_contador
TYPE i,
l_salir
TYPE ltype_flag.
3.4.3.3
* 6. Constantes locales
*---------------------CONSTANTS: lc_respuesta_si TYPE c VALUE 'S',
lc_respuesta_no TYPE c VALUE 'N'.
ENDFORM.
" Rutina
D
a
t
o
s estticos
Los datos definidos como estticos con la sentencia STATICS slo se declaran dentro de las subrutinas,
por la tanto son datos locales.
Los nombres de estos datos comenzarn siempre por SL_, adaptndose el resto del nombre a las
normas anteriores.
Pgina 29 de 84

Comunidad de Madrid
3.5
Pantalla de seleccin y dynpros
Las pantallas de seleccin, y los dynpros en general, se han de hacer lo ms agradables posibles de cara
al usuario final, sin perder nunca de vista que hay que adaptarse al aspecto estndar de SAP, de manera
que el usuario no perciba diferencia alguna entre las pantallas desarrolladas y las del estndar.
3.5.1
3.5.2
NOMENCLATURA
PARAMETERS.
o
Los parmetros de un programa (PARAMETERS) se comportan como variables

globales dentro de un programa.
Los nombres de los parmetros debern de comenzar por PG_.
SELECT-OPTIONS.
o
Los select-options de un programa se comportan como tablas internas globales dentro

de un programa.
Los nombres debern comenzar por SO_.
Campos de Dynpro.
o
Los campos de los dynpros han de ser globales (restriccin del sistema).
Siempre que se pueda, han de hacer referencia a campos del diccionario de datos, para
que adopten sus caractersticas. Para esto, se han de llamar igual que en el Diccionario.
Pero hay otros campos que no hacen referencia al diccionario; en estos casos como los
campos son globales, debern comenzar siempre por GD_ para indicar que son
campos globales y de Dynpro.
ASPECTO
El aspecto de las pantallas es fundamental de cara a la sensacin de calidad que se ha de transmitir al

usuario. No basta con que el desarrolle funcione, que eso se da por supuesto, hay que hacerlo agradable
a la vista y fcil de manejar.
Para ello, intentaremos cumplir lo siguiente:
Usar marcos (con ttulos) para agrupar campos relacionados
Alinear verticalmente los campos de la pantalla de manera que los campos de texto queden
debajo de campos de texto, los campos de entrada debajo de campos de entrada, etc
Usar iconos representativos que aporten algo de color, sobre todo en los pulsadores.
Iconos
Alineacin
Vertical de
campos
del mismo
tipo
Alineacin
Vertical de
campos del
mismo tipo
Iconos
Ttulos
Marcos
Ttulos
Marcos
Pgina 30 de 84

Comunidad de Madrid
3.6
Parmetros en las subrutinas
Siempre que sea posible se ha de indicar el tipo de parmetro en la interfase del FORM.
3.6.1
NOMENCLATURA
Los parmetros de las subrutinas se llamarn siempre P_ en el caso de parmetros normales y PT en

el caso de tablas internas. En este ltimo caso, se indicarn el tipo de tabla interna segn lo visto en el
apartado de nomenclatura de tablas internas.
3.6.2
PARMETROS CON TABLES, USING Y CHANGING
Vamos a establecer lo siguiente:
A travs de TABLES pasaremos a la subrutina las tablas internas (de tipo estndar) que son de
entrada/salida.
Los parmetros USING sern los parmetros de entrada al FORM (se puede usar el aadido
VALUE.
Los parmetros CHANGING sern los parmetros de salida o de entrada/salida.
*&---------------------------------------------------------------------*
*&
Form subrutina
*&---------------------------------------------------------------------*
*
text
*----------------------------------------------------------------------*
FORM subrutina TABLES pt_paises
STRUCTURE t005
USING pts_persona
TYPE
gtype_ts_persona
p_marcado
TYPE
c
CHANGING p_contador
TYPE
i
p_salir
TYPE
flag.
DATA: l_wa_ts_persona TYPE
gtype_persona.
CHECK NOT p_marcado IS INITIAL.

LOOP AT pts_persona INTO l_wa_ts_persona.
ADD 1 TO p_contador.
ENDLOOP.
IF p_contador IS INITIAL.
p_salir = 'X'.
ENDIF.
ENDFORM.
" subrutina
3.7
Cl
ases e interfaces
El nombre de las clases ha de seguir la siguiente norma: ZPCLAAAAxxxxxxx.
Pgina 31 de 84

Comunidad de Madrid
El nombre de las interfaces ha de seguir la siguiente norma: ZPIFAAAAxxxxxxx.
Excepciones a la norma:
Generacin automtica por SAP del nombre en las siguientes clases de implementacin:
BADI
o
Excepcin
o
3.7.1
ZCL_IM_PAAAAxxx...xxxx
ZCX_PAAAAxxxxxxx
PARMETROS
Los parmetros de las clases o interfaces se nombrarn de la siguiente manera:
IMPORT: Comenzarn por I_

EXPORT: Comenzarn por E_
CHANGING: Comenzarn por C_
RETURNING: Comenzarn por R_
3.8
Mdulos de funcin
3.8.1
NOMENCLATURA
El nombre de los mdulos de funciones ha de seguir las mismas normas que el resto de objetos; ha de
comenzar por el nombre de la clase de desarrollo a la que pertenecen. Pero en este caso, si la clase de
desarrollo comienza por Z o por Y, puede ser que el sistema de un mensaje diciendo que se incurre en
el rea de nombres de SAP. Por ello nombraremos a los mdulos de funcin con la clase de desarrollo
pero separando la Z o la Y del resto del nombre con un guin bajo: Z_
Clase de Desarrollo
: ZPAAAAxxxxxxxxxxx..xxxx
Mdulo de funciones
: Z_PAAAAxxxxx..xxxxx
3.8.2
PARMETROS
Los parmetros de los mdulos de funcin se nombrarn de la siguiente manera:
IMPORT
: Comenzarn por I_
EXPORT
: Comenzarn por E_
TABLES
: Comenzarn por T_
Pgina 32 de 84

Comunidad de Madrid
En cada uno de los casos, si los parmetros son tablas internas se han de adaptar los nombres, segn lo
visto en el apartado de nomenclatura de tablas internas.
3.8.3
PROGRAMACIN
No se han de escribir ms de 20 o 30 lneas dentro de la funcin. En caso necesario se usarn llamadas a

subrutinas.
FUNCTION Z_PAAAxxxxx..xxxxx
*"---------------------------------------------------------------------*"*"Interfase local
*" IMPORTING
*"
REFERENCE(I_IMPORTE)
TYPE ZHRX_TOOLS_IMPORTE_CHAR
*"
REFERENCE(I_MONEDA)
TYPE WAERS
*"
REFERENCE(I_SEPARADOR)
TYPE CHAR1 DEFAULT '.'
*"
REFERENCE(I_LIMPIAR_IMPORTE) TYPE CHAR1 DEFAULT 'X'
*" EXPORTING
*"
REFERENCE(E_IMPORTE)
TYPE ZHRX_TOOLS_IMPORTE_CHAR
*"
REFERENCE(E_DECIMALES_MONEDA) TYPE CURRDEC
*" TABLES
*"
T_MONEDAS
STRUCTURE TCURT
*" EXCEPTIONS
*"
MONEDA_INCORRECTA
*"
FORMATO_INCORRECTO
*"---------------------------------------------------------------------PERFORM importe_dec_moneda TABLES t_monedas
USING i_importe
i_moneda
i_limpiar_importe
i_separador_decimal_salida
CHANGING e_importe
e_decimales_moneda.
ENDFUNCTION.
3.9
Literales en programas
No utilizar textos literales en programas, en vez de ello se han de usar los elementos de texto del
programa.
SAP es un sistema multi-lenguaje, esto quiere decir que todos los textos del sistema son susceptibles de
poder traducirse a cualquiera de los idiomas soportados. Si en los programas se escriben textos de forma
literal, ya no es posible el proceso de traduccin.
Esto es especialmente preocupante en clientes, como las administraciones pblicas que pueden tener
dos idiomas oficiales.
Pgina 33 de 84

Comunidad de Madrid
3.10
E
xcepciones
Cuando se usan mdulos de funciones o eventos, siempre se han de recoger las excepciones, aunque no
se traten con posterioridad.
En los mdulos de funcin, basta con quitar los comentarios del bloque EXCEPTIONS, de otro modo si el
mdulo de funcin devuelve una excepcin y este bloque est comentado se produce un DUMP.
Pgina 34 de 84

Comunidad de Madrid
4
4.1
Normas de desarrollo
Controlar cdigo de retorno (sy-subrc)
MUY IMPORTANTE: Verificar siempre el cdigo de retorno (SY-SUBRC) en las sentencias que lo
devuelvan. En especial en los accesos a base de datos y manejo de tablas internas.
4.2
Limpiar variables
Antes de usar una variable hay que asegurarse que no tiene contenido, de esta manera nos
aseguraremos de no usar valores incorrectos.
Esto es especialmente importante dentro de bucles, en acceso a base de datos y en la bsqueda de
datos en tablas internas, as como en el uso de variables globales.
4.3
V
ariables globales
MUY IMPORTANTE: Minimizar el uso de variables globales.
Las variables globales hacen muy difcil de leer el cdigo fuente, a la vez que pueden proporcionar errores
insospechados si se usan en distintas partes del programa.
Como norma, siempre que sea posible, no se han de usar variables globales, siempre han de ser locales
a las subrutinas (FORMs, eventos) en las que se usan, y se han de pasar por parmetro a otras
subrutinas.
4.4
Tablas internas
Hay que evitar declarar las tablas internas con lneas de cabecera; en vez de ello se han de utilizar reas
de trabajo (work areas)
SAP, poco a poco, est eliminando las tablas internas con lneas de cabecera. De hecho, en la
programacin orientada a objetos ya no se permite.
Pgina 35 de 84

Comunidad de Madrid
4.5
Liberar memoria
MUY IMPORTANTE: Hay que usar la menor cantidad de memoria posible.

Cuando se haya terminado de utilizar una tabla interna hay que liberar su espacio en memoria (sentencia
FREE).
Si se usan las sentencias IMPORT/EXPORT FROM/TO MEMORY, una vez realizados los IMPORTs
necesarios se ha de liberar la memoria (sentencia FREE MEMORY).
La memoria es un recurso compartido, y si una aplicacin utiliza ms de la normal, se la estar quitando a
otra, con lo que el rendimiento general del sistema se ver afectado.
Pgina 36 de 84

Comunidad de Madrid
Normativa de usuarios de OSS
La solicitud de los usuarios administradores para el portal de SAP Service Marketplace se

realizar siguiendo el flujo de solicitud aprobado.
Pgina 37 de 84

Comunidad de Madrid
6
6.1
Conceptos importantes
Clases de desarrollo / Paquetes
Es muy importante tener en cuenta que una Clase de Desarrollo o Paquete sirve para organizar los
objetos, de manera que luego resulte fcil identificarlos para algn fin posterior (p.e. el transporte de todo
un mdulo a otro sistema)
La creacin de una clase de desarrollo o paquete es responsabilidad del consultor tcnico.
Todos los objetos han de estar asignados de una Clase

de Desarrollo, salvo aquellos que no se van a transportar
nunca a otros sistemas. Nunca se debe crear un objeto en
la clase de desarrollo local y con idea de reasignarlo a
otra clase ms tarde. Esto puede traer muchos problemas.
Los Consultores Tcnicos han de tener controlados los

objetos de los que son responsables, en que rdenes se
encuentran, y en que estado estn.
Sentido de
Utilizacin
de Objetos
Jerarquas de Clases de Desarrollo

Nivel 4
A121
1
Nivel 3
A121
B111
A12
B11
Nivel 2
A11
Nivel 1
Nivel 0
A1
B1
C1
Clases de Desarrollo Estndar de SAP
Las clases de desarrollo se suelen identificar con

aplicaciones, que pueden, y en algunos casos deben, ser
independientes unas de otras. Por esta razn, los paquetes o clases de desarrollo necesitan una gestin,
y los objetos que contienen han de cumplir unas normas bsicas de organizacin.
Esta gestin no es tan rgida en los sistemas cliente como en los sistemas centrales, ya que en los
sistemas centrales es dnde se mantienen aplicaciones multi-cliente, y stas deben de organizarse de
manera que su desarrollo y traspaso a otros sistemas no de problemas.
En los sistemas centrales, siempre que sea posible, seguiremos las siguientes normas:
Las clases de desarrollo se deberan organizar jerrquicamente y en niveles.
Los objetos pertenecientes a una clase de desarrollo, slo pueden utilizar o hacer referencia a objetos de
la propia clases de desarrollo, de clases de niveles inferiores (pero dentro de su propia jerarqua), o del
estndar de SAP.
De esta manera conseguiremos clases o paquetes estancos, o relacionados con otros de nivel inferior,
pero que son conocidos.
Cada clase de desarrollo, debera de tener su propia orden de transporte.

De forma que para transportar una aplicacin (que pertenece a una clase de desarrollo) a otro sistema,
habr que transportar antes las clases de desarrollo de nivel inferior, cosa que no es problema al tener
cada una su propia orden de transporte.
Pgina 38 de 84

Comunidad de Madrid
6.2
Concepto de Transaccin Unidad Lgica de Trabajo (L.U.W)
Por su importancia y desconocimiento general, es necesario hacer hincapi en este punto.

A la hora de realizar desarrollos, es muy importante seguir una serie de recomendaciones que garanticen
el concepto de transaccin (principio de transaccionalidad) o Unidad Lgica de Trabajo (L.U.W.).
Bsicamente estas normas son las siguientes:
En cada aplicacin/desarrollo/programa, los datos que se van a actualizar en la base de

datos (grabar, modificar, borrar) se han de tratar como una unidad, o se actualizan todos de
forma correcta, o no se actualiza ninguno (concepto de transaccin).
Para poder hacer esto en un sistema SAP, deberemos construir las aplicaciones de manera que
estn divididas en dos partes lgicas, que se han de ejecutar de forma secuencial:
1.
Interaccin con el usuario

o En esta parte se muestran y se piden al usuario datos necesarios.
o Se realizan las validaciones de los datos introducidos por el usuario o recuperados por
el proceso.
o Se emiten los mensajes informativos o de error y se solicitan las acciones
pertinentes.
2.
Actualizacin de datos.
o En esta parte ya no se emiten mensajes ni se solicitan acciones al usuario. Eso ya se
debi de haber hecho en la fase anterior.
o En esta parte solo se realiza la actualizacin de datos en base de datos y se termina
la aplicacin.
o En caso se fallo en la actualizacin de los datos, se ejecutarn los mecanismos de
rollback adecuados (Sentencia ROLLBACK WORK, mensajes tipo A o X, etc) y se
terminar la aplicacin.
Una transaccin termina correctamente siempre que no se haya emitido ningn mensaje de
cancelacin que produzca rollback (mensajes de Tipo A o X).
Hay que tener en cuenta que si una transaccin termina correctamente, automticamente el
sistema ejecuta un Commit Work, con todo lo que ello conlleva (actualizacin de los datos,
ejecucin de funciones in update-task, perform on commit, etc).
Si una transaccin no termina bien, se ejecutarn los mecanismos de rollback y los datos no
sern actualizados en base de datos.
Pgina 39 de 84

Comunidad de Madrid
La razn por la cual hay que programar de esta manera, tiene que ver con la arquitectura de un sistema SAP.
ARQUITECTURA GENERAL (Fig. 1)

Usuarios
-
Servidores
de
Aplicacin
Servidor
de Base
de datos
SAPGUI
DISPACHER
Los sistemas SAP usan arquitecturas Cliente/Servidor, en concreto un sistema SAP tpico bsicamente tiene esta estructura:
ARQUITECTURA DETALLADA. SERVIDOR DE APLICACIN (Fig.2)

USUARIOS - SAPGUI
SERVIDOR DE APLICACIN
Usuario 1 Peticin 1
Usuario 1 Peticin 2
Usuario 2 Peticin 1
Proceso Trabajo 1
SERVIDOR BASE DE DATOS

DB Link 1
Proceso Trabajo 2
Proceso Trabajo 3
DB Link 3 (roto)
Usuario n Peticin n
Proceso Trabajo n
DB Link n
La forma de en la que funciona un sistema SAP es:
Los usuarios a travs del SAPGUI, realizan peticiones al servidor de aplicacin, y ste a su vez, al servidor de base de datos (si es necesario).
De forma simplificada, un Servidor de Aplicacin est formado por un elemento llamado DISPACHER y otros llamados Procesos de Trabajo (work process).
El Dispacher recibe las peticiones de los usuarios, y las distribuye entre los procesos de trabajo que estn libres, los cuales realizan dichas acciones.
Pgina 40 de 84

Comunidad de Madrid
Un proceso de trabajo puede quedar libre, bsicamente por dos razones:

o Por que ha terminado su trabajo.
o O porque enva al usuario algn popup, mensaje o pantalla con la cual ste tenga que
interactuar.
El proceso de trabajo no se queda a la espera de la respuesta del usuario,

sino que queda libre para que el Dispacher lo use de nuevo.
Cuando el usuario contesta, el trabajo asociado a la accin correspondiente

ser asignado por el Dispacher a un work process libre, que no tiene por
que ser el mismo que estaba atendiendo con anterioridad al usuario.
De esta manera se optimiza el trabajo.
Cada vez que un proceso de trabajo necesita conectarse con el servidor de base de datos, bien
para acceder a datos de tablas o bien para actualizarlos, se crea un enlace de base de datos
(DB Link).
Y cada vez que un work process se queda libre, se rompe este enlace, y cada vez que se rompe
un enlace de base de datos, se ejecuta un Commit Work. Con ello las actualizaciones hechas
por el work process se hacen firmes en base de datos.
De lo anterior se deduce, que si entre dos sentencias de actualizacin de base de datos (que las est
ejecutando un solo work process), se muestra al usuario una pantalla (dynpro), un mensaje, o cualquier
otro elemento que haga que un work process quede libre, las actualizaciones hechas hasta ese momento
(por ese work process) se harn firmes en base de datos, pues al romperse el DB Link, la base de datos
ejecuta el correspondiente Commit Work.
Esto nos lleva a lo expuesto al principio de este punto. Mientras que se realicen interacciones con el
usuario no se han de hacer actualizaciones en base de datos.
Como norma: en los programas y sobre todo el los de tipo Modul Pool, se han de realizar primero todas
las verificaciones necesarias sobre los datos, indicando al usuario que corrija lo que tenga que corregir, y
una vez que todos los datos son coherentes y ya no es necesaria la interaccin con el usuario (se han
superado todas las validaciones) se puede proceder a actualizar dichos datos. Pero siempre teniendo en
cuenta lo anterior: todas las actualizaciones se han de llevar a cabo juntas y al final del proceso,
para que las realice un solo work process, a travs de un mismo enlace de base de datos (DB
Link).
Pgina 41 de 84

Comunidad de Madrid
Rendimiento
7.1
Recomendaciones generales
7.1.1
ACCESO A LA BASE DE DATOS
Al utilizar la instruccin SELECT sobre una tabla de Base de Datos, se ha de evaluar con qu
campos se va a especificar la clusula WHERE.
Como norma general, siempre que sea posible se ha de acceder a la tabla con la mayor cantidad
de campos clave posibles. En caso de no ser as se ha de investigar la existencia de algn ndice que se
adapte a la seleccin, y en caso de no existir se ha de sopesar si es conveniente su creacin.
Tanto en el caso de acceso por campos clave como por campos de ndices, se han de cumplir una serie
de normas:
-
Suministrar la mayor cantidad posible de campos de la clave o del ndice elegido.
Al escribir los campos en la clusula WHERE, se han de escribir en el mismo orden que los campos
de la clave o del ndice (en versiones anteriores a la 4.0) para obligar a algunas bases de datos a
usar un ndice en concreto.
En caso de accesos con todos los campos clave o del ndice se ha de usar siempre SELECT
SINGLE.
La utilizacin de sentencias con EXEC-SQL (SQL nativo) en tablas grandes puede mejorar el
rendimiento respecto al SELECT de ABAP (Open SQL). Principalmente para tablas que no residen en
buffer y contra las que se realicen muchos accesos o en las que presumiblemente el acceso sea
secuencial, o sea, que no se utilice un ndice. En caso de dudas, siempre conviene realizar un pequeo
programa sobre el que se realice un anlisis de rendimiento comparativo entre SELECT de ABAP y el
EXEC-SQL. Como recordatorio, las instrucciones que se realizan con EXEC-SQL no acuden al buffer
intermedio de SAP.
7.1.2
-
CLCULO Y PROCESOS
Evitar en lo posible la repeticin de clculos o procesos.

o Si estos clculos se repiten dentro de un programa, se pueden usar variables auxiliares o
tablas internas en las que se pueden almacenar los resultados de estos clculos o
procesos, de manera que slo se realicen una sola vez.
o Si son clculos o procesos que se repiten cada vez que se ejecutan uno o ms programas,
se pueden usar tablas transparentes para almacenar estos clculos. Para ello se dispone de
las tablas tipo cluster (tpicamente la tabla INDX), de manera que los datos se lean en
ejecuciones posteriores, evitando as su repeticin.
Cuando dos registros A y B tengan exactamente la misma estructura, es ms eficiente la instruccin
MOVE que la instruccin MOVE-CORRESPONDING.
SENTENCIAS
MOVE-CORRESPONDING BSEG TO *BSEG
SUSTITUIR POR
MOVE BSEG TO *BSEG
Pgina 42 de 84

Comunidad de Madrid
-
Para asignar el contenido de una tabla interna a otra con igual estructura, es mejor usar la forma
ITAB1[] = ITAB2[].
SENTENCIAS
SUSTITUIR POR
LOOP AT ITAB2.
ITAB1 = ITAB2.
ITAB1[] = ITAB2[],
APPEND ITAB1.
ENDLOOP.
La ejecucin de programas que realicen CALL TRANSACTION de forma masiva debe estar limitada
cuando se procesen de forma on-line. Este tipo de operaciones consumen mucho tiempo.
La ejecucin de sesiones de Batch-Input deben evitarse en concurrencia con el on-line.
Al codificar bucles, disearlos de forma que las condiciones que ms frecuentemente sean
verdaderas ocupen los niveles exteriores del bucle.
En muchas ocasiones para resolver operaciones de condicin (tipo IF) es posible utilizar tanto una
evaluacin IF como una evaluacin CASE. La instruccin CASE es deseable por dos motivos: es
ms fcilmente legible, y en los casos en los que el nmero de IFs a evaluar sea superior a 5 es
ms eficiente.
Para expresiones o evaluaciones lgicas que incluyan el operador AND, situar la condicin que ms
frecuentemente sea falsa en primer lugar
Para expresiones o evaluaciones lgicas que incluyan el operador OR, situar la condicin que ms
frecuentemente sea verdadera en primer lugar.
Limitar el uso de la sentencia ASSIGN, y en general de los FIELD-SYMBOLS. Su uso genera mayor
carga en el sistema y puede afectar negativamente tanto a los tiempos como a legibilidad del
programa.
7.2
Mejoras en la programacin
Muchas de las recomendaciones que vamos a enumerar estn localizables en el sistema mediante:
Herramientas Workbench ABAP Test Anlisis Tmpo. Ejecucin Tips & Tricks
Tambin existen herramientas en el sistema que nos pueden ayudar en momentos de duda a elegir entre
un algoritmo u otro ms adecuado. Es importante conocer este tipo de herramienta, y usarlas.
7.2.1
7.2.1.1
-
INSTRUCCIONES SQL INTERFASE

SELECT
Por norma general Evitar las SELECTs anidadas.

Se pueden convertir estos accesos en selecciones de datos basados en JOINs, implementados
como vistas de base de datos.
SENTENCIAS
SUSTITUIR POR
Pgina 43 de 84

Comunidad de Madrid
SELECT * FROM DD01L

WHERE DOMNAME LIKE 'CHAR%'.
SELECT * FROM DD01V
SELECT * FROM DD01T

WHERE
DOMNAME
DOMNAME
= DD01L-
WHERE DOMNAME LIKE 'CHAR%'

AND DDLANGUAGE = SY-
= DD01L- LANGU.
ENDSELECT.
AND DDLANGUAGE = SY-LANGU.
AND AS4VERS
AS4VERS
ENDSELECT.
ENDSELECT.
Tambin se pueden recuperar los datos en un solo paso en tablas internas, y sustituir uno o ms de los
SELECT anidados por LOOPs - ENDLOOPs, ya que es ms eficiente recuperar los datos necesitados
de una sola vez que en varias.
SENTENCIAS
SUSTITUIR POR
SELECT * FROM DD01L

SELECT * FROM DD01L
INTO TABLE T_DD01L
SELECT * FROM DD01T
LOOP AT T_DD01L.
WHERE DOMNAME = DD01L-DOMNAME
SELECT * FROM DD01T
AND AS4VERS = DD01L-AS4VERS

ENDSELECT.
ENDSELECT.
WHERE DOMNAME
AND AS4VERS
= T_DD01L-DOMNAME
= T_DD01L-AS4VERS

ENDSELECT.
ENDLOOP.
Adems se pueden usar otras tcnicas, como la variante FOR ALL ENTRIES de la sentencia
SELECT. Usando esta variante, algunos sistemas de base de datos dividen la seleccin en varias partes
ms sencillas, recombinando ms tarde los resultados como si se hubiesen realizado en un solo paso.
Se ha de evitar a toda costa usar el aadido CLIENT SPECIFIED sin indicar el campo MANDT en la
clusula WHERE.
Esto hace que el optimizador de base de datos no sea capaz de escoger ningn ndice, con lo cual
los accesos a las tablas van a ser siempre secuenciales.
Pgina 44 de 84

Comunidad de Madrid
SENTENCIAS
-
Evitar
las
SUSTITUIR POR
SELECT ... CLIENT SPECIFIED
SELECT ... CLIENT SPECIFIED

WHERE MANDT = 300 AND
WHERE BUKRS = sociedad.
BUKRS = sociedad.
.....
.....
ENDSELECT.
ENDSELECT.
sentencias SELECT * ...

Cuando no se van a necesitar todos los campos de la tabla, es ms ptimo evitar este tipo de
accesos sustituyndolos por:
SELECT <col 1> <col 2> ... <col n> INTO ...
SELECT sobre vistas de proyeccin
Evitar los chequeos de datos dentro de las sentencias SELECT ... ENDSELECT.
Es mejor dejar que la base de datos evale las condiciones sobre la tabla.
SENTENCIAS
SELECT ...
CHECK <condicin>
ENDSELECT
SUSTITUIR POR
SELECT ....
WHERE <condicin>
ENDSELECT
De esta forma la base de datos puede utilizar ndices en los casos en los que es posible, adems, la
utilizacin de la red es menor al haber menos seleccin de datos.
Pgina 45 de 84

Comunidad de Madrid
Evitar acceder a las tablas por campos que no sean clave o no estn incluidos en algn ndice.
Si esto no es posible, se ha de sospesar la conveniencia de crear un ndice para los campos de la

seleccin, a menos que esta seleccin sea muy frecuente, en cuyo caso se ha de pensar adems, en
poner la tabla en Memoria Intermedia (Buffer)
SELECT sobre tablas que crecen constantemente.
Hay que tener cuidado con las SELECT que se hacen sobre tablas que crecen constantemente (BSEG,
VBAK, etc). Si no tienen una clusula WHERE apropiada (por campos clave o ndice) se ha de replantear
el proceso.
- Cargas de datos en tablas internas.

Si se hacen accesos a tablas, con la pretensin de almacenar los datos recuperados en tablas internas,
se han de evitar las formas SELECT ... APPEND itab ... ENDSELECT.
En general es ms eficiente transferir los datos necesitados desde la base de datos una sola vez, en vez
de llamar a la besa de datos repetidamente.
SENTENCIAS
SUSTITUIR POR
SELECT <campo 1> <campo n>

FROM ...
INTO wa
WHERE ...
FROM ...
INTO TABLE itab.
APPEN wa TO itab.
ENDSELECT
Se han de evitar las clusulas ORDER BY en las sentencias SELECT.
Es mejor recuperar los datos en una tabla interna y posteriormente ordenarla, o bien recuperarlos
directamente en una tabla de tipo SORTED TABLE con lo cual el sistema la ordena inmediatamente a
medida que la carga.
Uso de las funciones agregadas.
Si se necesita hacer algn tipo de clculo sobre los datos recuperados, del tipo MIN, MAX, AVG, COUNT,
etc es mejor dejar que lo haga la base de datos en vez de programarlo.
Pgina 46 de 84

Comunidad de Madrid
7.2.2
EL WHERE EN SELECT
Las clusulas WHERE complejas son malas para el optimizador de la base de datos
En una clusula WHERE, el operador lgico NOT no esta soportado por los indices.
SENTENCIAS
SUSTITUIR POR
FROM ...
FROM ...
WHERE NOT FECHA <= 19990212.
WHERE fecha >= 19990212.
ENDSELECT.
ENDSELECT.
Siempre que se desee usar un ndice, se ha de especificar dentro del WHERE, los campos del ndice
(o una parte de ellos) concatenados con ANDs.
Siempre se han de especificar cuantos mas = (smbolos IGUAL) sea posible
En general especificando los N primeros campos del ndice (en el mismo orden en el que estn
definidos el ndice) aumenta el rendimiento de forma considerable
7.2.3
-
MODIFICACIN E INSERCIN DE DATOS
Especificar la mayor cantidad de campos clave o de ndice en las sentencias UPDATE.

Al igual que sucede en las sentencias SELECT, al modificar registros de tablas, se ha de indicar en la
clusula WHERE la mayor cantidad posible de campos de la clave o de un ndice en concreto. De
esta forma los accesos a lo registros son ms rpidos.
Inserciones de datos desde tablas internas

Es preferible hacer muchas actualizaciones de datos de golpe que no hacerlas de una en una.
SENTENCIAS
SUSTITUIR POR
LOOP AT TAB.
INSERT INTO <tabla> VALUES TAB.
INSERT <tabla> FROM TABLE itab.
ENDLOOP.
Utilizar actualizaciones de columna en vez de modificaciones de fila.
Pgina 47 de 84

Comunidad de Madrid
Es preferible actualizar los valores de una o ms columnas de una tabla de una sola vez, en vez de
hacerlo registro a registro.
SENTENCIAS
SUSTITUIR POR
SELECT * FROM SFLIGHT.

SFLIGH T-SEATSOCC = SFLIGHT-SEACSOCC -1.
UPDATE SFLIGHT
UPDATE SFLIGHT.
SET SEATSOCC = SEATSOCC - 1.
ENDSELECT.
Hacer COMMITs tras una o ms LUWs

Si se estn desarrollando programas de tipo dilogo, hay que controlar que se haga al menos un
COMMIT WORK despus de una o ms Unidades Lgicas de Trabajo completadas.
7.2.4
TRATAMIENTO DE CADENA DE CARACTERES
En strings largos, los tiempos de CPU aumentan considerablemente
Usar los operadores CO, CA, CS en lugar de programarlos
No programar las sentencias para truncar strings, sino utilizar la instruccin SPLIT.
Para averiguar la longitud de un campo, utilizar la funcin que el sistema proporciona al efecto.
Long_campo = STRLEN(campo)
7.2.5
TRATAMIENTO DE TABLAS INTERNAS
Es muy importante familiarizarse con el uso de los nuevos tipos de tablas internas, sobre todo con
las tablas SORTED y HASHED. Estos nuevos tipos de tablas aumentan de forma considerable el
rendimiento en las bsquedas de datos almacenados en ellas.
Usar COLLECT frente a algoritmos programados.
A partir de la release 3.0 de SAP, el algoritmo de la instruccin COLLECT ha sido mejorado. Por
tanto, se recomienda usar COLLECT, si es necesario, frente a cualquier otro cdigo que se
programe a tal efecto.
Accesos por clave

Al acceder a registros de la tabla interna, especificar la clave de forma explcita
SENTENCIAS
SUSTITUIR POR
MOVE SPACE TO TAB.

READ TABLE TAB WITH KEY K = 'X'
TAB-K = 'X'.
BINARY SEARCH
READ TABLE TAB BINARY SEARCH.
Intentar siempre acceder a una tabla interna ya ordenada

Las bsquedas sobre tablas internas, son mucho ms eficientes si stas se encuentran ordenadas
por el criterio de bsqueda.
Pgina 48 de 84

Comunidad de Madrid
Lo ms recomendable es usar SORTED TABLES. En estas tablas, las bsquedas son muy rpidas,
al igual que las HASHED TABLES, que no estn ordenadas pero que usan un algoritmo de
posicionamiento que hace que las bsquedas de registros sean casi inmediatas.
En los casos en los que se usan tablas normales (STANDARD TABLES), antes de hacer bsquedas
se ha de ordenar su contenido, y posteriormente indicar que se haga una bsqueda binaria por la
clave de ordenacin.
SENTENCIAS
SUSTITUIR POR
READ TABLE TAB WITH KEY K = 'X'

READ TABLE WITH KEY.
BINARY SEARCH
En LOOP de tablas utilizar la clusula WHERE.

SENTENCIAS
SUSTITUIR POR
LOOP AT TAB.
LOOP AT TAB WHERE K = KVAL.
CHECK TAB-K = KVAL.
.....
.....
ENDLOOP.
ENDLOOP.
Construir ndices secundarios.

Si se necesita acceder frecuentemente a una tabla interna por diferentes claves, es conveniente
llevar ndices secundarios propios. Con estos ndices, se puede reemplazar una bsqueda lineal de
la tabla, por una binaria o bien usar un acceso por ndice. En el ejemplo TAB_INDEX es una tabla en
la que se guarda un ndice por el campo fecha de la tabla TAB.
SENTENCIAS
SUSTITUIR POR
READ TABLE TAB WITH KEY DATE = SY-DATUM.

IF SY-SUBRC = 0.
READ TABLE TAB_INDEX
...
WITH KEY DATE = SY-DATUM
ENDIF.
BINARY SEARCH.
IF SY-SUBRC = 0.
READ TABLE TAB INDEX TAB_INDEX-INDX.
...
ENDIF.
Pgina 49 de 84

Comunidad de Madrid
Construccin de tablas ordenadas

Se ha de evitar siempre usar la instruccin APPEND itab SORTED BY. Pues cada vez que se aade
una fila a la tabla se ha de ordenar, lo cual resulta poco eficiente.
SENTENCIAS
SUSTITUIR POR
...
...
APPEND itab SORTED BY campo1.
APPEND itab
...
...
APPEND itab SORTED BY campo1
APPEND itab
...
...
APPEND itab SORTED BY campo1.
APPEND itab
SORT itab BY campo1.
Lo que se ha de hacer siempre es llenar la tabla y seguidamente ordenarla por los campos que se
desean.
SENTENCIAS
REFRESH TAB_DEST.
LOOP AT TAB_SRC.
READ TABLE TAB_DEST WTTH KEY K= ....
INSERT TAB_SRC INTO TAB_DEST INDEX SYINDEX.
SUSTITUIR POR
REFRESH TAB_DEST.
LOOP AT TAB_SRC.
APPEND TAB_SRC TO TAB_DEST.
ENDLOOP.
SORT TAB_DEST BY K
ENDLOOP.
Construccin de tablas internas sin duplicados

Es preferible borrar las entradas duplicadas una vez llena la tabla interna que ir borrando los
duplicados a medida que se llena. El procedimiento a seguir es:
o
Llenar la tabla
Ordenar la tabla
Borrar las entradas duplicadas

SENTENCIAS
SUSTITUIR POR
REFRESH TAB_DEST.
Pgina 50 de 84

Comunidad de Madrid
REFRESH TAB_DEST.
LOOP AT TAB_SRC.
READ TABLE TAB_DEST WITH KEY K= TAB_SRCK.
IF SY-SUBRC <> 0 .
LOOP AT TAB_SRC
ENDLOOP
INSERT TAB_SRC INTO TAB_DEST

INDEX SY-INDEX.
SORT TAB_DEST BY K.
DELETE ADJACENT DUPLICATES
ENDIF.
FROM TAB_DEST.
ENDLOOP.
Uso de reas de trabajo.

Evitar MOVEs innecesarios utilizando las reas de trabajo en las sentencias:
o
APPEND
wa TO
tab.
INSERT
wa INTO tab.
COLLECT
wa INTO tab.
MODIFY
tab FROM wa.
READ TABLE tab INTO wa.
LOOP AT
tab INTO wa.

SENTENCIAS
SUSTITUIR POR
TAB = TAB_WA.
APPEND TAB_WA TO TAB.
APPEND TAB.
Copia de tablas internas

Siempre que se pueda se ha de utilizar asignacin directa de variables.
SENTENCIAS
SUSTITUIR POR
REFRESH TAB_DEST.
LOOP AT TAB_SRC INTO TAB_DEST.
TAB_DEST[ ] = TAB_SRC[ ]
APPEND TAB_DEST.
ENDLOOP.
Comparacin de tablas internas

Dos tablas internas son iguales cuando tienen el mismo nmero de lneas y coincide una a una. Es
preferible comparar todo el contenido de la tabla a realizar un barrido secuencial de la misma, e ir
comparando con la entrada equivalente en la otra tabla.
Pgina 51 de 84

Comunidad de Madrid
SENTENCIAS
SUSTITUIR POR
DESCRIBE TABLE: TAB1 LINES L1,

TAB2 LINES L2.
IF L1 <> L2.
TAB_DIFFERENT = 'X'.
ELSE.
TAB_DIFFERENT = SPACE.
LOOP AT TAB1.
READ TABLE TAB2 INDEX SY-TABIX.
IF TAB1 <> TAB2.
TAB_DIFFERENT = 'X'. EXIT.
IF TAB1[ ] = TAB2 [ ]
....
ENDIF
ENDIF.
ENDLOOP.
ENDIF.
IF TAB_DIFFERENT = SPACE.
" ...
ENDIF.
Para ordenar tablas internas, especificar los campos sobre los que debe verificarse la ordenacin.
SENTENCIAS
SORT ITAB.
SUSTITUIR POR
SORT ITAB BY FIELD1 FIELD2.
Para cargar en una tabla interna el resultado de una seleccin de una tabla transparente de SAP sin
chequeos adicionales.
Es ms ptimo llenar de una sola vez la tabla interna, que ir aadiendo fila a fila.
SENTENCIAS
SUSTITUIR POR
SELECT * FROM dbtable
SELECT * FROM dbtable.
INTO TABLE itab
MOVE ...
WHERE ...
Pgina 52 de 84

Comunidad de Madrid
APPEND itab.
ENDSELECT..
Para averiguar el nmero de registros en una tabla interna

Utilizar la sentencia ABAP destinada a tal efecto, evitando programar un algoritmo que cuente el
nmero de lneas.
SENTENCIAS
SUSTITUIR POR
LOOP AT ITAB.
C_LINEAS = C_LINEAS + 1.
DESCRIBE TABLE ITAB LINES C_LINEAS.
ENDLOOP.
Bucles anidados
Se han de evitar recorridos secuenciales y plantearse accesos por ndice en la segunda tabla o
tablas ms interna del bucle. En general, los anidamientos de cualquier tipo de bucles son poco
eficientes. Por ejemplo, suponiendo: tablas ordenadas, TAB2 contiene slo entradas que existen en
TAB1.
SENTENCIAS
SUSTITUIR POR
I2 = 1.
LOOP AT TAB1.
LOOP AT TAB2 FROM I2.
LOOP AT TAB1.
IF TAB2-K <> TAB1-K.
LOOP AT TAB2 WHERE K = TAB1-K.
I2 = SY-TABIX.
...
EXIT.
ENDLOOP.
ENDIF.
ENDLOOP.
" ...
ENDLOOP.
ENDLOOP.
Si TAB2 no contuviese slo entradas de TAB1, el algoritmo sera mas complicado, pero an as se
mejorara el rendimiento.
Insercin en una tabla desde otra

Con la instruccin APPEND / INSERT LINES OF la tarea se transfiere al Kernel.
SENTENCIAS
SUSTITUIR POR
Pgina 53 de 84

Comunidad de Madrid
LOOP AT TAB_SRC.
APPEND LINES OF TAB_SRC TO TAB_DEST.
ENDLOOP.
Borrado de lneas
Utilizar accesos por ndice para transferir trabajo al kernel: DELETE itab FROM
SENTENCIAS
SUSTITUIR POR
LOOP AT TAB_SRC.
APPEND LINES OF TAB_SRC TO TAB_DEST.
ENDLOOP.
Utilizar clusula WHERE frente a barridos secuenciales.

SENTENCIAS
SUSTITUIR POR
LOOP AT TAB_DEST WHERE K = KVAL

DELETE TAB_DEST
DELETE TAB_DEST WHERE K = KVAL
ENDLOOP
Modificacin de campos de una tabla interna

Es ms eficiente modificar slo un campo de la tabla que todos los campos, como sucede si usamos
la lnea de cabecera.
SENTENCIAS
SUSTITUIR POR
WA-DATE = SY-DATUM.
LOOP AT TAB.
TAB-DATE = SY-DATUM.
MODIFY TAB.
LOOP AT TAB.
MODIFY TAB FROM WA
TRANSPORTING DATE.
Pgina 54 de 84

Comunidad de Madrid
ENDLOOP.
ENDLOOP.
7.2.6
-
LLAMADAS A SUBRUTINA
Especificar el tipo de parmetros en las rutinas

Si se especifica el tipo de los parmetros formales de las rutinas, el compilador de ABAP/4 puede
optimizar el cdigo resultante. Adems, el riesgo de utilizar secuencias errneas de parmetros
disminuye.
SENTENCIAS
FORM UP2 USING REPEAT
SUSTITUIR POR
FORM UP2 USING REPEAT TYPE I
DIMID.
DIMID
.....
.....
ENDFORM.
ENDFORM.
LIKE T006-DIMID.
Mltiples llamadas a subrutinas.

En caso de tener que llamar a distintas rutinas dependiendo de un valor, es ms eficiente usar la
sintaxis PERFORM n OF form1 form2 form3. que otras implementaciones.
SENTENCIAS
SUSTITUIR POR
I1 = 5
CASE I1.
PERFORM I1 OF
WHEN 1. PERFORM PV1.
PV1
PV2
PV3
PV4
PV5
PV6
PV7
PV8.
ENDCASE.
7.2.7
-
COMPARACIN DE CARACTERES
Cuando hay tipos de carcter de por medio, es mucho ms rpido las comparaciones entre tipos
carcter que entre carcter y otros tipos.
SENTENCIAS
DATA: C1A VALUE 7.
SUSTITUIR POR
DATA: C1A VALUE 7.
Pgina 55 de 84

Comunidad de Madrid
IF 1 = C1A.
IF '1' = C1A.
ENDIF.
ENDIF.
7.2.8
-
SENTENCIAS IF O CASE
CASE ms claro y eficiente con mltiples condiciones.

Es ms claro usar la sentencia CASE para solventar casos de decisin mltiple. Por otro lado cuando
entran en juego ms de cinco decisiones es algo ms rpido.
SENTENCIAS
SUSTITUIR POR
CASE C1A.
IF
C1A = 'A'. WRITE '1'.

WHEN 'A'. WRITE '1'.
ELSEIF C1A = 'B'. WRITE '2'.

WHEN 'B'. WRITE '2'.
ELSEIF C1A = 'C'. WRITE '3'.
WHEN 'C'. WRITE '3'.
ELSEIF C1A = 'D'. WRITE '4'.
WHEN 'D'. WRITE '4'.
ELSEIF C1A = 'E'. WRITE '5'.
WHEN 'E'. WRITE '5'.
ELSEIF C1A = 'F'. WRITE '6'.
WHEN 'F'. WRITE '6'.
ELSEIF C1A = 'G'. WRITE '7'.
WHEN 'G'. WRITE '7'.
ELSEIF C1A = 'H'. WRITE '8'.
WHEN 'H'. WRITE '8'.
ENDIF.
ENDCASE.
7.2.9
-
SENTENCIAS DO..ENDDO, WHILE..ENDWHILE
Es ms eficiente usar un bucle WHILE ENDWHILE que la construccin DO + EXIT.

SENTENCIAS
SUSTITUIR POR
I1 = 0.
I1 = 0.
DO.
WHILE C1A = SPACE.
IF C1A NE SPACE. EXIT. ENDIF.
ADD 1 TO I1.
ADD 1 TO I1.
IF I1 GT 10. C1A = 'X'. ENDIF.
IF I1 GT 10. C1A = 'X'. ENDIF.
ENDWHILE.
ENDDO.
Pgina 56 de 84

Comunidad de Madrid
7.2.10 TRATAMIENTO DE FIELD-SYMBOLS

-
Definir tipo en los field-symbols: Si se especifica el tipo del field-symbol, el compilador puede mejorar
el rendimiento del programa
SENTENCIAS
FIELD-SYMBOLS: <I>.
SUSTITUIR POR
FIELD-SYMBOLS: <F>TYPE I.
7.2.11 MANEJO DE VARIABLES Y TIPOS

-
Si los contenidos de las variables van a ser numricas, se han de definir de tipo I o P, pero no de tipo
C.
Utilizar variables de tipo I, no de tipo P, para campos que almacenan valores enteros, como pueden
ser ndices de bucle. Se evitarn los tiempos de conversin.
SENTENCIAS
DATA: IP TYPE P.
DATA: IP TYPE I.
DO 5 TIMES.
DO 5 TIMES.
IP = SY-INDEX * 2.
IP = SY-INDEX * 2.
READ TABLE X100 INDEX IP.
READ TABLE X100 INDEX IP.
ENDDO.
SUSTITUIR POR
ENDDO.
En las asignaciones, utilizar constantes con tipo mejor que literales.

SENTENCIAS
DATA:
SUSTITUIR POR
CONSTANTS: PI TYPE F
FLOAT TYPE F.
VALUE '3.1415926535897932'.
DATA: FLOAT TYPE F.
FLOAT = '3.1415926535897932'.
FLOAT = PI.
En clculos aritmticos no mezclar tipos a no ser que sea absolutamente necesario, de esta forma se
evitan conversaciones innecesarias de tipos.
SENTENCIAS
DATA: F1 TYPE I VALUE 2,
DATA: F1 TYPE F VALUE 2,
F2 TYPE P DECIMALS 2 VALUE '3.14',
F2 TYPE F VALUE '3.14',
F3 TYPE F.
F3 TYPE F.
F3 = F1 * F2.
SUSTITUIR POR
F3 = F1 * F2.
En clculos aritmticos utilizar variables de tipo P.

SENTENCIAS
DATA:
SUSTITUIR POR
DATA:
Pgina 57 de 84

Comunidad de Madrid
N1(15) TYPE N VALUE '123456789012345',

P1
TYPE P VALUE '123456789012345',
P2
TYPE P VALUE '543210987654321',
P3
TYPE P.
N2(15) TYPE N VALUE '543210987654321',

N3(15) TYPE N.
N3 = N1 + N2.
P3 = P1 + P2.
Se han de usar literales numricos o constantes de tipo numrico en vez de cadenas de caracteres
cuando se estn tratando tipos I o P.
SENTENCIAS
7.3
7.3.1
SUSTITUIR POR
MOVE SPACE TO SY-SUBRC.
SY-SUBRC = 0.
CASE SY-SUBRC.
CASE SY-SUBRC.
WHEN '1'.
WHEN 1.
WHEN '2'.
WHEN 2.
WHEN '3'.
WHEN 3.
WHEN '4'.
WHEN 4.
ENDCASE.
ENDCASE.
Mejoras basadas en el sistema

TRATAMIENTO DE MODOS INTERNOS
Las instrucciones CALL DIALOG, CALL TRANSACTION y SUBMIT, se utilizan para hacer
llamadas desde un programa a otro programa o transaccin. Para el usuario es deseable que este
proceso sea reversible, es decir, que el usuario pueda repetir la secuencia de pantallas en orden inverso.
Para ello, la secuencia de llamadas se almacena en una pila. Si se alcanza el nmero mximo de
llamadas internas, no se pueden hacer ms llamadas.
El nmero mximo de llamadas internas es 9 y no puede cambiarse.
En el desarrollo de programas hay que asegurarse de que esta situacin no pueda darse.
7.3.2
ACTUALIZACIN DE BASES DE DATOS
Siempre que se ejecuta una operacin de actualizacin de la base de datos con sentencias
UPDATE, INSERT, etc., se produce un submit interno a un programa que es el que se encarga de realizar
las actualizaciones en la base de datos.
En las operaciones de actualizacin de registros ya existentes en la base de datos, es
conveniente comprobar que la actualizacin es necesaria para no provocar los submits innecesariamente.
Pgina 58 de 84

Comunidad de Madrid
Por otro lado, las instrucciones de actualizacin UPDATE usadas en la forma larga, usando el
parmetro SET disminuyen el trfico de red, ya que slo se modifican aquellos campos introducidos por
SET:
UPDATE t001 SET
butxt = Iberdrola Produccion

ort01 = Bilbao
WHERE
bukrs = 0200.
Al introducir cantidades de datos relativamente grandes, es recomendable ejecutar una

instruccin COMMIT WORK, p. ej., cada 1000 registros introducidos. Esto se debe hacer con el objeto de
no sobrecargar los recursos de SAP y facilitar el trabajo del gestor de la base de datos. Adems, de esta
forma se evita que se produzcan cancelaciones de los procesos, al llenarse el rea de rollback.
En el caso de actualizaciones masivas de la BD con BATCH INPUT, es recomendable fraccionar
las cargas en varios Juegos de Datos pequeos, en vez de uno solo y enorme. Es ms fcil relanzar una
carga fallida (o interrumpida) pequea que una grande.
Se puede utilizar la planificacin de jobs con la opcin de predecesor finalizado para
automatizar la tarea.
7.3.3
7.3.3.1
NDICES DE BD
Consideraciones generales
La existencia de ndices adecuados para ciertas tablas es un prerrequisito esencial para el buen
rendimiento de un sistema SAP R/3. El estndar de SAP contiene los ndices necesarios para el
desarrollo normal de las aplicaciones estndar. Pero an as, puede surgir la necesidad de crear algunos
ndices, esta necesidad puede depender de:
-
Las funcionalidades usadas, es decir, del customizing.
El tamao de las tablas.
La base de datos utilizada.
El modo de acceso a las tablas
Desarrollos propios.
En los programas batch y el reporting on-line, de las variantes utilizadas por los reports.
Pgina 59 de 84

Comunidad de Madrid
Para mantener los ndices, la base de datos necesita: espacio en disco, memoria y CPU. Por
ello, el rendimiento global del sistema puede verse severamente impactado por la creacin de ndices
inadecuados, es decir, demasiados ndices, ndices no usados, etc.
La necesidad de creacin de nuevos ndices se puede determinar por varios mtodos:
-
Las trazas SQL comprueban la eficiencia de los ndices individuales con la funcin EXPLAIN.
Estadsticas de transacciones. Con ellas podemos identificar los programas que consumen ms
tiempo de ejecucin y mayor tiempo de base de datos, con lo que podemos comprobar la eficiencia
de los accesos a la base de datos.
Los diferentes monitores de base de datos ofrecen gran nmero de funcionalidades para comprobar la
eficiencia en los accesos a la base de datos.
En este punto es importante colaborar con el administrador del sistema, l es quin mejor puede
interpretar la informacin que proporcionan estos monitores y las herramientas de gestin de Base de
Datos.
7.3.3.2
Optimizador de BD
En las bases de datos hay un elemento llamado Optimizador, que es el que determina cmo se
van a realizar los accesos a las tablas. La misin de este elemento es la de optimizar en lo posible estos
accesos, de manera que sean lo menos costosos posibles. Para ello ha de evaluar muchos parmetros,
como la cantidad de entradas de la tabla, los ndices definidos, el tipo de tabla, etc.
Bsicamente hay dos tipos de optimizadores:
-
Basados en reglas. Se basan en el uso de una serie de reglas fijas, ms o menos complejas, que
intentan descubrir cual es la mejor forma de acceder a los datos. Se usan en versiones anteriores la
versin 4.0.
Por ejemplo:
Puede haber una regla que le diga al Optimizador que seleccione para el acceso a una
tabla, el ndice que tenga ms campos coincidentes con la clusula WHERE del SELECT.
Basados en costes. Estos hacen un clculo aproximativo de lo costoso que resulta el acceso a los
datos para cada posible estrategia de acceso (lo costoso que resulta usar cada ndice, usando una
combinacin de varios, acceso secuencial, etc.) Al final, la estrategia menos costosa es la que se
usa. Se usan a partir de la versin 4.0.
Para que el optimizador sea capaz de calcular los costes de acceso a los datos, necesita conocer
una serie de datos estadsticos sobre diversos aspectos de las tablas y de los ndices de la base de
datos, como pueden ser:
o
La cantidad de filas de un ndice o tabla.
Cantidad de valores distintos de cada columna de la tabla.
Estos valores se actualizan peridicamente, y es responsabilidad del administrador que no se queden

desfasados, pues pueden llevar al optimizador a adoptar estrategias de acceso incorrectas.
7.3.3.3
-
Reglas de creacin de ndices secundarios
Conceptos:
o
Campos selectores, son aquellos que tienen una gran variedad de valores distintos. P.e.:
Nmero de documento, nmero de cliente, NIF
Campos no selectores, son aquellos con pocos valores distintos. P.e.: Sociedad, mandante,
sector
Pgina 60 de 84

Comunidad de Madrid
-
Usar siempre campos selectores en el ndice.
Los campos del ndice han de reducir de forma significativa el conjunto de resultados seleccionados por
la sentencia SQL. El objetivo es que lo registros seleccionados no superen el 5% de la cantidad total de
registros de la tabla, en caso de superarla el optimizador basado en costes de Oracle puede elegir no
usar el ndice y realizar un acceso secuencial completo a la tabla.
-
Usar poco campos en el ndice. Como norma no ms de 5.
Si se usan demasiados campos en un ndice:
Cada campo aadido requiere operaciones adicionales para adaptar el ndice cuando el valor
cambia.
La cantidad de datos almacenados y ledos aumenta. Esto hace que decrezca la eficiencia del
ndice y que decrezca tambin la posibilidad de que el optimizador lo use.
El optimizador tiene mucha ms posibilidades de cometer fallos.
El tiempo necesario para preparar las sentencias SQL necesarias se incrementa

considerablemente. Esto es especialmente relevante con tablas con mucho ndices y enlazadas
mediante operaciones JOIN.
Se han de poner los campos selectivos al principio de los campos del ndice.
7.3.4
7.3.4.1
TABLAS TRANSPARENTES EN MEMORIA INTERMEDIA (MI)

MI en SAP (BUFFERS)
R/3 usa varios tipos de memorias intermedias (Buffers) que son locales al Servidor de Aplicacin
y que tienen como misin principal almacenar datos en tiempo de ejecucin. Entre estos tipos de Buffers
hay uno destinado a almacenar datos de tablas.
Hay que recordar que los procesos en R/3 se ejecutan en el Servidor de Aplicacin, por lo tanto,
si conseguimos almacenar en estos Buffers datos de tablas que se leen a menudo, evitaremos accesos a
la base de datos, lo que har que aumente el rendimiento del sistema, ya que los accesos a estos Buffers
son muy rpidos.
R/3 gestiona los Buffers de manera que los cambios realizados en las tablas que residen en
memoria intermedia, se repliquen tanto en la Base de Datos como el propio Buffer. Esta gestin no es del
todo eficiente en entornos con ms de un Servidor de Aplicacin, pues los cambios realizados en uno no
se replican en los dems hasta pasado un tiempo (generalmente entorno a 1 minuto). Por lo tanto, en
memoria intermedia, slo deben residir tablas que son casi exclusivamente de lectura, y que desde los
puntos de vista de los procesos y de las aplicaciones, no sea traumtico este espacio de tiempo, en el
que no hay sincronizacin de datos entre servidores de aplicacin.
Tpicamente, podrn ser tablas de parametrizacin, o de datos maestros con muy pocas
modificaciones.
Cuando se realizan desarrollos con este tipo de tablas, se han de evitar las sentencias de ABAP
que hacen que se ignoren los buffers, y se acceda directamente a la base de datosUna relacin de estas
sentencia se explica ms adelante.
7.3.4.2
Grabacin en MI
Como no todas las tablas son iguales, en cuanto a tamao y uso, es lgico pensar que la forma en la que
el sistema debe almacenar los datos en los buffers, tambin variar en funcin de los datos que contiene
cada tabla.La grabacin en memoria intermedia se gestiona desde las Opciones Tcnicas de las Tablas
(Transaccin SE13)
Pgina 61 de 84

Comunidad de Madrid
Hay tres estados en los que pueden estar las tablas respecto a la memoria intermedia:
-
Sin grabacin en Memoria Intermedia (No Buffering).

Los datos de estas tablas no se grabarn nunca en Memoria Intermedia.
Grabacin en Memoria Intermedia desactivado.

Los datos de estas tablas se graban generalmente en la Memoria Intermedia, pero con esta
opcin se desactiva la grabacin.
Grabacin en Memoria Intermedia activado.

Los datos se graban en memoria intermedia de la forma que se especifique.
Cuando se marca una tabla para que se grabe en memoria intermedia, se ha de indicar una forma de
grabacin. La forma de grabacin va a depender de la cantidad de entradas de la tabla y de la naturaleza
de los datos. Hay que tener siempre en mente, que al marcar una tabla para que se grabe en buffer, los
datos van a ocupar memoria del Servidor de Aplicacin, por lo que, si grabamos en buffer una tabla muy
grande, incidiremos en el rendimiento, e incluso podramos colapsar el Servidor.
Para evitar esto, es por lo que existe la forma de grabacin en memoria intermedia. Hay tres formas de
grabacin:
-
Grabacin total en Memoria Intermedia.

Usando esta forma de grabacin, todos los registros de la tabla se cargan en memoria intermedia
la primera vez que se accede a cualquier registro de la tabla.
Cundo se ha de elegir esta forma de grabacin?
o
En tablas con un alcance de hasta 30 KB. Si se accede frecuentemente a una tabla para
lectura, puede sobrepasarse tambin este valor
En tablas mayores en las que se producen accesos de cantidad. Sin embargo, si se formula
para estos accesos de cantidad una condicin WHERE muy selectiva mediante un ndice de
base de datos, podr ser ms interesante renunciar al almacenamiento completo en
memoria intermedia.
En tablas en las que prevalecen los accesos a datos que no existen. Como la tabla se
encuentra completa en la memoria intermedia, se puede decidir muy rpidamente si existe
un registro de una entrada clave.
Para decidir a favor o en contra del almacenamiento completo en memoria intermedia,

deben tenerse en cuenta tres aspectos. Cuanto ms pequea sea la tabla, cuanto ms se
lea, y cuanto menos se escriba, ms interesante ser almacenarla completamente en la
memoria intermedia.
La modificacin de cualquier registro de la tabla, marca como invlido todo el contenido de la

tabla, y se volver a cargar en el buffer la prxima vez que se acceda a los datos.
Grabacin de Registro Sencillo en Memoria Intermedia.
Cuando se marca esta opcin, lo que se va grabando en memoria intermedia son registros
individuales de la tabla. Estos registros se van pasando al buffer a medida que los procesos los van
seleccionando.
Si se accede a un registro que todava no se ha almacenado en memoria intermedia por medio
de SELECT SINGLE, se acceder a la base de datos a fin de cargar un registro. Si la tabla no contiene
ningn registro de la clave introducida ('No record found'), se marcar este registro en la memoria
intermedia como no existente. Puede evitarse un nuevo acceso a la base de datos, intentando acceder de
nuevo a este registro.
Pgina 62 de 84

Comunidad de Madrid
o
En caso de grandes tablas a las que frecuentemente se accede por registros (por medio de
SELECT SINGLE...). El alcance de los registros a los que se accede debe estar entre 100 y
200 KB.
En caso de tablas comparativamente ms pequeas, en las que el rango de acceso es

grande, resulta ms interesante, por regla general, realizar un almacenamiento completo en
memoria intermedia, ya que para cargar este tipo de tablas, con almacenamiento en
memoria intermedia completo, solamente se necesita un acceso a la base de datos,
mientras en el almacenamiento en memoria intermedia de registro individual se necesitan
muchos accesos a la base de datos.
La modificacin de un registro, que esta en el buffer, hace que se marque como invlido y se volver a
cargar en memoria intermedia la prxima vez que se le trate.
Grabacin de un mbito Genrico en Memoria Intermedia.
Un mbito genrico est formado por un nmero dado de campos clave menor que la cantidad
total de estos campos, y expresado desde el primero al ltimo. Es decir, si tenemos una tabla cuya clave
son cinco campos, un mbito genrico es el que forma el primero, o los dos primeros, o los tres primeros,
o incluso los 4 primeros, pero no los cinco campos clave, porque sino, nos estaramos refiriendo a un
registro sencillo de la tabla y no a un mbito dentro de ella. Por lo tanto, cuando se marca esta forma de
grabacin, se han de indicar la cantidad de campos que van a forma el mbito genrico.
Cuando los procesos empiecen a seleccionar registros de las tablas, lo que se va a cargar en el
buffer, son los registros que tienen los mismos datos dentro del mbito definido.
Por ejemplo: Supongamos que tenemos una tabla con 4 campos clave (Mandante, Sociedad,
Centro y Material), y que tiene macada esta opcin de grabacin en memoria intermedia, y para la cual se
ha definido el mbito como los 3 primeros campos de la clave. Si se hace un SELECT SINGLE por
Mandante = 777, Sociedad = 1001, Centro = 0001 y Material = 1000000001, en memoria intermedia
se van a cargar todos los registros de la tabla que cumplan que Mandante = 777, Sociedad = 1001,
Centro = 0001.
o
Una tabla debe almacenarse genricamente en la memoria intermedia cuando slo se

necesiten determinadas reas de la tabla. Se tratan los mbitos genricos individuales
como tablas propiamente dichas, que se almacenan en su totalidad en la memoria
intermedia. Por ello, hay que tener tambin en cuenta el texto (tablas de textos) para el
almacenamiento completo en la memoria intermedia.
Debe seleccionarse el mbito genrico de claves, de tal forma que los mbitos genricos no
sean demasiado pequeos, a fin de que no se creen demasiados mbitos genricos. Si
existen muy pocos registros por mbito genrico, resultar ms eficiente almacenar
totalmente la tabla en la memoria intermedia.
Slo tendr sentido realizar un almacenamiento genrico en memoria intermedia, si se

accede a la tabla con una clave genrica perfectamente especificada. Si un campo de la
clave genrica no est provisto de un valor durante el acceso, se leer directamente de la
base de datos evitando la memoria intermedia.
Las tablas de idioma son un ejemplo del empleo oportuno del almacenamiento genrico en
la memoria intermedia (con el campo clave del idioma como mbito clave genrico).
La modificacin de un registro del mbito, hace que se marque todo el mbito como invlido, y se volver
a cargar en memoria intermedia, la prxima vez que se acceda a los datos de ese mbito.
Pgina 63 de 84

Comunidad de Madrid
7.3.4.3
Bypassing buffer: Sentencias que ignoran la MI

Son sentencias que no pueden satisfacer su peticin de datos desde la memoria intermedia.
Este tipo de sentencias, se han de evitar cuando se usan con tablas que residen de alguna forma
en memoria intermedia, a fin de optimizar el rendimiento. Sin embargo hay que tener en cuenta que
puede haber excepciones, debidas a el tiempo necesario de resincronizacin entre servidores de
aplicacin. Por lo tanto, si necesitamos asegurarnos de acceder a los datos ms recientemente
actualizados en estas tablas deberemos usar este tipo de sentencias.
- SELECT ... BYPASSING BUFFER
- SELECT ... FOR UPDATE
- Cualquier funcin agregada (COUNT, MAX, MIN, SUM, AVG) de la sentencia SELECT.
- SELECT DISTINCT...
- Clusulas WHERE con IS NULL.
- SELECT... ORDER BY ... (Menos por la clave primria)
- Cualquier sentencia en SQL Nativo (EXEC SQL ... END EXEC).
Si una tabla se graba en memoria intermedia con, forma de grabacin por registro sencillo,
sentencias que no accedan a un registro de forma unvoca (SELECT SINGLE) no acceden al buffer y van
directamente a base de datos.
Si una tabla se graba en memoria intermedia, con forma de grabacin por mbito genrico,
sentencias que no especifiquen de forma unvoca ese mbito genrico, no acceden al buffer y
seleccionan los datos directamente de la
7.3.5
UTILIZACIN DE TABLAS INTERNAS
7.3.5.1
Asignacin de memoria
El uso de memoria por las tablas internas en ABAP/4 depende de varios factores: El requisito
bsico corresponde al producto de la anchura del registro por el nmero de lneas en la tabla. La memoria
se asigna en bloques de 8Kb o 16Kb. La localizacin y la forma en la que se asigna el primer bloque de
memoria depende del sistema y la versin de ste, de la siguiente manera:
-
En sistemas en los que las tablas internas se almacenan en el rea de paginacin de SAP, es decir,
en sistemas con versiones 2.1/2.2, y en sistemas con versin 3.0/3.1, en los que el parmetro de la
instancia ABAP/use_paging est activo (nunca en sistemas en versin 4.0).
En estos sistemas el primer bloque de memoria asignado a una tabla interna se almacena en el
rea de roll con tamao:
Anchura de registro x Valor OCCURS
Las siguientes lneas se almacenan en bloques de 8Kb en el rea de paginacin. En estos
sistemas, un valor OCCURS de 0, provoca que la tabla se almacene completamente en el rea de
paginacin.En estos sistemas, el valor OCCURS sirve para determinar cuntas entradas de la
tabla se van a guardar en la memoria principal.
En sistemas que utilizan el nuevos sistemas de gestin de memoria SAP, es decir, en sistemas en
versin 3.0/3.1 en los que el parmetro de la instancia ABAP/use_paging no est activo y siempre en
sistemas en versin 4.0.
En estos sistemas, todas las entradas de tabla se almacenan en el rea de roll. El parmetro
OCCURS slo tiene efecto cuando:
Anchura de registro x valor OCCURS < 8Kb
Pgina 64 de 84

Comunidad de Madrid
En este caso, el primer bloque se crea con el tamao mnimo (Anchura de registro x valor
OCCURS). Un valor de OCCURS 0 provoca que el primer bloque y los siguientes, se cree con un
valor de entre 8 y 16 KB. En estos sistemas, el valor OCCURS se utiliza para evitar una utilizacin
innecesaria de la memoria principal al almacenar en ella tablas pequeas.
7.3.5.2
ndices en tablas internas
Se crea un ndice para realizar las siguientes operaciones sobre tablas internas:
-
Al insertar una lnea antes que otra ya existente con la instruccin (INSERT).
Cuando se borra una lnea (no la ltima).
Cuando se ordena la tabla con SORT.
El ndice de la tabla se crea en el rea de roll. Son necesarios 4 bits por cada registro del ndice, y es
necesaria una entrada en el ndice por cada entrada en la tabla. SAP asigna memoria para la creacin
del ndice de forma que inicialmente quepan a priori ms entradas de las necesarias.
Debido a que el ndice no puede particionarse, cuando son necesarios ms registros en el ndice de los
estimados, es necesario reubicar completamente el ndice, esto puede hacerse:
-
Durante la ordenacin es necesario asignar memoria adicional, aunque esta se libera al terminar el
proceso de ordenacin.
Cuando se borra una lnea con DELETE itab, la entrada slo se borra de forma lgica y por tanto la
memoria ocupada por el registro no se libera, sino que se retiene internamente para ser ocupada por
nuevas entradas.
Cuando se borra una tabla interna con REFRESH itab, se liberan fsicamente todos los bloques de
memoria utilizados por la tabla excepto el inicial y el ndice (si existe).
Cuando se libera una tabla con FREE itab, se liberan fsicamente todos los bloques de memoria
incluyendo el inicial y el espacio ocupado por el ndice.
Si se carga una tabla interna itab_dest con las instrucciones:

o
MOVE itab TO itab_dest.
SELECT ... INTO TABLE itab_dest.
IMPORT itab_dest FROM ...
Se provoca un REFRESH automticamente de los datos anteriores existentes en la tabla

itab_dest.
7.3.5.3
Ordenacin de tablas internas no grandes
Cuando se ejecuta una instruccin SORT sobre una tabla interna o un FIELD-GROUP, se crea
un ndice para la tabla, ya que nunca se ordena fsicamente la tabla, sino que slo se produce la
ordenacin del ndice. Por lo tanto, cuando se ordenan tablas muy grandes, puede requerirse un gran
volumen de memoria adicional para crear el ndice. Este problema se incrementa cuando la tabla o el
FIELD-GROUP se ordena por una secuencia de campos diferente al de la definicin.
En general este mtodo tiene un mejor rendimiento durante la ordenacin fsica de la tabla, pero
tiene un peor rendimiento en los recorridos de la tabla, ya que en el caso de grandes tablas, puede
provocarse paginacin.Para evitar esto, en caso de necesitar hacer varios recorridos, es a veces mejor
almacenar la tabla una vez ordenada e inmediatamente volver a leerla con las sentencias
EXPORT/IMPORT o TRANSFER/READ DATASET. Este mtodo implica que la tabla quedar fsicamente
ordenada.
Pgina 65 de 84

Comunidad de Madrid
7.4
Procesamiento en paralelo
A veces resulta muy conveniente poder partir un proceso en varios ms sencillos y que se
ejecuten a la vez, de manera que el rendimiento aumenta de forma considerabe.A partir de versin 3.0A,
SAP R/3 permite la divisin de determinadas tareas de forma que todas estas divisiones pueden
procesarse en paralelo.
La gestin de procesamiento paralelo es una funcionalidad que debe ser utilizada con mucha
prudencia, siempre tras un detenido anlisis y tras la consulta con el equipo de soporte ABAP/4 del
proyecto.
Aunque a priori, este mtodo de procesamiento puede inicialmente parecer una gran ventaja,
debe utilizarse siempre con mucho cuidado, ya que puede llevar a graves deterioros en el rendimiento
global del sistema. Esto es debido a que el procesamiento asncrono de los datos en las distintas tareas
ejecutadas, puede provocar graves inconsistencias en el sistema, debido a que las tareas deben
ejecutarse sin referencia a otros datos que estn siendo procesados en paralelo por otro proceso, y las
tareas ejecutadas no pueden ser dependientes de los resultados de otros procesos paralelos
concurrentes.
Algunos programas, especialmente los reports, en sistemas con un gran volumen de datos se
ejecutan en batch por la noche, y tendrn una duracin de varias horas, pudiendo llegar a ser difcil su
terminacin durante la ventana batch. Estos reports de larga duracin pueden implementarse utilizando
tcnicas de procesamiento paralelo, que permite la divisin del trabajo en varios procesos de trabajo y
recoger sus resultados.
El procesamiento on-line tambin soporta el procesamiento paralelo de programas.
7.4.1
-
PRERREQUISITOS
Unidades de trabajo independientes: La tarea debe ejecutarse sin referencia a otros datos que estn
siendo procesados en paralelo por otro proceso, y las tareas ejecutadas no pueden ser dependientes
de los resultados de otros procesos paralelos concurrentes.
Por ejemplo, el procesamiento paralelo, no es adecuado para datos que deben ser procesados
secuencialmente o para datos en los que un registro depende del procesamiento de otro. Por definicin,
no hay ninguna garanta de que los datos se procesen en un orden determinado ni de que un resultado
particular est disponible en un punto dado del procesamiento.
-
Prerrequisitos
o
El mdulo de funcin llamado debe estar definido con Apoyo Remote Function Call.
El mdulo de funcin llamado no puede contener ninguna llamada a funcin con destino
BACK.
El programa llamador no puede pasar a un modo interno despus de la llamada a la funcin

RFC, es decir, no puede usarse CALL TRANSACTION ni SUBMIT despus de CALL
FUNCTION STARTING NEW TASK.
No puede usarse CALL FUNCTION STARTING NEW TASK DESTINATION IN GROUP para
llamar a programas externos.
En llamadas entre sistemas SAP, ambos deben tener versin 3.0A o superior.
Para poder procesar tareas de jobs paralelos, al menos un servidor del grupo de servidores
definidos desde la transaccin RZ12 debe tener al menos 3 procesos de trabajo de dilogo.
7.4.2
MDULOS DE FUNCIN Y SENTENCIA ABAP
Se puede implementar procesamiento paralelo en nuestras aplicaciones batch utilizando los

siguientes mdulos de funcin y palabras clave:
-
El mdulo de funcin SPBT_INITIALIZE.
Pgina 66 de 84

Comunidad de Madrid
Opcional. Se utiliza para determinar los recursos disponibles para el procesamiento paralelo de
un programa. Con ella se puede:
Comprobar que el grupo de servidores para procesamiento paralelo indicado es correcto.
Averiguar el nmero de procesos de trabajo disponibles para determinar el nmero de

bloques en que podemos dividir el trabajo.
La palabra clave CALL FUNCION <funcin> STARTING NEW TASK <nombre de tarea> con el
argumento DESTINATION IN GROUP:
Con esta instruccin se indica al sistema SAP que procese el mdulo de funcin indicado en
paralelo. Normalmente se indica esta llamada en un bucle en el que dividimos el trabajo a realizar en
paquetes para el procesamiento paralelo. A la funcin le pasamos los datos que queremos procesar en
forma de parmetros y tablas internas (EXPORT y TABLES). La instruccin implementa el procesamiento
paralelo ejecutando llamadas RFC asncronas a los servidores disponibles en el grupo de servidores
especificado para procesamiento paralelo. Notar que las llamadas RFC ejecutados con CALL
TRANSACTION se ejecutan en procesos de trabajo de dilogo. El lmite de tiempo para ejecucin on-line
(300 segundos) se aplica tambin para las llamadas RFC.
-
El mdulo de funcin SPBT_GET_PP_DESTINATION.
Opcional. Debe ser llamado inmediatamente despus de CALL FUNCTION... para obtener el
nombre del servidor en el que correr la tarea.
-
El mdulo de funcin SPBT_DO_NOT_USE_SERVER.
Opcional. Excluye un servidor en particular para posteriores tareas de procesamiento paralelo.

Usado junto con SPBT_GET_PP_DESTINATION si no se quiere utilizar un servidor.
-
La instruccin WAIT.
Es necesaria si se quiere esperar a que terminen todas las llamadas asncronas ejecutadas con
CALL TRANSACTION.
-
La instruccin RECEIVE.
Obtiene los resultados del procesamiento de una funcin asncrona RFC. Se obtiene el IMPORT
y TABLES de la funcin junto con las EXCEPTIONS.
7.4.3
MANEJO DE LOS RECURSOS CON GRUPOS DE SERVIDORES RFC
El sistema de procesamiento paralelo est diseado de modo que elimina la posibilidad de que
un job paralelo pueda utilizar todos los recursos del sistema SAP R/3 y causar problemas de rendimiento
en otros jobs o usuarios. Adicionalmente, se puede optimizar los recursos a travs de los grupos de
servidores RFC. En el contexto de procesamiento paralelo, un grupo especifica un conjunto de servidores
de aplicacin SAP R/3 que pueden utilizarse para ejecutar un programa paralelo en particular. Por
defecto, el grupo comprende todos los servidores de aplicacin. Pero se pueden crear grupos ms
restringidos desde la transaccin RZ12, o bien: Herramientas -> Gestin -> Gestin -> Red -> Destinos
RFC -> RFC -> Grupos RFC.
El grupo de servidores debe indicarse en las llamadas a las funciones SPBT_INITIALIZE (si se
usa), y en la llamada CALL FUNCTION STARTING NEW TASK.
7.4.4
MENSAJES Y EXCEPCIONES
En el mdulo de funciones llamado, se deben utilizar excepciones para reportar al programa

principal cualquier motivo de error, y nunca la instruccin MESSAGE. Adems de las excepciones
definidas por la funcin se dispone de dos excepciones adicionales: SYSTEM_FAILURE y
COMMUNICATIONS_FAILURE.
Pgina 67 de 84

Comunidad de Madrid
7.4.5
AUTORIZACIONES
Si el parmetro de perfil auth/rfc_authority_check est activo (valor 1),

el sistema
automticamente verifica en la sentencia CALL FUNCTION si el usuario del job batch tiene las
autorizaciones RFC necesarias.
El objeto de autorizacin es S_RFC. La verificacin de autorizacin comprueba el acceso a los
mdulos de funcin por el grupo de funciones. Es decir, comprueba si el usuario est autorizado a
ejecutar funciones pertenecientes a un grupo.
Pgina 68 de 84

Comunidad de Madrid
Verificaciones del Code Inspector
Como norma general, cada programador de la factora ser responsable de entregar el cdigo a
su responsable tcnico habiendo pasado los controles especificados de la calidad del Cdigo Fuente.
Para ello SAP nos proporciona la herramienta Code Inspector.
El coordinador tcnico dar de alta la Variante de Verificacin DEFAULT para todos los usuarios
desarrolladores asignados al proyecto como copia de la global pero aadiendo parmetros necesarios
propuestos por el proyecto.
El Code Inspector facilita un log muy completo de los errores que hay en el cdigo y de su
rendimiento a nivel de sistema. La clasificacin de este tipo de errores es:
-
Error Este tipo de errores, implican un problema grave de rendimiento, problemas con el acceso a
tablas (por tamao, ndices), seguridad, verificacin de sintaxis/generacin (puede realizar
llamadas dinmicas) y de superficies. Este tipo de errores, deben ser solucionados en el sistema,
antes de su transporte al entorno de calidad.
Advertencia Se debern corregir siempre que sea posible. En los casos en los que esto no sea
posible, se deber especificar, en el diseo tcnico del programa, el motivo de los mensajes.
Informativo No es necesaria su documentacin.
A continuacin, se describe las posibles verificaciones del Code Inspector.
8.1
Anlisis de condicin WHERE para SELECT
Este chequeo examina la condicin WHERE de las sentencias SELECT para accesos a tablas no
cacheadas, de acuerdo a los siguientes criterios (los JOINS no se procesan):
-
SELECT que no continen ninguna condicin WHERE
La condicin WHERE no contiene ningn campo ndice en la tabla
La condicin WHERE no contiene ningn campo inicial de algn ndice de la tabla
Aunque se ha especificado CLIENT SPECIFIED, la condicin WHERE no incluye el campo CLIENT
La tabla no existe o no existe entrada en nametab.
La prioridad del mensaje depende de la categora de tamao de la tabla accedida.
8.2
Anlisis de condicin WHERE para UPDATE y SELECT
Este chequeo examina la condicin WHERE de las sentencias UPDATE y DELETE de acuerdo a
los siguientes criterios:
-
La condicin WHERE no existe
La condicin WHERE no contiene ningn campo ndice en la tabla
La condicin WHERE no contiene ningn campo inicial de algn ndice de la tabla
Aunque se ha especificado CLIENT SPECIFIED, la condicin WHERE no incluye el campo CLIENT
8.3
Sentencias SELECT que se leen en memoria intermedia de tablas
El cache de tablas en el servidor de aplicacin optimiza las lecturas de tablas de la base de datos. Este
chequeo verfica la existencia de sentencias SELECT que puentean dicho cacheo:
-
SELECT ... FOR UPDATE and SELECT ... BYPASSING BUFFER
Uso de JOIN
Uso de subqueries
Uso de funciones agregadas COUNT, MAX, MIN, SUM, AVG
Pgina 69 de 84

Comunidad de Madrid
-
Select DISTINCT
Group by
Order by
IS not NULL en select
SELECT SINGLE sin especificar toda la clave
8.4
Sentencias SELECT con CHECK posterior
Busca sentencias CHECK inmediatamente despus de SELECT
8.5
SELECTS en loops
Busca SELECTS en bucles del tipo:

-
SELECT... ENDSELECT.
LOOP... ENDLOOP.
DO... ENDDO.
WHILE... ENDWHILE.
PROVIDE... ENDPROVIDE.
8.6
Modificacin en loops
Busca sentencias INSERT, MODIFY, DELETE, UPDATE en loops del tipo:

-
SELECT... ENDSELECT.
LOOP... ENDLOOP.
DO... ENDDO.
WHILE... ENDWHILE.
PROVIDE... ENDPROVIDE.
8.7
Loops anidados
Busca loops anidados en bucles del tipo.

-
SELECT ... ENDSELECT.
LOOP ... ENDLOOP.
DO ... ENDDO.
WHILE ... ENDWHILE.
PROVIDE ... ENDPROVIDE.
8.8
Operaciones no eficientes en tablas internas
Busca accesos a tablas internas no optimizados.
Pgina 70 de 84

Comunidad de Madrid
8.9
Traspasos de parmetros no eficientes
Busca parmetros no utilizados en rutinas, funciones, etc. o parmetros tipo tabla que por su
tamao pueden llegar a ser no eficientes
8.10 EXIT ninguna sentencia en loop SELECTENDSELECT

Busca la sentencia EXIT or RETURN dentro de un bucle SELECT..ENDSELECT o busca bucles
vacios del tipo SELECTENDESELECT.
8.11 Sentencias crticas

Busca sentencias crticas en cdigo del tipo:
-
CALL 'cfunc' ... Llamadas a funciones de sistema.
CALL TRANSACTION ...
SYSTEM-CALL ...
EDITOR-CALL ...
SUBMIT REPORT ...
EXEC ... ENDEXEC.
ROLLBACK WORK.
%_HINTS ...
GENERATE REPORT prog
READ REPORT / READ TEXTPOOL
INSERT/DELETE REPORT / INSERT/DELETE TEXTPOOL
IMPORT DYNPRO
EXPORT/DELETE DYNPRO
IMPORT NAMETAB
EXPORT NAMETAB
8.12 Accesos dinmicos y especficos en SELECT

Realiza los siguientes chequeos en la sentencia SELECT:
-
Accesos a tablas dinmicamente.
Condiciones dinmicas en el WHERE de la SELECT
Accesos complicados a ciertos tablas
Accesos especificando el mandante
8.13 Accesos dinmicos y especficos en INSERT, UPDATE, MODIFY y DELETE

Realiza los siguientes chequeos en las sentencias INSERT, UPDATE, MODIFY y DELETE:
-
Accesos a tablas dinmicamente.
Pgina 71 de 84

Comunidad de Madrid
-
Condiciones dinmicas en el WHERE de la SELECT
Accesos complicados a ciertos tablas
Accesos especificando el mandante
8.14 Verificacin tratamiento SY-SUBRC

Verifica el tratamiento del cdigo de retorno en las siguientes sentencias:
-
Write accesses to the database: INSERT, UPDATE, MODIFY, and DELETE
Read accesses to the database: SELECT, FETCH
Authorization check: AUTHORITY-CHECK
Function module call: CALL FUNCTION
Method call: CALL METHOD
Setting a lock: CALL FUNCTION 'ENQUEUE_...', CALL FUNCTION 'FLUSH_ENQUEUE'
Catch runtime error: CATCH...ENDCATCH
Dynamic assignment of a data object to a field symbol: ASSIGN * (f) TO <fs>
8.15 Verificacin de sintaxis

Verifica la correccin del programa
8.16 Verificacin de programas ampliada

La verificacin de programas ampliada realiza verificaciones estticas muy complejas para la
verificacin de sintaxis normal.
8.16.1 INTERFASES PERFORM/FORM

En particular, se han realizado las verificaciones siguientes para las llamadas PERFORM:
-
Test de si la definicin FORM llamada existe
Test de si el programa que contiene la definicin FORM existe y de que no contiene errores de
sintaxis
Test de si coincide la cantidad de parmetros reales y formales
Test de si coinciden las categoras de los parmetros (USING, CHANGING, TABLES)
Test de si los parmetros real y formal son compatibles
Test de si un literal se llama en un parmetro estructurado o en la categora CHANGING
Existen los tests siguientes para las definiciones FORM:

-
Test de si para una definicin FORM existe una llamada PERFORM
Listar los parmetros FORM sin tipo
Verificacin de si las excepciones que pueden producirse mediante PERFORM llamado externo o
CALL FUNCTION en una definicin FORM, aparecen en la clusula RAISING de FORM.
Pgina 72 de 84

Comunidad de Madrid
8.16.2 INTERFASES CALL FUNCTION

Por lo general, aqu estn agrupados los tests que verifican la llamada y la definicin de mdulos
de funciones (lo mximo posible de forma esttica).
En particular, se realizan las verificaciones siguientes:
-
Test de si en un mdulo de funciones llamada existe el grupo de funciones correspondiente y que no

contiene errores
Test de si existen las funciones llamadas
Test de si se transfieren todos los parmetros necesarios
Test de que no se transfieren parmetros desconocidos
Test de si los parmetros tienen la categora correcta (IMPORT, EXPORT, TABLES, EXCEPTION)
Test de si los parmetros real y formal son compatibles
Test de si para EXCEPTION's se realiza un tratamiento SY-SUBRC
Test de si la clusula RAISING intercepta todas las excepciones correctamente
Test de si un mdulo de funciones est identificado como obsoleto
En los grupos de funciones se verifica en las definiciones de mdulos de funciones:

-
Test de si un mdulo de funciones contiene una entrada TFDIR
Test de si para cada EXCEPTION existe un comando RAISE y si para cada comando RAISE aparece
una EXCEPTION.
8.16.3 TEST SUBMIT VS.INTERFASE REPORT

Por lo general, aqu se agrupan los tests que verifican las llamadas CALL TRANSACTION,
LEAVE TO TRANSACTION, CALL DIALOG, SUBMIT y USER EXIT's (lo mximo posible de forma
esttica).
En particular, se realizan las verificaciones siguientes:
-
Test de si existe un cdigo de transaccin en la tabla de base de datos TSTC
Test de si existe un mdulo de dilogo en la tabla de base de datos TDCT
Test de si un report llamado mediante SUBMIT tiene el tipo 1
Test de si los programas llamados son correctos sintcticamente
Test de si todos los parmetros SUBMIT indicados mediante WITH estn definidos en el report.
En el caso de EXITS DE USUARIO, el test contiene

o
Falta ampliacin de exit de usuario
Falta Modulo de Funciones con interfase en un GF (X...)
Modulo de Funciones no est desactivado mediante TMOD/SMOD
8.16.4 VERIFICACIONES DE CONSISTENCIA DE DYNPRO

Este test realiza una verificacin de cada Dynpro del programa que se indique relativo a los errores que a
continuacin se describen:
-
En los atributos dynpro se ha introducido una secuencia dynpro que no existe.
Llamada de un mdulo no definido en el modulpool.
El campo dynpro no est definido ni en DDIC ni en el programa.
Pgina 73 de 84

Comunidad de Madrid
-
CALL SUBSCREEN con una variable no definida
CALL SCREEN / SET SCREEN / CALL SUBSCREEN para un dynpro no definido
Un mdulo definido en el programa no se utiliza.
En los atributos dynpro se ha introducido un campo no existente como posicin de cursor.
Entrada de un contexto del elemento de datos para un campo no DDIC
El contexto del elemento de datos introducido no existe.
El campo Dynpro no tiene nombre en la lista de campos (el campo dynpro es una mscara de
edicin o un campo de palabra clave que no slo tiene carcteres especiales).
En la lgica de proceso existen referencias a un campo que no est definido en la lista de campos.
8.16.5 VERIFICACIN DE TABLAS LOAD

En el ncleo R/3 existen lmites superiores para ciertas partes integrantes (Load-Parts) de un
programa ABAP. La verificacin de programa ampliada enva un mensaje en cuanto un programa llega al
menos al noventa por ciento de este lmite superior. La verificacin de programa ampliada slo
comprueba
aquellas
partes
para
las
que
existe
un
lmite
superior,
a
saber:
Descripcin parte
Lmite superior
HEAD
Magnitud de programa direccionable -> 2 097 152 Bytes
DATA
Descripcin de datos esttica -> 16 384 Entradas
DATV
Descripciones de datos variables -> 16 384 Entradas
LITL
Literales -> 65 536 Bytes
COMP
Descripciones de estructura -> 65 536 Entradas
INCL
Nmero de programas Include -> 4 000 Includes
Si se supera el 90 por ciento del lmite superior, saldr un mensaje. A partir del 95 por ciento
aparece una advertencia y a partir del 98 se visualiza como un error el hecho de haber llegado al lmite.
A muy tardar, a partir del lmite de errores, debe transferirse el resto de coding a mdulos de
funcin o a una rutina FORM externa. Por lo general resulta preferible reservar un 10 por ciento por lmite
superior en cada programa, puesto que siempre se debe contar con que el cliente realizar
modificaciones.
8.16.6 AUTORIZACIONES
Este test verifica si el objeto de autorizacin especificado se encuentra en la tabla TOBJ y si los
mbitos de autorizacin se han especificados correctamente.
8.16.7 STATUS-PF INCORRECTOS

En particular, se han realizado las verificaciones siguientes:
Pgina 74 de 84

Comunidad de Madrid
-
Test de si el STATUS PF est definido
Test de si el TTULO est definido
Test de si una definicin de STATUS aparece en un pool de formularios
Test de si una llamada SET TITLEBAR aparece en un pool de formularios
8.16.8 IDS PARMETRO SET/GET INCORRECTOS

Verifica si todos los parmetros SET/GET utilizados estn definidos en la tabla TPARA y la
longitud de campo es lo suficientemente larga.
8.16.9 INSTRUCCIONES MESSAGE INCORRECTAS

Este test contiene las verificaciones siguientes:
-
Test de si los mensajes dirigidos estn definidos en la tabla T100
Verifica si la cantidad de parmetros transferidos con WITH coincide con la cantidad de parmetros
formales en el mensaje o en el texto explicativo correspondiente.
Si MESSAGE necesita un texto explicativo, se verifica:

o
Si existe el texto explicativo para MESSAGE
Si el texto explicativo para MESSAGE est activado
Si el texto explicativo para MESSAGE est obsoleto
8.16.10VERIFICAR TEXTOS
Test de strings:
-
En un string falta el elemento de texto
Elemento de texto no definido en el POOL DE TEXTOS
El string en el texto fuente contiene caracteres no permitidos
El elemento de texto finaliza con metafona
Strings diferentes con mismo ID de elemento de texto
Elemento de texto definido de forma diferente en pool de textos y programa
El elemento de texto no se utiliza
Elemento de texto en include compartido
Texto de seleccin superfluo
El texto de seleccin est sin actualizar
Pool de textos inconsistente
8.16.11OPERACIONES EN CAMPOS
Activar el test CURRENCY/UNIDAD: Verifica si en una sentencia WRITE
-
se ha introducido un campo con el tipo DDIC CURR (importe de la moneda) sin el apndice
CURRENCY (==> WRITE CURRENCY) o
un campo con el tipo DDIC QUAN (indicacin de cantidad) sin el apndice unidad (==> WRITE UNIT)
Pgina 75 de 84

Comunidad de Madrid
8.16.12PROPIEDADES DE CAMPOS
-
Ayuda para bsqueda no definida
Valor inicial demasiado para tipo de campo
Campos no utilizados
Campos no ledos
El nombre de campo es idntico a un tipo predefinido pero tiene otro tipo.
El nombre de campo es idntico a un nombre de operador.
El nombre de campo contiene un guin como parte del nombre.
Los resultados se visualizan a modo de resumen siempre que no est activada la primera funcin
adicional. Haciendo doble clic se puede pasar desde ah a la(s) descripcin(ones) de errores y a la(s)
posicin(ones) correspondiente(s) de cdigo fuente.
8.16.13VERIFICAR PLURILINGISMO
Verifica si las sentencias TRANSLATE-.. TO UPPER/LOWER CASE trabajan en el entorno de idioma
correcto.
Se visualizan las sentencias TRANSLATE... TO UPPER/LOWER CASE que trabajan con campos de tabla
sin llamar poco antes el SET LOCALE LANGUAGE.
Existen dos casos distintos:
-
En la misma tabla que contiene el campo con el que trabaja TRANSLATE existe un campo de idioma.
En los casos aqu visualizados aparecen los datos procesados en una tabla que contiene un campo
de idioma (en clave o seccin de datos). Es muy probable que con ste se pueda configurar el
entorno de idioma correcto antes de ejecutar la sentencia TRANSLATE.
La tabla tratada no contiene ningn campo de idioma. En el caso de que la tabla actual no contenga
ningn campo de idioma, la correccin tarda ms en realizarse. Se puede determinar el idioma a
partir de datos cercanos, o bien debe introducirse posteriormente un campo de idioma que habr que
completar con valores.
8.16.14VERIFICACIONES DE PAQUETES
Para todos los programas referidos de forma externa de un programa ABAP as como para las
definiciones de Dictionary ABAP referidas se verifica lo siguiente:
-
Si se suministra el programa ABAP, tambin se suministran objeto referidos de forma externa.
Que el programa utiliza slo objetos de paquetes permitidos.
8.16.15SENTENCIAS SUPERFLUAS
-
El programa contiene sentencias BREAK-POINT
El programa contiene un flujo de control dependiente de usuario. (Si se utiliza en una condicin SYUNAME)
Sentencias trace, por ejemplo, para el anlisis de tiempo de ejecucin (SET RUN TIME..) o el
comando SYNTAX-TRACE ON.
Una sentencia consta slo de un punto.
Tras EXIT, RETURN, STOP, RAISE o SUBMIT.. AND RETURN existen otras sentencias.
Pgina 76 de 84

Comunidad de Madrid
8.16.16SENTENCIAS PELIGROSAS
-
Ayuda para bsqueda no definida
Valor inicial demasiado para tipo de campo
Campos no utilizados
Campos no ledos
El nombre de campo es idntico a un tipo predefinido pero tiene otro tipo.
El nombre de campo es idntico a un nombre de operador.
El nombre de campo contiene un guin como parte del nombre.
Los resultados se visualizan a modo de resumen siempre que no est activada la primera funcin
adicional. Haciendo doble clic se puede pasar desde ah a la(s) descripcin(ones) de errores y a la(s)
posicin(ones) correspondiente(s) de cdigo fuente.
8.16.17MENSAJES DE ADV.O AMPL.ESTRUCTURA

En este punto se da salida a los mensajes de advertencia de la verificacin de sintaxis o
ampliaciones de estructura. Igualmente, aqu los mensajes de advertencia o las ampliaciones de
estructura en la comparacin de firmas son visualizados por mdulos de funciones y llamadas PERFORM
externas.
8.16.18SENTENCIAS OBSOLETA
En este punto se indican sentencias obsoletas incluidas en el cdigo fuente.
Pgina 77 de 84

Comunidad de Madrid
ANEXO1 - Funcionalidades del proyecto NEXUS02

ECOFIN
CDIGO
ESCENARIO
EP
MC
CG
TE
CO
EG
EI
TR
OE
AF
EG
SB
RF
CF
CD
OP
OC
CC
CN
MODULO SAP (AAAA)
DESCRIPCIN
BPC_
Elaboracin Presupuestaria
EAPS
Modificaciones de Crdito
FIGL
Contabilidad General
FIAR / FIAP / FIBP
Terceros (es transversal)
COCA
Contabilidad Analtica
EAPS
Ejecucin Gastos
EAPS
Ejecucin Ingresos
FITR
Tesorera
FIGL
Extrapresupuestaria
FIAA
Activos Fijos
EAPS / PS__
Proyectos
Subvenciones (El cdigo a utilizar depender
del mdulo donde se localice el desarrollo
EAPS / BPC_ / BCS_ / GM__ correspondiente)
IM__
Registro de facturas (Transversal)
EAPS / FI__ / IM__
Caja Fija/Pagos a Justificar
FI__ / FITR
Caja de Depsitos y Garantas
CFM_
Operaciones financieras
FI__ / EAPS
Operaciones comerciales
FI__ / EAPS
Cierres y Cambio de estructura
BI__ / EAPS / FI__ / PI__
Contabilidad Nacional (Transversal)
LOGSTICA
MM
LA
PM
FT
MM__ / SRM_ / MDM_
Maestro de Materiales
MM__ / WM__
Logstica(Compras) & Almacenes
PM__
Mantenimiento
SD__
Facturacin a terceros
RC
PR
RL
CM
BI__ / RMS_
Registro de Contratos
PPS_ / RMS_ / WF__
Procedimientos de Contratacin
BP__
Registro de Licitadores (ver con terceros)
MM__
Catlogos Material (CPV, etc.)
EXPEDIENTES DE CONTRATACIN
Pgina 78 de 84

Comunidad de Madrid
10 ANEXO2 Funcionalidades del proyecto NEXUS03

RRHH
CDIGO
ESCENARIO
MODULO SAP (AAAA)
DESCRIPCIN
OM
OM01
Definicin de Estructura Organizativa
OM
OM
OM
OM
OM
OM
PA
PA
PA
PA
OM02
Actualizaciones Estructura. Organizativa sin

Expediente
OM03
Expedientes modificacin estructura
OM04
Plantilla y Relacin de Puestos de Trabajo
OM05
Cobertura de vacantes por interinos
OM06
Conexin con otras aplicaciones
OM07
Sistema de Informacin
PA01
Incorporaciones/Extinciones
PA02
Situaciones administrativas
PA03
Gestin de absentismos
PA04
Reconocimientos
PA
PA
PA
PA
PS
RE
PY
PY
PA05
Otras funciones departamentales

(uniformidad)
PA06
Altos cargos y personal directivo.
PA07
Conexin Otras Aplicaciones
PA08
Sistema de Informacin e Interfaces
PS__
Seleccin y Provisin
REG1
Registro de Personal
PY02
Conceptos Nmina
PY03
IRPF
PY
PY
PY
PY
PY
PY
PY
GP
GP
GP
GP
PS
PS
PS
PS
PY04
Integracin Presupuestaria / Contabilidad /

Intervencin
PY05
Gestin de las Nminas Negativas
PY06
Integracin con Tiempos
PY07
Seguridad Social
PY08
No Implantados
PY09
Centros Concertados
PY10
GP01
Proyeccin y Control del Gasto de nmina.
GP02
GP03
Elaboracin del Anteproyecto de Capitulo 1.

Seguimiento de Empresas y Entes Pblicos.
GP04
PS01
Seleccin de personal.
PS02
Concurso de Traslados
PS03
Provisin y movilidad administrativa
PS04
LB
Cobertura interina.
Bolsas de Empleo.
LB01
Pgina 79 de 84

Comunidad de Madrid
PS
PS
PT
PT
PD
PD
PE
PE
AS
EH
EH
PS05
Elaboracin de Censos Sindicales de los

distintos colectivos.
PS06
Integracin de Provisin y Registro
PT01
Gestin de turnos
PT02
PD01
Gestin de Carrera Profesional.
PD02
Evaluacin por objetivos y competencias.
PE01
Formacin
PE02
Integracin de Registro con Formacin
AS01
Accin Social
EHS1
Prevencin de riesgos
EHS2
Salud laboral - Asistencia Mdica
Pgina 80 de 84

Comunidad de Madrid
11 ANEXO3 - Plantilla de codificacin de programas ABAP
*--------------------------------------------------------------------------------------------------*
*
*
* ID_PROGRAMA: ZPAAAATxxxxxxxxxxxxxx..xxxx
*
*
* TIPO DE PROGRAMA:
*
*
*
* DESCRIPCIN:
*
*
*
*
*
*
*
* AUTOR: USUARIO SAP Y NOMBRE Y APELLIDOS
*
*
*
* FECHA DE CREACIN: dd/mm/aaaa
*
*
*
*--------------------------------------------------------------------------------------------------*
* CHEQUEOS DE AUTORIZACIN
*
*
*
* Objetos de autorizacin campos ABAP
*
*
*
*
*
*
*
*--------------------------------------------------------------------------------------------------*
*
*
*
*
*
* FECHA
DESCRIPCION
AUTOR MARCA CODIGO S.Desk *
* ----------------- ------------------------- -------------- ------------------------ ---------- *
* dd/mm/aaaa
usuario
*
*
*
*
*
*
*
* dd/mm/aaaa
usuario
*
* ...
...
*
*--------------------------------------------------------------------------------------------------*
REPORT ZEAAATXXXXXNNN NO STANDARD PAGE HEADING LINE-SIZE 250.

******************************************************************************************
*
*
* DECLARACION DE VARIABLES, TABLAS, TIPOS Y ESTRUCTURAS
*
*
*
******************************************************************************************
* INCLUDES
* INCLUDE:
* TABLAS DEL SISTEMA
* TABLES:
* DEFINICIN DE TIPOS
Pgina 81 de 84

Comunidad de Madrid
* TYPES:
* Tipos necesarios para el listado ALV
* TYPE-POOLS: slis.
* DECLARACION DE CONSTANTES
* CONSTANTS:
* DEFINICION DE ESTRUCTURAS
* DATA:
* DEFINICION DE TABLAS INTERNAS
* DATA:
* DEFINCION DE RANGOS
* RANGES:
* DEFINICION DE VARIABLES
* DATA:
* DEFINICION DE CLASES Y METODOS
*CLASS lcl_application DEFINITION DEFERRED.
*-----------------------------------------------------------------------*
*
CLASS lcl_application DEFINITION
*-----------------------------------------------------------------------*
*CLASS lcl_application DEFINITION.
* PUBLIC SECTION.
* METHODS
*
*
handle_item_double_click FOR EVENT item_double_click

OF cl_gui_alv_tree IMPORTING node_key.
*ENDCLASS.
"lcl_application DEFINITION
*-----------------------------------------------------------------------*
*
CLASS lcl_application IMPLEMENTATION
*-----------------------------------------------------------------------*
*CLASS lcl_application IMPLEMENTATION.
* METHOD handle_item_double_click.
*
CODIGO DEL METODO
* ENDMETHOD.
*ENDCLASS.
"handle_item_double_click
"lcl_application IMPLEMENTATION
Pgina 82 de 84

Comunidad de Madrid
*******************************************************************
*
*
*
CODIGO DE PROGRAMA
*
*
*
*******************************************************************
**** PANTALLA DE SELECCION ****
*SELECTION-SCREEN BEGIN OF BLOCK seleccion WITH FRAME TITLE text-001.
*
SELECT-OPTIONS: s_xxxx FOR XXXXX.
"XXXXXX
PARAMETERS: p_xxxxx LIKE XXXXXX OBLIGATORY.
"XXXXXX
*SELECTION-SCREEN END OF BLOCK selecion.

*SELECTION-SCREEN BEGIN OF BLOCK selecion2 WITH FRAME TITLE text-002.
*
SELECT-OPTIONS: s_xxxx FOR XXXXX.
"XXXXXX
PARAMETERS: p_xxxxx LIKE XXXXXX OBLIGATORY.
"XXXXXX
*SELECTION-SCREEN END OF BLOCK selecion2.
**** AT SELECTION-SCREEN ON VALUE-REQUEST ****

*AT SELECTION-SCREEN ON VALUE-REQUEST FOR ...
**** VALIDACIONES DE LOS PARMETROS DE ENTRADA ****

*AT SELECTION-SCREEN.
**** DEFINICIN DE ACCIONES POR DOBLE CLIC ****

*AT LINE-SELECTION.
**** CONTROL DE ACCIONES A TOMAR SEGN ENTRADA DEL USUARIO ****

*AT USER-COMMAND.
**** INITIALIZATION ****

*INITIALIZATION.
* Limpiar tablas y variables globales de trabajo
* REFRESH: XXXXX.
* CLEAR: XXXXX.
Pgina 83 de 84

Comunidad de Madrid
**** PROCESO PRINCIPAL ****

*START-OF-SELECTION.
* Realizamos la seleccin de datos
* PERFORM seleccionar_datos.
**** ACCIONES DE FINAL DE PROCESO ****

*END-OF-SELECTION.
* Mostramos el listado ALV
* PERFORM mostrar_listado TABLES gt_XXX USING 'XXXX'.
**** DEFINCIN DE CABECERAS DE LISTADO ****

*TOP-OF-PAGE.
**** DEFINICIN DE LNEAS DE PIE DE LISTADO ****

*END-OF-PAGE.
***********************************************************************
*
*
*
RUTINAS
*
*
*
***********************************************************************
*&--------------------------------------------------------------------*
*&
Form mostrar_listado
*
*&--------------------------------------------------------------------*
*&
Salida por pantalla de los datos seleccionados
*
*&--------------------------------------------------------------------*
*& --> p_ta_listado
Tabla con los datos a mostrar
*
*& --> pe_nombre_table Nombre de la tabla para catalogo de campos *
*---------------------------------------------------------------------*
*FORM mostrar_listado TABLES p_ta_listado USING pe_nombre_tabla.
*ENDFORM.
" mostrar_listado
Pgina 84 de 84

NEXUS02 E0 NO02 00 GG Normativa Desarrollo ABAP 00.06

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

NEXUS02 E0 NO02 00 GG Normativa Desarrollo ABAP 00.06

Загружено:

Авторское право:

Доступные форматы

Normativa de desarrollo ABAP (NO02)

Proyecto: Modernizacin y externalizacin de los

Nombre del fichero:

Javier Carrero Snchez

Modernizacin y externalizacin de los Sistemas de

Historial de la versin (si procede)

Javier Carrero Snchez

Elaboracin del documento

Javier Carrero Snchez

Re-elaboracin del documento

Javier Carrero Snchez

Correccin del documento

Javier Carrero Snchez

Correccin del documento.

Javier Carrero Snchez

Correccin del documento 00.04

Cambio del estado del documento.

Javier Carrero Snchez

Aadir cambios del documento PRO03

OBJETO DEL DOCUMENTO............................................................................................... 6

Estilo del cdigo fuente........................................................................................... 7

Sangrados en todas las sentencias......................................................................15

Resaltar palabras clave........................................................................................15

Una sentencia en cada lnea................................................................................15

Usar lneas en blanco para separar sentencias o grupos de sentencias..............16

NOMENCLATURA DE LOS OBJETOS.................................................................................17

CONVENCIN EN LA NOMENCLATURA DE OBJETOS..........................................................18

Cuadro resumen de nomenclatura de objetos......................................................18

Estructura del cdigo fuente.................................................................................22

Sangrados en todas las sentencias......................................................................24

Usar siempre la funcin PRETTY PRINTER con la opcin de resaltar palabras

Una sentencia en cada lnea................................................................................24

Modernizacin y externalizacin de los Sistemas de

Usar lneas en blanco para separar sentencias grupo de sentencias................25

Limitacin del n de lneas en cada bloque de proceso (Modularizacin)............25

Cuadro resumen de declaraciones.......................................................................26

PANTALLA DE SELECCIN Y DYNPROS............................................................................30

PARMETROS EN LAS SUBRUTINAS................................................................................31

Parmetros con TABLES, USING y CHANGING..................................................31

DECLARACIN DE TIPOS, VARIABLES Y CONSTANTES.......................................................25

CONTROLAR CDIGO DE RETORNO (SY-SUBRC)..............................................................36

NORMATIVA DE USUARIOS DE OSS...............................................................................38

CLASES DE DESARROLLO / PAQUETES...........................................................................39

CONCEPTO DE TRANSACCIN UNIDAD LGICA DE TRABAJO (L.U.W)...........................40

Acceso a la base de datos....................................................................................43

Instrucciones SQL Interfase.................................................................................44

Modificacin e insercin de datos.........................................................................48

Tratamiento de cadena de caracteres..................................................................49

Modernizacin y externalizacin de los Sistemas de

Tratamiento de tablas internas.............................................................................49

Sentencias DO..ENDDO, WHILE..ENDWHILE....................................................58

Manejo de variables y tipos..................................................................................58

Tratamiento de modos internos............................................................................60

Actualizacin de bases de datos..........................................................................60

Tablas transparentes en Memoria Intermedia (MI)...............................................62

Utilizacin de tablas internas................................................................................65

MEJORAS BASADAS EN EL SISTEMA................................................................................60

Mdulos de funcin y sentencia ABAP.................................................................67

Manejo de los recursos con grupos de servidores RFC.......................................68

VERIFICACIONES DEL CODE INSPECTOR.....................................................................70

ANLISIS DE CONDICIN WHERE PARA SELECT..........................................................70

ANLISIS DE CONDICIN WHERE PARA UPDATE Y SELECT........................................70

SENTENCIAS SELECT QUE SE LEEN EN MEMORIA INTERMEDIA DE TABLAS.......................70

SENTENCIAS SELECT CON CHECK POSTERIOR...........................................................71