• Author / Uploaded
• Alan Fuentes Arce

• Categories
• Programa de computadora
• Variable (informática)
• Tabla (base de datos)
• Programación de computadoras
• Gestión de tecnología de la información

Citation preview

---

Estándares de Desarrollo ABAP

Crystalis Consulting Chile

01/01/2007

Version 1.2

Página: 1 de 50

1. Estándares para objetos SAP..............7 1.1 Convenciones generales.........................................................................................7 1.1.1 Primeras Letras..........................................................................................7 1.1.2 Modulo SAP..................................................................................................7 1.1.3 Tabla de Función técnica del programa............................................8 1.1.4 Código de Sociedad/País.........................................................................8 1.2 Estándares para Programas..................................................................................8 1.2.1 Reportes........................................................................................................8 1.2.2 Module Pools y Dynpros..........................................................................9 1.3 Estándares para Formularios.............................................................................11 1.3.1 SAPScript Form.........................................................................................11 1.3.2 SAPScript Standard Text.......................................................................11 1.3.3 SAPScript Style.........................................................................................12 1.3.4 SAPScript Text ID.....................................................................................12 1.3.5 SmartForm.................................................................................................12 1.3.6 Smartform Graphic.................................................................................13 1.3.7 SmartStyle.................................................................................................13 1.3.8 SmartForm Text Module........................................................................14 1.4 Estándares para Funciones.................................................................................14 1.4.1 Grupos de Funciones..............................................................................14 1.4.2 Módulos de Funciones...........................................................................14 1.5 Estándares para BAdI’s......................................................................................15 1.5.1 Business Add-In Implementation Class...........................................15 1.5.2 Business Add-In Implementation Name..........................................16 1.6 Estándares para CATT’s.....................................................................................16 1.6.1 Módulos de Test.......................................................................................16 1.6.2 Procedimientos.........................................................................................16 1.6.3 Casos de Test............................................................................................17 1.6.4 Catálogos de Test....................................................................................17 1.6.5 Planes de Test...........................................................................................17 1.7 Estándares para Diccionario de Datos...............................................................19 1.7.1 Tablas...........................................................................................................19

01/01/2005

Version 1.1

Página: 2 de 50

1.7.2 1.7.3 1.7.4 1.7.5 1.7.6 1.7.7 1.7.8

Vistas...........................................................................................................19 Estructuras.................................................................................................19 Dominios.....................................................................................................20 Elementos de Datos...............................................................................20 Campos.......................................................................................................21 Ayuda de Búsqueda................................................................................21 Objetos de Bloqueo................................................................................22

1.8 Workflows.............................................................................................................22 1.8.1 Workflow /Business Objects................................................................22 1.9 Otros......................................................................................................................23 1.9.1 Ordenes de Transporte..........................................................................23 1.9.2 Estándares para Clases de Desarrollo/Paquetes.........................23 1.9.3 Estándares para Transacciones.........................................................24

2. Buenas prácticas de programación....26 2.1 Estructura de Programa......................................................................................26 2.1.1 Programa Base...............................................................................................26 2.1.2 Orden del código............................................................................................27 2.1.3 Modificaciones al codigo...............................................................................28 2.1.4 Comentarios...................................................................................................29 2.1.5 Formateo de Código.......................................................................................29 2.1.6 Nombres de variables.....................................................................................29 2.1.6.1 Estándares de Tablas Internas........................................................................29 2.1.6.2 Nombres de variable de programa.................................................................30 2.1.6.3 Flags.....................................................................................................30 2.1.6.4 Constantes.........................................................................................31 2.1.6.5 Estructuras.........................................................................................31 2.1.6.6 Variables de Trabajo.......................................................................31 2.1.6.7 Variables de Parámetro.................................................................32 2.1.6.8 Variables Select-options...............................................................32 2.1.6.9 Variables Ranges.............................................................................32 2.2

Actualizaciones de Datos.....................................................................................33

2.3

Subrutinas y módulos de función.......................................................................33

2.4

Comprobación de Autorización..........................................................................34

2.5

Objetos de Bloqueo..............................................................................................34

01/01/2005

Version 1.1

Página: 3 de 50

2.6

Debugging.............................................................................................................34

2.7

Mantenimiento / Corrección de código existente en producción.....................34

2.8

Chequeo de SY-SUBRC.......................................................................................34

2.9

Sentencia DATA...................................................................................................35

2.10

Mensajes de “No hay datos”...............................................................................35

2.11

AT PFnn vs. AT USER-COMMAND.................................................................36

3. Guía de Performance y eficiencia.......37 3.1 Acceso de base de datos.......................................................................................37 3.1.1 Minimizando los "hits" y el tráfico de red.....................................................38 3.1.2 SELECT-OPTIONS.......................................................................................38 3.1.3 Evite usar NOT en la cláusula WHERE........................................................39 3.1.4 Evite la utilización de SELECT/ENDSELECTs............................................39 3.1.5 ORDER BY vs. SORTing..............................................................................39 3.1.6 Evite SELECT *............................................................................................39 3.1.7 SELECT SINGLE..........................................................................................39 3.1.8 Vista. Vs. Select anidados para Joins.............................................................39 3.1.9 Actualización por columnas o actualización por filas...................................40 3.1.10 Funciones agregadas......................................................................................41 3.2 Índices...................................................................................................................41 3.2.1 Diseño de índice.............................................................................................41 3.3 Tablas Internas.....................................................................................................42 3.3.1 Procesando registro por registro o LOOP AT................................................42 3.3.2 Cláusula OCCURS........................................................................................44 3.3.3 Leyendo un registro únicamente....................................................................44 3.3.4 Ordenamiento.................................................................................................45 3.3.5 Tabla Interna vs. Select – EndSelect..............................................................45 3.3.6 Cantidad de Entradas.....................................................................................45 3.3.7 Borrando Registros........................................................................................46 3.3.8 Copiado de Tablas Internas............................................................................46 3.3.9 Loop/Where vs. Loop/Check.........................................................................46 3.3.10 Internal Tables: vs. Field Groups...................................................................47 3.3.11 Internal Table Import.....................................................................................47 3.3.12 Cláusula INTO TABLE.................................................................................47 3.3.13.............................................................................................................................48 3.3.14 Manejando Múltiples Tablas Similares..........................................................48 01/01/2005

Version 1.1

Página: 4 de 50

3.3.15 WHERE excluye AT......................................................................................48 3.3.16 Cláusulas APPEND…SORTED....................................................................49 3.3.17.............................................................................................................................49 3.4 Lógica de Proceso.................................................................................................49 3.4.1 CHECK, EXIT, REJECT, y STOP................................................................49 3.4.2 CHECK..........................................................................................................49 3.4.3 IF’s anidados..................................................................................................49 3.4.4 Case vs. IF......................................................................................................49 3.4.5 WHILE vs. DO Loops...................................................................................50 3.4.6 Modularización..............................................................................................50 3.5 Manipulación de Texto........................................................................................51 3.5.1 Operadores de texto.......................................................................................51 3.5.2 Instrucción Shift … Left................................................................................51 3.5.3 Field Length...................................................................................................51 3.6 Misceláneos...........................................................................................................52 3.6.1 Código Limpio...............................................................................................52 3.6.2 MOVE-CORRESPONDING.........................................................................52 3.6.3 Elegir mejores tablas......................................................................................52 3.6.4 Tablas Cluster y Pool.....................................................................................52 3.6.5 Elementos de Texto........................................................................................53 3.6.6 AT Statements................................................................................................53 3.6.7 Tipos de Datos y Conversión de Tipos..........................................................53 3.6.8 WRITE...........................................................................................................54 3.6.9 Desalentado y Evitado...................................................................................54

01/01/2005

Version 1.1

Página: 5 de 50

Estándares y directivas de desarrollo – Buenas prácticas en la programación Este documento define los estándares y directivas sugeridas para nombrar objetos de desarrollo a generar en las implementaciones de SAP. Este es solamente un estándar de desarrollo y no implica la sustitución de estándares propios de la empresa cliente. Este documento es dinámico y será actualizado y corregido a medida que SAP libere versiones nuevas de su software o bien por un acuerdo entre el equipo de desarrolladores.

1.Estándares para objetos SAP 2.1 Convenciones generales 1.1.1

Primeras Letras

SAP reserva nombres para los clientes. Usando estos nombres nos aseguramos que nuestros objetos no van a ser sobrescritos por SAP en las futuras versiones. Todos los objetos del cliente requieren “Z” o “Y” en la primera posición. Nosotros tomaremos “Z” para los objetos transportables e “Y” para los objetos locales. 1.1.2 Modulo SAP Los desarrollos se agruparán por módulo estándar de SAP al que pertenece el objeto. que se corresponderán con los módulos estándares de SAP (Finanzas FI, Ventas SD, etc.). Se le asignaran los próximos dos caracteres a esta nomenclatura. Para los objetos Cross Application (que son para mas de un modulo) se utilizará CA. Si existiera un desarrollo específico que no se podría clasificar por Modulo SAP al que pertenece el objeto. se le solicitara al jefe del equipo de desarrollo que defina cual utilizar.

1.1.3

Tabla de Función técnica del programa Funcion Técnica

IN OU RP IX FO CI CT BI UT

1.1.4

Descripción

Interfaz de entrada Interfaz de salida Report Include Form Carga inicial Call transacction Batch Input Utility

Código de Sociedad/País

En caso de implementaciones globales, es conveniente acordar con el cliente una nomenclatura para diferenciarse del resto de las sociedades. Por ejemplo, para una sociedad de Chile se podría utilizar los caracteres ‘CL’ despues del carácter inicial, siendo: ZSD_CL_xxxxxxx

2.2 Estándares para Programas 1.1.1 Reportes Un programa ABAP puede ser un reporte, un programa de interfase o conversión, un programa para llamar a un formulario, etc. Los reportes pueden ser llamados por una transacción o por un Module Pool. En el caso que el desarrollador haya copiado un programa estándar de SAP para usar de base para el programa del cliente, se debe usar las convenciones de nombres estándar definidas en este documento. Las variables originales de SAP no tienen que ser renombradas. Pero cualquier nueva variable introducida en el programa debe llevar la nomenclatura sugerida. El desarrollador debe indicar comentarios para todos los cambios

en el programa, tanto para agregados o borrados de código. El documento principal debe hacer referencia al programa estándar SAP que se utilizo de copia. El largo máximo del nombre de un programa ABAP es de 40 caracteres. SAP requiere que la primera letra de los objetos comience con Z o Y, seguido por el módulo SAP al que pertenece el objeto. y la función técnica del programa. Los restantes caracteres son una descripción del desarrollo. Long.Ca Estándar Descripción mpo

40

Z AA _ XX _ xxxxxxx

Objeto del cliente Modulo SAP al que pertenece el objeto. Underscore Función técnica del programa (Según Tabla) Undersore Texto Libre

Ejemplo

ZSD_CI_CLIENTE S Carga inicial declientes

1.1.2 Module Pools y Dynpros El module pool es un programa ABAP que chequea y procesa la interfaz con el usuario en forma on line. Consiste principalmente de un programa principal y de programas INCLUDE y de pantallas. Estos agrupan los procesos que procesan datos comunes y parte de la lógica de proceso. Los nombres de los Module Pool deben tener un largo de 11 caracteres con el siguiente formato.

Long.C Estándar ampo 11

SAPM Z AA XXXX

Descripción

Ejemplo

Prefijo requerido de los Module Pools. Objeto del cliente Modulo SAP al que pertenece el objeto. Dos caracteres secuenciales (0-9 / A-Z)

SAPMZFI0001

Las pantallas de SAP son llamadas DYNPROS (Dynamic Programs). La identificación del screen painter consiste del nombre del Programa ABAP y un número de cuatro dígitos de la dynpro. El rango de número reservado para los desarrollos custom de programas estándar de SAP debe ser entre el 9000 y el 9999. Para dynpros custom de programas custom se debe iniciar con el screen 100 e ir incrementando las pantallas de a 100 para las subsiguientes pantallas y de a 10 para las subpantallas de estas pantallas. Un module pool consiste enteramente de programas INCLUDE que normalmente sigue la siguiente forma:

INCLUDE MZAAxxxxTOP INCLUDE MZAAxxxxO##

Contiene datos y declaraciones (Tablas, variables) Process Before Output (PBO) modules donde ## se incrementa de a 10.

INCLUDE MZAAxxxxI##

Process After Input (PAI) modules donde ## se incrementa de a 10.

INCLUDE MZAAxxxxF##

Subrutinas (FORM...ENDFORM) donde ## se incrementa de a 10.

INCLUDE MZAAxxxxH##

Process On Help-Request (POH) modules donde ## se incrementa de a 10. Process On Value-Request (POV) modules INCLUDE MZAAxxxxV## donde ## se incrementa de a 10.

2.3 Estándares para Formularios 1.1.3 SAPScript Form Long. Estándar Campo

16

Z AA _ X

Descripción

Ejemplo

Objeto del cliente Modulo SAP al que pertenece el objeto. Underscore Libre

ZSD_FACTURA_EXP

1.1.4 SAPScript Standard Text Long. Estándar Campo

32

Z ST AA _ X

Descripción

Ejemplo

Objeto del cliente ZSTFI_CONDICIONE Identifica al Objeto como S un SapScript Standard Text Modulo SAP al que pertenece el objeto. Underscore Libre

Nota: Los tres primerso caracteres (optativos) de la descripcion del objeto deberian ser el Código de Empresa/Sucursal. 1.1.5 SAPScript Style Long. Estándar Campo

8

Z _ X (6 Caracteres)

Descripción

Ejemplo

Objeto del cliente Underscore Libre

Z_ESTILO

1.1.6 SAPScript Text ID Long. Estándar Campo

4

Z AA N

Descripción

Ejemplo

Objeto del cliente Modulo SAP al que pertenece el objeto. Numero

ZFI1

1.1.7 SmartForm Long. Estándar Campo

30

Z SF AA _ X

Descripción

Ejemplo

Objeto del cliente Identifica al Objeto como un SmartForm Modulo SAP al que pertenece el objeto. Underscore Libre

ZSFFI_FACTURA

1.1.8 Smartform Graphic Long. Estándar Campo

30

Z FG AA _ X

Descripción

Ejemplo

Objeto del cliente Identifica al Objeto como un SmartForm Graphic Modulo SAP al que pertenece el objeto. Underscore Libre

ZFGFI_LOGO

Descripción

Ejemplo

Objeto del cliente Identifica al Objeto como un SmartForm Style Modulo SAP al que pertenece el objeto. Underscore Libre

ZFYFI_FACTURA

1.1.9 SmartStyle Long. Estándar Campo

30

Z FY AA _ X

1.1.10SmartForm Text Module Long. Estándar Campo

30

Z FX AA _ X

Descripción

Ejemplo

Objeto del cliente ZFXFI_NOTA Identifica al Objeto como un SmartForm Text Module Modulo SAP al que pertenece el objeto. Underscore Libre

2.4 Estándares para Funciones 2.4.1 Grupos de Funciones Un grupo de funciones es una colección de módulos de funciones y sus objetos asociados. Los Grupos de Funciones están contenidos en la librería de funciones que soportan la creación y modificación de las funciones. NOTA: Para los Grupos de Funciones utilizados en las Vistas de Actualización de Tablas puede utilizarse el nombre de la tabla como nombre del Grupo de Funciones. Long. Estándar Campo

26

Z AA _ X (19 caracteres)

Descripción

Ejemplo

Objeto del cliente Modulo SAP al que pertenece el objeto. Undersore Texto Libre

ZTX_IVA: grupo de funciones para el modulo SAP de Impuestos para las funciones de IVA.

2.4.2 Módulos de Funciones Los módulos de funciones son programas escritos en ABAP que forman unidades lógicas en grupos de función. Ellos pueden ser llamados por cualquier programa ABAP o por los mismos módulos de función. Ellos son manejados centralmente en la biblioteca de funciones (SE37).

Long. Estándar Campo

30

Z _ AA _ X (21 caracteres)

Descripción

Ejemplo

Objeto del cliente Underscore Modulo SAP al que pertenece el objeto. Undersore Texto Libre

Z_CA_CONVERT_TO_ JULIAN_DATE

Los módulos de función son agrupados juntos usando los grupos de funciones. Los módulos de función pueden estar asignados a uno y sólo un grupo de función. Los grupos de función suministrados por SAP nunca deberán ser usados para definir nuevos módulos de función. Los módulos de función son similares a los programas, la diferencia principal es que ellos pueden ser llamados usando llamadas RFC, pueden ser llamados desde y a través de programas, y no son típicamente construidos para reportes con criterios de selección.

2.5 Estándares para BAdI’s 2.5.1 Business Add-In Implementation Class Long. Estándar Campo

30

Z CL AA _ X

Descripción

Ejemplo

Objeto del cliente Identifica al Objeto Clase de BADI Modulo SAP al que pertenece el objeto. Underscore Libre

ZCLMM_PEDIDO

2.5.2 Business Add-In Implementation Name Long. Estándar Campo

30

Z IM AA _ X

Descripción

Ejemplo

Objeto del cliente Identifica al Objeto Implementacion de BADI Modulo SAP al que pertenece el objeto. Underscore Libre

ZIMMM_PEDIDO_GR ABAR

2.6 Estándares para CATT’s CATT: Computer Aided Test Tool, es una herramienta para crear manual o automaticamente casos de pruebas. 2.6.1 Módulos de Test Long. Estándar Campo

30

Z CM AA _ X

Descripción

Ejemplo

Objeto del cliente Identifica al Objeto CATT Modulo de Test Modulo SAP al que pertenece el objeto. Underscore Libre

ZCMMM_PEDIDO

2.6.2 Procedimientos Long. Estándar Campo

30

Z CP AA _ X

Descripción

Ejemplo

Objeto del cliente Identifica al Objeto CATT Procedimiento Modulo SAP al que pertenece el objeto. Underscore

ZCPMM_PEDIDO

Libre

2.6.3 Casos de Test Long. Estándar Campo

30

Z CT AA _ X

Descripción

Ejemplo

Objeto del cliente Identifica al Objeto CATT Caso de Test Modulo SAP al que pertenece el objeto. Underscore Libre

ZCTMM_PEDIDO

2.6.4 Catálogos de Test Long. Estándar Campo

30

Z CC AA _ X

Descripción

Ejemplo

Objeto del cliente Identifica al Objeto CATT Catalogo de Test Modulo SAP al que pertenece el objeto. Underscore Libre

ZCCMM_PEDIDO

2.6.5 Planes de Test Long. Estándar Campo

30

Z CL AA _ X

Descripción

Ejemplo

Objeto del cliente Identifica al Objeto CATT Planes de Test Modulo SAP al que pertenece el objeto. Underscore Libre

ZCLMM_PEDIDO

2.7 Estándares para Diccionario de Datos 1.1.11Tablas Se recomienda que todas las tablas sean definidas como tablas transparentes. Las pequeñas tablas pueden ser definidas como Pool Tables. Long. Estándar Campo

20

Z AA _ X

Descripción

Ejemplo

Objeto del cliente Modulo SAP al que pertenece el objeto Underscore Libre

ZFI_CODIGOS

1.1.12Vistas Las vistas son Tablas transparentes que consisten en una vista alterna o la combinación de múltiples Tablas, como una Tabla unida. Long. Estándar Campo

20

Z V AA _ X

Descripción

Ejemplo

Objeto del cliente Identifica al Objeto como una Vista Modulo SAP al que pertenece el objeto. Underscore Libre

ZVFI_CODIGOS

1.1.13Estructuras Esta sección contiene la información sobre las opciones disponibles para mantener estructuras. Las estructuras son construidas de casi el mismo modo que las Tablas, la única diferencia es que ninguna tabla de base de datos es generada de las estructuras. Por esta razón, los métodos para crear, corregir, y suprimir estructuras son en gran parte el mismo como

aquellos usados para las tablas. Long. Estándar Campo

20

Z S AA _ X

Descripción

Ejemplo

Objeto del cliente Identifica al Objeto como una Estructura Modulo SAP al que pertenece el objeto. Underscore Libre

ZSFI_CODIGOS

1.1.14Dominios Un Dominio define una variedad de valores. Un Dominio es asignado a un elemento de datos. Todos los campos de las tablas o componentes de estructura que usan este elemento de datos tienen esta variedad de valores. Long. Estándar Campo

30

ZZ _ X

Descripción

Ejemplo

Objeto del cliente Underscore Libre

ZZ_DOMINIO

1.1.15Elementos de Datos Un elemento de datos describe un tipo elemental o un tipo de referencia. Un tipo elemental es definido por el tipo de datos incorporado, longitud y posiblemente el número de posiciones decimales. Estos atributos de tipo pueden ser definidos directamente en el elemento de datos o copiados de un dominio.

Long. Estándar Campo

30

ZZ _ X

Descripción

Ejemplo

Objeto del cliente Underscore Libre

ZZ_ELEM_DAT

1.1.16Campos Campos de una tabla o de una estructura. El nombre de campo puede tener un máximo de 16 caracteres y puede contener letras, dígitos y underscore. El nombre del campo debe comenzar con una letra. Long. Estándar Campo

30

ZZ X

Descripción

Ejemplo

Objeto del cliente Libre

ZZ_CAMPO

1.1.17Ayuda de Búsqueda La ayuda de búsqueda (F4 ayuda) es una función estándar del Sistema R/3. El usuario puede mostrar la lista de todos los valores de entrada posibles para un campo de pantalla con la ayuda de búsqueda. Los valores de entrada posibles pueden ser realzados con información adicional. Este es importante sobre todo cuando el campo requiere la entrada de un campo clave. Este proceso estándar puede ser completamente definido creando una ayuda de búsqueda en el Diccionario ABAP. Esta ayuda de búsqueda sólo tiene que ser adjudicada a los campos de pantalla en los cuales ellos deberían estar disponibles. Long. Estándar Campo

30

Z HV _ AA _ X

Descripción

Ejemplo

Objeto del cliente Identifica al Objeto como Ayuda de Busqueda Undersscore Modulo SAP al que pertenece el objeto. Underscore Libre

ZHV_MM_AYUDA

1.1.18Objetos de Bloqueo Un objeto de bloqueo es una unión virtual de varias tablas SAP que sincroniza el acceso simultáneo de dos usuarios al mismo set

de datos ( Concepto de bloqueo SAP). La solicitud y/o la liberación de los bloqueos se realizan en la programación de las transacciones de diálogo mediante la llamada de determinados módulos de funciones que se generan automáticamente de la definición de los objetos de bloqueo. Estos objetos deben crearse explícitamente en el Dictionary ABAP. Para fijar bloqueos debe seguir los siguientes pasos: 1. Debe definir un objeto de bloqueo en el Dictionary ABAP cuyo nombre debería empezar con E. 2. Debe incluir los módulos de funciones para la solicitud y/o liberación de bloqueos en la programación de las transacciones de diálogo correspondientes. Los módulos se crearán automáticamente al activar el objeto de bloqueo. Long. Estándar Campo

16

E Z X

Descripción

Ejemplo

Pre fijo Objeto del cliente Nombre de tabla primaria

EZTFI_CODIGOS

2.8 Workflows 2.8.1 Workflow /Business Objects Long. Estándar Campo

30

Z BO AA _ X

Descripción

Ejemplo

Objeto del cliente Identifica al Objeto como Business Object Modulo SAP al que pertenece el objeto. Underscore Libre

ZBOSFI_CLIENTE

2.9 Otros. 1.1.19Ordenes de Transporte Los nombres de las órdenes de transporte deben seguir una nomenclatura para un mejor seguimiento y control. Estas

deberán ser creadas de acuerdo al siguiente formato (60 caracteres): Long. Camp Estándar o

60

AADD.MM.AAAAxxx

Descripción

Ejemplo

Modulo SAP al que pertenece el objeto. Fecha Identificador de Desarrollo Texto Libre

SD-EM1-00000001: CREACIÓN DE PEDIDO

1.1.20Estándares para Clases de Desarrollo/Paquetes La Clase de Desarrollo es un código para ligar un juego de objetos del ambiente de desarrollo que son mutuamente dependientes el uno al otro. El código de Clase de Desarrollo es usado entonces para corregir y transportar sus objetos de desarrollo juntos, como una unidad. Al comenzar un proyecto de inplementación se deben crear un paquete de desarrollo por módulo en la forma Z mas el id de mñodulo (ZMM, ZFI, ZSD, ZHR, etc.). En caso de necesitarse otras clases de desarrollo, seguiremos la siguiente nomenclatura. Long. Estándar Campo

10

Z AA NN

Descripción

Ejemplo

Objeto del cliente Modulo SAP al que pertenece el objeto. Números (0..9)

ZFI001

1.1.21Estándares para Transacciones Las transacciones forman la base del procesamiento de negocio de SAP. El código de transacción, cuando es llamado o ejecutado, lleva a la pantalla inicial del module pool. Es aquí donde los datos interactivos son presentados al usuario en manera 'de diálogo'. Los tipos de transacciones pueden ser: 1. Transacciones de Diálogo

En una transacción de diálogo, el flujo del programa es determinado por una secuencia de pantallas. Las pantallas que llaman dentro de una transacción deberían pertenecer a un programa solo ABAP, por lo general un Module Pool (Programa tipo M). 2. Transacciones de Informe En una transacción de informe, usted usa un código de transacción para comenzar un programa ejecutable (Programa tipo 1). Un programa ejecutable por lo general tiene tres pasos - entrada de datos (pantalla de selección), proceso de datos (a menudo usando una base de datos lógica), y salida de datos (lista). 3. Transacciones Orientadas a Objeto En una transacción OO, usted puede unir un código de transacción a un método de una clase de Objetos de ABAP. 4. Transacciones de Variante Las variantes de transacción permiten que se preestablezcan valores para campos en una transacción, ponga atributos de campos, o esconda pantallas enteras. 5. Transacciones de Parámetro Las transacciones de parámetro permiten preadjudicar valores a campos sobre la pantalla inicial de una transacción. Los códigos de transacción consisten en 20 caracteres. Nosotros solo tomaremos 7 Long. Estándar Campo

20

Z AA _ X(3 caracteres)

Descripción

Ejemplo

Objeto del cliente Modulo SAP al que pertenece el objeto. Underscore Texto Libre

ZFI_IVA

2.Buenas prácticas de programación El objetivo de esta sección es acercar a los integrantes de Crystalis Consulting Chile determinadas buenas prácticas para el desarrollo de programas en ABAP, con el fin de que tengan en cuenta algunas recomendaciones, herramientas y funciones, al momento de necesitar resolver las problemáticas del día a día en los distintos proyectos. De esta manera se intenta aunar criterios al momento de seleccionar una alternativa para el desarrollo de los programas. Se incluyen también consideraciones de performance para tener en cuenta a la hora de programar. Este documento está hecho en base a las experiencias de muchos de nosotros en distintos proyectos, documentación y recomendaciones de SAP. La idea es seguir “alimentando” este documento con los aportes que cada uno haga. Todos los comentarios, sugerencias, críticas y correcciones son bienvenidas.

2.10 Estructura de Programa 2.10.1

Programa Base.

Se recomiendan que la estructura de los programas y el orden de los componentes sigan el layout indicado:

*&--------------------------------------------------------------------*& Compañía : SDA Chile S.A. *& Autor : Crystalis Consulting Chile – Peperino Pómoro *& Funcional : Julieta D. Ortega *& Fecha : 27.09.2006 *& Vers. SAP : 640 *& Transporte : P12K907478 *& Objetivo : Este programa está basado en el standard RVADIN01 y su *& función es dar salida a las facturas hacia el *& Servicio de Impuestos Internos *&--------------------------------------------------------------------*&--------------------------------------------------------------------*& MODIFICACIONES *&--------------------------------------------------------------------*& Modificó : *& Fecha : *& Solicitó : *& Transporte : *& Objetivo :

*&--------------------------------------------------------------------*---------------------------------------------------------------------* INCLUDES UTILIZADOS *---------------------------------------------------------------------*---------------------------------------------------------------------* DECLARACIONES GLOBALES *---------------------------------------------------------------------*---------------------------------------------------------------------* SELECTION-SCREEN *---------------------------------------------------------------------*---------------------------------------------------------------------* INITIALIZATION *---------------------------------------------------------------------*---------------------------------------------------------------------* AT SELECTION-SCREEN *---------------------------------------------------------------------*---------------------------------------------------------------------* START-OF-SELECTION *---------------------------------------------------------------------*---------------------------------------------------------------------* END-OF-SELECTION *---------------------------------------------------------------------*---------------------------------------------------------------------* TOP-OF-PAGE *---------------------------------------------------------------------*********************************************************************** ************ RUTINAS LOCLAES ************** ***********************************************************************

2.10.2

Orden del código

Para mejorar la performance de un programa, se pueden dividir grandes programas ABAP, en varios programas pequeños, siempre que sea apropiado. Cuando los eventos (p.ej, END-OF-SELECTION, TOP-OF-PAGE, etc.) son usados en el código, ellos deberán aparecer en el orden que es usado generalmente por SAP en sus programas. Cualquier evento no necesario puede ser suprimido. Todas las subrutinas (FORM’s) serán colocadas después de todo el código que no sea subrutina, después de END-OF-SELECTION. Los forms deben ser colocados en el orden general de uso.

La declaración de los objetos debe seguir el siguiente orden: Constantes Estructuras del diccionario(TABLES) Includes Declaraciones de variables Tipos Tablas internas Variables estructuradas Variables simples Rangos Selection Screen

2.10.3

Modificaciones al codigo

Dentro del código del programa, comentar cada cambio (inserción, borrado). Indicar en el comentario la fecha, el ID de usuario y el numero de requerimiento. Ej: ***Inicio – (userid) – (fecha) – (Nro. Req.) *** *SELECT * FROM LFA1 * WHERE KUNNR EQ I_TAB-KUNNR. SELECT SINGLE * FROM LFA1 WHERE KUNNR EQ I_TAB-KUNNR. ***Fin – (userid) – (fecha) – (Nro. Req.) *** Esto aplica solo para pequeños cambios realizados una vez que el programa está en prooducción. Para desarrollos desde cero o grandes cambios, no deberían ser nombrados. Evitemos comentariar grandes trozos de códigos.

2.10.4

Comentarios

ABAP es de por si claro en su lenguaje, de cualquier modo, es prudente proveer a futuros programadores con documentación de propósitos, cambios, enhancements, adiciones y borrados. Explique el propósito, diseño, estructura y cualquier ayuda en la cabecera del programa. Mantener una log de modificaciones con el cambio mas viejo al principio. Una descripción general del

programa debe indicarse en la cabecera. Las declaraciones "comentadas" deben ser usadas para las siguientes condiciones:  Antes de cada gran / pequeña sección de código.  Para clarificar lógica compleja o confusa.  En el encabezado de cada PERFORM para explicar brevemente el objetivo del mismo y sus parametros.

2.10.5

Formateo de Código

Sea prolijo con su programación, alinee código y deje renglones en blanco para separar secciones o sentencias diferentes. No programe varias sentencias en una misma línea, complican el debuging y el mantenimiento. -

Haga el uso del “Patrón” para añadir módulos de funciones y clases Utilizar el formato ‘Palabras claves en mayúsculas’ Utilizar la herramienta ‘Pritty printer’ para tabular y arreglar automáticamente todo el código. Usar la indentanción, siempre de dos espacios No superar las 72 columnas en el editor Agrupe sentencias, ciempre dejando las comas del lado derecho

2.10.6

Nombres de variables

2.10.6.1 Estándares de Tablas Internas Las tablas internas son definidas dentro de programas y usadas para sostener bloques de registros. Las tablas internas deberían tener un prefijo de variable "t_". Lo siguiente es un ejemplo de una variable de tabla interna: t_customer

2.10.6.2 Nombres de variable de programa El objetivo de esta sección es definir algunas pautas para la nomenclatura de variables de programas basadas en los tipos de las variables. Las variables de programa son definidas usando la declaración DATA. La declaración de parámetros mediante PARAMETER puede ser usada también para definir variables que son presentadas al usuario en la ejecución de los programas. Variables especiales para criterios de selección pueden ser

también definidas usando la instrucción SELECT-OPTIONS. Lo que sigue son los tipos variables a utilizarse: Banderas (Flags) Constantes Variables de Trabajo Parámetros Estructuras Variables Select-options Variables Ranges Underscores '_' deben ser usados para separar palabras o letras que definen una variable en vez de guiones. Los guiones '-' son usados para referirse a sub campos de un registro o estructura de datos. Se recomienda que variables del diccionario de datos sean usadas donde quiera que sea posible para la consistencia de datos y el chequeo de tipos. 2.1.1.1

Flags

Los flagas son variables que contienen sólo uno de dos valores. Estas variables serán definidas como CHAR de longitud 1. En todos los casos, los valores siguientes deben ser cumplidos: X para Sí Blanco para No Estos tipos variables deben de tener un prefijo 'f_'. Los siguientes son ejemplos de nombres variables para ser usados: f _eof f_continuar

2.1.1.2

Constantes

Las variables constantes no se cambian durante la ejecución de un programa. Estos tipos de variables deberán ser prefijados con 'k _ '. Lo siguiente es un ejemplo de nombres de constantes a ser usados: Ejemplo: k_pi LIKE bseg-dmbtr VALUE '3.1416'. 2.1.1.3

Estructuras

Las estructuras son un conjunto de campos que se unen para un propósito puntual. Ejemplo: El header line de una tabla interna. Lo siguiente es un ejemplo de nombres de Estructuras a ser usados: x_bseg 2.1.1.4

Variables de Trabajo

Las variables de trabajo son variables de propósito general. Estos son cualquier tipo variable que no puede ser definido en las categorías anteriores. Estas variables pueden contener valores alfanuméricos, numéricos, empaquetado, binario, fecha, tiempo, o valores hexadecimales. Los tipos variables de esta categoría deben ser prefijados con 'w_ ' para variables globales y 'l_ ' para variables locales o privadas. Lo siguiente es un ejemplo de nombres de variables de trabajo a ser usados: w_temp_salary_nb l_empl_adress_tx w_last

2.1.1.5

Variables de Parámetro

La variable de parámetros es usada para permitir la entrada de datos en la pantalla de selección antes de la ejecución de un programa. Estas variables tienen una longitud limitada de ocho (8) caracteres. Los tipos variables de esta categoría deberían ser prefijados con 'p_'. Lo siguiente es un ejemplo de nombres de Parámetros a ser usados: p_custom

p_fiscyr

2.1.1.6

Variables Select-options

Los SELECT-OPCION la declaración FOR generan una variable de programa a ser usada para los criterios de selección. Esta permite a un usuario en la pantalla de selección entrar un rango de selección. La variable generada es realmente una tabla del sistema auto generada que contiene -highvalue, -lowvalue, -signo, y -opción para el campo de la tabla seleccionada. Los tipos variables de esta categoría deberán ser prefijados con 's _ ' y tener una longitud limitada de 8 caracteres. Lo siguiente es un ejemplo de nombres de Parámetros a ser usados: s_lifnr s_bukrs 2.1.1.7

Variables Ranges

La instrucción RANGES: FOR generan una variable de programa usada para los criterios de selección muy parecido a los generados por SELECT-OPTIONS. La variable generada es realmente un Tabla Interna generada por el sistema que contiene -high-value, -lowvalue, -signo, y -opción para el campo de la tabla seleccionada. Los tipos variables de esta categoría deberían ser prefijados con 'r_' y tener una longitud limitada de ocho caracteres. Lo siguiente es un ejemplo de nombres de Parámetros a ser usados: r_lifnr r_bukrs

2.11 Actualizaciones de Datos Los tablas de base de datos de SAP sólo pueden ser actualizado por código proporcionado por SAP. Este puede ser por el uso de transacciones de SAP existentes o por el uso de batch data (BDC). Si una Tabla del cliente tiene que ser mantenida, deberá ser mantenido exclusivamente por programas on-line del cliente o por la trnasccion SM30 en caso que sea una tabla de customizing.

2.12 Subrutinas y módulos de función Cuando se llama a módulos de función, el grupo de función entero es cargado en memoria en tiempo de ejecución. Por lo tanto, se debe guardar el número de módulos de función dentro de un grupo de función a un mínimo. En cambio piense en usar subrutinas dentro de INCLUDE’s. Usar variables locales siempre que sea posible dentro de subrutinas para modularización. Sin embargo, las subrutinas usadas con gran frecuencia dentro de una llamada de programa deberían usar variables globales para eliminar el tiempo de creación de aquellas variables locales. Las subrutinas que deben ser llamadas por múltiples programas deberían ser creadas como módulos de función. Las subrutinas externas deberían ser también implementadas como Módulos de Función. No olvidar de dejar las exceptions de las funciones y su correspondiente chequeo para evitar dumps inecesarios en los progrmas (utilizar el patron para hacer las llamadas a las funciones.). Exceptuando que si la función dispara las excepciones usando MESSAGE xxxx RAISING (solo para este caso), en un module pool puede no ser necesario capturar las excepciones, dado que directamente se manda el mensaje de error y así no es necesario estar haciendo el chequeo del “sysubrc 0”.

2.13 Comprobación de Autorización La comprobación de autorización debería ser añadida en la definición de la transacción o en el programa. Los objetos de autorización pueden ser definidos en Menú del Workbench de ABAP seleccionando Desarrollo / Otras Herramientas / Obj. De Autorización / Objetos.

2.14 Objetos de Bloqueo

Los objetos de bloqueo deben ser usados cada vez que se actualice (insert/delete o update/modify) a una tabla, esto es para evitar problemas de concurrencia sobre las tablas. Los objetos de bloqueo deben ser creados como módulos de funciones (Enqueue / Dequeue) en un grupo de funciones del cliente.

2.15 Debugging Todo el código de debugging debe ser removido de los programas antes de ser liberados a Calidad y Producción. Esto incluye Break-Point y cualquier código agregado para testeo.

2.16 Mantenimiento / Corrección de código existente en producción. Cuando se cambie código de programas que estén en producción, estas modificaciones deben ser comentados en el bloque de modificaciones del programa.

2.17 Chequeo de SY-SUBRC SY-SUBRC es el código de retorno que nos sirve para diferenciar entre excepciones y código normal de proceso. Siempre se debe chequear SY-SUBRC con una instrucción IF o CASE inmediatamente después de una instrucción ABAP que puede alterar el mismo. Ejemplo de estas instrucciones son OPEN, READ, TRANSFER, SELECT, MODIFY, INSERT, LOOP AT, y CALL TRANSACTION. Ejemplo: SELECT belnr FROM BKPF INTO TABLE t_bkpf. IF sy-subrc 0. MESSAGE S000 WITH ‘No hay datos en la Base de Datos’(101). ELSE. PERFORM sub_next_step. ENDIF.

2.18 Sentencia DATA La definición de variables con la sentencia DATA debe estar en concordancia con la nomenclatura (2.1.1 Nombres de Variable de Programa). El parámetro LIKE en la sentencia DATA debe de ser usada siempre que sea posible, de esta forma nos aseguramos la consistencia de los campos con los definidos por SAP en los distintos programas. Inicialice todas las variables que apliquen en el evento INITIALIZATION usando el comando CLEAR. Siempre limpie las variables y estructuras especialmente en loops.

2.19 Mensajes de “No hay datos” Cuando se desarrollen reportes, recuerde de escribir un mensaje de error si no se han encontrados datos a listar. Ejemplo: SELECT belnr FROM BKPF INTO TABLE t_bkpf. IF sy-subrc 0. WRITE: / ‘No hay datos en la Base de Datos’(101). ENDIF.

2.20 AT PFnn vs. AT USER-COMMAND Cuando desarrolle reportes interactivos, use 'AT USER COMMAND' en vez de 'AT Pfnn' – SY-UCOMM valores tales como “SORT” y “NEXT” son mucho mas legibles que “PF05” y “PF06”. Ejemplo: AT PF05. SORT itab. AT PF06. LEAVE TO SCREEN 9100.

Es mucho menos legible que: AT USER-SELECTION. CASE SY-UCOMM.

WHEN ‘SORT’. SORT itab. WHEN ‘NEXT’. LEAVE TO SCREEN 9100. ENDCASE.

3. Guía de Performance y eficiencia. 2.21 Acceso de base de datos Siempre especifique sus condiciones en la cláusula WHERE en lugar de verificarlo con sentencias CHECK. El sistema de base de datos puede usar entonces un índice (si es posible) y la carga del sistemas se mejora considerablemente. Los contenidos de la Tabla entera se deben leer de los archivos de base de datos en los cache de DBMS y transferido sobre la red. Después de esto, la mayor parte de los datos son ordenados. En el segundo ejemplo, el DBMS leen exactamente los datos necesarios. Ejemplo: SELECT * FROM

CHECK: . ENDSELECT.

Es menos eficiente que: SELECT * FROM WHERE . ENDSELECT. Nota: Siempre especifique todas las condiciones conocidas en la cláusula del WHERE ( si posible ). Si no existe ninguna cláusula WHERE los DBMS no tienen ningún posibilidad de realizar optimizaciones.

En el caso de las tablas cluster, en especial la más conocida de todas la BSEG, donde no se debería acceder si no es con la clave completa, y no se le pueden crear indices ni hacer joins con ella. Es recomendable que siempre se busquen en las demás tablas de partidas (BSID, BSAD, BSIK, BSAK, etc). No es recomendable que no hagan joins con muchas tablas (no más de 4 o 5), porque es más difícil que el DBMS pueda optimizar realmente un acceso así, además los joins los tiene que resolver siempre el DBMS y eso hace que no se usen los buffers de SAP. Esto último en el caso de las tablas de descripciones de tipos de documentos es contraproducente.

2.21.1

Minimizando los "hits" y el tráfico de red

Proporcione los criterios de selección apropiados para limitar el número de registros que se lean de la base de datos.

Siempre que se estén seleccionando datos de la base de datos los “hits” deben ser en el servidor de base de dato y es por esto que se debe mantener tan pequeño como sea posible. El Set de datos seleccionado debe ser transportado por la red al servidor de aplicación, así reduciendo el conjunto de “hits” también reduce el tráfico de red. Para aumentar al máximo rendimiento, ambos número de los “hits” y el tráfico de red deben ser minimizados. Considere forzar a los usuarios para que proporcionen datos de selección en la pantalla de selección evaluando los criterios de selección en el evento AT SELECTION-SCREEN.

2.21.2

SELECT-OPTIONS

Puede hacer que un reporte se ejecute mucho mas rápidamente si prohíbe preguntas ilimitadas en las tablas de base de datos, queries ilimitados pueden demorar mucho tiempo en procesar. Para evitar esto, puede usar la cláusula SELECTOPTIONS disponible en SAP. Si la Tabla Interna asociada con el SELECT-OPTIONS es vacía, el usuario no ha especificado ninguna selección y usted puede tratarlo como si fuera un error. Ejemplo: SELECT-OPTIONS s_matnr for mara-matnr. AT SELECTION-SCREEN ON s_matnr. IF s_matnr[] IS INITIAL. ERROR MESSAGE ... ENDIF. START-OF-SELECTION SELECT ..... WHERE ...matnr >= s_matnr-low AND matnr SALE-AMT. SALE-AMT = COUNTRY-SALE ENDSELECT.

Es menos eficiente que: SELECT MAX ( COUNTRY-SALE )FROM DB01 WHERE COUNTRY = 'US'. ENDSELECT.

2.22 Índices Añadir un índice para una tabla de SAP es considerado una modificación. De acuerdo con la política de “no modificación” de CLIENTCOMPANY’s para los objetos dados por SAP, todo asunto concerniente a los índices debe ser tratado con el gerente de sistema. Siempre que se cree un indice para una tabla que tiene mandante, hay que poner el mandante como parte del indice.

2.22.1

Diseño de índice

Al acceder a tablas del usuario, use, cuando sea posible, índices para ayudarlo en la selección. Busque en el diccionario de datos de esa tabla para ver si existen índices alternos que pueden servir para su selección. Puede crear también un nuevo índice para este propósito particular. Vea la transacción SE30 (Tips & Tricks) para ver todas las posibles formas en que puede usar un índice. Los índices deben contener campos muy selectivos. Ciertos optimizadores son capaces de combinar dos o más índices para ejecutar una selección. Los índices de una tabla deben tener pocos campos comunes, esto es para no confundir al optimizador sobre que índice debe usar. Cada índice retarda las inserciones en las tablas. Las actualizaciones son retardadas solo si se actualizan campos de la clave. Por lo general, tablas con inserts pesados sólo deben tener pocos índices mientras que las tablas con muchos accesos podrían tener más índices.

Nota: Tener aproximadamente tres índices por tabla es lo recomendable.

2.23 Tablas Internas 2.23.1

Procesando registro por registro o LOOP AT.

Procese múltiples registros dentro de una tabla interna usando el comando LOOP AT en vez del comando DO. Ejemplo: LOOP AT T001_INFO_TAB. WRITE: / T001_INFO_TAB-BUKRS, T001_INFO_TAB-WAERS. ENDLOOP.

Notas: Si la tabla esta vacía, ABAP saltea todas las sentencias entre LOOP y ENDLOOP. Cuando sea posible, reduzca la cantidad de registros dentro del LOOP-ENDLOOP usando la cláusula WHERE. El campo de sistema SY-TABIX contiene el índice de entrada de la tabla actual dentro del Loop. Después de dejar el LOOP, SY-TABIX vuelve al valor que tenia de antemano. Se debe de tener cuidado con el WHERE del LOOP en tablas internas muy grandes. En las tablas comunes (que no sean tablas del typo SORT o HASH) el sistema internamente compara todos los registros con el criterio del WHERE, eso en LOOPs anidados puede ser muy poco performante. Por ejemplo, si hacen: LOOP AT IT_MKPF. LOOP AT IT_MSEG WHERE MBLNR = IT_MKPF-MBLNR AND MJAHR = IT_MKPF-MJAHR. ……………proceso de datos ENDLOOP. ENDLOOP.

Con muchos registros es muy poco performante, una forma sencilla de evitarlo es haciendo: DATA: w_index like sy-index.

W_index = 1. SORT: t_mkpf by t_mseg LOOP AT T_MKPF. LOOP AT T_MSEG from w_index. IF T_MSEG-MBLNR ne T_MSEG-MBLNR. w_index = sy-index * Guardo el último registro donde estuve…. EXIT. “(salgo del loop) ENDIF. ……………proceso de datos ENDLOOP. ENDLOOP.

Siempre que sea posible se deben de usar tabla internas HASH o SORT y utilizar: LOOP T_TABLA ASSIGNING . ENDLOOP.

Para cuando hay que loopear una tabla y se van a modificar registros, conviene hacer un loop asignando el registro a un field symbol, así queda actualizado el registro sin necesidad de hacer un MODIFY. El campo de sistema SY-SUBRC contiene uno de los siguientes valores al finalizar el loop (ENDLOOP): 0: Al menos ocurrió un pasada dentro del loop. 4: Ningún pasada dentro del loop ocurrió - ninguna entrada existe o las condiciones de un LOOP AT WHERE no fueron encontrados. Puede haber circunstancias donde sea conveniente utilizar un estructura DO-ENDDO. Use la orden CLEAR después de la orden APPEND para limpiar el contenido del registro de cabecera de una tabla interna.

2.23.2

Cláusula OCCURS

La instrucción 'OCCURS n' debería emparejar estrechamente el número esperado de filas que la tabla interna contendrá. Un área en el área de roll del sistema es reservada basada en el tamaño de tabla definido por esta declaración. Si mas registros de la tabla interna son añadidas a la misma que los definidos en la cláusula ‘OCCURS’, los registros

serán almacenados en el buffer del área de roll o paginados en memoria. Esto causara una degradación de la performance en el referenciamiento a las entradas de la tabla Interna. Siempre realice un análisis sobre volúmenes de datos antes de adjudicar un valor al parámetro OCCURS. Un valor incorrecto en el OCCURS puede derivar en un pobre rendimiento. Si usted no está seguro del tamaño de la tabla interna, adjudíquele un valor 0 al OCCURS y deje a SAP adjudicarle un valor dinámico. SAP incrementalmente reserva el espacio de bloques de 8 Kb. Mientras mas grande el valor del OCCURS mas grande el Área de ROLL que se utiliza.

2.23.3

Leyendo un registro únicamente

Cuando estemos leyendo un registro únicamente en una tabla interna, haga un SORT y utilice un READ TABLE WITH KEY BINARY SEARCH. Si tiene N entradas, la búsqueda lineal corre en O(N) pasos, mientras que la búsqueda binaria toma sólo O(LOG2(N)) – pasos de algoritmo. Ejemplo: "búsqueda lineal de una Tabla Interna" READ TABLE TAB WITH KEY K = 'X'.

Menos eficiente que: "búsqueda binaria de una Tabla Interna" READ TABLE TAB WITH KEY K = 'X' BINARY SEARCH.

Nota: no realice una búsqueda binaria sin antes haber hecho un SORT de la tabla interna ya que las búsquedas muy probablemente sean incorrecta. Solo tener en cuenta hacer el SORT en caso que sea necesario y no cada vez que vayamos a hacer un READ TABLE.

2.23.4

Ordenamiento

Cuando Ordene Tablas Internas, especifique los campos a ser clasificados. Ejemplo: SORT ITAB.

Menos eficiente que:

SORT ITAB BY FLD1 FLD2.

2.23.5

Tabla Interna vs. Select – EndSelect

Si usted trata sus datos sólo una vez, utilice las sentencias SELECT-ENDSELECT en vez de coleccionar datos en una Tabla Interna. El manejo de Tablas Internas toma mucho más espacio. Pero si usted tiene acceso a una Tabla múltiples veces en su programa, entonces es recomendable acceder a la Tabla una vez y guardar toda la información necesaria en una Tabla Interna por un mejor rendimiento.

2.23.6

Cantidad de Entradas

Para averiguar cuantas entradas posee una tabla interna utilice la cláusula DESCRIBE, antes que hacer incrementar un contador dentro del programa. Ejemplo: LOOP AT ITAB. CNTLNS = CNTLNS + 1. ENDLOOP.

Menos eficiente que: DESCRIBE TABLE ITAB LINES CNTLNS.

Además si solo se quiere saber si la tabla interna tiene o no registros se puede hacer lo siguiente: IF NOT TABLE[] IS INITIAL.

2.23.7

Borrando Registros

Utilice la sentencia DELETE ITAB [FROM ...] [TO ...] WHERE ...para borrar una líneas y transferir la carga de trabajo al sistema en vez de utilizar LOOP, la adición WHERE junto con FROM...y/o TO ... deben ser usado para mejorar la performance. Ejemplo: LOOP AT TAB_DEST WHERE K = KVAL. DELETE TAB_DEST. ENDLOOP.

Menos eficiente que: DELETE TAB_DEST WHERE K = KVAL.

2.23.8

Copiado de Tablas Internas.

Las tablas internas pueden ser copiadas como cualquier otro Objeto de datos. El modo clásico de copiar las tablas internas REFRESH T_DEST. LOOP AT T_SRC INTO T_DEST. APPEND T_DEST. ENDLOOP.

Pero ahora las tablas internas pueden ser copiadas de una manera más eficiente, como series variables: T_DEST[] = T_SRC[]

2.23.9

Loop/Where vs. Loop/Check

LOOP... WHERE es mas rápido que LOOP.. CHECK porque LOOP...WHERE evalúa la condición especificada internamente. Ejemplo: LOOP AT TAB. CHECK TAB-K = KVAL. ... ENDLOOP.

Menos eficiente que: LOOP AT TAB WHERE K = KVAL. ... ENDLOOP.

2.23.10 Internal Tables: vs. Field Groups Use field groups cuando este tratando cantidades grandes de datos a diferencia de tablas internas. Sin embargo, los field groups no pueden ser usados para el procesamiento recurrente como una tabla interna.

2.23.11 Internal Table Import Si usted importa una tabla Interna asegúrese de liberar la memoria asignada cuando termine de utilizar la tabla Interna. Ejemplo: FREE itab.

2.23.12 Cláusula INTO TABLE. 1. Use INTO TABLE cuando este cargando una tabla interna. Esto es más eficiente que mover los valores a la línea de cabecera e insertar. Ejemplo: SELECT * FROM LFA1. MOVE LFA1 TO T_LFA1. APPEND T_LFA1. ENDSELECT.

Menos eficiente que: SELECT * FROM LFA1 INTO TABLE T_LFA1.

2. Recuerde que una sentencia SELECT/ENDSELECT tiene el cursor OverHead Cuando sea posible, use el INTO TABLE para almacenar el juego de datos en una Tabla Interna antes que usar SELECT/ENDSELECT. SELECT * FROM LFA1. WRITE: / LFA1-LIFNR. ENDSELECT.

Menos eficiente que: SELECT * FROM LFA1 INTO TABLE T_LFA1. LOOP AT T_LFA1. WRITE: / T_LFA1-LIFNR. ENDLOOP.

2.23.13 2.23.14 Manejando Múltiples Tablas Similares.

Si usted tiene múltiples tablas Internas con campos comunes entonces es mejor crear una type structure e incluir esta estructura cuando define sus tablas internas. Si usted necesita añadir o quitar un campo se puede hacer modificando el type structure y todas las otras Tablas Internas heredaran los cambios.

2.23.15 WHERE excluye AT Si Ud. utiliza la sentencia WHERE en un LOOP (Ejemplo: LOOP AT ITAB WHERE X = '10'), Ud. no puede usar el evento AT dentro de un loop. (AT NEW Y, AT END OF Z, etc.). Si usted usa el comando AT la línea de cabecera no estará disponible para ningún campo a la derecha del campo clave en la estructura de la Tabla Interna. En caso de que usted necesite un campo que es a la derecha del campo de control, guarde cada registro en otro registro mientras loopea la tabla interna.

2.23.16 Cláusulas APPEND…SORTED Utilice la cláusula SORTED cuando: Haya menos de 100 filas. Las filas ya estén en el orden deseado

2.23.17 Si una Tabla Interna debe ser ordenada y lo antedicho no puede estar satisfecho, llenar la tabla desordenadamente y luego ordénela por los campos claves.

2.24 Lógica de Proceso 2.24.1

CHECK, EXIT, REJECT, y STOP

Use estas declaraciones para suspender el procesamiento y/o saltar el procesamiento restante innecesario para mejorar el funcionamiento.

2.24.2

CHECK Utilice CHECK siempre que sea posible en vez de utilizar

IF's.

2.24.3

IF’s anidados

Cuando codifique IF’s, anide las condiciones de pruebas de modo que las condiciones externas sean aquellos que mas probablemente sean verdaderos. Para expresiones lógicas con AND, coloque lo que mas probable sea falso primero y para el OR, coloque lo que sea más probablemente verdadero primero.

2.24.4

Case vs. IF

Las declaraciones CASE son generalmente más claras y un poco más rápidas que los IF’s. Cuando uno esta probando campos "igual" a algo, uno puede usar IF’s anidados o CASE. Pero CASE es más recomendado por dos motivos: 1. Es más fácil leer 2. Después de aproximadamente cinco IF’s anidados, el funcionamiento del CASE es más eficiente.

2.24.5

WHILE vs. DO Loops

Use WHILE en vez de DO+EXIT. WHILE es más entendible y un poco más rápido. Ejemplos: DO.

... IF SY-SUBRC 0. EXIT. ENDIF. ENDO.

Menos eficiente que: WHILE SY-SUBRC = 0 ... ENDWHILE.

2.24.6

Modularización

Para una buena modularización, la decisión de si realizar o no una llamada a una subrutina debería ser tomada antes de que llamen la subrutina. Ejemplos:

PERFORM sub1. FORM sub1. IF f1 NE 0. ... ENDIF. ENDFORM.

Menos eficiente que: IF f1 NE 0. PERFORM sub1. ENDIF. FORM sub1. .... ENDFORM.

2.25 Manipulación de Texto 2.25.1

Operadores de texto.

Use a los operadores especiales CO, CA, CS, CP en vez de programar las operaciones usted mismo. Ejemplos: a CA b (contains any): a contiene por los menos un caracter de b. a CO b (contains only): a contiene solo los caracteres de b (en cualquier orden) a CS b (contains string): a contiene el string b (blancos a izquierda son ignorados, case-insensitive) a CP b (contains pattern): a contiene el patrón b (* significa cualquier numero de caracteres, + cualquier caracter singular)

2.25.2

Instrucción Shift … Left

Si usted quiere suprimir los espacios en blanco a izquierda en un string use la siguiente sentencia de ABAP: SHIFT...LEFT DELETING LEADING... Se recomienda minimizar el uso de esta sentencia.

2.25.3

Field Length

Para averiguar la longitud de un campo use la función STRLEN. Ejemplos:

IF FLD CP ‘* #’. ENDIF. FLDLEN = SY-FDPOS.

Menos eficiente que: FLDLEN = STRLEN( FLD ).

2.26 Misceláneos 2.26.1

Código Limpio

Evite dejar "código muerto" en el programa. Quite campos definidos a los cuales no se hace referencia y código que lógicamente puede nunca ser ejecutado. Chequee que no haya forms que no son llamados. Puede verificar todo esto y más ejecutando la Transacción SLIN.

2.26.2

MOVE-CORRESPONDING

MOVE's individuales son más eficientes que MOVECORRESPONDING. Ejemplos:

MOVE-CORRESPONDING a TO b.

Menos eficiente que: MOVE a TO b.

2.26.3

Elegir mejores tablas

Siempre trate de usar la tabla apropiada para exactitud y mejor funcionamiento. Referencie tablas alternas para tablas como VBFA y BSEG que son muy grandes en tamaño y no muy eficientes para usar.

2.26.4

Tablas Cluster y Pool.

Note que las Tablas Cluster y Pool puede tener overhead de lectura. De ahí cada acceso a una tabla cluster o pool debe ser evaluado con cuidado y sólo si no hay otra opción disponible.

2.26.5

Elementos de Texto.

Los elementos de texto que no cambien a lo largo del programa, como textos comunes de cabecera, deberían ser seleccionados sólo una vez. Colocar estos selects en eventos como TOP-OF-PAGE hará que se repita el mismo select por cada nueva pagina del reporte.

2.26.6

AT Statements

Es más eficiente usar el comando AT (AT NEW, AT END OF, AT LAST ...) como propósito de suma o cortes de control. AT generalmente son mejores para tablas internas que ON CHANGE OF porque ellos tienen en cuenta la estructura jerárquica de las tablas internas y permite la suma automática. Sin embargo recuerde que dentro de AT NEW o AT END OF usted no puede referirse a campos individuales que estén físicamente a la derecha del campo de clave en la tabla interna. Esto tiene sentido en la mayoría de los casos y debería servir como una ayuda en el diseño de la estructura de tablas internas.

2.26.7

Tipos de Datos y Conversión de Tipos

Intente eliminar tantas conversiones de datos como sea posible. Defina el envío y la recepción de campos de datos con el mismo tipo o mueva los datos una vez a un campo intermedio del tipo que usted necesita y mueva este campo a los otros campos de recepción. .Ejecute la transacción SE30 ("Análisis de tiempo de Ejecución") para ver todas las conversiones de datos hechas. Durante el cálculo, el rendimiento depende del tipo de dato usado. Un número entero es más rápido, seguido por Floating Point y Packed, que es el que mas recurso requiere.

2.26.8

WRITE

Use una sola instrucción WRITE cuando sea posible en vez de múltiples WRITEs. Cada WRITE causa una llamada de salida de ABAP la cual es costosa. Ejemplo: WRITE / ‘this is a test’, MATNR. WRITE / ‘new line’, 20 ‘start in position 20’. Menos eficiente que: WRITE: / ‘this is a test’, MATNR, / ‘new line’, 20 ‘start in position 20’.

2.26.9 

Desalentado y Evitado Field symbols, cuando sean definidos y cuando sean usados, deben ser bien documentados en el programa.