metodologia y estandares de desarrollo sap.doc.docx

METODOLOGIA y ESTANDARES DE DESARROLLO SAP.doc.docx

SAP Abap WorkBench

Metodologa y Estndares de Desarrollo

Autor: Juan Carlos UribeFecha de creacin: 29 de Septiembre de 2005ltima modificacin: 27 de octubre de 2013Versin : 1.0

ndice

I. Control De Actualizaciones II. Introduccin III. Objetivo IV. AlcanceV. Metodologa de Desarrollo

1.Metodologa Para Desarrollo De Ajustes de Personalizacin/Localizacin, y de Extensiones Puntuales de Funcionalidad1.1.Fase De Revisin Tcnica 1.2.Fase De Precodificacin 1.3.Fase De Codificacin

2. Metodologa Para Desarrollo de Mdulos Complementarios a la funcionalidad Estndar de SAP y Para Ampliaciones Significativas de Funcionalidad2.1.Fase De Inicio 2.2.Fase De Elaboracin2.3.Fase De Construccin Iterativa (Springs) - Realizacin2.4.Fase De Transicin2.5.Fase De Mantenimiento

VI.Estndares De Programacin

1.Estndares Generales1.1.Un Comando Por Lnea1.2.Cdigo Fuente Indentado1.3.Nombramiento De Variables1.4.Cdigo reutilizable1.5.Paso De Parmetros En Subrutinas1.6.Manejo De Textos1.7.Uso De Userids En Programas1.8.Uso De Mensajes1.9.Uso de un Programa Estndar SAP como Plantilla de Desarrollo.1.10.Uso de Tablas.1.11.Uso de Variantes.1.12.Uso de Parmetros de Seleccin.1.13.Uso de Eventos.

2Estndares De Desarrollo De Tablas2.1.Definicin de Dominios2.2Definicin de Elementos de Datos2.3Definicin de Estructuras de Registro2.4Reglas de definicin de campos2.5Configuraciones De Mantenimiento2.6Consideraciones de seguridad2.7Actualizaciones Directas De Tablas Estndar De Sap

3.Estndares De Interfaz De Usuario

3.1.GUI: Gua De Estilo De Sap

4.Estndares De Documentacin

4.1.Aspectos Que Se Deben Documentar4.2.Documentacin De Produccin4.3.Documentacin De Cdigo Fuente4.4.Documentacin De Secciones De Cdigo ABAP4.4.1.Documentacin de Declaracin de Tablas4.4.2.Documentacin de Declaracin de Constantes4.4.3.Documentacin de Declaracin de Tipos4.4.4.Documentacin de Declaracin de Parmetros y de Opciones de Seleccin4.4.5.Documentacin de Variables4.4.6.Documentacin de Declaracin de Eventos4.4.7.Documentacin de Declaracin de Secuencia de Comandos4.4.8.Documentacin de Declaracin de Literales4.4.9.Documentacin de Llamadas a las Subrutinas(Forms)4.4.10. Documentacin de rutinas4.5.Documentacin de Mdulos De Funcin. 4.6.Documentacin Externa al Desarrollo4.6.1. Arquitectura del Sistema. 4.6.2.Manual Tcnico 4.6.3.Manual del Usuario

5.Estndares De Rendimiento/Performance

5.1.Cdigo Inactivo5.2.Uso De Bases De Datos Lgicas5.3.Uso De Subrutinas5.4.Declaraciones IF5.5.CASE Vs. IFs Anidados5.6.Estructuras MOVE-ING5.7.SELECT Y SELECT SINGLE5.8.Tablas Internas Pequeas Vs. Tablas Internas Completas5.9.Procesamiento de tablas a nivel de registro5.10.SELECT SINGLE Y Procesamiento A Nivel De Fila5.11.Nmero De Entradas En Una Tabla Interna5.14.Longitud De Un Campo5.15.Diagnstico De Rendimiento5.16.SELECTs Anidados Versus Vistas de Tabla5.17.Si SELECTs Anidados Deben Ser Usados5.18.SELECT * Versus SELECT De Campos Individuales5.19.Evitar Instrucciones Innecesarias5.20.Copiar o Aadir En Tablas Internas

6.Estndares De Nomenclatura6.1.Convenciones De Nomenclatura De Tablas y de Vistas6.2.Nomenclatura de Objetos de Desarrollo6.3.Clases De Desarrollo6.4.1.Convenciones De Nomenclatura Clases De Desarrollo6.5.Module Pools6.6.Convenciones De Nomenclatura de ABAP Objects6.7.Reglas Generales6.10.Convenciones Generales De POO En ABAP6.11.Convenciones De Objetos De Mtodo6.12.Convenciones De Parmetros De Mtodo6.13.Convenciones De Excepciones

7.Buenas Prcticas Adicionales de Desarrollo7.1.Guas Para Suprimir Cdigo ABAP Viejo o No Usado 7.2.Grupos de Autorizacin7.3.Autorizaciones: Uso De Objetos SAP7.4.Uso de Formatos de Fechas7.5.JOBS: Registro De Estado Usando ZJOBRUN27.6.Comunicacin Entre Procesos De Primer Plano Y Procesos De Fondo

VI.ABAP/4 Lista De Comprobacin Para Afinacin - TUNING

VII.Programas de Ejemplo/Plantillas1.Plantilla Reporte Bsico De Lista2.Plantilla Reporte Interactivo De Lista3.Plantilla Creacin De Un Archivo Plano Secuencial4.Plantilla Lectura De Un Archivo Plano Y Creacin De Una Sesin Batch Input5.Plantilla Tcnica Call Transaction Using6.Plantilla Desarrollo Sapscript

7.Plantilla Desarrollo Smartform

8.Plantilla Desarrollo Reporte Alv

I. Control De Actualizaciones

FechaAutorVersinReferencia de Cambios

05 de Septiembre de 2005Juan Carlos Uribe1.0No existe documento anterior

27 Octubre 2013Juan Carlos A. Uribe Gonzlez2.0Actualizacin con Metodologa ASAP 8 Agile Development

II. Introduccin

Este documento fue creado para establecer una metodologa de desarrollo que permita abordar los diferentes desarrollos teniendo en cuenta la arquitectura del sistema o mdulo, as como la metodologa especfica a usar dependiendo del desarrollo. Se han distinguido dos escenarios de desarrollo los cuales se atacarn con metodologas diferentes: Desarrollo De Ajustes de Personalizacin/Localizacin, y de Extensiones Puntuales de Funcionalidad, y Desarrollo de Mdulos Complementarios a la funcionalidad Estndar de SAP y Para Ampliaciones Significativas de Funcionalidad.

La metodologa busca tambin garantizar y permitir realizar desarrollos uniformes, documentados, acogidos a estndares de nombramiento, estndares de programacin, y mejores prcticas en la programacin de ABAP y proporcionar pautas para el desarrollo ABAP para el grupo de desarrollo.

En este documento se trabajaron los siguientes Estndares de Desarrollo:

Estndares generales de programacin Estndares de rendimiento Estndares de interfaz de usuario - GUI Convenciones de nombramiento Programas de muestra / Plantillas

Esta gua debe ser actualizada a medida que ms estndares sean desarrollados, o que los existentes sean actualizados.

Adicionalmente este documento se constituye como una gua metodolgica para desarrollos especficos y extensiones de R/3, para el uso del grupo de Desarrollo ABAP.

Como prerrequisito para el entendimiento del contenido de este documento se tiene que el desarrollador debe estar familiarizado con conceptos bsicos de R/3.

Como objetivos adicionales de este documento se tienen:

Proveer y describir un conjunto consecuente de prcticas de modo que todo el cdigo que sigue estas prcticas use convenciones y tcnicas uniformes. Por lo tanto, una vez que un programador se haya familiarizado con estas convenciones, le tomar mucho menos tiempo entender todos los otros programas que tambin siguen el mismo conjunto de prcticas.

Recomendar, explicar e ilustrar tcnicas que han sido desarrolladas como modos eficientes de manejar ciertas situaciones que surgen en la programacin de ABAP.

Los estndares han sido elaborados junto con varias plantillas de desarrollo, con el fin de garantizar la estructura mnima por tipo de desarrollo, as como para maximizar tiempos de desarrollo.

Iii. Objetivo

El objetivo de este documento es proporcionar una metodologa de desarrollo adaptada a los diferentes requerimientos, casos, y tipos de desarrollo que se pueden presentar en un proyecto SAP.

El documento define:

1. La metodologa de desarrollo a seguir de acuerdo a cada caso.2. Guas y estndares de desarrollo3. Convenciones de nombramiento4. Programas de ejemplo o plantillas

Todo el equipo de desarrollo (tanto senior como junior) debe seguir y cumplir juiciosamente lo dispuesto en este documento.

Iv. Alcance

Desarrollar la metodologa y las guas necesarias para el proceso de desarrollo de requerimientos SAP, as como proveer los estndares requeridos que asegurarn la calidad, desarrollo, mantenimiento, y reuso del software.

V. Metodologa

Para el desarrollo de los requerimientos ABAP de los proyectos SAP se han identificado dos metodologas a aplicar segn el caso las cuales se describirn a continuacin.

Para el desarrollo de todos los requerimientos se utilizarn las convenciones, los estndares, y las plantillas expuestas(os) en este documento.

A. Desarrollo De Ajustes De Personalizacin/Localizacin, Y De Extensiones Puntuales De Funcionalidad

Corresponden a desarrollos dentro de proyectos SAP que no requieren la creacin de nuevos modelos de datos y de procesos no modelados ni incluidos dentro la funcionalidad estndar de SAP, dentro de los cuales se cuentan:

1. Carga de datos y conversiones (Ej. BI, LSWB)2. Reportes (Ej. Listas, Grillas)3. Formularios (Ej. SAPScrip, Smartforms)4. Workflow5. Extensiones puntuales de funcionalidad (BADI, BAPIs, Reglas)6. Integracin/Interfases (Ej. RFCs, ALE, IDOCs)7. BSP (Aplicaciones sencillas).

Esta metodologa esta compuesta de las siguientes fases:

1.1. Fase de Revisin Tcnica

Esto es la responsabilidad del desarrollador la de realizar un anlisis tcnico de las especificaciones de negocio.

El documento de procesos de negocio (Bussines Blue Print) proporciona una lista de comprobacin para el anlisis tcnico realizado por el desarrollador.

Por lo general, al final de este proceso, las especificaciones comerciales son actualizadas y finalizadas por el Analista funcional, y especificaciones tcnicas son preparadas por el desarrollador.

Las especificaciones tcnicas deben mostrar las entradas y las salidas delproceso y la lgica de programa.

Si las especificaciones tcnicas afectan varios mdulos, estos deben ser validados por cada consultor funcional del mdulo apropiado.

Los anexos XX, de este documento contienen las plantillas de la arquitectura del sistema y de los manuales tcnico y del usuario, con la informacin mnima que debe incluir la especificacin tcnica del desarrollo.

Al final de esta etapa el desarrollador debe finalizar el diseo tcnico del programa y examinarlo con el Analista funcional.

1.2. Fase de Precodificacin

Antes de comenzar a programar, y a veces como parte de revisin tcnica, el Desarrollador debe:

A. Identifican programas similares, funciones, etc.B. Identifican tablas para ser usadas como una fuente de la informacin.C. Aconsejan DBAs si las nuevas tablas o los ndices deben ser creados.D. Decidir si hay que copiar un programa existente o crear nuevo.E. Definir nombres para nuevos programas, tablas, etc.F. Para programas de actualizacin o de conversin, determinar el mejor mtodo de actualizacin (CALL TRANSACTION, sesiones de batch input, o inserts). El volumen de datos es un factor importante en esta decisin.G. Decidir que clase de desarrollo usar

Para identificar programa similar o funciones, habra que examinar las funciones y/o los informes existentes. Ya que esto es parte de la investigacin preliminar del Analista funcional, este debe ser capaz de proporcionar esta informacin al Desarrollador.

Para identificar que tablas deben ser usadas como una fuente de informacin, el Desarrollador debe usar siguientes recursos:

A. Preguntar al Analista funcional,B. Ver el documento de Arquitectura de Datos del mdulo,C. Buscar bases de datos lgicas,D. Aplicar debug o SQL-trace a los programas SAP relacionados con el desarrollo,E. Usar las herramientas de gestin del repositorio(SE11/SE80).

Los programas similares o las funciones deben ser usados para reducir el tiempo de desarrollo y de depuracin.

Los nuevos objetos de desarrollo podran ser:

A. ProgramasB. TablasC. Elementos de datosD. DominiosE. EstructurasF. Objetos de bloqueoG. Documentos de cambioH. Mdulos de funcinI. PantallasJ. Ayudas de bsquedaK. SAPscript => juegos de disposicinL. IncludesM. TransaccionesN. Rangos de NmeroO. Objetos de SeguridadP. MensajesQ. Mens de rea

Si nuevos objetos deben ser desarrollados, hay que usar las convenciones de nombramiento descritas adelante en este documento.

Si no hay ninguna convencin para el nuevo objeto, el Desarrollador debe ponerse en contacto el Coordinador de Desarrollo.

Si se copi el cdigo de un estndar SAP se debe nombrar el nuevo programa con el prefijo 'z' y dos letras denotando el mdulo (p.ej ZR _). Esto para identificar fcilmente el mdulo al que pertenece el programa.

Si se deben crear nuevas tablas se debe consultar y notificar al DBAs y al arquitecto de datos.

Se debe proveer la siguiente informacin al DBAs y al arquitecto de datos:

Nombre de la tabla ndices Nmero Estimado de filas/registros Patrn de crecimiento Frecuencia de acceso Almacenado en un buffer o no almacenado en un buffer.

1. 3. Fase de Codificacin

El sistema de SAP tiene disponibles varias herramientas de desarrollo, entre las cuales se cuentan:

ABAP WorkBench Utilizado para desarrollar informes, programas, funciones, tablas, pantallas, y mensSAP Query Para desarrollar informesReport Writer - Para desarrollar informesDesarrollo de BAPI - Para desarrollar BAPIs para Web y RFCWAS BSP- Webdynpro Para desarrollo Web SAPSAPscript/Smartforms/Adobe Forms - Para desarrollar formularios impresos

ABAP WorkBench incluye: Diccionario de Datos, Editor de ABAP, constructor de Funcin, etc.

Se recomienda fuertemente usar la Biblioteca de Reutilizacin de SAP (transaccin SAPLRLB_DISPLAY) y Ejemplos de Controles (transaccin DWDM) para reducir el tiempo de desarrollo.

B. Desarrollo De Mdulos Complementarios A La Funcionalidad Estndar De Sap Y Para Ampliaciones Significativas De Funcionalidad

Corresponden a desarrollos que implican la creacin de un modelo de datos complementario al entregado por SAP, desarrollo e implementacin de nuevos procesos de negocio, y de un conjunto relevante de desarrollos puntuales necesarios para resolver el requerimiento. Corresponde a la creacin de mdulo de software, o de un sistema de informacin especfico, el cual debe desarrollarse como extensin de la funcionalidad propia de SAP garantizando una compatibilidad total con el modelo de datos y la funcionalidad nativa y extendida existente de SAP en el momento del requerimiento.

Para la realizacin de este tipo de desarrollos se utilizarn las convenciones, los estndares, y las plantillas expuestas(os) en este documento.

2. Metodologa Para Desarrollos De Magnitud Significativa

Esta metodologa est compuesta de las siguientes fases donde cada fase consta de las etapas de Levantamiento de requerimientos de informacin, Anlisis, Diseo, Implementacin, y Pruebas.

2.1. Fase de Inicio

En esta fase se definen los requerimientos funcionales y su alcance.

Dentro del proyecto esta fase se cubre por la consultora funcional que es la que entrega los requerimientos de desarrollo junto con las especificaciones funcionales requeridas, producto del anlisis de los procesos de negocio y de la respectiva especificacin de personalizacin/parametrizacin/localizacin del desarrollo.

Se anexa Formulario de Especificacin de Desarrollos ABAP.

Como resultado de esta fase se tienen los siguientes entregables:

1. Especificacin funcional Inicial2. Diagramas ilustrativos

2.2. Fase de ELABORACIN

En esta fase se realiza el Anlisis (incluyendo los Casos de Uso), y determinan el Diseo, la Arquitectura, la Lnea de Base, los Riesgos, los Niveles de Servicio, los Recursos requeridos, y el Plan del Proyecto.

Como resultado del anlisis de los requerimientos entregados por los consultores funcionales se proceder a especificar los casos de uso.

Con base en los casos de uso se proceder a realizar las etapas de anlisis y de diseo de la solucin.

Con base en el diseo se construir la arquitectura del sistema lo cual contas de los siguientes componentes:

1. Modelo de Datos, 2. Relaciones, 3. Componentes de software (como Middleware, ADS, BRF) , 4. Entradas, 5. Salidas, y 6. Plataforma tecnolgica.

La arquitectura del sistema tambin define los siguientes Objetos de desarrollo globales de desarrollo para la plataforma SAP:

1. Tipos, 2. Tablas Transparentes, 3. Tablas Z, 4. Estructuras, 5. Vistas, 6. Objetos, 7. Mtodos, 8. Funciones, 9. BADIs, 10. BAPIs, 11. Reglas, 12. Eventos, 13. Diccionario de datos actualizado.14. Programa.

A partir de la Arquitectura del Sistema se sigue con la definicin del Plan del Proyecto a travs del ajuste del listado inicial de requerimientos, incluyendo los desarrollos que apoyaran la construccin de los requerimientos funcionales del sistema, y de la actualizacin de la hoja de programacin y seguimiento del proyecto. Lo anterior causar una reasignacin de recursos de desarrollo.

Como resultado de lo anterior, se obtiene la lnea de base del proyecto

Los desarrollos deben ajustarse a la Arquitectura Global del Sistema definida.

En esta fase tambin se determinan los riesgos administrativos y de logstica (como recursos tcnicos, econmicos, operativos y humanos), y tcnicos (como reglas crticas de negocio, puntos clave de validacin, versiones de herramientas de software).

Los niveles se definen para especificar los siguientes atributos de calidad: desempeo, disponibilidad del sistema, y tolerancia a fallas.


1. Anlisis Inicial incluyendo los casos de uso 2. Arquitectura del Sistemaa. Diseo Inicial incluyendo los diagramas requeridosb. Componentes globales del sistemac. Objetos globales de desarrollo3. Especificacin tcnica inicial de cada desarrollo4. Lista de riesgos especficos del proyecto5. Plan de desarrollo del proyectoa. Lista de requerimientosb. Programacin de los desarrollosc. Asignacin de recursosd. Plan de seguimiento

2.3. Fase de Construccin Iterativa (Springs) - Realizacin

En esta fase se realiza el Prototyping, la mitigacin de riesgos, el desarrollo ajustado a los requerimientos, y el diseo y construccin de los escenarios de pruebas.

Prototyping y Ajuste de Requerimientos. Para todos los requerimientos se seguir la metodologa de desarrollo por prototipos, la cual consiste en la creacin de versiones consistentes de control de flujo, interfaz, y lgica de procesos; cada una de las cuales debe ser validada iterativamente con la participacin activa del consultor funcional y del respectivo usuario lder del cliente.

La especificacin de requerimientos se actualizar de acuerdo al aporte y validacin y pruebas realizadas a cada una de las versiones.

En esta fase se realizar tambin la construccin del diseo y construccin de los escenarios y casos de prueba.

Esta etapa se apoya en la metodologa SAP AGILE ASAP la cual incluye la metodologa SCRUM [Scrum es un marco de trabajo para la gestin y desarrollo de software basada en un proceso iterativo e incremental, utilizado comnmente en entornos basados en el desarrollo gil de software]:

Las actividades anteriores permiten el logro de la reduccin de los riesgos.


1. Documentacin de Inspeccin de Versiones2. Documentos de aceptacin3. Diseo Actualizado4. Escenarios de prueba

2.4. Fase de TRANSICIN

En esta fase se ejecutan las Pruebas Integrales sistema desarrollado contra la funcionalidad requerida considerando los riesgos detectados y utilizando los escenarios y casos de prueba elaborados durante la fase de construccin. As mismo, se realizan los ajustes requeridos como resultado de las pruebas, y se termina la Documentacin.


1. Especificacin funcional definitiva2. Especificacin Tcnica3. Programas desarrollados y Probados4. Manual Tcnico del desarrollo5. Manual Funcional del desarrollo6. Actas de aceptacin de pruebas integrales7. Aprobacin por parte de los Consultores Funcionales, Analistas Funcionales y Gerencia del Proyecto Entidad.

2.5. Fase de Mantenimiento

Esta fase es responsabilidad del cliente y corresponde al mantenimiento del sistema en productivo.

Vi. Estndares De Desarrollo

1. Estndares Generales

Los siguientes estndares de programacin se definieron para garantizar el entendimiento y el posterior mantenimiento de los programas escritos en el ambiente de desarrollo ABAP WorkBench.

1.1.Un comando por lnea

Cada instruccin de ABAP/4 consiste en una oracin que se termina con un punto. rdenes mltiples pueden estar en una lnea; sin embargo, se establece como un principio estndar usar una instruccin por lnea. Lo anterior permite realizar ms fcilmente las tareas como edicin, depuracin, comentariado de cdigo y depuracin.

1.2.Cdigo fuente Indentado

El editor ABAP/4 tiene el comando "PRETTY PRINTER" para indentar por 2 posiciones lneas especficas del cdigo y aadir comentarios de subrutina. Las palabras clave de eventos normalmente no son indentadas.

DATA: BEGIN OF tab OCCURS 100, f1 LIKE sg-field1, f2 LIKE sg-field2, END OF tab.. DATA: f1 TYPE I, f2 TYPE I. START-OF-SELECTION. GET table. IF f1 = f2. f1 = 0. ELSE. f1 = 1. ENDIF. SELECT * FROM table WHERE field1 EQ sg-field2 AND field2 BETWEEN sg-field5 AND sg-field6. MOVE ... APPEND ... ENDSELECT. END-OF-SELECTION. LOOP AT tab. AT NEW f1. CASE F1. WHEN ... WRITE: ... WHEN ... WRITE:/ ... ENDCASE. ENDAT. WRITE:/ f1, f2, ... ENDLOOP.

1.3.Nombramiento de variables

Los nombres de variable de ABAP/4 pueden usar hasta 30 caracteres para campos de DATOS y subrutinas y hasta 8 caracteres para OPCIONES de SELECCION y para PARMETROS, por lo tanto, como estndar se deben hacer nombres descriptivos.

Los nombres de los campos de una tabla o de un segmento de SAP son escritos con guin con un '-', y se usa ' _' (guin bajo) para separar las palabras para variables especficas de programa. Siempre que posible, el parmetro LIKE debe ser usado para definir campos de trabajo.

DATA: MAT_DT LIKE SY-DATUM, DAYS TYPE I, HOLD_ACCTNO LIKE sg-field1, GROSSAMT(10) TYPE P DECIMALS 2, GROSS_PERCENT(3) TYPE P DECIMALS 2, NET%(3) TYPE P DECIMALS 2.

Algunos tipos variables deben ser prefijados con una prefijo especifico:

Tipo VariablePrefijo

Parmetro de pantalla de seleccinp_

Parmetro de rutina form p_

Opciones de seleccinso_

Rangos r_

Tablas internas (globales)t_

Tablas internas (locales)Lt_

Constantesc_

Variables lv_

Tipos_type (postfijo)

Parmetros de importacin y de exportacin de mdulos de funcinmi_ (importacin)me_ (exportacin)

Ejemplos de subrutina:

FORM CALCULATE_MATURITY_DATE. MAT_DT = SY-DATUM + DAYS. ENDFORM.

1.4.Cdigo reutilizable

Si un bloque de cdigo es ejecutado ms de una vez, debe ser colocado en una subrutina (form) en la parte inferior del cdigo. Esto hace el cdigo ms legible, requiere menos codificacin, y es ms fcil para eliminar fallas ya que facilita la depuracin del programa.

Tal procedimiento debe ser adoptado para eliminar grupos de cdigo redundante.

Tambin, cuando deben ser pasados los posibles parmetros a y desde subrutinas, es ms fcil entender y se reduce la necesidad de utilizar ms variables globales.

Siempre se debe documentar el objetivo de cada parmetro.

Una subrutina debe realizar apenas un proceso. Si existiera una subrutina que realice mas de un proceso, entonces debe evaluarse se debe dividirla en varias subrutinas. El nombre de una subrutina debe ser mnemnico.

1.5.Paso de parmetros en subrutinas

Siempre use las declaraciones TYPE y LIKE cuando especifique los parmetros formales de una subrutina. Este es un estilo de programacin bueno, ya que esto permite que el compilador ABAP genere el cdigo ms eficiente (que puede aumentar la interpretacin hasta un factor de dos). Por ejemplo: form tables p_tab1 like [] using p_param1 like p_param2 like p_param3 like p_param4 type p_param5 type .... endform.

1.6.Manejo de textos

Los archivos INCLUDE no pueden definir sus propios Elementos de Texto. Todos los Elementos de Texto a los cuales ellos se refieren deben ser definidos en el programa principal que invoca el archivo INCLUDE. Por lo tanto, si se requiere que un archivo INCLUDE pueda ser invocado por ms de un programa principal, el texto constante que es usado dentro del archivo INCLUDE debe ser definido con la declaracin de CONSTANTES. En casos adicionales a los archivos INCLUDE, el texto constante que es impreso en un informe puede ser almacenado como Smbolos de Texto. Hay dos caminos que usted puede hacer referencias a estos Smbolos de Texto, TEXTO-XXX o USING '...' (xxx). Aqu, el xxx significa un nmero de 3 dgitos, y ... para el texto del Smbolo de Texto. La primera forma requiere que usted por separado defina un Smbolo de Texto para el nmero xxx. Si xxx no es un Smbolo de Texto definido, la salida es vaca.

La segunda forma mejora la legibilidad del programa. El texto entre comillas debe corresponder al texto almacenado como el valor del Smbolo de Texto. Excepcin: Si no hay ningn texto salvado bajo el nmero xxx, se usa el texto entre comillas.

Ejemplo:

El smbolo de texto el nmero 001 tiene el texto 'Por favor entre su nombre':

WRITE: / TEXT-001, / 'Por favor entre su nombre'(001), / 'Cual es su nombre?'(001).

En este ejemplo todos tienen la misma salida: "por favor entre en su nombre".

En el Editor ABAP, se pueden comparar los textos usados en el programa con los textos almacenados como Smbolos de Texto eligiendo "Goto-> elementos de Texto-> smbolos de Texto".

1.7.Uso de UserIDs en programas

En ningn caso un programa de produccin o una funcin debe contener un UserID como dato literal o como constante. En el sistema de desarrollo puede ser necesario codificar Breakpoints para UserIDs especficos, sin embargo, estas tcnicas de depuracin deben ser quitadas antes de que el programa sea transportado.

1.8.Mensajes

Declare la clase de mensaje en la sentencia REPORT. Es posible especificar la clase de mensaje cada vez que un mensaje es la salida, pero es ms fcil especificarlo una vez en la declaracin de informe. Sin embargo, se puede usar un mensaje en otra clase que el de la clase definida en el informe aadiendo la clase en parntesis despus del mensaje.

Report ZZTEST1 message-id zz. message e001. message e012 with p_user. message e231(zl).

Evite usar mensajes genricos (placeholder) en programas.

Ejemplo: clase de mensaje ZZ:

001 Su trabajo ha sido salvado! ... 999 & & & &

En vez de usar el mensaje s999 con 'Su trabajo ha sido salvado!'", se debe usar el mensaje s001.

Para ayudar a localizar un mensaje apropiado, se puede usar la funcin "pattern" en el editor ABAP. Elija "other pattern" y teclee "find message" (o escjalo de la lista desplegable), y presiones enter. Siga las instrucciones desde all para encontrar un mensaje conveniente para su programa. Si no puede encontrar un mensaje conveniente, debe crear uno en la biblioteca de mensajes ZZ, a menos que su programa sea un programa de uso "temporal" y por tanto ser improbable que el mensaje sea reutilizado.

Si su programa tiene como salida un mensaje especfico que requiere de explicacin adicional, cree un nuevo mensaje y llene la forma de texto larga. Cuando el usuario haga clic en el mensaje, se mostrar el texto largo. Use el tipo de mensaje correcto:

TipoDescripcinAccin On-line Accin en Background

IInformativoPresione ENTER para CONTINUARNinguna

WAdvertenciaCorreccin posibleNinguna

EErrorCorreccin requeridaTerminacin de Programa

ATerminacin anormalSe abort la Transaccin Terminacin de Programa

SxitoMensaje en pantalla subsecuenteNinguna

Note que todos los mensajes son registrados en fondo por el sistema de procesamiento de fondo.

Todos los mensajes de error debern ser impresos va MESSAGE Id.

1.9.Uso de un Programa Estndar SAP como Plantilla de Desarrollo

Cuando se realice una copia de programas SAP estndar (copiar y renombrar para alteracin), no se debe eliminar ninguna lnea del programa original. En vez de eliminar cdigo, se debe comentar (sin excepciones !!!). Cuando una lnea del programa original sea alterada, se debe comentariar y colocar la lnea alterada enseguida de la comentariada.

1.10.Uso de Tablas

En la declaracin de tablas internas, el parmetro occurs deber existir siempre, cuando sea posible, el nmero mximo de entradas previsto para la tabla. De esta forma, el programa intentara apartar los recursos necesarios para su procesamiento en el inicio de su ejecucin. Cuando no fuera posible prever, con certeza, el nmero mximo de registros en la tabla, se debe usar occurs 0.

Ejemplo:

data: begin of ti_bdc occurs 100. include structure bdcdata. data: end of ti_bdc.

Siempre que fuera posible, evite cargar tablas internas con mas de 1000 registros. Tablas internas con un nmero muy grande de registros perjudican a nivel general el performance del sistema.

Cuando defina tablas internas usando el comando like, utilice la opcin with header line, sino en ese caso SAP no creara el header line automticamente.

Ejemplo:

data: ti_bdc like bdcdata occurs 100 with header line.

Dentro de un programa, la mayor parte del tiempo computacional es gastado en el acceso a la base de datos. El acceso a tablas muy grandes se puede transformar en un factor de riesgo a un buen desempeo de un programa, principalmente si se trata de programas que deban ser ejecutados peridicamente, tales como interfaces. A fin de minimizar el tiempo de gasto en el acceso a la base de datos, vale la pena recordar que en ABAP, los mtodos de extraccin de datos ( del ms eficiente para el menos eficiente) son:

1. Ejecutar una clusula select en una vista en vez de utilizarla en varias tablas2. Realizar un loop en una tabla interna3. Ejecutar una clusula select en una tabla interna4. Utilizar una tabla lgica usando el comando get.

1.11.Uso de Variantes

El desarrollador es responsable de asegurar que las variantes de prueba no sean transportadas al ambiente de produccin.

1.12.Uso de Parmetros de Seleccin

En pantallas de seleccin, los campos deben ser siempre referenciados a un campo existente en el diccionario de datos del R/3. De esta forma, el usuario podr accesar la pantalla de ayuda del campo a travs de las teclas de funcin F1 y F9 cuando el mouse estuviese posicionado en el campo.Evite la utilizacin de valores explcitos en el programa. Para obtener los datos necesarios a la lgica del programa, clusulas de seleccin (select statement), archivos de entrada o salida, utilice parmetros o pantallas de seleccin para garantizar flexibilidad de mantenimiento. Por lo tanto evite comandos del tipo:

select * from marc where werks = `5000`

if w_vbfa-vbtyp_n = `J` w_custo = mbew-strps * `1.2`.

Evite tambin el uso del default para atribuir valores iniciales a los parmetros o en las pantallas de selecciones. Esos valores pueden cambiar en el futuro. De preferencia a la creacin de variantes para fijar esos valores.

Los parmetros de seleccin deben ser validados en el evento at-selection-screen para limitar los datos entregados, configurados, por el equipo funcional.

Ejemplo:

No permitir que la fecha informada tenga un ao anterior al inicio del ao en curso.Todos los parmetros para seleccin de nombres de archivos deben ser definidos con entradas en caracteres minsculos (lower case) de tamao 128 bytes. (Use like rlgrap-filename).

1.13.Uso de Eventos

El evento start-of-selection no debe poseer mas de 20 lneas (excluyendo los comentarios) para que se resuma de forma lgica y concisa el procesamiento global del programa. El uso de subrutinas (perform xxxxxxx using yyyyyyy) debe ser extensamente utilizado para que ste limite de 20 lneas sea mantenido.

Ejemplo:

START-OF-SELECTION.* inicia el procesamiento de la interface PERFORM PROCESS_INTERFACE_OUTBOUND.

2. Estndares De Desarrollo De Tablas

2.1. Definicin de Dominios

Se deben definir los dominios de datos especficos de la aplicacin para controlar la validez, la precisin y la calidad de la entrada de datos.

Para cada dominio de datos se debe definir:

DominioTabla/ValorDescripcin

2.2. Definicin de Elementos de Datos

Se deben definir los elementos de datos necesarios para representar la semntica de los datos propios de la aplicacin.

Para cada elementos de datos se debe definir:

ElementoTipoLong.DominioDescripcin

2.3. Definicin de Estructuras

Para definir el contenido de la tabla se debe definir la estructura de registro de la tabla incluyendo los campos necesarios para construir la llave y para almacenar la informacin requerida..

Para cada dominio de datos se debe definir:

CampoElemento de datosClaveTipoLongitudDescripcin

2.4. Reglas De Definicin De Campos

El primer campo definido para cualquier tabla debe ser: MANDT.

Este es el campo 'de cliente/mandante', y hace la tabla especfica al cliente/mandante en el cual esta usada/modificada.

La nica excepcin a esta regla podra ser ciertas tablas de infraestructura que podran ser definidas. Sin embargo, stos no seran tablas de aplicacin (de lgica de negocio).

2.5. Configuraciones De Mantenimiento

Si el flag "Tab. Maint. Allowed" esta activo o sea si esta en 'X', se permite el mantenimiento con el Navegador de Datos (Transaccin SE16).

Si este flag est puesto y si el usuario tiene la autorizacin necesaria, los datos en la tabla pueden ser cambiados.

Si los archivos de datos de la tabla slo pueden ser mantenidos por el programa o mantenimiento desde vista de tabla (Transaccin SM30), no se debe poner este flag.

2.6. Consideraciones De Seguridad

Cuando se desarrolla una tabla en SAP, se debe considerar lo siguiente:

1. Cmo sern aadidas, cambiadas, o suprimidas las entradas para esta tabla?

Para responder est pregunta se tienen las siguientes opciones:

a. Solo a travs de un programa b. Solo a travs de mantenimiento de tabla estndar c. tanto por mantenimiento de tabla estndar como por la aplicacin.

2. Las entradas en esta tabla son dependientes de entradas en otra tabla o viceversa? Es esto necesario para consistencia lgica?

De ser as, una tabla de control debe ser usada para asegurar esta consistencia, o el mantenimiento slo debe ser hecho va una aplicacin expresamente desarrollada para asegurar esta relacin.

3. Quin puede aadir, cambiar, suprimir entradas de esta tabla?

Solo pueden tener acceso las personas que usan la tabla va una transaccin. 4. Es esta tabla uno de varias que tienen exigencias IDNTICAS de control de acceso, y que: a. Comnmente consultadas por un mismo grupo de usuarios? b. Comnmente mantenida por el mismo grupo de usuarios? Con esta informacin usted puede establecer una matriz que define 1. Las agrupaciones de las tablas, 2. Los tipos del acceso necesario, 3. Los grupos de las personas que tienen cada tipo del acceso.

2.7. Actualizaciones Directas De Tablas Estndar De Sap

En ningn caso un programa debe actualizar directamente tablas ENTREGADAS POR SAP usando los comandos INSERT, UPDATE, O DELETE. Las tablas entregadas por SAP comienzan con todas las letras diferentes de Y y Z, y ellas slo deben ser actualizados usando una transaccin de SAP. Para automatizar actualizaciones de una tabla va un programa, puede usar el comando CALL TRANSACTION (u opcionalmente crear un BDC que usa funciones suministradas de la SAP, o a travs del uso de BAPIs).

3. Estndares De Interfaz De Usuario

3.1. GUI: Gua de Estilo de SAP

Para aplicaciones que requieren la programacin de dilogo, la Gua de Estilo de SAP debe ser usada como una base para el desarrollo. La utilizacin de esta gua para diseo de pantalla y ergonoma asegurar la consistencia en las transacciones desarrolladas.

La Gua de Estilo de SAP est disponible en la documentacin de ayuda usando el siguiente camino de men: Help -> R/3 Library -> BC-Basis Components -> ABAP Workbench (BC-DWB) -> BC-> SAP Style Guide.

Otro recurso til es la transaccin de demostracin suministrada de SAP la cual da ejemplos (con documentacin) de los estndares usados tanto en programacin de dilogo como en generacin de lista.

La transaccin de demostracin BIBS debe ser usada como gua para el Screen Painter.

La transaccin de demostracin LIBS debe usada como guas para salida de lista.

Como estndar para la interfaz GUI de los desarrollos de LIQUIDACION DE RENTAS se manejar las disposiciones de pantalla para datos generales y para posiciones, incluidas en el anexo XX.

4. Estndares De Documentacin

4.1. Aspectos Que Se Deben Documentar

El desarrollador es responsable de proporcionar la descripcin exacta del programa en la seccin 'Documentacin' del editor ABAP.

La descripcin debe ser actualizada cuando los cambios son hechos al programa.

La documentacin debe describir lo que el programa hace en trminos generales, entrada y salida del programa.

En caso de criterios de seleccin complejos, proporcione explicaciones de campos de seleccin y de las opciones de seleccin si es el caso.

Tambin, incluya los siguientes comentarios en la parte superior del cdigo fuente:

1. Cuando cree un nuevo programa, registre al Autor, la descripcin del desarrollo, y la fecha para consulta o referencia futura.2. Al hacer cambios, el nombre de desarrollador quin hizo el cambio o la extensin, descripcin del cambio, el transporte el nmero y la fecha3. Cdigo de transaccin, y camino de men.4. Si es necesario, notas de documentacin de algunos aspectos tcnicos del programa.

4.2. Documentacin De Produccin

Al mover el programa al ambiente de produccin, el desarrollador debe actualizar la documentacin de transportes a Produccin con instrucciones especficas del transporte.

El desarrollador debe informar al basis va el correo electrnico sobre el nuevo trabajo tan pronto como sea posible.

4.3. Documentacin De Cdigo Fuente

El editor de cdigo de ABAP/4 auto documenta. Sin embargo, es necesario proveer a futuros desarrolladores de la documentacin. Explique el objetivo, el diseo, la estructura y cualquier nota adicional en la parte superior del programa.

El desarrollador debe mantener una historia de notas de modificacin, con fechas, y con el cambio ms reciente primero. Comentario con los campos de trabajo y parmetros con su explicacin respectiva, todas las subrutinas con su objetivo. Los comentarios deben explicar lo que el cdigo hace, no como el cdigo lo hace.

Es obligatorio para completar la plantilla de documentacin antes del transporte del programa al sistema de produccin.

Adems de la documentacin va las plantillas, los comentarios breves dentro del cdigo son muy provechosos para el mantenimiento de programa. Por ejemplo, usted debe documentar los pasos principales en la fuente de programa, como:

do 16 times. "Explicar porque 16 veces ... enddo.

Para el siguiente ejemplo de CASE, cada valor posible debe ser documentado:

case . when 'Y'. "Explicar que significa Y ... when 'H'. "explicar que significa H ... endcase.

Para la documentacin general del cdigo fuente, se debe usar la siguiente convencin de documentacin:

*********************************************************************** * Nombre: (nombre_reporte)* Descripcin:* Fecha (MM/DD/AAAA): * Autor:* Transaccin (si aplica):* Requerido por:*********************************************************************** * HISTORIAL DE CAMBIOS************************************************************************ Descripcin:** Fecha:* Autor:* Solicitado por:**********************************************************************

Dependiendo del tipo de desarrollo, el encabezado del cdigo se debe documentar indicando lo siguiente:

ELEMENTO DESCRIPCION

Nombre Nombre del desarrollo

Tipo de desarrolloPrograma ejecutable, funcin, module pool, SAPScript, Smart Form, Mdulo de Funcin, Mdulo Web, Field Exit, User Exit, Customer Exit, Menu Exit, Screem Exit, Bath Input, Direct Input, LSW, ECAT

Objetivo del desarrolloDescripcin breve de la finalidad del desarrollo

Descripcin del desarrolloDescriba detallada del alcance del desarrollo y de los requerimientos que esta solventando

VersionNmero de la ltima versin liberada de el programa

Autor/ Escrito porNombre del programador y de la compaa

Fecha de creacinFecha Terminacin del Desarrollo en formato MM/DD/YY

Area de Aplicacin Nombre del mdulo SAP al que est orientado el desarrollo

Frecuencia de ejecucinUna vez, Diaria, Cuando se requiera, etc.

Parmetros de corridaLista de los parmetros, de las opciones de seleccin y su uso correspondiente

Cdigos de TransaccinLista las transacciones usadas para correr el programa

Describir el Macroproceso de la solucinLista de los pasos lgicos (Por ejemplo MACROALGORITMO) constitutivos del desarrollo.

Nombres de archivos de entradaNombre, descripcin y pathname (si es necesario) de los nombres de los archivos de entrada requeridos por el desarrollo

ImplementacinDescripcin tcnica del desarrollo. Aqu se describen los algoritmos especiales que se hayan desarrollado.

Nombres de archivos de salidaNombre , descripcin y pathname (si es necesario) de los nombres de los archivos de generados por el desarrollo

Validaciones de datos de entradaDescripcin de las validaciones de campo adicionales a las realizadas a travs del diccionario de datos (Search Help)

Reportes generadosLista de los reportes generados

Procesos funcionales relacionadosLista de los procesos funcionales directamente relacionados con el desarrollo

LimitacionesLista de la limitaciones y vulnerabilidades conocidas

Historia de MantenimientoEs deseable que las modificaciones ms viejas estn de primero.Se sugieren los siguientes datos:1. Autor de la modificacin: Desarrollador y compaa2. Fecha de la mdificacin: en Formato MM/DD/YY3. Descripcin del cambio4. # de la Orden de transporte creada

AlcanceLocal/Nacional/Internacional

Modo de ejecucinComo ejecutar el programa : En Lnea/En Batch/Como Trasaccin

ScreensPantallas includas en el desarrollo

Customizing/ParametrizacinDocumentacin de parametrizacin preliminar requerida

Cambios de releasesQue hacer cuando se migre a un nuevo release de SAP

R/3 ReleaseEn que release de R/3 fue desarrollado y probado

Otras consideracionesCualquier otra cosa que el desarrollador encuentre importante para documentar

LISTA DE ERRORES

Lista con una tabla de errores manejados en el desarrollo, indicando error y descripcin de error.

4.4. Documentacin De Secciones De Cdigo ABAP

Cada una de las siguientes secciones del desarrollo debe ser documentada y en lo posible estas secciones deben ir en el orden dado a continuacin:

Tablas Parmetros y Opciones de Seleccin Declaracin de Estructuras, Tablas y de Variables de Trabajo (DATA) Constantes Inicializaciones Verificaciones de Opciones de Seleccin Lgica de solucin (EJ. START OF SELECTION) Eventos de pgina Lgica de navegacin (Ej: Comandos de usuario, Lneas de seleccin) Formas (Rutinas de programa).

Como norma los bloques de cdigo se deben documentar de la siguiente forma:

1. Hacer un breve comentario para cada bloque del cdigo.2. Comentario con el transporte y rango de las lneas cambiadas.

La idea es guardar la documentacin a alto nivel (general para el usuario) en el Seccin 'de documentacin' y el tcnico / detalle en el fuente.

La documentacin en la seccin 'de Documentacin' puede ser extrada de el documento de especificaciones. Esta documentacin puede referirse ms al proceso de negocio.

A continuacin se presenta la documentacin mnima esperada de cada seccin de cdigo.

4.4.1. Documentacin De Declaracin De Tablas

Aqu sern declaradas todas las tablas del diccionario de datos que pretendamos utilizar en el programa.

Ejemplo: *****************************************************************Tablas del Diccionrio de Datos **************************************************************tables: MARA.Breve descripcin de la tabla

4.4.2. Documentacin De Declaracin De Constantes

Media lnea de comentario debe ser utilizada para describir la funcionalidad de cada constante.

Ejemplo: *****************************************************************Definicin de Constantes **************************************************************constants: c_constante type n.Descripcin de la constante

4.4.3. Documentacin De Declaracin De Tipos

Todas las constantes deben se de la forma nombre_TYPE. Media lnea de comentario debe ser utilizada para describir la funcionalidad de cada tipo utilizado. Observe que _TYPE es fijo.

Ejemplo:

*****************************************************************Definicin de Tipos **************************************************************types: werks_TYPE.Breve descripcin del tipo

4.4.4. Documentacin De Declaracin De Parmetros Y De Opciones De Seleccin

Media lnea de comentario debe ser utilizada para describir cada uno de los parmetros y de las opciones de seleccin.

Ejemplo:

*****************************************************************Definicin de la Pantalla de Selecciones **************************************************************parameters: p_param(8) type c. Descripcin del parmetroselect-option so_name for mara-matnr. Descripcin del campo

4.4.5. Documentacin De Variables

Media lnea de comentario debe ser utilizada para describir cada una de las variables.

Ejemplo: *****************************************************************Definicin de las Variables **************************************************************data: w_var1 type n, Descripcin de la variable global

4.4.6. Documentacin De Declaracin De Eventos

Todos los eventos deben poseer un comentario en su inicio y otro en su fin.

Ejemplo:

*****************************************************************Evento: At Selection Screen **************************************************************At selection-screen....************ Fin del Evento At Selection Screen **************

4.4.7. Documentacin De Declaracin De Secuencia De Comandos

Todas las secuencias de comandos deben ser comentadas por 3 asteriscos en el inicio de la lnea precediendo el texto de comentario. Adems de eso debe existir una lnea en blanco antecediendo el comentario

Ejemplo:

***Lee el registroread dataset pc_file into gw_record.

4.4.8. Documentacin De Declaracin De Literales

En el caso que un determinado texto sea muy utilizado a lo largo de un programa, utilice TEXT ELEMENT:

Ejemplos: correcto: write: /TEXT-001. "Nmero total de registros:.incorrecto: write: / Nmero total de registros:.

4.4.9. Documentacin De Llamadas A Las Subrutinas(Forms)

Los Forms deben ser llamados de la siguiente forma.

Ejemplo: *** Busca los datos del reporte.perform buscar_datos.

4.4.10. Documentacin De Rutinas

Los Formso subrutinas deben poseer un encabezado de la siguiente forma. Ejemplo:

**************************************************************** Form:*** Descripcin: *** Parmetros de Entrada: *** Parmetros de Salida: *************************************************************

4.5. Documentacin De Mdulos De Funcin

Los parmetros de importacin y de exportacin de mdulos de funcin deben ser documentados con breves descripciones de los campos y sus contenidos tpicos. Tambin, cualquier exigencia especial o uso deben ser denotados. Como mnimo, para cada parmetro se debe completar la documentacin 'short text'.

4.6. Documentacin Externa al Desarrollo

4.6.1. Documentacin De La Arquitectura Del Sistema

La elaboracin de este documento aplica cuando se haya aplicado la Metodologa Para Desarrollo de Mdulos Complementarios a la funcionalidad Estndar de SAP y Para Ampliaciones Significativas de Funcionalidad.

El documento de Arquitectura del Sistema debe contar con los siguientes componentes:

1. Modelo de Datos, 2. Relaciones, 3. Componentes de software (como Middleware, ADS, BRF) , 4. Entradas, 5. Salidas, y 6. Plataforma tecnolgica.

La arquitectura del sistema debe incluir tambin la definicin de los siguientes Objetos de desarrollo globales de desarrollo :

1. Tipos, 2. Tablas Transparentes, 3. Tablas Z, 4. Estructuras, 5. Vistas, 6. Objetos, 7. Mtodos, 8. Funciones, 9. BADIs, 10. BAPIs, 11. Reglas, 12. Eventos, 13. Diccionario de datos actualizado,14. Programas.

4.6.2. Manual Tcnico

Constituye la documentacin tcnica de cada desarrollo realizado. El Manual Tcnico debe contener los siguientes elementos segn sea el caso, as como las pantallas asociadas a cada uno de ellos (si aplica):


Nombre Nombre del desarrollo:

Tipo de desarrollo Programa ejecutable, funcin, module pool, SAPScript, Smart Form, Mdulo de Funcin, Mdulo Web(BSP, WebDinpro), Field Exit, User Exit, Customer Exit, Menu Exit, Screem Exit, Bath Input, Direct Input, LSW, ECAT y dems

Clase de desarrolloClase de desarrollo asignada al nuevo desarrollo

Transaccin AsignadaTransaccin asignada en SAP al desarrollo

Camino de MenCamino de men asignado al desarrollo

Objetivo Descripcin breve de la finalidad del desarrollo

Descripcin / PropsitoDescripcin detallada del alcance del desarrollo

Versin SAPVersin SAP a la cual aplica el desarrollo

Fecha CreacinFecha de creacin del desarrollo

AutorNombre del desarrollador

Fecha Ultima ActualizacinFecha de la ltima actualizacin realizada al desarrollo


Macroproceso de la solucin implementadaLista y describe los pasos de procesamiento realizados en el desarrollo. Describe los Eventos de programacin.Se debe incluir diagrama de bloques indicando la lgica del proceso.Si es del caso, debe incluir las formulas utilizadas o requeridas en cada paso del proceso.

PrecondicinLista de cualquier entrada y procesamiento necesarios antes de ejecutar el programa

Opciones de SeleccinLista de todas las opciones de seleccin esperadas por el desarrollo, y de sus valores esperados

Salidas Lista de las salidas desde el desarrollo

Rutinas / Forms Incluye las rutinas realizadas como parte del desarrollo. Se especfica descripcin tcnica y funcional, entradas y salidas. Se sugiere incluir tambin el desarrollador y fecha del desarrollo, as como estos mismos datos para actualizacin incluyendo el cambio realizado.

Funciones SAP Lista de las funciones SAP y de Cliente usadas por el programa

Transacciones llamadasLista de las transacciones SAP llamadas en el desarrollo

Programas llamadosLista de los programas llamados por el desarrollo

IncludesLista de los mdulos Incluye incluidos dentro del desarrollo

Tablas UsadasLista de las tablas transparentes e internas usadas en el desarrollo.Para las tablas nuevas se sugiere incluir adicionalmente los siguientes campos: Nombre de la Tabla, Indices, Nmero estimado de registros, Patrn de crecimiento, Frecuencia de acceso, Buffered o No Buffered.

Indices Lista de nuevos ndices que deben ser creados

Campos-Tabla UsadosLista de los campos usados por cada tabla incluida en el desarrollo.

Tablas Internas

Nombre de la tabla, y campos de su registro

Campos-Tabla InternaLista de los campos usados por cada tabla interna incluida en el desarrollo.

EstructurasLista de las estructuras usadas en el desarrollo

Campos/Variables de trabajoLista de las variable de trabajo claves usadas en el desarrollo

LISTA DE ERRORES


En el anexo XX se adjunta la plantilla del manual tcnico.

4.6.3. Manual Del Usuario

Constituye la documentacin de usuario de cada desarrollo realizado. El Manual del Usuario debe contener los siguientes elementos segn sea el caso, as como las pantallas asociadas a cada uno de ellos (si aplica):


Nombre Nombre del desarrollo:

Transaccin AsignadaTransaccin asignada en SAP al desarrollo

Camino de MenCamino de men asignado al desarrollo

Fecha CreacinFecha de creacin del desarrollo


Fecha Ultima ActualizacinFecha de la ltima actualizacin realizada al desarrollo

Autor Nombre del desarrollador

Objetivo Descripcin breve de la finalidad del desarrollo

Descripcin / PropsitoDescripcin detallada del alcance del desarrollo

Versin SAPVersin SAP a la cual aplica el desarrollo

Macroproceso de la solucin implementadaLista y describe los pasos de procesamiento realizados en el desarrollo. Se debe incluir diagrama de bloques indicando la lgica del proceso.

Si es del caso, se deben incluir las frmulas utilizadas o requeridas en cada paso del proceso.

PrecondicinLista de cualquier entrada y procesamiento necesarios antes de ejecutar el programa

Opciones de SeleccinLista de todas las opciones de seleccin esperadas por el desarrollo, y de sus valores esperados

Salidas Lista de las salidas desde el desarrollo

LISTA DE ERRORES


En el anexo XX se adjunta la plantilla del manual del usuario.

5. Estndares De Rendimiento

5.1.Cdigo Inactivo

Evite dejar cdigo "muerto" en el programa. Se deben comentariar (o suprimir) las variables que no son referidas y cdigo que no es ejecutado.

5.2.Uso de bases de datos lgicas

Elija la base de datos lgica ms eficiente posible. Estudie los criterios de seleccin y qu ndices secundarios son usados para aquella vista. Provea los criterios de seleccin apropiados para limitar el nmero de registros ledos. Obligue a los usuarios a proveer los criterios de seleccin evaluando los criterios de seleccin entrados en la pantalla de seleccin durante en la pantalla de PANTALLA DE SELECCIN. Finalmente, cuando sea posible aproveche los matchcodes para aumentar la velocidad.

5.3.Uso de subrutinas

Para una modularizacin, la decisin de ejecutar una subrutina debe ser tomada antes de que la subrutina sea llamada. Por ejemplo: Esto es mejor:

IF f1 NE 0. PERFORM sub1. ENDIF. FORM sub1. ... ENDFORM. Que esto: PERFORM sub1. FORM sub1. IF f1 NE 0. ... ENDIF. ENDFORM.

5.4.Declaraciones IF

Al codificar las condiciones de IF anide las condiciones de modo que las condiciones externas sean aquellas que con la mayor probabilidad fallarn. Para expresiones lgicas con AND, coloque primero el valor probable falso y para el OR, coloque primero el valor probable verdadero.

Ejemplo - IF'S anidados :

IF (least likely to be true). IF (less likely to be true). IF (most likely to be true). ENDIF. ENDIF. ENDIF.

Ejemplo - IF...ELSEIF...ENDIF : IF (most likely to be true). ELSEIF (less likely to be true). ELSEIF (least likely to be true). ENDIF.

Ejemplo - AND: IF (least likely to be true) AND (most likely to be true). ENDIF.

Ejemplo - OR: IF (most likely to be true) OR (least likely to be true).

5.5.CASE vs. IFs anidados

Para probar si un campo es "igual" a algo, se puede usar IF anidados, o la declaracin CASE. EL CASE es mejor por dos motivos: Es ms fcil leerlo despus de aproximadamente cinco IFs anidados, y la interpretacin del CASE es ms eficiente.

5.6.Estructuras MOVE-ing

Cuando los archivos a y b tienen exactamente misma estructura, es ms eficiente ejecutar MOVE a TO b que MOVE-CORRESPONDING a TO b.

MOVE BSEG TO *BSEG.

es mejor que

MOVE-CORRESPONDING BSEG TO *BSEG.

5.7.SELECT y SELECT SINGLE

Usando la declaracin SELECT, estudie la llave y siempre que sea posible proporcione la mayor parte de la parte extrema izquierda de la llave. Si la llave entera puede ser calificada, utilice un SELECT SINGLE y no un SELECT solamente. Si slo est interesado en la primera fila o slo desea que una sola fila sea devuelta, usando SELECT SINGLE se puede aumentar la interpretacin hasta tres veces.

5.8.Tablas internas pequeas vs. tablas internas completas

En general es mejor minimizar el nmero de campos declarados en una tabla interna. Aunque puede ser conveniente declarar una tabla interna usando la orden LIKE, en la mayor parte de casos, los programas no usarn todos los campos de la tabla de estndar de SAP. Por ejemplo:

En vez de este:

data: t_vbak like vbak occurs 0 with header line.

Use este:

data: begin of t_vbak occurs 0, vbeln like vbak-vbeln, ... end of t_vbak.

5.9.Procesamiento de Tablas a Nivel de Registro

La seleccin de datos en una tabla interna usando un LOOP contra un ciclo SELECT-ENDSELECT, dar una mejora de interpretacin de al menos 2 veces.

Despus de que los datos han sido puestos en la tabla interna, entonces se puede realizar el procesamiento a nivel de registro.

Por ejemplo, use:

select ... from table into (corresponding fields of itab) where ... loop at endloop.

En vez de utilizar: select ... from table Technical Info) presenta un bajo rendimiento, al igual que el rendimiento resultante del procesamiento de un ciclo SELECT-ENDSELECT.

Se debe hacer lo siguiente para mejorar el rendimiento:

Usar SELECT into para almacenar las filas necesarias en una tabla interna, entonces Clasificar las filas por los campos llave, Use READ TABLE WITH KEY ... BINARY SEARCH en lugar de SELECT SINGLE. Note que esto slo tiene sentido cuando la tabla que usted almacena en una tabla interna no es demasiado grande (esta decisin debe ser tomada segn el caso).

5.11.LECTURA de registros simples de tablas internas

Cuando lee un solo registro en una tabla interna, el READ TABLE WITH KEY no es un READ directo. Este significa que si los datos no son clasificados segn la llave, el sistema debe leer secuencialmente la tabla. Por lo tanto, usted debe:

ORDENAR la tabla Usar READ TABLE WITH KEY BINARY SEARCH para un rendimiento mejor.

5.12.Ordenando Tablas internas

Cuando ORDENE tablas internas, especifique los campos de ordenamiento.

Por ejemplo :

SORT ITAB BY FLD1 FLD2.

es ms eficiente que

SORT ITAB.

5.13.Nmero de entradas en una tabla interna

Para averiguar cuantas entradas estn en una tabla interna use DESCRIBE.

DESCRIBE TABLE ITAB LINES CNTLNS.

es ms eficiente que

LOOP AT ITAB. CNTLNS = CNTLNS + 1. ENDLOOP.

5.14.Longitud de un campo

Para averiguar la longitud de un campo use la funcin de longitud de un campo.

FLDLEN = STRLEN (FLD).

es ms eficiente que

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

5.15.Diagnstico de rendimiento

Para diagnosticar problemas de rendimiento, es recomendable usar la transaccin de SAP SE30, para Anlisis de Tiempo de ejecucin de ABAP/4. Esta transaccin permite el anlisis estadstico de transacciones y programas.

5.16.SELECTs anidados versus table views

Desde el release 4.0, OPEN SQL permite ambos inner y outer table joins. Los SELECTs anidados pueden ser usados para llevar a cabo la misma seleccin.

No obstante, el rendimiento de SELECT anidados es muy pobre en comparacin con un join. De ah, para mejorar el rendimiento por un factor de 25x y reducir la carga de la red, se debe crear o una vista en el diccionario de datos y entonces usan esta vista para seleccionar datos, o utilizar un join.

5.17.Si SELECTs anidados deben ser usados

Como se menciono antes, el rendimiento puede ser mejorado obstenciblemente usando vistas en vez de SELECTs anidados, sin embargo, si esto no es posible, entonces el siguiente ejemplo de usar una tabla interna en un SELECT anidado tambin puede mejorar la interpretacin por un factor de 5 veces.

Use este: form select_good. data: t_vbak like vbak occurs 0 with header line. data: t_vbap like vbap occurs 0 with header line. select * from vbak into table t_vbak up to 200 rows. select * from vbap for all entries in t_vbak where vbeln = t_vbak-vbeln. ... endselect. endform.

En vez de este:

form select_bad. select * from vbak up to 200 rows. select * from vbap where vbeln = vbak-vbeln. ... endselect. endselect. endform.

Aunque usando "SELECT...FOR ALL ENTRIES IN..." es generalmente muy rpido, hay que tener en cuenta lo siguiente:

En primer lugar, la SAP automticamente quita cualquier duplicado del resto de los archivos recuperados. Por lo tanto, si usted desea asegurar que ninguno registros calificados son desechados, la lista de registros del INNER SELECT debe ser diseada para asegurar que los registros recuperados no contendrn duplicados (normalmente, este significara incluir en la lista de campos recuperados todos aquellos campos que comprenden la llave primaria de aquella tabla).

En segundo lugar, si utiliza "SELECT ... FROM FOR ALL ENTRIES IN TABLE " y la tabla interna esta vaca, entonces todas las filas de sern recuperadas.

En tercer lugar, si la tabla interna que suministra los criterios de seleccin (es decir tabla interna en el ejemplo "...FOR ALL ENTRIES IN TABLE ") contiene un nmero grande de entradas, puede generar degradacin del rendimiento.

5.18.SELECT * versus SELECT de campos individuales

En general use la instruccin SELECT con la especificacin de una lista de campos en vez de un SELECT *, para reducir trfico de red y para mejorar el rendimiento. Puede que la mejora no sea muy alta para tablas con unos pocos campos, pero muchas tablas de SAP contienen ms de 50 campos cuando el programa necesita slo unos cuantos. En este ltimo caso, las ganancias de rendimiento pueden ser sustanciales.

Por ejemplo Use:

select vbeln auart vbtyp from table vbak into (vbak-vbeln, vbak-auart, vbak-vbtyp) where ...

En lugar de usar:

select * from vbak where ...

5.19.Evitar instrucciones innecesarias

Hay unos casos donde un comando es mejor que dos.

Por ejemplo use: append to .

En lugar de: = . append (modify ).

Y tambin use:

if not [] is initial.

En lugar de:

describe table lines . if > 0.

5.20.Copiar o aadir en tablas internas

Use esto:

[] = []. (if is empty)

En vez de esto:

loop at . append to . endloop.

Sin embargo, si no esta vaca y no debe ser sobrescrita, entonces se debe usar:

append lines of [from index1] [to index2] to .

6. Estndares De Convenciones De Nombres

6.1. Convencin De Nombres De Tablas Y De Vistas

Las tablas SE DEBEN NOMBRAR como sigue: PosicinUso

1'Z'

2-3Abreviacin de nombre de aplicacin

4-16Caracteres Descriptivos

Las tablas se nombran de igual manera, pero se agrega la letra V al final.

6.2. Nomenclatura De Objetos De Desarrollo

En general, cualquier desarroll a la medida de programas o de objetos deben ser nombrados con "Z" para el primer carcter. SAP ha designado objetos que comienzan con las letras "Y" y "Z" para que el cliente nombre objetos y para asegurar que este espacio de nombres no ser superpuesto durante una actualizacin.

Los programas que no sern migrados para Produccin deben comenzar con "Y". As mismo, SAP con regularidad actualiza las convenciones recomendadas para los rangos de nombre de cliente para todos los objetos de desarrollo. Para objetos no incluidos en esta gua, por favor consulte el documento CREADO POR SAP, y localizado en la nota SAP OSS #16466.

En el release de R/3 3.0F, los nombres de un programa ABAP estaban limitados con 8 caracteres. Desde el release de R/3 4.6C, los nombres de programas ABAP pueden ahora tener una longitud de hasta 40 caracteres.

Para todos los objetos y documentos de desarrollo se utilizar la siguiente convencin de nombres:

ZMMSS_NN_texto

La cual se describe a continuacin:

PosicinUso

1'Y' Si el programa no se migrar a produccin

'Z' Si el programa ser migrado a produccin


4-5Abreviacin de nombre de mdulo

6Guin bajo [Underline]

7-8Abreviacin que Identifica el TIPO DE OBJETO o de DOCUMENTO

LETRAOBJETO

PGProgramaINIncluyeFMMdulo de FuncinRPReportesBIBatch InputSQSAP QueryWFWorkFlowSFSmartformSSSapscriptAFAfobeFormBSBSPFG Grupo de FuncionesTXTransaccinEFDocumento de Especificacin FuncionalETDocumento de Especificacin TcnicaDTDocumento de Documentacin Tcnica

9Guin bajo [Underline]

10-40Palabras o acrnimos descriptivos del desarrollo. En el caso de mdulos de funcin se usan los caracteres 10-30.

Si el programa ABAP est siendo creado como un INCLUDE de datos globales o un INCLUDE de subrutina, este debe ser formatea como sigue: PosicinUso

1'Z' requerido para desarrollos cliente

2-37Igual que las posiciones 2-37 del programa principal

ltimos 3 caracteres'TOP' si el INCLUDE es usado para datos globales, constantes, declaraciones de tabla, tipos, field symbols.

'F##' para subrutinas, donde ## es un nmero, desde 00 hasta 99.

6.3. Clases De Desarrollo Paquete

Las clases de desarrollo slo deben ser creadas cuando un nuevo proyecto especfico requiere que todos los componentes sean unidos para objetivos organizativos.

6.3.1. Nomenclatura Clases De Desarrollo

Para las clases de desarrollo Z que se creen se utilizar la siguiente nomenclatura:

Zmm

En donde: mm = Letras que Identifican al MODULO PRINCIPAL

En donde mm puede ser de mayor longitud dependiendo del caso especial que se est trabajando.

Todos los objetos creados durante el desarrollo de alguna aplicacin, deben ser asignados a la clase de desarrollo de acuerdo al Mdulo SAP al que pertenecen.

En caso de creacin de nuevos mdulos adicionales a la funcionalidad de SAP, en mm se utilizar la sigla definida para el mdulo adicionado.

6.4. Module Pools

Los Module pools se deben nombrar de la siguiente forma: Posicin Uso

1-3'SAPM' requerido por el sistema para denotar mdulos en lnea

5'Z' para denotar nombres en el espacio de nombres del usuario


8Nmero consecutivo (0-9)

Los includes de Module pool deben ser nombrados siguiendo la siguiente convencin: Posicin Uso

1'M' Requerido por el sistema para denotar mdulos en lnea

2'Z' para denotar nombres en el espacio de nombre del cliente


5Nmero secuencial (0-9) correspondiendo al programa principal

6'I' para mdulos PAI, 'O' para mdulos PBO, 'F' para subrutinas

7-8Nmero secuencial (00-99)

6-8'TOP' si el include es el de datos globales

6.5. Convenciones De Nombramiento De Objetos De La Interfaz GUI

Los objetos de la interfaz GUI deben ser nombrados como sigue:

ELEMENTOLONGITUDNOMENCLATURA

Screens4Nmerico entre 9000 y 9999

Area menu4Zxxxx:Abierto

GUI Status4Zxxxx:Abierto

Function keys4xxxxx:Abierto

Titlebar3Zxxx:Abierto

6.6. Convenciones De Nombramiento De Objetos De Desarrollo Adicionales

Se definen a continuacin las siguientes convenciones de nombres para objetos adicionales de desarrollo:

ELEMENTOLONGITUDNOMENCLATURA

Message Classes6Zaaxxxa:Mdulo SAP Relacionadox: Abierto

ABAP Variant14ZxxxxxxxxxxxxxxX:Abierto

Domains10ZDxxxxxxxxX:Abierto

Data Elements10ZExxxxxxxxX:Abierto

Matchcode objects4ZxxxX:Abierto

6.7. Convenciones De Nombramiento En ABAP Objects.

A fin de evitar problemas durante el desarrollo y durante las actualizaciones de versin, no es slo provechoso sino tambin necesario hacer convenciones de nombres dentro del espacio de nombres de cliente para los Objetos ABAP.

Las clases y sus subclases dependientes comparten el mismo espacio de nombres que afectan:

Constantes (CONSTANTS) , Variables (DATA, CLASS-DATA) , Mtodos (METHODS, CLASS-METHODS) y Eventos (EVENTS, CLASS-EVENTS).

SAP no ha decidido todava si permite maysculas o minsculas para nombres internos (para separar palabras individuales - como en JAVA). Por lo tanto, para separar palabras individuales todava tenemos que usar el carcter subrayar.

6.7.1. Reglas Generales

Siempre use trminos significativos para nombrar objetos. Use trminos de diccionario de datos siempre que sea posible. Por ejemplo: ZCL_COMPANY_CODE, en vez de BUKRS, ya que este ser estndar de SAP en el futuro (ver BAPIs) Cuando los nombres estn agrupados use '_' como un separador. Por ejemplo: ZCL_COMPANY_CODE, ZCL_GENERAL_LEDGER_ACCOUNT Los nombres deben describir lo que es el sujeto, y no como este ser implementado. Por ejemplo: PRINT_RECTANGLE y no RECTANGLE_TO_SPOOL.

6.7.2. Convenciones Generales De Poo Programacion Orientada A Objetos

Clases en la Librera de Clases ZCL_ El nombre de clase debe consistir de sustantivos y slo debe usar la forma singular: ZCL_COMPANY_CODE ZCL_GENERAL_LEDGER_ACCOUNT

Interfaces en la Librera de Clases ZIF_ Las convenciones de nombramiento para clases tambin se aplican para interfases:. ZIF_STATUS_MANAGEMENT, ZIF_CHECKER

Tipos en el DDIC (Data Diccionary) Z

Clase Local LCL_ El nombre de clase debe consistir de sustantivos y slo debe usar la forma singular: LCL_TRANSACTION

Interface Local LIF_ Las convenciones de nombramiento para clases tambin se aplican para interfases: LIF_PRINTER

6.7.3. Convenciones De Nomenclatura De Clase

Nombre de mtodo El nombre del mtodo debe comenzar con un verbo. GET_STATUS, CREATE_ORDER, DETERMINE_PRICE

Evento Los nombres de eventos deben ser como estos: _. BUTTON_PUSHED, COMPANY_CODE_CHANGED, BUSINESS_PARTNER_PRINTED

Definicin de Tipo de Clase Local _ty INTERNAL_TYPE_TY, TREE_LIST_TY

Definicin de Datos (Variable) Para evitar confusiones con nombres de mtodos, se debe evitar usar verbos al comienzo durante el nombramiento de variables dentro de una clase (CLASS-DATA, DATA). Ejemplos: LINE_COUNT, MARK_PRINTED, MARK_CHANGED, STATUS

Definicin de datos(Constantes) C_ C_MAX_LINE, C_DEFAULT_STATUS, C_DEFAULT_WIDTH, C_MAX_ROWS

6.7.4. Convenciones De Objetos De Metodo

Atributos de acceso SET_, GET_ Se deben prefijar todos los atributos de acceso con GET_ o con SET segn el caso. GET_STATUS, SET_USE_COUNT

Mtodos que tratan con un Evento ON_ Para mtodos que tratan con un evento, se debe comenzar el nombre con ON_ seguido del nombre del evento relevante. ON_BUTTON_PUSHED, ON_BUSINESS_PARTNER_PRINTED

Mtodos que realizan conversiones de tipo AS_ AS_STRING, AS_ISOCODE

Mtodos que devuelven un valor booleano Estos mtodos no pueden retornar ninguna EXCEPCION. Recomendacin: El valor booleano puede ser representado por ESPACIO/"X" para Falso/Verdadero.. IS_ IS_OPEN, IS_EMPTY, IS_ACTIVE

Mtodos de Verificacin Estos mtodos difieren de los IS_" por su habilidad para retornar excepciones. CHECK_ CHECK_AUTHORIZATION, CHECK_PROCESS_DATE

6.7.5. Convenciones De Parmetros De Mtodo

Los parmetros son nombrados desde el punto de vista de los mtodos, que los pusieron en prctica:

IMPORTING-ParmetroIM_

EXPORTING- ParmetroEX_< nombre_ parmetro >

CHANGING- ParmetroCH_< nombre_ parmetro >

RESULTRE_

EXCEPTIONSVer seccin a continuacin

6.7.6. Convenciones De Excepciones

El trabajo del desarrollador es ms fcil cuando estn disponibles los estndares para el nombramiento de excepciones. Lo siguiente es una tabla de excepciones ms significativas, y que tambin pueden ser usadas genricamente.(Ejemplo: ...NOT_FOUND podra usarse como DATE_NOT_FOUND)

EXCEPCIN SIGNIFICADO

ACTION NOT SUPPORTEDLa accin solicitada o el solicitado OK-Code soportado

CANCELLEDEsta EXCEPCIN puede ser colocada si se requiere que el usuario seleccione lo que pasa despus en un mtodo (por ejemplo: Lista de Seleccin) y l/ella selecciona "Anular".

EXISTINGUn nuevo objeto ya existe en la base de datos.

FAILEDLos mtodos no se pueden ejecutar debido al estado de ejecucin. Esta excepcin es usada sobretodo para casos donde el estado de ejecucin est temporalmente en una situacin que no permite que las tareas del mtodo sean realizadas.

..._FAILEDUna sub funcin del mtodo no puede ser ejecutada debido al estado de ejecucin (OPEN_FAILED, CLOSE_FAILED, SELECTION_FAILED, AUTHORIZATION_FAILED)

FOREIGN_LOCKOtros usuarios bloquean los datos.

INCONSISTENTEl objeto de datos en la base de datos es inconsistente.

..._INCONSISTENTEl sub-object de datos de un objeto en la bases de datos es inconsistente.

INVALIDEl objeto de datos entrado no es correcto. (e.g. Company Code is not available)

..._INVALIDLos datos dados del subobjeto de un objeto no son correctos.

INTERNAL_ERROREl ltimo recurso. Si todo lo dems falla y el error no puede manejarse, se debe aplicar esta EXCEPCIN.

NOT_AUTHORIZEDEl usuario no tiene la autorizacin para esta accin.

NOT_CUSTOMIZEDEl objeto solicitado no esta correctamente personalizado.

..._NOT_CUSTOMIZEDEl subobjeto del objeto solicitado no esta correctamente personalizado.

NOT_FOUNDEl objeto solicitado no ha sido encontrado.

..._NOT_FOUNDEl subobjeto del objeto solicitado no ha sido encontrado.

NOT_QUALIFIEDLa combinacin de parmetros de entrada no es suficiente para permitir que funciones del mtodo fueran realizadas.

..._NOT_QUALIFIEDUn parmetro especfico del mtodo no es calificado

NUMBER_ERRORError en la provisin de nmeros.

SYSTEM_ERROREsta excepcin puede ser puesta cuando el Basis System registra un cdigo de error inesperado.

Vi. Abap/4 Lista De Comprobacin Para Afinacin - Tuning

La siguiente lista de comprobacin fue desarrollada por la SAP para examinar rpidamente los problemas de rendimiento ms comunes.

El programa est usando instrucciones SELECT *?Convierta estas instrucciones a SELECT column1 column2, o use vistas/projection views.

Las instrucciones CHECK Para campos de tabla estn embebidas en un cliclo SELECT ... ENDSELECT?Incorpore las instrucciones CHECK en la clasula WHERE de la sentencia SELECT.

Se hacen SELECTS sobre campos no llave usando un ndice de la base de datos, o esta la tabla almacenada en un buffer?Cree un ndice para la tabla en el diccionario de datos o almacene tablas en un buffer si ellos son slo ledos o muy ledos.

El programa esta usando SELECTs anidados para recuperar datos?Convierta SELECTs anidados a database views, a DB joins (v4.0), o a SELECT xxx FOR ALL ENTRIES IN ITAB.

Hay SELECTs sin condicin WHERE contra tables que crecen constantemente(BSEG, MKPF, VBAK)?Se debe revisar el desarrollo/programa. Se debe verificar condiciones de seleccin.

Los accesos SELECT a tablas de datos maestros estn buffered?Haga buffer de las tablas de datos maestros almacenando los datos en una tabla interna y llenando la tabla usando el mtodo READ TABLE ... BINARY SEARCH.

El programa esta usando la tcnica SELECT ... APPEND ITAB ... ENDSELECT para llenar tablas internas?Cambie el procesamiento para leer los datos inmediatamente en una tabla interna. (SELECT VBELN AUART ... INTO TABLE T_VBAK ...).

El programa est usando instrucciones SELECT ORDER BY?Los datos deben ser ledos en una tabla interna primero y luego clasificados a menos que haya un ndice apropiado en los campos del ORDER BY.

El programa esta hacienda clculos que podran hacerse va las funciones SUM, AVG, MIN, o MAX de la sentencia SELECT?

Use las capacidades de clculo de la base de datos va SELECT SUM, ...

Se estn procesando las tablas internas usando la tcnica READ TABLE itab WITH KEY ... BINARY SEARCH?

Cambie el acceso a las tablas internas al mtodo BINARY SEARCH.

El programa est creando, actualizando, o borrando datos en modo de dilogo (y no a travs de un update function module)?

Este seguro que el programa utiliza la sentencia COMMIT WORK cuando una o ms unidades de trabajo (LUWs) han sido procesadas.

Vii. Buenas Prcticas De Desarrollo

1. Guas Para Suprimir Cdigo De ABAP Viejo O No Usado

Al realizarle mantenimiento a un programa, se escribe nuevo cdigo para sustituir el cdigo ms viejo. Esto es por lo general buena idea comentar el cdigo ms que suprimirlo completamente. Este sirve para 2 objetivos: hace disponible el cdigo viejo en el caso de que haya un problema con el nuevo cdigo, y esto sirve como documentacin para ver como cdigo funcionaba el cdigo anterior.

Despus de un tiempo, tanto cdigo comentado puede acumularse haciendo difcil de leer el programa - es decir el cdigo comentado acumulado puede ser confuso ms que provechoso. (El cdigo que alguna vez fue activo debe llevarse generalmente como cdigo comentado en al menos un transporte antes de que realmente sea suprimido, pero este no es una exigencia absoluta.) Si, a juicio del desarrollador, el cdigo comentado es confuso ms bien que provechoso, el viejo cdigo puede ser suprimido si se cumplen TODAS las siguientes cuatro condiciones:

1. El cdigo que se va a suprimir se ha registrado en el sistema de gestin de versiones de SAP como la parte de un transporte liberado.

2. Usted aade el texto a la historia de revisiones del programa, especificando las lneas que suprimi, por qu las suprimi, y el transporte liberado; y se debe citar tambin el ltimo transporte en el cual este cdigo estaba activo.

3. La historia de revisin del programa es razonablemente completa con explicaciones buenas de lo que fue aadido o suprimido como la parte de cada transporte, as como las consecuencias funcionales de aquel cambio (no slo un comentario genrico como "problema solucionado" o se aadieron nuevas funciones"). Una historia de versiones como esta debe ser mantenida contemporneamente con cambios en el cdigo. Si adquiere la responsabilidad de mantener un programa que ya est en la produccin y el cdigo comentado no esta descrito en la historia de versiones, usted no tiene que documentar retroactivamente el efecto del cdigo comentado. Usted tiene que aadir realmente a la historia de revisiones una explicacin acerca del cdigo comentado que usted suprime.

4. (Si es aplicable) Cuando un algoritmo o especificacin general son cambiados, los comentarios deben ser aadidos cerca del cdigo para el nuevo algoritmo o descripcin de la especificacin:

a. Como la nueva especificacin se diferencia de la anterior. b. El ltimo transporte liberado de la vieja especificacin. c. El rango de nmeros de lnea que contienen el cdigo que puso en prctica la especificacin anterior, el transporte mencionado en el punto b.

2. Grupos De Autorizacin

Se usarn grupos de autorizacin para controlar la ejecucin de transacciones y de funcionalidad restringida.

3. Autorizaciones: Uso De Objetos SAP

Para cualquier desarrollo especifico de cliente usando controles de autorizacin - authorization checks, los desarrolladores deben determinar si un objeto de autorizacin de SAP estndar debe ser usado, o si debe ser desarrollado un objeto de autorizacin especfico de cliente.

Ya que la realizacin de objetos de autorizacin normalmente est ms relacionada con el negocio que con asuntos tcnicos, para definir su implementacin, los desarrolladores deben consultar con los analistas funcionales responsables de la aplicacin.

4. Uso De Fechas

Los formatos preferidos para representar una fecha en un informe impreso son MM/DD/YYYY o DD-Mon-YYYY (donde "el MM" es un nmero de dos dgitos del mes, "DD" es un nmero de dos dgitos del da dentro del mes, y "YYYY" es un ao de cuatro dgitos, y "Mon" es la abreviatura de tres letras del nombre del mes).

En cualquier caso, el uso de un ao de 4 dgitos es una exigencia. (El formato preferido para fechas en entrada es YYYYMMDD.)

Siempre que una fecha sea escrita o leda, el campo de ao debe contener cuatro dgitos. La nica excepcin a este estndar es cuando se lee desde o se escribe a archivos externos, donde la restriccin de ao 2000 en el sistema externo puede ser diferente. Sin embargo, hasta en este caso, es deseable asignar cuatro dgitos para el ao en la disposicin de archivo.

5. JOBS: Registro De Estado Usando ZJOBRUN2

Muchos programas leen archivos de entrada o producen extractos del R/3 y requieren nombres detallados de archivo de datos y estados de error (ms all de la capacidad del planificador de trabajo Job Scheduler estndar de R/3). La tabla ZJOBRUN2 fue creada para proporcionar un registro comn para el estado de trabajo. Todos los programas que tienen que consultar el estado de trabajo deben leer / escribir archivos a / desde esta tabla. Los nuevos programas no deben usar archivos de texto fuera del sistema R/3 u otras tablas cliente para este fin.

NOTA: ZJOBRUN2 es una versin nueva y mejorada de la tabla de ZJOBRUN original. La tabla original est todava en el uso por programas ms viejos, pero ya no debe ser usada para desarrollar nuevos programas.

Aqu est la disposicin del ZJOBRUN2 tabla:

ZJOBRUN2 Table

CAMPODESCRIPCINDATO DE EJEMPLO

PROVIDERFile Transfer Provider

FEEDFile transfer Feed Code

BATCHSequential number of the job run145

DATUMDate of run08/07/2004

UZEITTime of run06:30:13

PGNAMProgram nameZPE_EXTRACT_TO_EHSWEB

FILEFile Namedehsetrq.145.20040807063013

TIMEFile Time Stamp20040807063013

EXTRDDate of Extract Creation08/07/2004

EXTRTTime of Extract Creation06:30:13

RECCOUNTRecord counter number processed589

CREDITTotal Credits (if aplicable)116.00

DEBITTotal Debits (if aplicable)473.00

CNTRLRECControl Record589

CTRL_CREDITTotal control Credits (if applicable)116.00

CTRL_DEBITTotal control Debits (if applicable)473.00

ERRCOUNTError Counter number or error records0

ERR_CREDITTotal error credits (if applicable)0.00

ERR_DEBITTotal error debits (if applicable)0.00

ERRFILEError File location of error file on UNIX filesystem

CURCYCurrency KeyUSD

FILSTATFile StatusG

REVIEWReview Flag

TEXTText any additional text info

UNAMEUser who executed the jobZZPEBATCH001

6. Comunicacin Entre Procesos De Primer Plano Y Procesos De Fondo

Esta seccin trata del mtodo "recomendado" para comunicar la informacin de un proceso de primer plano a un proceso de fondo.

En algunos casos es se requiere tener un programa interactivo que carga datos (por ejemplo leyendo un archivo en la mquina de escritorio, u otros leyndolos por otros medios como la entrada de usuario o una seleccin controlada por entrada de usuario) y pasa datos a un trabajo de fondo para un procesamiento adicional. Hay varios caminos a travs de los cuales la informacin podra ser pasada. Un mtodo es hacer que el programa interactivo escriba un archivo que el trabajo de fondo leer. Lo anterior ya no se recomienda.

Los tres mtodos siguientes son los recomendados.

Los dos primeros mtodos asumen que el trabajo interactivo (primer plano) crea y llama el trabajo de fondo y puede pasar parmetros al trabajo de fondo por la inclusin de los valores de parmetro en el comando SUBMIT.

Si hay datos muy pequeos, hacer que el trabajo de primer plano use el comando SUBMIT de pasar los datos actuales por parmetros de pantalla de seleccin u opciones de seleccin cuando cree el trabajo de fondo.

Si hay ms datos, hacer que el trabajo de primer plano lo exporte a la tabla INDX en la base de datos y con el comando SUBMIT se pasa la llave ID con un parmetro de pantalla de seleccin cuando se cree el trabajo de fondo.

En algunos casos especiales, podra ser mejor crear una nueva tabla cliente y hacer que el trabajo de primer plano cargue los datos en la tabla cliente, desde la cual el trabajo de fondo lo recuperar.

Este es un ejemplo ampliado del mtodo 2, mencionado arriba.

En el trabajo de primer plano, se asume que se tiene definida una tabla interna llamada "t_itab", junto con la carga de datos. La tabla interna el "t_itab" tiene exactamente la misma definicin en el fondo trabajo.

En el trabajo de primer plano:

TABLES INDX.DATA key like INDX-SRTFD. EXPORT t_itab TO DATABASE INDX(ar) ID key. donde "t_itab" es el nombre de su tabla interna, el "ar" es una constante de dos caracteres de su eleccin, "key" es una variable que contiene una llave nica (hasta 22 carcteres) que usted cre (usted puede usar elementos como el nombre de usuario, la fecha, el tiempo, el nmero de proceso de trabajo, el nombre de servidor de aplicacin, etc. para producir una llave nica):

SUBMIT BACKGRND ... WITH A_KEY1 = key ... .

En el trabajo de fondo: TABLES INDX. PARAMETERS: a_key1 like INDX-SRTFD NO-DISPLAY. IMPORT t_itab FROM DATABASE INDX(ar) ID a_key1.

donde "t_itab" es el nombre de su tabla interna, el "ar" es la misma constante de dos caracteres, el "a_key1" es el parmetro en el cual la llave nica fue pasada .

Cuando ya no necesite los datos, el programa debe borrar:

DELETE FROM DATABASE INDX(ar) ID a_key1. Programas de Ejemplo / Programas de Ejemplo /

Viii. Plantillas De Desarrollo

1. Plantilla Reporte Bsico De Lista

REPORT ZSKELREP.*********************************************************************** Nombre: (nombre_reporte)* Descripcin:* Fecha (MM/DD/AAAA): * Autor:* Transaccin (si aplica):* Requerido por:*********************************************************************** HISTORIAL DE CAMBIOS************************************************************************* Descripcin:** Fecha:* Autor:* Solicitado por:**********************************************************************

*------I N C L U D E S ------------------------------------------------------------*

*------C O N S T A N T E S ---------------------------------------------------*

*------TABLAS/ESTRUCTURAS----------------------------------------------*TABLES: ...

*------VARIABLES------------------------------------------------------------*DATA: ...*------PARAMETROS Y OPCIONES DE SELECCION-------------------*SELECT-OPTIONS: ...PARAMETERS: ...*------ FIELD-GROUPS Y FIELD-SYMBOLS --------------------------*FIELD-GROUPS: HEADER, ...FIELD-SYMBOLS: ...

* Evento que ocurre antes que la pantalla de seleccin sea mostrada al usuario *------ INICIALIZACION ------------------------------------------------------*INITIALIZATION.* Evento que sucede cada vez que el usuario da Enter en una pantalla de * seleccin. Este evento se ignora en procesamiento en Background..*------ AT SELECTION-SCREEN ----------------------------------------*AT SELECTION-SCREEN.*------ TOP-OF-PAGE ----------------------------------------*TOP-OF-PAGE.*------ END-OF-PAGE ----------------------------------------*END-OF-PAGE.*------ START-OF-SELECTION ----------------------------------------*START-OF-SELECTION.

* Definicin de campos para el FIELD-GROUP headerINSERT: ... INTO HEADER.GET ...END-OF-SELECTION.

SORT ...LOOP ... AT FIRST. ENDAT. AT NEW ... ENDAT. AT END OF ... ENDAT. AT LAST. ENDAT.ENDLOOP.* Subrutinas*----------------------------------------------------------------***----------------------------------------------------------------FORM ...ENDFORM.

2. Plantilla Reporte Interactivo De Lista

REPORT ZSKELINT.************************************************************************* Nombre: (nombre_reporte)* Descripcin:* Fecha (MM/DD/AAAA): * Autor:* Transaccin (si aplica):* Requerido por:************************************************************************* HISTORIAL DE CAMBIOS************************************************************************* Descripcin:** Fecha:* Autor:* Solicitado por:************************************************************************TABLES: ...DATA: ...SELECT-OPTIONS: ...PARAMETERS: ...FIELD-SYMBOLS: ...FIELD-GROUPS: ...* Evento que ocurre antes que la pantalla de seleccin sea mostrada al usuario INITIALIZATION.* Evento que ocurre cada vez que el usuario presiona F2 o da doble-click* sobre la lnea en la pantalla de seleccin. Este evento se ignora en * procesamiento en background.AT SELECTION-SCREEN.TOP-OF-PAGE.* Top of page para sublistas.TOP-OF-PAGE DURING LINE-SELECTION.END-OF-PAGE.START-OF-SELECTION.GET ...END-OF-SELECTION.

* Producir el reporte de la lista principal. SY-LSIND = 0.SORT ...LOOP...WRITE:/ ...

metodologia y estandares de desarrollo sap.doc.docx

Documents