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 (Econmico-Financiero, Compras, Logstica y Contratacin Pblica) de la Comunidad de MadridHistorial de la versin (si procede)

Versin nFecha de la versinRealizada por Descripcin

00.0106/09/2011Javier Carrero SnchezElaboracin del documento

00.0227/11/2011Javier Carrero SnchezRe-elaboracin del documento

00.0330/11/2011Javier Carrero SnchezCorreccin del documento

00.0414/12/2011Javier Carrero SnchezCorreccin del documento.

- Usuarios OSS

- Nomenclatura de objetos

00.0514/12/2011Javier Carrero SnchezCorreccin del documento 00.04

20.0014/12/2011AC&ACambio del estado del documento.

00.0603/10/2013Javier Carrero SnchezAadir cambios del documento PRO03

INDICE61Objeto del documento

72Estndares de desarrollo

72.1Metodologa de desarrollo

72.1.1Estilo del cdigo fuente

152.1.2Sangrados en todas las sentencias

152.1.3Resaltar palabras clave

152.1.4Una sentencia en cada lnea

162.1.5Usar lneas en blanco para separar sentencias o grupos de sentencias

173Estilo de programacin

173.1Nomenclatura de los objetos

183.2Convencin en la nomenclatura de objetos

183.2.1Cuadro resumen de nomenclatura de objetos

223.3Aspecto del cdigo fuente

223.3.1Estructura del cdigo fuente

233.3.2Uso de comentarios

243.3.3Sangrados en todas las sentencias

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

243.3.5Una sentencia en cada lnea

253.3.6Usar lneas en blanco para separar sentencias grupo de sentencias

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

253.4Declaracin de tipos, variables y constantes

263.4.1Cuadro resumen de declaraciones

263.4.2Declaracin globales

283.4.3Declaracin locales

303.5Pantalla de seleccin y dynpros

303.5.1Nomenclatura

303.5.2Aspecto

313.6Parmetros en las subrutinas

313.6.1Nomenclatura

313.6.2Parmetros con TABLES, USING y CHANGING

323.7Mdulos de funcin

333.7.1Nomenclatura

333.7.2Parmetros

333.7.3Programacin

343.8Literales en programas

353.9Excepciones

364Normas de desarrollo

364.1Controlar cdigo de retorno (sy-subrc)

364.2Limpiar variables

364.3Variables globales

364.4Tablas internas

374.5Liberar memoria

385Normativa de usuarios de OSS

396Conceptos importantes

396.1Clases de desarrollo / Paquetes

406.2Concepto de Transaccin Unidad Lgica de Trabajo (L.U.W)

437Rendimiento

437.1Recomendaciones generales

437.1.1Acceso a la base de datos

437.1.2Clculo y procesos

447.2Mejoras en la programacin

447.2.1Instrucciones SQL Interfase

487.2.2El WHERE en SELECT

487.2.3Modificacin e insercin de datos

497.2.4Tratamiento de cadena de caracteres

497.2.5Tratamiento de tablas internas

567.2.6Llamadas a subrutina

577.2.7Comparacin de caracteres

577.2.8Sentencias IF o CASE

587.2.9Sentencias DO..ENDDO, WHILE..ENDWHILE

587.2.10Tratamiento de FIELD-SYMBOLS

587.2.11Manejo de variables y tipos

607.3Mejoras basadas en el sistema

607.3.1Tratamiento de modos internos

607.3.2Actualizacin de bases de datos

607.3.3ndices de BD

627.3.4Tablas transparentes en Memoria Intermedia (MI)

657.3.5Utilizacin de tablas internas

677.4Procesamiento en paralelo

677.4.1Prerrequisitos

677.4.2Mdulos de funcin y sentencia ABAP

687.4.3Manejo de los recursos con grupos de servidores RFC

687.4.4Mensajes y excepciones

697.4.5Autorizaciones

708Verificaciones del Code Inspector

708.1Anlisis de condicin WHERE para SELECT

708.2Anlisis de condicin WHERE para UPDATE y SELECT

708.3Sentencias SELECT que se leen en memoria intermedia de tablas

718.4Sentencias SELECT con CHECK posterior

718.5SELECTS en loops

718.6Modificacin en loops

718.7Loops anidados

718.8Operaciones no eficientes en tablas internas

728.9Traspasos de parmetros no eficientes

728.10EXIT ninguna sentencia en loop SELECTENDSELECT

728.11Sentencias crticas

728.12Accesos dinmicos y especficos en SELECT

728.13Accesos dinmicos y especficos en INSERT, UPDATE, MODIFY y DELETE

738.14Verificacin tratamiento SY-SUBRC

738.15Verificacin de sintaxis

738.16Verificacin de programas ampliada

738.16.1Interfases PERFORM/FORM

748.16.2Interfases CALL FUNCTION

748.16.3Test SUBMIT vs.interfase report

748.16.4Verificaciones de consistencia de dynpro

758.16.5Verificacin de tablas Load

758.16.6Autorizaciones

768.16.7Status-PF incorrectos

768.16.8IDs parmetro SET/GET incorrectos

768.16.9Instrucciones MESSAGE incorrectas

768.16.10Verificar textos

768.16.11Operaciones en campos

778.16.12Propiedades de campos

778.16.13Verificar plurilingismo

778.16.14Verificaciones de paquetes

778.16.15Sentencias superfluas

788.16.16Sentencias peligrosas

788.16.17Mensajes de adv.o ampl.estructura

788.16.18Sentencias obsoleta

799ANEXO1 - Funcionalidades del proyecto NEXUS02

8010ANEXO2 Funcionalidades del proyecto NEXUS03

8211ANEXO3 - Plantilla de codificacin de programas ABAP

1 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.

2 Estndares de desarrollo2.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 programasLa 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-ABAP-00-GGPlantilla Programa ABAP-VF.01.txt

Existe una plantilla de codificacin ABAP para NEXUS03, ver documento NEXUS03-R0-ABAP-00-GGPlantilla Programa ABAP-VF.01.txt.

*---------------------------------------------------------------------------------------------------------*

*

*

* 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 *

* *

* *

* *


* ... ... *

*----------------------------------------------------------------------------------------------------------*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. 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:

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 (*

Las lneas que se aaden se marcarn al final de la lnea con el comentario nnnnn < - - -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 normativaNN(Se trata de un nmero secuencial.*----------------------------------------------------------------------------------------------------------*

* *

* EXCEPCIONES A LA NORMATIVA

*

*

*

* FECHA DESCRIPCION AUTOR MARCA CODIGO *

* ----------------- ------------------------- -------- ------------ ------------ *


* *

* *

* *


* ... ... *

*----------------------------------------------------------------------------------------------------------*

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. 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.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.

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.2.1.3 Resaltar palabras claveUsar 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 lneaUna sentencia ABAP por lnea de cdigo lo hace infinitamente ms legible.Forma errnea:

Forma correcta:

2.1.5 Usar lneas en blanco para separar sentencias o grupos de sentenciasSi 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.3 Estilo de programacin3.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.

3.2 Convencin en la nomenclatura de objetosZPAAAATxxxxxxxxxxxxxxxxxxxx Z- Para todos los objetos.P- Identificador del Proyecto: F - Nexus02, R - Nexus03.

AAAA Funcionalidad (mdulo SAP). Ver el Anexo1 y Anexo2 de este documentoT 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

ObjetoLong. Max.NomenclaturaComentariosReserva cdigo

Base de Datos Lgica3XXXNO

Batch y batch input12ZPAAAAexxxxxxe - (P) pruebas - (R) realNO

Clase de desarrollo30ZPAAAAxxxxxxxxxxx..xxxxS

Transacciones20ZPAAAAxxxxxxxxxxxxxxxS

Objeto de bloqueo16EZPAAAAxxxxxx.xxxxPara nombrar los objetos de bloqueo se usa normalmente los primeros dos caracteres EZ o EY.NO

Dominio30ZPAAAAxxxxxx.xxxxxNO

Elemento de datos30ZPAAAAxxxxxxxxxNO

Matchcode objetos4ZPxxNO

Matchcode ID10-9NO

Estructura Diccionario30ZPAAAAxxxxxxxxxxxNO

rea de Mensajes 20ZPAAAAxxxxx.xxxxxS

Nmero de mensaje3000-999NO

Programa Ejecutable

(Para ejecutables on-line)40ZPAAATxxxxx..xxxxxxxS

Programa Module Pool

(Se llama a travs de una transaccin) 40SAPMZPAAAAxxxxxx..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 moduloS

Programas de Infotipos8MP9NNN00S

Grupo Funcin26ZPAAAAxxxxxx..xxxxxNO

Mdulo de Funciones30Z_PAAAAxxxxx..xxxxxNO

Tabla Transparente16ZPAAAAxxxxxxxxxSI

Tablas Pool10ZPxxxxxxxxNO

Tablas clster10ZPxxxxxxxxNO

ndices de tablas3ZxxNO

Nombres de Tipo30ZPAAAAxxxxxx.xxxxxxxxxxxNO

Sapscripts/Smartforms16 / 30 ZPAAAAxxxxxxxxxxxxS

Proyectos de ampliacin8ZPAAAAxxxS

Objeto de autorizacin10ZPAAAAxxxxxNO

Ttulo barra3XxxNO

SPA/GPA parmetro3XxxNO

Variantes14xxxxxxxxxxxxxxx (va asociado el report)

CUS&_PAAAAxxxPara crear una variante que pueda ser transportada simplemente debemos crearla con un nombre que empiece por CUS&NO

Estructuras APPEND30ZPAAAAxxxxxxxxx (Nombre de la tabla que contiene la estructura APPEND)NO

nombres de los campos de estructuras APPEND30ZZPxxxxxx.xxxxNO

Perfil de

Autorizacin10Pendiente*este tema lleva el equipo de seguridadNO

Rol de Autorizacin30Pendiente *este tema lleva el equipo de seguridadNO

Vistas (Views)16ZPAAAAVVxxxxxxxxx

Los valores de la VV, sern los siguientes:

V_ -> Vista BBDD

VA -> Vista de actualizacion

VS -> Vista de supresin

VH -> Vista de ayuda

S

Ayuda de bsqueda30ZPAAAAxxxxxxxxxxxxxxxxxxxxxxNO

Help Vistas (Views)16ZPAAAAVHxxxxxxxx (tambien puede ser lo anterior)NO

Tipo de objeto workflow10ZPWxxxxxx

NO

Tipos de dispositivos impresin8ZPIxxxxx

NO

Formato de pgina de impresin8ZPFxxxxx

NO

ampliacin para infotipos8ZPnnnn00NO

Clase30ZPCLAAAAxxxxxxxxExcepciones a la norma:

Generacin automtica por SAP del nombre en las siguientes clases de implementacin:

BADI: ZCL_IM_PAAAAxxx...xxxx

Excepcin: ZCX_PAAAAxxxxxxxSI

Interfase30ZPIFAAAAxxxxxxxxSI

Grupo Tipos5ZPxxxNO

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.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.

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.

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 Limitacin 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:

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.

3.4 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:

5. Tipos

6. Tipos de tabla interna

7. Tablas internas

8. reas de trabajo de las tablas internas (Work Areas)

9. Variables

10. Constantes

Dentro de los programas; los tipos de datos, variables y constantes, pueden ser globales y locales.

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_SELECT-OPTIONS

PG_PARAMETERS

G_Variables globales

L_Variables locales

R_Rango

GD_Campos de Dynpro

SL_Datos estticos

G_O_Objeto global

L_O_Objeto local

G_CL_Clase Global

L_CL_Clase local

3.4.2 Declaracin globales

3.4.2.1 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:

TIPO DE TABLANOMENCLATURA

STANDARDGTYPE_T_

SORTEDGTYPE_TS_

HASHEDGTYPE_TH_

3.4.2.2 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:


STANDARDG_T_

SORTEDG_TS_

HASHEDG_TH_

RANGESG_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:

NOMBRE DE TABLANOMENCLATURA

G_T_TAB1G_WA_T_TAB1

G_TS_TAB2G_WA_TS_TAB2

G_TH_TAB3G_WA_TH_TAB3

G_R_RANGGO1G_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.

3.4.3 Declaracin locales

3.4.3.1 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:


STANDARDLTYPE_T_

SORTEDLTYPE_TS_

HASHEDLTYPE_TH_

3.4.3.2 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:


STANDARDL_T_

SORTEDL_TS_

HASHEDL_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 TABLANOMENCLATURA

G/L_T_TAB1L_WA_T_TAB1

G/L_TS_TAB2L_WA_TS_TAB2

G/L_TH_TAB3L_WA_TH_TAB3

Si lo que se est declarando es una constante, entonces sta ha de comenzar por LC_.

3.4.3.3 Datos 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.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 Nomenclatura

PARAMETERS.

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.

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.

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.

3.5.2 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.

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.

3.7 Clases e interfaces

El nombre de las clases ha de seguir la siguiente norma: ZPCLAAAAxxxxxxx.

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

ZCL_IM_PAAAAxxx...xxxx

Excepcin

ZCX_PAAAAxxxxxxx

3.7.1 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_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_

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.

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.

3.10 Excepciones

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.

4 Normas de desarrollo

4.1 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 Variables 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.

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.

5 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.

6 Conceptos importantes

6.1 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.

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.

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

En esta parte se muestran y se piden al usuario datos necesarios.

Se realizan las validaciones de los datos introducidos por el usuario o recuperados por el proceso.

Se emiten los mensajes informativos o de error y se solicitan las acciones pertinentes.

2. Actualizacin de datos.

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.

En esta parte solo se realiza la actualizacin de datos en base de datos y se termina la aplicacin.

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.

La razn por la cual hay que programar de esta manera, tiene que ver con la arquitectura de un sistema SAP.

Los sistemas SAP usan arquitecturas Cliente/Servidor, en concreto un sistema SAP tpico bsicamente tiene esta estructura:

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.

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

Por que ha terminado su trabajo.

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).7 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. 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. 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.SENTENCIASSUSTITUIR POR

MOVE-CORRESPONDING BSEG TO *BSEG

MOVE BSEG TO *BSEG

Para asignar el contenido de una tabla interna a otra con igual estructura, es mejor usar la forma ITAB1[] = ITAB2[].SENTENCIASSUSTITUIR POR

LOOP AT ITAB2.

ITAB1 = ITAB2.

APPEND ITAB1.

ENDLOOP.

ITAB1[] = ITAB2[],

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 Instrucciones SQL Interfase7.2.1.1 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.

SENTENCIASSUSTITUIR POR

SELECT * FROM DD01L

WHERE DOMNAME LIKE 'CHAR%'.

SELECT * FROM DD01T

WHERE DOMNAME = DD01L-DOMNAME

AND AS4VERS = DD01L-AS4VERS

AND DDLANGUAGE = SY-LANGU.

ENDSELECT.

ENDSELECT.

SELECT * FROM DD01V

WHERE DOMNAME LIKE 'CHAR%'


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.


SELECT * FROM DD01L


SELECT * FROM DD01T

WHERE DOMNAME = DD01L-DOMNAME

AND AS4VERS = DD01L-AS4VERS


ENDSELECT.

ENDSELECT. SELECT * FROM DD01L

INTO TABLE T_DD01L


LOOP AT T_DD01L.

SELECT * FROM DD01T

WHERE DOMNAME = T_DD01L-DOMNAME

AND AS4VERS = 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.


SELECT ... CLIENT SPECIFIED

WHERE BUKRS = sociedad.

.....

ENDSELECT.

SELECT ... CLIENT SPECIFIED

WHERE MANDT = 300 AND

BUKRS = sociedad.

.....

ENDSELECT.

Evitar las 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 ... 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.


SELECT ...

CHECK

ENDSELECT

SELECT ....

WHERE

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.

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.


SELECT

FROM ...

INTO wa

WHERE ...

APPEN wa TO itab.

ENDSELECT

SELECT

FROM ...

INTO TABLE itab.

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.

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.


SELECT

FROM ...

WHERE NOT FECHA = 19990212.

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 considerable7.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.


LOOP AT TAB.

INSERT INTO VALUES TAB.

ENDLOOP.

INSERT FROM TABLE itab.

Utilizar actualizaciones de columna en vez de modificaciones de fila.

Es preferible actualizar los valores de una o ms columnas de una tabla de una sola vez, en vez de hacerlo registro a registro.


SELECT * FROM SFLIGHT.

SFLIGH T-SEATSOCC = SFLIGHT-SEACSOCC -1.

UPDATE SFLIGHT.

ENDSELECT.

UPDATE SFLIGHT

SET SEATSOCC = SEATSOCC - 1.

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


MOVE SPACE TO TAB.

TAB-K = 'X'.

READ TABLE TAB BINARY SEARCH.

READ TABLE TAB WITH KEY K = 'X'

BINARY SEARCH

Intentar siempre acceder a una tabla interna ya ordenadaLas bsquedas sobre tablas internas, son mucho ms eficientes si stas se encuentran ordenadas por el criterio de bsqueda.

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.


READ TABLE WITH KEY.READ TABLE TAB WITH KEY K = 'X'

BINARY SEARCH

En LOOP de tablas utilizar la clusula WHERE.


LOOP AT TAB.

CHECK TAB-K = KVAL.

.....

ENDLOOP.

LOOP AT TAB WHERE K = KVAL.

.....

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.


READ TABLE TAB WITH KEY DATE = SY-DATUM.

IF SY-SUBRC = 0.

...

ENDIF. READ TABLE TAB_INDEX

WITH KEY DATE = SY-DATUM

BINARY SEARCH.

IF SY-SUBRC = 0.

READ TABLE TAB INDEX TAB_INDEX-INDX.

...

ENDIF.

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.


APPEND itab SORTED BY campo1.

...

APPEND itab SORTED BY campo1

...

APPEND itab SORTED BY campo1.

...

APPEND itab

...

APPEND itab

...

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.


REFRESH TAB_DEST.

LOOP AT TAB_SRC.

READ TABLE TAB_DEST WTTH KEY K= ....

INSERT TAB_SRC INTO TAB_DEST INDEX SY-INDEX.

ENDLOOP.

REFRESH TAB_DEST.

LOOP AT TAB_SRC.

APPEND TAB_SRC TO TAB_DEST.

ENDLOOP.

SORT TAB_DEST BY K

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:

Llenar la tabla

Ordenar la tabla

Borrar las entradas duplicadas


REFRESH TAB_DEST.

LOOP AT TAB_SRC.

READ TABLE TAB_DEST WITH KEY K= TAB_SRC-K.

IF SY-SUBRC 0 .

INSERT TAB_SRC INTO TAB_DEST

INDEX SY-INDEX.

ENDIF.

ENDLOOP.

REFRESH TAB_DEST.

LOOP AT TAB_SRC


ENDLOOP

SORT TAB_DEST BY K.

DELETE ADJACENT DUPLICATES

FROM TAB_DEST.

Uso de reas de trabajo.

Evitar MOVEs innecesarios utilizando las reas de trabajo en las sentencias:

APPEND wa TO tab.

INSERTwa INTO tab.

COLLECT wa INTO tab.

MODIFYtab FROM wa.

READ TABLE tab INTO wa.

LOOP AT tab INTO wa.


TAB = TAB_WA.

APPEND TAB. APPEND TAB_WA TO TAB.

Copia de tablas internasSiempre que se pueda se ha de utilizar asignacin directa de variables.


REFRESH TAB_DEST.

LOOP AT TAB_SRC INTO TAB_DEST.

APPEND TAB_DEST.

ENDLOOP.TAB_DEST[ ] = TAB_SRC[ ]

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.


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.

ENDIF.

ENDLOOP.

ENDIF.

IF TAB_DIFFERENT = SPACE.

" ...

ENDIF.

IF TAB1[ ] = TAB2 [ ]

....

ENDIF

Para ordenar tablas internas, especificar los campos sobre los que debe verificarse la ordenacin.


SORT ITAB.

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.


SELECT * FROM dbtable.

MOVE ...

APPEND itab.

ENDSELECT..

SELECT * FROM dbtable

INTO TABLE itab

WHERE ...

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.


LOOP AT ITAB.

C_LINEAS = C_LINEAS + 1.

ENDLOOP.

DESCRIBE TABLE ITAB LINES C_LINEAS.

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.


LOOP AT TAB1.

LOOP AT TAB2 WHERE K = TAB1-K.

...

ENDLOOP.

ENDLOOP. I2 = 1.

LOOP AT TAB1.

LOOP AT TAB2 FROM I2.

IF TAB2-K TAB1-K.

I2 = SY-TABIX.

EXIT.

ENDIF.

" ...

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.


LOOP AT TAB_SRC.


ENDLOOP.

APPEND LINES OF TAB_SRC TO TAB_DEST.

Borrado de lneasUtilizar accesos por ndice para transferir trabajo al kernel: DELETE itab FROM


LOOP AT TAB_SRC.


ENDLOOP.

APPEND LINES OF TAB_SRC TO TAB_DEST.

Utilizar clusula WHERE frente a barridos secuenciales.


LOOP AT TAB_DEST WHERE K = KVAL

DELETE TAB_DEST

ENDLOOPDELETE TAB_DEST WHERE K = KVAL

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.


LOOP AT TAB.

TAB-DATE = SY-DATUM.

MODIFY TAB.

ENDLOOP.

WA-DATE = SY-DATUM.

LOOP AT TAB.

MODIFY TAB FROM WA

TRANSPORTING DATE.

ENDLOOP.

7.2.6 Llamadas a subrutina

Especificar el tipo de parmetros en las rutinasSi 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.SENTENCIASSUSTITUIR POR

FORM UP2 USING REPEAT

DIMID.

.....

ENDFORM.FORM UP2 USINGREPEAT TYPE I

DIMID LIKE T006-DIMID.

.....

ENDFORM.

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.


CASE I1.

WHEN 1. PERFORM PV1.








ENDCASE. I1 = 5

PERFORM I1 OF

PV1

PV2

PV3

PV4

PV5

PV6

PV7

PV8.

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.


DATA: C1A VALUE 7.

IF 1 = C1A.

ENDIF. DATA: C1A VALUE 7.

IF '1' = C1A.

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.


IF C1A = 'A'. WRITE '1'.

ELSEIF C1A = 'B'. WRITE '2'.

ELSEIF C1A = 'C'. WRITE '3'.

ELSEIF C1A = 'D'. WRITE '4'.

ELSEIF C1A = 'E'. WRITE '5'.

ELSEIF C1A = 'F'. WRITE '6'.

ELSEIF C1A = 'G'. WRITE '7'.

ELSEIF C1A = 'H'. WRITE '8'.

ENDIF. CASE C1A.

WHEN 'A'. WRITE '1'.

WHEN 'B'. WRITE '2'.

WHEN 'C'. WRITE '3'.

WHEN 'D'. WRITE '4'.

WHEN 'E'. WRITE '5'.

WHEN 'F'. WRITE '6'.

WHEN 'G'. WRITE '7'.

WHEN 'H'. WRITE '8'.

ENDCASE.

7.2.9 Sentencias DO..ENDDO, WHILE..ENDWHILE

Es ms eficiente usar un bucle WHILE ENDWHILE que la construccin DO + EXIT.


I1 = 0.

DO.

IF C1A NE SPACE. EXIT. ENDIF.

ADD 1 TO I1.

IF I1 GT 10. C1A = 'X'. ENDIF.

ENDDO. I1 = 0.

WHILE C1A = SPACE.

ADD 1 TO I1.

IF I1 GT 10. C1A = 'X'. ENDIF.

ENDWHILE.

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


FIELD-SYMBOLS: .FIELD-SYMBOLS: 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.SENTENCIASSUSTITUIR PORDATA: IP TYPE P. DO 5 TIMES. IP = SY-INDEX * 2. READ TABLE X100 INDEX IP.ENDDO. DATA: IP TYPE I. DO 5 TIMES. IP = SY-INDEX * 2. READ TABLE X100 INDEX IP.ENDDO. En las asignaciones, utilizar constantes con tipo mejor que literales.SENTENCIASSUSTITUIR PORDATA: FLOAT TYPE F. FLOAT = '3.1415926535897932'.CONSTANTS: PI TYPE F VALUE '3.1415926535897932'. DATA: FLOAT TYPE F. FLOAT = PI. En clculos aritmticos no mezclar tipos a no ser que sea absolutamente necesario, de esta forma se evitan conversaciones innecesarias de tipos.SENTENCIASSUSTITUIR PORDATA: F1 TYPE I VALUE 2, F2 TYPE P DECIMALS 2 VALUE '3.14', F3 TYPE F. F3 = F1 * F2. DATA: F1 TYPE F VALUE 2, F2 TYPE F VALUE '3.14', F3 TYPE F. F3 = F1 * F2. En clculos aritmticos utilizar variables de tipo P.SENTENCIASSUSTITUIR POR DATA: N1(15) TYPE N VALUE '123456789012345', N2(15) TYPE N VALUE '543210987654321', N3(15) TYPE N. N3 = N1 + N2. DATA: P1 TYPE P VALUE '123456789012345', P2 TYPE P VALUE '543210987654321', P3 TYPE P. 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.SENTENCIASSUSTITUIR PORMOVE SPACE TO SY-SUBRC.CASE SY-SUBRC. WHEN '1'. WHEN '2'. WHEN '3'. WHEN '4'. ENDCASE. SY-SUBRC = 0. CASE SY-SUBRC. WHEN 1. WHEN 2. WHEN 3. WHEN 4. ENDCASE. 7.3 Mejoras basadas en el sistema7.3.1 Tratamiento de modos internosLas 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 datosSiempre 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.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 SETbutxt = 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 ndices de BD7.3.3.1 Consideraciones generalesLa 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.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 BDEn 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: 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: 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 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 Tablas transparentes en Memoria Intermedia (MI)7.3.4.1 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 MIComo 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)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? 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.Cundo se ha de elegir esta forma de grabacin? 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.Cundo se ha de elegir esta forma de grabacin? 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.7.3.4.3 Bypassing buffer: Sentencias que ignoran la

NEXUS02 E0 NO02 00 GG Normativa Desarrollo ABAP 00.06

Documents

Transcript of NEXUS02 E0 NO02 00 GG Normativa Desarrollo ABAP 00.06