3. Manual Abap4 - i

ABAP Fundamentos y Reporting


Contenidos 1 INTRODUCCIÓN AL SISTEMA SAP R/3 ....................................................................................7

1.1 VISIÓN LÓGICA DEL SISTEMA.......................................................................................................7 1.1.1 Kernel y servicios básicos ......................................................................................................8 1.1.2 ABAP Workbench ...................................................................................................................9 1.1.3 Nivel de presentación .............................................................................................................9

1.2 VISIÓN DESDE EL PUNTO DE VISTA DEL SOFTWARE......................................................................9 1.2.1 Nivel de Base de Datos.........................................................................................................10 1.2.2 Nivel de Aplicación...............................................................................................................10 1.2.3 Nivel de Presentación...........................................................................................................10 1.2.4 Arquitectura multinivel: ventajas .........................................................................................10 1.2.5 Consecuencias para la programación de aplicaciones ........................................................11

1.3 VISIÓN DESDE EL PUNTO DE VISTA DEL USUARIO.......................................................................12 1.4 USUARIOS..................................................................................................................................12 1.5 MENÚ Y TRANSACCIONES ..........................................................................................................13 1.6 TECLAS DE FUNCIÓN COMUNES..................................................................................................14 1.7 HERRAMIENTAS DE DESARROLLO ..............................................................................................15 1.8 ORGANIZACIÓN DEL DESARROLLO.............................................................................................16

1.8.1 Crear clases de desarrollo ...................................................................................................16 1.8.2 Asignar tareas ......................................................................................................................17

2 EL DICCIONARIO DE DATOS....................................................................................................18 2.1 TABLAS .....................................................................................................................................19

2.1.1 Pestaña "Campos"................................................................................................................20 2.1.2 Pestaña "Entrega y actualización":......................................................................................21 2.1.3 Pestaña "Campos de moneda/cantidad": .............................................................................22 2.1.4 Pestaña "Ayuda p./Verif.entr.": ............................................................................................22 2.1.5 Opciones técnicas.................................................................................................................25 2.1.6 Índices ..................................................................................................................................28 2.1.7 Append estructures ...............................................................................................................30

2.2 DOMINIOS..................................................................................................................................30 2.2.1 Definición .............................................................................................................................31 2.2.2 Ámbito de valores .................................................................................................................32

2.3 ELEMENTOS DE DATOS ..............................................................................................................33 2.4 ESTRUCTURAS ...........................................................................................................................35 2.5 VISTAS.......................................................................................................................................35

2.5.1 Vistas de Base de Datos........................................................................................................36 2.5.2 Vistas de Proyección ............................................................................................................38 2.5.3 Vistas de actualización .........................................................................................................39 2.5.4 Vistas de ayuda.....................................................................................................................41 2.5.5 Unión, Proyección y Selección .............................................................................................41 2.5.6 Relación entre Clave Externa y Condición Join...................................................................43

2.6 AYUDAS PARA BÚSQUEDA.........................................................................................................45 2.6.1 Ayuda para búsqueda elemental: .........................................................................................46 2.6.2 Definición de ayudas de búsqueda .......................................................................................47 2.6.3 Ayuda para búsqueda compuesta .........................................................................................51 2.6.4 Enlace de una Ayuda de Búsqueda con un campo de pantalla ............................................51 2.6.5 Jerarquía de la llamada a la Ayuda de Búsqueda................................................................52

2.7 MODIFICACIÓN DE OBJETOS.......................................................................................................53 2.8 TRATAMIENTO DE LOS DATOS....................................................................................................54

2.8.1 Data browser ........................................................................................................................54 2.8.2 Actualización de tablas.........................................................................................................55 2.8.3 Transacciones: SM30, SM31. ...............................................................................................55

3 CREACIÓN DE PROGRAMAS....................................................................................................56 3.1 EDITOR Y OBJECT NAVIGATOR..................................................................................................56 3.2 ELEMENTOS DE UN PROGRAMA..................................................................................................57 3.3 ESCRIBIR CÓDIGO (TEXTO FUENTE)............................................................................................58

Página 2 de 195


3.3.1 Elementos sintácticos básicos...............................................................................................58 3.3.2 Funciones de edición ............................................................................................................59 3.3.3 Patrones de instrucciones.....................................................................................................60

3.4 INTERACCIÓN CON EL USUARIO .................................................................................................61 3.4.1 Pantalla de selección............................................................................................................61 3.4.2 Lista ......................................................................................................................................61 3.4.3 Mensajes ...............................................................................................................................61

3.5 INTERACCIÓN CON LA BASE DE DATOS.......................................................................................62 3.6 OPERACIONES CON PROGRAMAS................................................................................................62

3.6.1 Verificación de sintaxis ........................................................................................................62 3.6.2 Activación.............................................................................................................................63 3.6.3 Ejecución ..............................................................................................................................63

3.7 DEBUGGING...............................................................................................................................63 3.7.1 Pantalla ................................................................................................................................64 3.7.2 Funciones importantes .........................................................................................................64 3.7.3 Breakpoints...........................................................................................................................65

4 TIPOS DE DATOS Y OBJETOS DE DATOS..............................................................................66 4.1 TIPOS DE DATOS.........................................................................................................................66

4.1.1 Predefinidos..........................................................................................................................66 4.1.2 Definidos por el usuario .......................................................................................................67 4.1.3 Grupos de tipos.....................................................................................................................68 4.1.4 Visibilidad.............................................................................................................................68

4.2 OBJETOS DE DATOS....................................................................................................................69 4.2.1 Variables ..............................................................................................................................69 4.2.2 Constantes y literales............................................................................................................70 4.2.3 Parámetros y selecciones .....................................................................................................71 4.2.4 Tablas ...................................................................................................................................71 4.2.5 Rangos ..................................................................................................................................71 4.2.6 Atributos de objetos ..............................................................................................................71

4.3 FIELD SYMBOLS .........................................................................................................................72 5 PROCESAMIENTO DE DATOS ..................................................................................................73

5.1 ASIGNACIÓN Y CONVERSIÓN......................................................................................................73 5.1.1 Sub-campos...........................................................................................................................73 5.1.2 Inicialización ........................................................................................................................74

5.2 OPERACIONES NUMÉRICAS........................................................................................................74 5.2.1 Aritméticas............................................................................................................................74

5.3 CADENAS DE CARACTERES ........................................................................................................74 5.3.1 Concatenate..........................................................................................................................74 5.3.2 Split.......................................................................................................................................74 5.3.3 Shift.......................................................................................................................................75 5.3.4 Replace .................................................................................................................................75 5.3.5 Condense ..............................................................................................................................75 5.3.6 Translate...............................................................................................................................75 5.3.7 Overlay .................................................................................................................................75 5.3.8 Search...................................................................................................................................75

6 CONTROL DEL FLUJO DEL PROGRAMA..............................................................................76 6.1 EXPRESIONES LÓGICAS ..............................................................................................................76

6.1.1 Comparaciones.....................................................................................................................76 6.1.2 Comparación de Strings .......................................................................................................76

6.2 DISTINCIÓN DE CASOS................................................................................................................76 6.2.1 If ...........................................................................................................................................76 6.2.2 Case ......................................................................................................................................77

6.3 BUCLES......................................................................................................................................77 6.3.1 Do .........................................................................................................................................77 6.3.2 While.....................................................................................................................................77

6.4 FINALIZAR BUCLES ....................................................................................................................77 6.4.1 Continue ...............................................................................................................................77

Página 3 de 195


6.4.2 Check ....................................................................................................................................77 6.4.3 Exit........................................................................................................................................78

7 PANTALLA DE SELECCIÓN ......................................................................................................79 7.1 PARAMETERS.............................................................................................................................79

7.1.1 Activación de parámetro obligatorio....................................................................................80 7.1.2 Asignación de valores por defecto........................................................................................80 7.1.3 Supresión de la visualización ...............................................................................................80 7.1.4 Permitir mayúsculas y minúsculas como entrada ................................................................80 7.1.5 Parámetro con apariencia de checkbox ...............................................................................80 7.1.6 Parámetro con apariencia de radiobutton ...........................................................................81 7.1.7 Asignación de ayudas de búsqueda ......................................................................................81

7.2 SELECT-OPTIONS........................................................................................................................81 7.2.1 Asignación de valores por defecto........................................................................................82 7.2.2 Supresión de la visualización ...............................................................................................83 7.2.3 Permitir mayúsculas y minúsculas como entrada ................................................................83 7.2.4 Asignación de ayudas de búsqueda ......................................................................................83 7.2.5 No permitir múltiples valores ...............................................................................................83 7.2.6 No permitir intervalos ..........................................................................................................83

7.3 ASIGNACIÓN DE DESCRIPCIONES A LOS CAMPOS DE LA PANTALLA DE SELECCIÓN .....................83 7.4 DISEÑO DE LA PANTALLA DE SELECCIÓN ...................................................................................84 7.5 EVENTOS ...................................................................................................................................84 7.6 PANTALLAS DE SELECCIÓN DEFINIDAS POR EL USUARIO ............................................................84 7.7 MENSAJES..................................................................................................................................85

7.7.1 Uso de mensajes ...................................................................................................................85 7.7.2 Gestión de mensajes .............................................................................................................86

8 ACCESO A LA BASE DE DATOS................................................................................................87 8.1 OPEN SQL VS SQL NATIVO .......................................................................................................87 8.2 LECTURA DE DATOS: SELECT ..................................................................................................87

8.2.1 Una o varias líneas...............................................................................................................88 8.2.2 Más de una tabla ..................................................................................................................89 8.2.3 Funciones de agregado ........................................................................................................90 8.2.4 Selección (WHERE)..............................................................................................................90 8.2.5 Selecciones dinámicas ..........................................................................................................91 8.2.6 Cláusula For All Entries.......................................................................................................91 8.2.7 Cláusula Order by ................................................................................................................91 8.2.8 Cláusula Group by................................................................................................................92 8.2.9 Cláusula Bypassing buffer....................................................................................................92

8.3 MODIFICACIÓN DE DATOS: INSERT/UPDATE/MODIFY/DELETE ........................................92 8.4 CONFIRMAR/DESHACER MODIFICACIONES: COMMIT/ROLLBACK ........................................92 8.5 RENDIMIENTO............................................................................................................................92

9 BASES DE DATOS LÓGICAS......................................................................................................93 9.1 PARTES DE UNA BDL.................................................................................................................94 9.2 UTILIZACIÓN CLÁSICA ...............................................................................................................94 9.3 FUNCIÓN LDB_PROCESS........................................................................................................95

9.3.1 Comportamiento en tiempo de ejecución..............................................................................95 9.3.2 Parámetros de LDB_PROCESS ...........................................................................................95 9.3.3 Profundidad de la Lectura y Rutinas de Vuelta....................................................................96 9.3.4 Excepciones de LDB_PROCESS ..........................................................................................97 9.3.5 Ejemplo.................................................................................................................................97

10 TABLAS INTERNAS ...............................................................................................................102 10.1 ATRIBUTOS DE LAS TABLAS .....................................................................................................102 10.2 OPERACIONES Y ÁREAS DE TRABAJO .......................................................................................103 10.3 DECLARACIÓN: TIPOS Y OBJETOS............................................................................................103 10.4 AÑADIR REGISTROS .................................................................................................................104

10.4.1 Append ...........................................................................................................................104 10.4.2 Collect ............................................................................................................................104

Página 4 de 195


10.5 LEER REGISTROS......................................................................................................................104 10.5.1 Loop ...............................................................................................................................104 10.5.2 Read ...............................................................................................................................105

10.6 MODIFICACIONES ....................................................................................................................105 10.6.1 Modify ............................................................................................................................105 10.6.2 Insert ..............................................................................................................................106 10.6.3 Delete .............................................................................................................................106

10.7 INICIALIZAR TABLAS................................................................................................................106 10.7.1 Refresh ...........................................................................................................................106 10.7.2 Clear...............................................................................................................................106 10.7.3 Free ................................................................................................................................106

10.8 DESCRIBIR Y ORDENAR............................................................................................................106 10.8.1 Atributos.........................................................................................................................106 10.8.2 Sort .................................................................................................................................107

11 CREAR LISTAS .......................................................................................................................108 11.1 LISTA ESTÁNDAR .....................................................................................................................108

11.1.1 Cabeceras y símbolos de texto .......................................................................................108 11.1.2 WRITE............................................................................................................................109 11.1.3 Iconos y símbolos ...........................................................................................................110 11.1.4 Check-boxes y campos de entrada .................................................................................110 11.1.5 SKIP ...............................................................................................................................110 11.1.6 ULINE ............................................................................................................................110

11.2 DISEÑO DE LA PÁGINA .............................................................................................................110 11.2.1 Dimensiones ...................................................................................................................111 11.2.2 Cabeceras no estándar...................................................................................................111 11.2.3 Columnas fijas................................................................................................................112 11.2.4 Salto de página...............................................................................................................112 11.2.5 Pie de página..................................................................................................................112 11.2.6 Sentencias adicionales ...................................................................................................112

11.3 SENTENCIA FORMAT.............................................................................................................112 11.4 DIBUJAR LÍNEAS ......................................................................................................................113 11.5 NIVELES DE CONTROL..............................................................................................................113

11.5.1 Tablas internas...............................................................................................................114 11.5.2 Extract datasets..............................................................................................................115

11.6 IMPRESIÓN...............................................................................................................................116 12 LISTAS INTERACTIVAS .......................................................................................................118

12.1 INTERFASE (GUI) ....................................................................................................................118 12.1.1 Status..............................................................................................................................119 12.1.2 Funciones .......................................................................................................................119 12.1.3 Barra de menús ..............................................................................................................120 12.1.4 Usar status .....................................................................................................................121 12.1.5 Título ..............................................................................................................................121

12.2 EVENTOS .................................................................................................................................121 12.2.1 AT USER-COMMAND...................................................................................................121 12.2.2 AT LINE-SELECTION ...................................................................................................122 12.2.3 Top-of-page During line-selection .................................................................................122

12.3 VARIABLES DEL SISTEMA.........................................................................................................122 12.4 RECUPERAR DATOS DE LA LISTA..............................................................................................123

12.4.1 HIDE ..............................................................................................................................123 12.4.2 GET CURSOR................................................................................................................124

12.5 LEER LISTAS ............................................................................................................................124 12.6 MODIFICAR LISTAS ..................................................................................................................125 12.7 NAVEGACIÓN...........................................................................................................................125 12.8 VENTANAS...............................................................................................................................125

13 MODULARIZACIÓN ..............................................................................................................127 13.1 DECLARACIÓN DE DATOS GLOBALES .......................................................................................128 13.2 EVENTOS .................................................................................................................................128

Página 5 de 195


13.2.1 INITIALIZATION ...........................................................................................................129 13.2.2 START-OF-SELECTION................................................................................................130 13.2.3 END-OF-SELECTION. ..................................................................................................130 13.2.4 TOP-OF-PAGE..............................................................................................................130 13.2.5 END-OF-PAGE..............................................................................................................130 13.2.6 AT SELECTION-SCREEN .............................................................................................130

13.3 MÓDULOS DE CÓDIGO FUENTE.................................................................................................131 13.3.1 Macros ...........................................................................................................................132 13.3.2 Programas Include.........................................................................................................133

13.4 PROCEDIMIENTOS ....................................................................................................................134 13.4.1 Subrutinas ......................................................................................................................135 13.4.2 Funciones .......................................................................................................................146

13.5 LLAMADAS A OTROS PROGRAMAS ...........................................................................................159 13.5.1 SUBMIT .........................................................................................................................159 13.5.2 CALL TRANSACTION ...................................................................................................160

13.6 PARÁMETROS DE MEMORIA .....................................................................................................160 13.6.1 SAP.................................................................................................................................160 13.6.2 ABAP..............................................................................................................................164

14 ALV ............................................................................................................................................166 14.1 FUNCIONALIDAD......................................................................................................................166 14.2 TRABAJAR CON ALV...............................................................................................................166 14.3 FUNCIÓN REUSE_ALV_LIST_DISPLAY .............................................................................167

14.3.1 Especificar disposición ..................................................................................................169 14.3.2 Parámetros de retorno ...................................................................................................170 14.3.3 Ejemplo simple ...............................................................................................................171

14.4 FUNCIÓN REUSE_ALV_FIELDCATALOG_MERGE ..........................................................171 14.5 OTRAS FUNCIONES...................................................................................................................175

15 TRATAMIENTO DE FICHEROS..........................................................................................178 15.1 DEL SERVIDOR DE APLICACIÓN................................................................................................178

15.1.1 Abrir ...............................................................................................................................178 15.1.2 Leer ................................................................................................................................179 15.1.3 Escribir...........................................................................................................................179 15.1.4 Cerrar.............................................................................................................................179 15.1.5 Autorizaciones................................................................................................................179

15.2 DEL SERVIDOR DE PRESENTACIÓN ...........................................................................................181 15.2.1 Escritura.........................................................................................................................182 15.2.2 Lectura ...........................................................................................................................187 15.2.3 Verificación de ficheros del Servidor de Presentación ..................................................192

Página 6 de 195


1 Introducción al sistema SAP R/3 SAP R/3 es una aplicación creada para poder gestionar todas las áreas de una empresa. A cada área le corresponde un módulo de la aplicación: el módulo SD a las ventas, PP a la planificación de la producción, FI a las finanzas, HR a los recursos humanos, etc. Los módulos son suficientemente independientes como para poder ser instalados por separado, pero al mismo tiempo existe comunicación de datos entre ellos, por lo que están perfectamente integrados.

Una gran ventaja del sistema R/3 es que muchos aspectos son parametrizables, y que incorpora un lenguaje de programación propio, el ABAP, que permite desarrollar extensiones de las aplicaciones existentes e incluso aplicaciones nuevas.

El ABAP (Advanced Business Aplications Programming) es un lenguaje de programación de cuarta generación (4GL) orientado, tal como su nombre especifica, al desarrollo de aplicaciones de negocios. Todas las aplicaciones de los módulos disponibles en SAP y también partes del sistema básico han sido programadas usando este lenguaje.

Una vez instalado el sistema SAP R/3, una de los usos más frecuentes del ABAP/4 es la generación de informes, ya sea porque no han sido contemplados por SAP o porque en la instalación se requiera un formato muy concreto. Por esto ABAP dispone de muchas instrucciones destinadas a facilitar la tarea de programar listados, que a menudo se llaman “reports”. Podemos diferenciar claramente entre reports planos y reports interactivos. Los primeros están orientados a visualizar información de una manera plana en un único nivel. En este tipo de listados las opciones de usuario sobre el tratamiento de la información son nulas. Los listados interactivos, en cambio, están orientados a presentar información en varios niveles de diferente detalle: por eso se presentan muchas opciones de usuario para la navegación.

Otras necesidades que puede cubrir la programación con ABAP son: la creación de interfases con otros sistemas a través de ficheros o la adaptación de programas estándar por medio de USEREXITS.

1.1 Visión lógica del sistema El diagrama siguiente muestra cómo el Sistema Base de R/3 forma parte de una plataforma central dentro del Sistema R/3. A continuación listaremos las tareas de los tres componentes lógicos del Sistema Base de R/3.

Página 7 de 195


Página 8 de 195

1.1.1 Kernel y servicios básicos Los componentes de Kernel y Servicios Básicos constituyen el entorno en tiempo de ejecución para todas las aplicaciones R/3 que son específicas del hardware, sistema operativo y base de datos. Están escritas generalmente en C y C++, aunque algunas partes a bajo nivel están escritas en el propio lenguaje de programación de SAP.

Las tareas de los componentes de Kernel y Servicios Básicos son las siguientes:

• Ejecución de aplicaciones.

Todas las aplicaciones de R/3 se ejecutan sobre procesadores software (máquinas virtuales). Esto las hace independientes del hardware y del sistema operativo, pero también implica que no se pueden ejecutar fuera del sistema.

• Administración de usuarios y procesos.

Todo sistema R/3 representa un entorno multiusuario, y cada usuario puede ejecutar varias aplicaciones independientes. En resumen, este componente es responsable de las tareas que normalmente lleva a cabo el sistema operativo. Los usuarios entran en el sistema R/3 y ejecutan aplicaciones sin entrar nunca en contacto con el sistema operativo del host sobre el que se está ejecutando. El Sistema R/3 es el único usuario del sistema operativo del host.

• Acceso a la base de datos.

Todo sistema R/3 está enlazado con el sistema de la base de datos, que consiste de un sistema de gestión de la base de datos (DBMS) y de la base de datos en sí misma. Las aplicaciones no se comunican directamente con la base de datos, sino que utilizan la interfase de los Servicios Básicos: el ABAP contiene un conjunto de instrucciones llamado OPEN SQL que permite acceder a la base de datos independientemente de su tipo.


• Comunicación.

Las aplicaciones R/3 se pueden comunicar con otros sistemas R/3 y con sistemas que no sean R/3. También es posible acceder a las aplicaciones de R/3 desde sistemas externos utilizando la interfase BAPI.

• Control y Administración del Sistema.

El componente contiene los programas que nos permiten controlar el Sistema R/3 mientras se está ejecutando, y cambiar sus parámetros de ejecución.

1.1.2 ABAP Workbench El componente ABAP Workbench es un entorno de desarrollo completamente integrado que sirve para crear, mejorar, probar y organizar las aplicaciones en el lenguaje de programación ABAP. Al igual que otras aplicaciones R/3, está escrito en ABAP.

1.1.3 Nivel de presentación Los componentes del nivel de presentación son responsables de la interacción entre el Sistema R/3 y el usuario, y de la integración con componentes del escritorio (tales como procesamiento de texto y hojas de cálculo).

1.2 Visión desde el punto de vista del software La siguiente ilustración representa el punto de vista desde el software de R/3. Aquí se describen los diferentes componentes software que tiene el sistema R/3.

El Sistema Base de R/3 es un sistema multinivel cliente/servidor. Los componentes individuales de software están situados en niveles y funcionan, dependiendo de su posición, como un cliente para los componentes situados por debajo de él o como un servidor para los componentes situados por encima de él. La configuración clásica de un sistema R/3 contiene los siguientes niveles de software:

Página 9 de 195


1.2.1 Nivel de Base de Datos El nivel más bajo de la arquitectura es el de la base de datos. Aquí se gestionan todos los datos del sistema R/3 con la ayuda de un sistema de gestión de bases de datos relacionales (RDBMS). SAP no fabrica su propio gestor, en lugar de ello, el sistema R/3 soporta los siguientes sistemas de bases de datos: ADABAS D, DB2/400 (sobre AS/400), DB2/Servidor Común, DB2/MVS, INFORMIX, Servidor Microsoft SQL, ORACLE, y Servidor paralelo ORACLE.

La base de datos no contiene sólo los datos maestros y las transacciones de datos de nuestras aplicaciones, sino también el código de los programas y las definiciones y parametrizaciones que describen al propio sistema.

Las aplicaciones se componen de código de programa, definiciones de pantallas, de tablas, menús y otros componentes. Todos estos objetos de desarrollo, que se crean y mantienen con las herramientas del ABAP Workbench, están almacenados en una sección especial de la base de datos llamada Repository R/3, y por ello, se clasifican como objetos del Repository. El Repository está organizado según la aplicación y cada aplicación consta de subdivisiones lógicas llamadas clases de desarrollo. A cada objeto se le debe asignar una clase de desarrollo cuando se crea. Disponemos de un sistema de información para buscar objetos del Repository según ciertos criterios ().

1.2.2 Nivel de Aplicación El nivel de aplicación está formado por uno o más servidores de aplicaciones y un servidor de mensajes (que gestiona la comunicación y balancea la carga entre ellos). Cada servidor de aplicaciones proporciona un conjunto de servicios que se utilizan en el Sistema R/3. En la práctica, los servicios se distribuyen por más de un servidor de aplicaciones. Esto significa que no todos los servidores de aplicaciones pueden ofrecer la totalidad de los servicios.

Los programas ABAP, tanto los de aplicaciones proporcionadas por SAP como los que desarrollemos nosotros, se ejecutan en los servidores de aplicaciones. Los programas trabajan con datos que recuperan de la base de datos y en ocasiones almacenan también resultados en la base de datos.

1.2.3 Nivel de Presentación El nivel de presentación contiene los componentes de software que conforman el SAPgui, la interfase gráfica entre el Sistema R/3 y los usuarios. Permite que éstos accedan a las aplicaciones, introduzcan nuevos datos y reciban los resultados de los procesos. El nivel de presentación envía las entradas del usuario al servidor de aplicaciones, y recibe los datos para mostrarlos desde él. Mientras se está ejecutando el SAPgui, permanece enlazado a la sesión del terminal del usuario.

1.2.4 Arquitectura multinivel: ventajas Existe una gran variedad de posibilidades de configuración hardware para ambos niveles y componentes. Cuando se distribuyen los niveles en vertical, por ejemplo, podemos tener todos los niveles en una única máquina, o en el extremo opuesto, podemos tener al menos una máquina para cada nivel. En horizontal, los componentes de los niveles de aplicación y presentación pueden distribuirse por cualquier número de máquinas.

La distribución del software de R/3 en tres niveles hace que la carga del sistema esté también distribuida. Esto conlleva una mejora en el rendimiento del sistema.

Ya que el sistema de la base de datos contiene todos los datos del sistema R/3, la está sujeto a una gran carga cuando el sistema se está ejecutando. Por ello es una

Página 10 de 195


buena idea no ejecutar programas de aplicaciones en la misma máquina. La arquitectura del Sistema R/3, en el cual están separados el nivel de aplicación y el de base de datos, nos permite instalarlos en máquinas separadas y comunicarlos utilizando la red.

También cobra sentido separar la ejecución de programas de las tareas de procesamiento (nivel de aplicación) de las entradas de usuario y de las de edición de salida de datos (nivel de presentación). SAPgui y los servidores de aplicación están diseñados de tal manera que se minimiza la cantidad de datos a transportar entre los dos niveles, por lo que SAPGui puede utilizarse en otras máquinas aunque éstas tengan conexiones lentas con los servidores de aplicación.

En sentido horizontal en el nivel de aplicación, podemos adaptar fácilmente nuestro sistema para cubrir la demanda instalando nuevos servidores de aplicación.

1.2.5 Consecuencias para la programación de aplicaciones Cuando ejecutamos un programa de aplicación que requiere interacción con el usuario, el control del programa se pasa continuamente desde y hacia los dos niveles. Cuando una pantalla está preparada para recibir datos del usuario, el nivel de presentación estará activo, y el servidor de aplicaciones estará inactivo con respecto a este programa en particular, pero libre para realizar otras tareas. Una vez que el usuario ha introducido los datos en la pantalla, el control del programa vuelve al nivel de aplicación y el nivel de presentación es visible pero no acepta entradas hasta que el programa de aplicación haya llamado a una nueva pantalla y la envíe al servidor de presentación.

La lógica de programación de la aplicación que tiene lugar entre dos pantallas se conoce como etapa de diálogo. El ABAP ha sido concebido de manera que los desarrolladores no se tienen que preocupar de la comunicación o de los problemas de distribución entre los diferentes niveles.

Página 11 de 195


Página 12 de 195

1.3 Visión desde el punto de vista del usuario La siguiente ilustración representa el punto de vista del usuario sobre el Sistema R/3:

Para el usuario los componentes visibles del Sistema R/3 son aquellos que aparecen como una ventana sobre su pantalla. Las ventanas son generadas por el nivel de presentación, y forman parte del Sistema Base de R/3.

Antes de que el usuario entre en el sistema R/3, debe ejecutar una utilidad llamada SAP Logon, que se instala en el front end. En el Logon de SAP, el usuario elige uno de los sistemas de R/3 disponibles. Entonces, el programa se conecta con el servidor de mensajes del sistema y obtiene la dirección del servidor de aplicaciones más conveniente (el que se utilice menos). Este lanzará el SAPGui conectado al servidor de aplicaciones.

SAPGui mostrará la pantalla de entrada al sistema. Una vez que el usuario ha entrado en él, se le mostrará la pantalla inicial del sistema R/3. Después de entrar en el sistema, el usuario puede abrir hasta seis ventanas dentro de la misma sesión SAPGui. Las diferentes ventanas nos permiten ejecutar diferentes aplicaciones en paralelo, independientes unas de otras.

Dentro de una ventana, el usuario puede ejecutar aplicaciones que llamen a su vez a nuevas ventanas (tales como cajas de diálogo y ventanas gráficas). Estas ventanas no son independientes – pertenecen a la sesión desde la cual fueron llamadas- . Estas ventanas pueden ser modales (la ventana original no estará preparada para recibir datos) o amodales (todas las ventanas admiten entrada).

El usuario puede abrir otros SAPGui, usando el SAP Logon, para entrar en el mismo sistema o en otro. Los SAPGui individuales y correspondientes a sesiones de un terminal de R/3 son totalmente independientes. Esto significa que podemos tener abiertos en nuestro ordenador varios SAPGui que representen los niveles de presentación de diferentes sistemas R/3.

1.4 Usuarios En SAP cada una de las acciones que se realiza está identificada por el nombre de usuario, guardando siempre históricos de modificaciones, versiones, etc. Por eso es necesario que antes de entrar al sistema el usuario se identifique con su nombre (username) y su clave (password); y también es muy importante que cada cual tenga un nombre de usuario no compartido para evitar problemas.


Página 13 de 195

Además se nos pide el número de mandante (client) y el idioma en que queremos trabajar.

El concepto de mandante permite trabajar en la misma máquina con los mismos programas pero en un espacio de datos diferentes. Es el mismo concepto que trabajar por empresas. Para separar los datos, todas las tablas tienen un campo clave llamado MANDT.

1.5 Menú y transacciones Podemos acceder a una determinada tarea a través del menú, escogiendo un camino, o bien a través de un código de transacción.

Un código de transacción está asociado a un programa. Permite que el usuario arranque el programa introduciendo el código en el campo de comandos. Normalmente el código de transacción está asociado a uno o varios caminos del menú, pero siempre es una vía rápida para acceder a la aplicación deseada.


Página 14 de 195

1.6 Teclas de función comunes Además hay teclas de función que siempre (o casi siempre) están activas, pero que siempre tienen la misma funcionalidad que un botón de la pantalla o una opción de menú. Las teclas de función más importantes y útiles son:

F11 Carpeta Grabar

F3 Flecha verde Paso atrás (Back)

F15 Flecha amarilla Finalizar (Exit)

F12 Aspa roja Cancelar (Cancel)

F8 Ejecutar

F4 Lupa Entradas posibles (sobre un campo): match code que nos permite elegir valores mediante distintos criterios de selección.

F1 Interrogante Ayuda (sobre un campo)

F2 Doble click - Seleccionar.

ESC Cancelar

CTRL+F1 Visualizar/Editar

CTRL+F2 Verificar

CTRL+Y Manteniendo pulsadas estas teclas se pueden copiar bloques.


Página 15 de 195

En todas las pantallas está activo el menú "Sistema", a partir del cual podemos acceder a las siguientes funcionalidades:

Crear modo: En SAP se puede trabajar simultáneamente hasta con seis sesiones (modos) a la vez, en cada una de las cuales se puede estar efectuando una tarea distinta de manera independiente.

Borrar modo: Eliminar la sesión actual.

Valores prefijados: Valores por defecto del usuario actual, que son configurables.

Servicios: Ejecutar Reports, mantener tablas, gestión de la impresión, etc.

Utilidades: Traza SQL, traza ABAP/4.

Lista: Download, imprimir,...

Jobs propios: Visualizar nuestras ejecuciones en fondo o background.

Status: Información sobre datos de usuario y de sistema. Útil para obtener el código de la transacción mediante la cual se llega a esta pantalla, el nombre del programa que se ejecuta mediante esta transacción y el número de pantalla en el que estamos (un mismo programa y una misma transacción pueden gestionar muchas pantallas -’Dynpros’- distintas).

Log off: Cerrar la sesión de SAP.

1.7 Herramientas de desarrollo El ABAP Workbench contiene diversas herramientas que permiten editar objetos específicos del repositorio. Las más importantes son:

El Editor ABAP para escribir y editar código de programas.


El Dictionary ABAP para editar tablas y otros objetos.

El Menu Painter para diseñar la interfase con el usuario (menú, barra de herramientas)

El Screen Painter para diseñar pantallas para diálogos de usuario.

La Biblioteca de funciones para programar módulos de función.

Se pueden usar estas herramientas principalmente de dos maneras:

Llamando sucesivamente al editor correspondiente para modificar cada objeto.

O trabajando con el Repository Browser (SE80) que proporciona una vista en forma de lista jerárquica de todos los objetos que forman un programa o un grupo de funciones o una clase de desarrollo. Haciendo doble-click en un objeto se llama al editor correspondiente.

1.8 Organización del desarrollo Los objetos del repositorio quedan ligados al sistema de correcciones y transportes en el momento que se les asigna una clase de desarrollo.

Cuando desarrollamos, lo hacemos sobre un sistema aparte del productivo para no interferir en su funcionamiento. Cuando un desarrollo ha finalizado, se debe transportar a un sistema de test y, finalmente, al sistema productivo. Para gestionar estos transportes se deben haber definido unos ciertos caminos a través del Workbench Organizer. Esta herramienta permite organizar los proyectos de desarrollo.

Cuando comienza un proyecto, el responsable crea una change request y asigna ciertos desarrolladores a esta petición. El Workbench Organizer asigna un número a esta petición (<SID>K9<nnnnn> donde SID es el número del sistema). Mediante las change request se puede realizar un control de versiones de los objetos, bloquearlos para otros desarrollos y anexar documentación descriptiva del desarrollo.

A partir de ese momento, cuando un desarrollador modifica un objeto y lo asigna a esta change request, el objeto se archiva automáticamente en la tarea correspondiente al usuario. La asignación de un objeto a una change request es temporal, a diferencia de la clasificación en clases de desarrollo (un objeto siempre pertenece a una única clase de desarrollo).

Cuando cambiamos o creamos un original la tarea recibe el nombre de CORRECCION, si por el contrario cambiamos una copia llevara el nombre de REPARACION.

Cuando acaba su trabajo, el desarrollador libera su tarea. En ese momento los objetos y bloqueos se transfieren de la tarea a la change request. Todavía cualquier desarrollador puede hacer modificaciones al objeto y se creará una nueva tarea si es necesario.

Cuando el proyecto ha acabado, el responsable libera la change request y se borran todos los bloqueos de los objetos que contenía. Los objetos se exportan al directorio central de transportes (en el sistema operativo). La importación en el sistema destino no es automática, el administrador de sistemas debe lanzarla y después el desarrollador puede consultar el log del transporte.

1.8.1 Crear clases de desarrollo Es necesaria la siguiente información:

Texto breve: Descripción que aparecerá al lado del nombre técnico de la clase.

Página 16 de 195


Capa de transporte: Determina a qué sistemas se transportarán los objetos de la clase. Los administradores pueden crear diferentes capas de transporte en un mismo sistema.

Componente de aplicación: División lógica de nivel superior de los objetos. Cada clase de desarrollo se debe asignar a un componente de aplicación.

Las clases de desarrollo también se transportan asignándolas a change requests.

1.8.2 Asignar tareas Siempre que creamos o modificamos un objeto el sistema nos solicita que lo asignemos a una change request.

Podemos consultar las change request que tenemos asignadas en el Workbench Organizer.

Página 17 de 195


2 El Diccionario de Datos El sistema R/3 almacena los datos con los que debe trabajar en una base de datos relacional, formada por miles de tablas interrelacionadas. La información sobre la estructura de cada una de las tablas y las características de sus campos se recoge en el Diccionario ABAP.

El Diccionario ABAP describe y gestiona de forma centralizada todas las definiciones de datos utilizadas en el sistema. Está completamente integrado en el Development Workbench de ABAP: el resto de los componentes pueden acceder activamente a las definiciones actualizadas almacenadas en el Diccionario de ABAP. De esta manera se asegura la integridad y consistencia de los datos. Los programas ABAP pueden utilizar referencias del Diccionario para crear objetos de datos internos.

Todos los objetos estándar están definidos en él, y deberemos incluir también todas las definiciones de tipos y las estructuras de los objetos desarrollados a medida. Estos objetos se crearán automáticamente en la base de datos. El Diccionario también proporciona herramientas para editar campos de pantalla, por ejemplo para asignar a un campo una ayuda de entradas posibles (ayuda F4).

Los elementos básicos del diccionario de datos son las tablas, las vistas, los tipos (elementos de datos, estructuras, tipos tabla), los dominios y las ayudas de búsqueda. Existen relaciones entre ellos, por ejemplo: una tabla está compuesta de campos, cada campo se crea haciendo referencia a un elemento de datos (descripción semántica), y cada elemento de datos se crea a partir de un dominio (descripción de atributos técnicos como el tipo y la longitud).

Se accede a la pantalla inicial del diccionario ABAP a través de la opción de menú "Herramientas/Workbench ABAP/Desarrollo/Dictionary ABAP" o llamando a la transacción SE11. Tiene el siguiente aspecto:

Página 18 de 195


Página 19 de 195

2.1 Tablas Una tabla representa un conjunto de atributos de una entidad. Una tabla del Diccionario ABAP es la descripción lógica de la estructura de una tabla en el sistema R/3. Hay que recordar que el sistema trabaja contra una base de datos relacional y que, por tanto, habrá otra descripción paralela en el nivel de la BBDD que denominaremos descripción física. La definición del Diccionario es independiente de la base de datos utilizada.

Cuando se crea una nueva tabla y se activa, se crea una definición física de la misma (en el lenguaje propio del RDBMS) a partir de la definición almacenada en el Diccionario ABAP. La tabla de la base de datos tiene el mismo nombre que la del Diccionario, y también los mismos nombres de campos (aunque la secuencia puede ser diferente, para facilitar la inserción de nuevos campos). Los tipos de datos son convertidos.

Las operaciones que haya que realizar sobre la base de datos se deben realizar a través del Diccionario, modificando y activando los objetos necesarios.


Página 20 de 195

La definición de una tabla en el Diccionario ABAP contiene los siguientes componentes:

Los campos de tabla definen los nombres de los atributos contenidos en la tabla y los tipos de datos correspondientes.

Las claves externas definen las relaciones entre la tabla y otras tablas.

Las características técnicas controlan la forma en la que se crea la tabla en la base de datos.

Los índices sirven para acelerar la selección de los datos.

Para crear, modificar o visualizar tablas, en el menú diccionario introducimos el nombre de la tabla que queremos tratar y seleccionamos la opción “Tablas”.

Visualizaremos la tabla SPFLI.

Descripción breve: Descripción significativa de la tabla.

En este caso "Itinerario de vuelos".

2.1.1 Pestaña "Campos" Para cada campo de una tabla del Diccionario se definen las siguientes características:

Nombre campo: Nombre del campo. Debe tener un máximo de 16 caracteres y puede contener letras, dígitos y subrayados. Debe comenzar con una letra.

Clave: Indica si el campo forma parte de la clave primaria de la tabla. Un campo o conjunto de campos son clave en una tabla si determinan de forma unívoca un único registro de dicha tabla. Toda tabla tiene que tener clave primaria.

Tipo de datos: Nombre del elemento de datos que describe al campo.

Tipo y longitud: Tipo de dato y longitud. (*)

Posiciones decimales: número de posiciones decimales después del punto decimal, específico para tipos de datos numéricos.


Página 21 de 195

Descripción breve: Descripción del significado del campo. (*)

(*) En general, las características (tipo, longitud, descripción) de un campo se asignan mediante un elemento de datos. Pero podemos crear campos en la tabla sin vincularlos a un elemento de datos, asignándoles directamente un tipo, longitud y descripción. Es necesario pulsar el botón "Tipo instalado" para habilitar para entrada estos campos. Aunque existe esta posibilidad, no es muy recomendable pues no permite la reutilización.

Ayuda de búsqueda: se puede asignar una ayuda de búsqueda para un campo. Esta ayuda de búsqueda define el flujo de ayuda que se utilizará para la entrada de datos en todas las pantallas en las que se utilice el campo.

2.1.2 Pestaña "Entrega y actualización": Clase de entrega: Indica quién es el responsable del mantenimiento de la tabla, si es una tabla de parametrización,…

Esta tabla en concreto es de tipo A, lo que significa que contiene datos de aplicación.

Permitida Actualización tabla: Habilita/ Deshabilita la posibilidad de que el contenido de la tabla pueda ser modificado en la transacción de visualización del contenido de la


tabla. (Si no se marca no se podrán modificar los registros de la tabla por esta transacción).

2.1.3 Pestaña "Campos de moneda/cantidad": TabRef y Cpo Ref.: Para los tipos de datos importe (CURR) y cantidad (QUAN), es necesario (y obligatorio) especificar el campo de la tabla donde se encuentra la correspondiente moneda o unidad de medida. Estos campos de referencia deberán de ser del tipo Moneda (CUKY) para los importes y Unidad (UNIT) para las cantidades De esta forma, cuando se visualicen datos (en pantallas, pantallas de selección…) serán formateados con el valor que contenga el campo al que han sido referenciados.

Nota: El campo MANDT, mandante, se añade como un atributo en las tablas de esta forma, se pueden tener varias colecciones de datos distintas según el mandante. En las selecciones, actualizaciones… de la tabla este campo es transparente ya que tendrá siempre el valor indicado al iniciar la sesión en el sistema. (No es obligatorio definir el mandante en todas las tablas aunque si es lo más habitual).

2.1.4 Pestaña "Ayuda p./Verif.entr.": Podemos definir las relaciones existentes entre las tablas del Diccionario ABAP mediante claves externas. Una clave externa enlaza dos tablas T1 y T2 asignando campos de la tabla T1 a los campos clave de la tabla T2.

La tabla T1, donde tenemos los campos que deseamos verificar, se llama tabla de clave externa (tabla dependiente) y la tabla T2, donde se encuentran los registros que definen los valores posibles, se llama tabla de verificación (tabla referenciada). Los campos a relacionar de las dos tablas deben compartir el mismo tipo de datos y longitud: cada campo clave de la tabla de verificación se corresponderá con un campo de la tabla de clave externa (campos de clave externa).

Mediante la utilización de claves externas podemos verificar fácilmente los valores introducidos en un campo. Las claves externas se pueden utilizar también para enlazar varias tablas en una vista o en un objeto de bloqueo.

Página 22 de 195


Cuando se realiza una entrada en los campos de clave externa, se comprueba que la tabla de verificación contenga un registro con la clave definida por los valores de los estos campos. Si existe, la entrada es válida. En cualquier otro caso, el sistema rechaza la entrada.

La verificación funciona internamente de la siguiente manera. Se genera una sentencia SELECT a partir de la definición de la clave externa. Al realizar una entrada en los campos de verificación se invoca esta sentencia SELECT. Si se encuentra un registro conveniente en la tabla de verificación, la entrada se considera válida. En otro caso, se rechazará la entrada.

La sentencia SELECT correspondiente tiene la siguiente forma para la tabla de clave externa mostrada en el gráfico superior:

SELECT * FROM T2 WHERE T2-CAMPO5 = T1-CAMPO2 AND T2-CAMPO6 = T1-CAMPO4.

Una entrada en una pantalla para el campo de verificación Campo2 sólo será válida si la tabla de verificación contiene un registro con las entradas realizadas en la pantalla para los campos Campo2 y Campo4 como clave.

En este ejemplo, se rechazaría una entrada con Campo2 = 2 y Campo4 = 2, ya que T2 no contiene un registro con la clave Campo5 = 2 Y Campo6 = 2.

Si no queremos realizar la verificación para todos los campos clave de la tabla de verificación, podemos excluir los campos de la tabla de clave externa de la asignación de campos de la tabla de verificación con claves externas genéricas y constantes.

Otro ejemplo:

La tabla SBOOK contiene la reserva de vuelos de un cliente para una compañía aérea. Las reservas de vuelo pueden realizarse en una agencia de viajes o directamente en la compañía aérea. Si la reserva se realiza directamente en una oficina de ventas de la compañía, el número de la oficina se almacena junto con la reserva en el campo COUNTER de la tabla SBOOK.

Página 23 de 195


Página 24 de 195

Deberíamos asegurar que sólo se introducen números de oficina válidos. Todas las oficinas de ventas existentes se encuentran en la tabla SCOUNTER. Se puede definir la verificación de valores necesaria creando una clave externa para el campo de verificación COUNTNUM.

Tab.verif.: En este punto aparecerá un ‘*’ cuando el elemento de datos introducido, haga referencia a un dominio que tenga una tabla de valores permitidos.


Página 25 de 195

2.1.5 Opciones técnicas Las opciones técnicas de una tabla definen la forma en la que se tratará la tabla cuando se cree en la base de datos, es decir, si la tabla tendrá memoria intermedia y si los cambios realizados en los registros de datos de la tabla serán guardados en logs.

Para definir estas características seleccionaremos la opción de menú ‘Pasar a

Opciones técnicas’ o el botón . Los parámetros más importantes son:

2.1.5.1 Clase Datos Define de forma lógica el área física de la base de datos en la que se ubica la tabla. Este lugar físico donde se determina en función del tipo de utilización de la tabla, de la cantidad de actualizaciones y de consultas que se realicen sobre ella.

Existen las siguientes clases de datos: • APPL0 (datos maestros). Son los datos que se leen muy a menudo, pero muy

raramente para su actualización. Un ejemplo de datos maestros son los datos que se encuentran en un fichero de direcciones, tale como el nombre, la dirección y el número de teléfono.

• APPL1 (datos de transacciones). Son los datos que se actualizan constantemente. Un ejemplo de este tipo de datos serian las mercancías que hay en un almacén, que cambian cada vez que realiza una orden de compra.


Página 26 de 195

• APPL2 (datos de gestión y parametrización): Son los datos que se definen cuando se instala el sistema y que no se suelen modificar posteriormente. Un ejemplo sería la tabla con los códigos de los países.

Existen dos clases de datos adicionales, USR y USR1, que se ofrecen para el cliente. Se utilizan para desarrollos del usuario. Las tablas que se asignen a esta clase de datos se almacenen en un área especial para desarrollos de usuario.

La clase de datos sólo influye en la grabación de la tabla en los sistemas ORACLE e INFORMIX.

2.1.5.2 Categoría tamaño Define el espacio demandado para guardar los datos de la tabla, el número aproximado de registros que se espera que albergue. Podemos elegir una categoría de tamaño de 0 a 4. Cada categoría tiene asignada un tamaño de memoria fijo en la base de datos, que depende del sistema de base de datos utilizado.

Cuando se crea una tabla, se reserva un espacio inicial (extensión inicial) en la base de datos. Si, posteriormente, se requiere más espacio, se añadirá la memoria adicional adecuada dependiendo de la categoría de tamaño seleccionada.

La selección de la correcta categoría de tamaño evita que se tengan que ir realizando varias extensiones pequeñas cuando se va aumentando el tamaño de la tabla. También evitará que se derroche espacio si se crea un tamaño inicial demasiado grande.


Página 27 de 195

2.1.5.3 Grabación en memoria intermedia Define si la tabla utilizará la memoria intermedia o no. La utilización de la memoria intermedia ahorra tiempo en el acceso a los registros contenidos en una tabla. La memoria intermedia de una tabla reside localmente en cada servidor de aplicaciones del sistema, de manera que se puede acceder directamente a ella para leer los datos de las tablas que tienen esta característica activada.

Existen tres posibilidades:

Imposible grabar en memoria intermedia. No se permite grabar en la memoria intermedia, por ejemplo porque los programas de aplicación necesitan los datos actualizados de la tabla o porque la tabla cambia muy frecuentemente.

Permitido grabar en memoria intermedia, desactivado. Se permite la grabación en memoria intermedia desde el punto de vista técnico. Las aplicaciones que acceden a la tabla funcionan correctamente con y sin utilización de la memoria intermedia. Si se va a obtener provecho o no de la memoria intermedia depende del tamaño de la tabla y del perfil de acceso a la tabla (frecuencia de los diferentes tipos de acceso a la tabla). La utilización de la memoria intermedia está desactivada porque no es posible conocer cuáles de éstos valores estarán en el sistema del cliente. Si la utilización de la memoria intermedia para la tabla va a resultar ventajosa por el tamaño de la tabla y el perfil de acceso a la tabla, podemos activarlo en cualquier momento.

Grabación en memoria intermedia activada: la tabla utilizará memoria intermedia. En este caso debemos especificar un tipo de grabación en memoria intermedia.

Si un programa de una aplicación accede a los datos de una tabla con memoria intermedia, la interfase de la base de datos determina si estos datos se encuentran en la memoria intermedia del servidor de aplicaciones. Si es así, se leerán los datos directamente de la memoria intermedia. Si los datos no se encuentran allí, se leerá de la base de datos y se cargará en la memoria intermedia. El siguiente acceso a estos datos ya podrá utilizar la memoria intermedia.


Página 28 de 195

Si se modifica una tabla con memoria intermedia, ésta es actualizada de forma síncrona en la memoria intermedia del servidor de aplicación en el que se realizó el cambio. Las memorias intermedias del resto de la red, es decir, las memorias intermedias del resto de los servidores de aplicación, son sincronizadas mediante un procedimiento asíncrono para no sobrecargar la red.

Debido a este método de sincronización, sólo se debería activar la memoria intermedia para aquellas tablas en las que se modifican raramente (y se lee frecuentemente) o para las cuales las inconsistencias temporales no son significativas. Las candidatas típicas para la utilización de la memoria intermedia incluyen a las tablas de parametrización y del sistema. En ciertos casos, los datos maestros también son susceptibles de utilizar memoria intermedia.

Si una tabla va a utilizar memoria intermedia, debemos definir el tipo de grabación en ella (total, registro único, ámbito genérico), es decir, cuántos registro de la tabla van a cargarse en la memoria intermedia cuando se acceda a una entrada de la tabla.

2.1.5.4 Registrar modificaciones de datos Este parámetro define si se llevará un registro de los cambios realizados en los datos de la tabla o no. Si está activo, cada cambio que se realice en la tabla se guardará en una tabla de logs. El flag de Convertir a tabla transparente (flag transparente) también aparecerá para las tablas pool o para las tablas que hayan sido convertidas en tablas transparentes mediante este flag.

2.1.6 Índices Podemos buscar más rápidamente en las tablas ciertos datos que satisfagan cierto criterio si utilizamos índices. Un índice puede considerarse como una copia de la tabla de la base de datos que se ha reducido a ciertos campos. Esta copia está siempre ordenada, lo cual ofrece un acceso más rápido a los registros de la tabla, por ejemplo por medio de una búsqueda binaria.


Página 29 de 195

El índice primario contiene los campos clave de la tabla y un puntero a los campos no clave. Se crea automáticamente cuando se genera la tabla.

Podemos crear otros índices para la tabla. Estos se llaman índices secundarios. Esto será necesario si se accede frecuentemente a la tabla por campos diferentes a la clave primaria.

Sólo tienen sentido aquellos índices cuyos campos restrinjan significativamente el conjunto de resultados de la selección.

Supongamos que se realiza frecuentemente la siguiente selección sobre la tabla de direcciones TABDIR:

SELECT * FROM TABDIR WHERE TITULO = ‘Prof.’ AND

NOMBRE = X

APELLIDO1 = Y.

El campo TITULO raramente restringirá un registro especificado con NOMBRE y APELLIDO1, en caso de que creáramos un índice por NOMBRE/APELLIDO/TITULO, ya que no es probable que mucha gente tenga el mismo nombre y diferentes títulos. Esto no tendría sentido en un índice. Un índice sólo sobre el campo TITULO podría tener sentido si, por ejemplo, se seleccionan frecuentemente todos los profesores.

El orden de los campos de un índice es de vital importancia en cuanto a la velocidad de acceso a los datos. Los primeros campos deben ser aquellos que tengan valores constantes para una gran cantidad de selecciones.

Los índices adicionales significan una carga adicional para el sistema, ya que deben ajustarse cada vez que cambia el contenido de una tabla. Por esta razón, las tablas que se modifican muy frecuentemente deberían tener unos pocos índices.

Los diferentes índices para una misma tabla se distinguen entre sí por medio de un identificador que sólo puede contener letras y números. El valor ‘0’ está reservado para el índice primario.


Página 30 de 195

Ejemplo: A menudo se buscan todas las oficinas de venta de las compañías aéreas de un cierto aeropuerto. El ID del aeropuerto se utilizará para buscar las oficinas de ventas para este acceso. La ordenación por el índice primario no es útil en este caso para acelerar la búsqueda. Como la tabla SCOUNTER tiene muchas líneas, se debe crear un índice secundario por el campos AIRPORT (ID del aeropuerto) para acelerar este tipo de búsqueda.

2.1.7 Append estructures Si queremos ampliar una tabla con un append structure, los nombre deben de tener el rango entre YY..ZZ. Al realizar esta operación el orden de los campos de la BB.DD es indiferente, (lo que se hace es un cambio en el catalogo). Esto permite añadir campos a las tablas sin alterar la tabla.

2.2 Dominios Un dominio es el objeto que define las características técnicas de un campo o atributo: el tipo de datos, la longitud, los valores posibles, las propiedades de salida,…

Tanto para crear un dominio como para modificarlo o visualizarlo se debe acceder a la pantalla inicial del Diccionario (SE11).

Veamos más a fondo cómo es un dominio a través de un ejemplo:

Seleccionamos la opción “Dominio” e introducimos en el campo adyacente el nombre del Dominio de datos que queremos tratar, en nuestro caso S_CITY. Pulsamos el botón de Visualizar (el procedimiento es similar para Crear y Modificar), también podemos acceder a estas opciones a través del menú ‘Objeto Dict‘.

Llegaremos a la siguiente pantalla:


Página 31 de 195

2.2.1 Definición En la pestaña Definición encontramos campos para introducir las siguientes características formales:

Descripción breve: Contiene una descripción del dominio a crear, un texto explicativo del dominio.

En nuestro caso la descripción es "Nombre de una ciudad".

Tipo de datos: El tipos predefinido que mejor se adapta a las características del objeto. Para visualizar los tipos posibles pulsamos F4 y vemos la siguiente ventana:


Página 32 de 195

En nuestro caso el tipo es "CHAR", pues los valores que se almacenan son cadenas de caracteres.

Longitud: Se corresponde al tamaño máximo deseado para los valores que tomará el dominio.

En nuestro caso la longitud es 20.

Los elementos del marco Atributos de salida varían dependiendo del tipo de datos seleccionado. Por ejemplo para el tipo CHAR tenemos la opción de minúsculas y para el tipo CURR tenemos la opción del signo.

Longitud de salida: Representa la longitud en la que se va a representar el valor a la hora de imprimirse en un informe, visualizarse en una pantalla, etc.

También 20.

Rutina de conversión: Es una referencia a los procedimientos de conversión entre el formato interno del dato y su representación externa.

(En blanco)

Flag de Minúsculas: Se permite la utilización de letras minúsculas.

(No marcado)

2.2.2 Ámbito de valores En la pestaña que tiene por título Ámbito Val se define el rango de valores que puede tomar un campo que haga referencia a este dominio. A partir de esta definición, el sistema realiza comprobaciones automáticas para verificar que el valor introducido se


encuentra dentro de los valores válidos. Para delimitar estos valores, si es necesario, hay dos posibilidades:

- que los valores válidos estén almacenados en una tabla, en cuyo caso introduciremos en esta pantalla el nombre de la tabla. El sistema propondrá la tabla de valores como tabla de verificación cuando intentemos definir una clave externa para este campo. Hay que tener en cuenta que no se realiza la verificación simplemente por introducir una tabla de valores. La verificación contra la tabla de valores sólo tiene efecto cuando se define una clave externa.

- que se fijen directamente en esta pantalla los valores válidos, bien a través de una lista de valores individuales (que pueden tener una descripción breve), bien definiendo intervalos de valores introduciendo los límites inferior y superior.

En nuestro caso de ejemplo el dominio tiene los valores posibles almacenados en la tabla SGEOCITY.

2.3 Elementos de Datos Si el dominio es la descripción técnica de un atributo, el elemento de datos describe la parte funcional del atributo, es su descripción semántica. Describe el propósito de un dominio para ciertos campos que dependen de él.

Para crear, modificar y visualizar elementos de datos debemos acceder también a la pantalla inicial del Diccionario (SE11). Allí seleccionamos la opción “Tipo de Datos” y introducimos el nombre del Elemento de datos que queremos tratar.

Visualizaremos el elemento de datos S_TO_CITY. Seleccionamos la opción "Elemento de datos", escribimos este nombre y pulsamos el botón de Visualizar.

Descripción breve: Descripción representativa del objeto.

"Ciudad de llegada"

En la pestaña "Tipo de datos" aparece el tipo de datos que corresponde al elemento. El tipo de datos se puede definir utilizando un dominio o por otros medios.

Dominio: Dominio al que hace referencia el elemento de datos. Varios elementos de datos pueden tener el mismo dominio.

Gráficamente podríamos definir la relación entre elementos y dominios de la siguiente forma:

Página 33 de 195


Página 34 de 195

El elemento de datos S_TO_CITY utiliza el dominio S_CITY. Este dominio es utilizado también por otros elementos de datos que deben tener las mismas características técnicas: S_CITY, S_FROM_CIT, S_VIA_CITY. Cada uno tiene una aplicación diferente dentro del modelo de datos.

Podemos averiguar en qué elementos de datos se utiliza un dominio a través de la opción "Utilidades"->"Referencia de utilización".

Tipo Instalado: Tipo de datos y longitud con el mismo significado que el que se define en los dominios.

ID parámetro: Permite referenciar a un parámetro de memoria SAP. Será útil para mostrar valores por defecto en pantallas, ya que este campo se completará con el valor que tenga el parámetro de memoria SAP al mostrar la pantalla. (En nuestro caso lo dejamos en blanco.)


Página 35 de 195

En la pestaña "Denom. Campo" aparecen los campos correspondientes a la descripción del objeto. Son tres textos de diferente longitud que se mostrarán en los diferentes lugares donde se utilicen campos con este elemento de datos: cabeceras de informes al visualizar contenidos de tablas, pantallas…

El campo longitud representa el espacio en el que se va a escribir el texto.

También se puede asignar una documentación online a un elemento de datos. El texto que aparece para la ayuda de campo (ayuda F1 ).

Tanto los elementos de datos como los dominios son objetos independientes dentro del diccionario de datos, lo que significa que podemos utilizarlos para diferentes campos de diferentes tablas. Un mismo dominio puede utilizarse para diferentes elementos de datos. Esto nos permite el uso de objetos que ya han sido definidos y asegurar la consistencia de los campos que tengan el mismo tipo de contenido y de características técnicas.

2.4 Estructuras Las estructuras se definen en el Diccionario de Datos de la misma forma que las tablas, pero no existe ninguna tabla en la base de datos que se corresponda con ella. Esto quiere decir que, mientras que las tablas contienen datos que están permanentemente almacenados en la base de datos, las estructuras sólo contienen datos en tiempo de ejecución de un programa. Para ellas sólo existe la definición lógica. Tienen la finalidad de almacenar datos durante la ejecución de un programa o permitir el paso de información de un programa a otro.

Se pueden utilizar los mismos elementos de datos y dominios que en las tablas y se pueden incluir las estructuras de otras tablas. Esto permite que, los programas que sean complejos, enlacen datos que provienen de diferentes tablas.

2.5 Vistas Los datos de una aplicación a menudo se encuentran distribuidos en diferentes tablas relacionadas. Por medio de las vistas podemos ver los datos como si se encontraran en una única tabla.

El primer paso en la definición de una vista es elegir las tablas base que formarán parte de ella. Si hay más de una, debemos especificar la condiciones de unión (es


Página 36 de 195

posible utilizar la clave externa definida entre las tablas). Después, elegiremos los campos de las tablas que queremos incluir en la vista (proyección), el resto de campos quedan ocultos. Por último, puede que queramos restringir los registros que deben formar parte de la vista (selección).

Existen cuatro tipos diferentes de vistas. Se diferencian entre sí en la forma en que se implementa la vista y en los métodos que se permiten para acceder a la vista de datos:

• Vistas de Base de Datos que se implementan mediante una vista equivalente en la base de datos.

• Vistas de Proyección que se utilizan para ocultar campos de una tabla • Vistas de actualización nos permiten realizar el mantenimiento de los datos

distribuidos en varias tablas • Vistas de ayuda que pueden utilizarse como método de selección en las ayudas de

búsqueda.

2.5.1 Vistas de Base de Datos En el modelo relacional, los datos de una aplicación a menudo se distribuyen en varias tablas de la base de datos. Crearemos vistas de bases de datos si queremos seleccionar simultáneamente datos de diferentes tablas que estén lógicamente relacionados entre sí. La selección mediante vistas normalmente es más rápida que el acceso individual a cada tabla.

Las vistas de base de datos que se definen en el Diccionario de ABAP tendrán su correspondiente reflejo en la base de datos, que se generará automáticamente cuando se active la vista. Sólo se pueden utilizar tablas transparentes en este tipo de vistas.

Los programas pueden acceder a los datos de la vista de base de datos utilizando la interfase de la base de datos. Cuando seleccionemos los datos mediante vistas, también deberíamos asegurar que existen los índices adecuados en las tablas contenidas en la vista.


Página 37 de 195

Si la vista contiene más de una tabla, sólo se permite el acceso de lectura. Como la operación de unión se ejecuta en la propia base de datos, podemos minimizar de esta manera el número de accesos a la base de datos.

Si la vista contiene una única tabla, se puede utilizar el estatus de mantenimiento para determinar si también se pueden insertar registros con la vista.

2.5.1.1 Includes en Vistas de Bases de Datos Es posible incluir una tabla completa en una vista de base de datos. En este caso, todos los campos de la tabla incluida serán campos de la vista. Si se añaden nuevos campos en la tabla o se borra alguno ya existente, la vista se ajustará automáticamente a estos cambios.


Página 38 de 195

2.5.2 Vistas de Proyección Las vistas de proyección se utilizan para ocultar ciertos campos de una tabla. Esto significa que sólo se transferirán los datos que se requieran cuando se acceda a la base de datos.

Una vista de proyección sólo puede aplicarse a una única tabla y no se pueden especificar condiciones de selección. En este tipo de vistas no existe el objeto correspondiente en la base de datos.


Página 39 de 195

También podemos acceder a tablas pool y cluster con una vista de proyección.

El estatus de mantenimiento de la vista controla cómo se puede acceder a los datos de la tabla con la vista de proyección.

2.5.3 Vistas de actualización Las vistas de actualización ofrecen una forma sencilla de mantener objetos de aplicaciones complejos.

Los datos distribuidos en varias tablas a menudo forman una unidad lógica, por ejemplo un objeto de aplicación, para el usuario. Normalmente este querrá ser capaz de visualizar, modificar y crear los datos de tal objeto de aplicación de forma conjunta. Además, generalmente el usuario no está interesado en la implementación técnica del objeto de aplicación, esto es, en la distribución de los datos en varias tablas.

Una vista de actualización nos permite gestionar el mantenimiento de los datos de un objeto de aplicación de forma conjunta. Los datos se distribuirán automáticamente en las tablas de la base de datos. El estatus de mantenimiento determina qué tipos de accesos son posibles a las tablas de la base de datos.

Todas las tablas incluidas en la vista de actualización deben estar enlazadas mediante claves externas, es decir, las condiciones de unión de las vistas de actualización se derivan siempre de la clave. No podemos introducir directamente las condiciones de unión como para las vistas de base de datos.

Existen algunas restricciones para los atributos de las claves externas con las que son enlazadas las tablas de una vista de actualización


Página 40 de 195

Se ofrece una transacción de actualización de tablas estándar (SM30), que nos permite gestionar el mantenimiento de los datos de los datos de las tablas base conjuntamente en una vista de actualización.

Los mecanismos de mantenimiento, tales como pantallas y programas de procesamiento, pueden ser creados a partir de la definición de la vista mediante la transacción Generar diálogo de actualización de tabla (SE54). Esto hace posible crear de una forma sencilla las interfases de mantenimiento de una vista.


Página 41 de 195

2.5.4 Vistas de ayuda Las vistas de ayuda se pueden utilizar como método de selección en las ayudas de búsqueda. Esto será especialmente necesario si se requiere una vista con unión externa para la selección de valores. Como las vistas de bases de datos siempre implementan una unión interna, en estos casos será necesario indicar una vista de ayuda como método de selección de la ayuda de búsqueda.

Todas las tablas incluidas en una vista de ayuda deben enlazarse mediante claves externas. Además, sólo se pueden utilizar claves externas que tengan ciertos atributos.

La funcionalidad de la vista de ayuda ha cambiado significativamente de la versión 3.0 a la versión 4.0. En la versión 3.0, la vista de ayuda se mostraba automáticamente para la ayuda de entrada (ayuda F4) para todos los campos que se verificaran contra la primera tabla (tabla primaria) de la vista de ayuda. Esto ya no pasa en la versión 4.0.

En la versión 4.0 podemos crear explícitamente una ayuda de búsqueda que debemos enlazar a los campos para los que se ofrecerá.

2.5.5 Unión, Proyección y Selección La estructura de una vista con los operadores de relación join, proyección y selección y la selección de datos utilizando una vista pueden mostrarse mediante un ejemplo.

Tablas: Seleccionaremos las tablas de las que se desee obtener información.

Condiciones Join: Definen los campos por los que se realiza la intersección entre las tablas seleccionadas. Para indicar las relaciones podemos utilizar el botón

o escribir directamente las relaciones.

Campos Vista: Se seleccionan los campos deseados. Podemos renombrar el campo en la vista será el que pongamos en Campos Vista’. (Por defecto será el nombre original del campo seleccionado).

Para facilitar la selección de campos de una tabla, situados sobre la tabla pulsamos el


Página 42 de 195

botón donde marcaremos los campos deseados , una vez seleccionados aparecerán automáticamente en la pantalla.

Para ver el contenido de la vista seleccionamos el menú ‘Utilidades Contenido’. Aparecera la pantalla de selección de la vista de la misma forma que en la visualización de los datos de una tabla.

Sean dos tablas TABA y TABB. La tabla TABA tiene 2 entradas y la tabla TABB tiene cuatro entradas.

Primero se pegan las dos tablas. Cada registro de TABA se combina con cada registro de TABB. Si no se define una condición join, el resultado cruzado de las tablas TABA y TABB puede ser visualizado mediante la vista.

2.5.5.1 Condiciones Join El resultado cruzado completo normalmente no es una selección sensible. Por lo tanto, el resultado cruzado de ambas tablas debe restringirse mediante condiciones join. Una condición join describe la forma en la que se conectan los registros de las dos tablas.

En nuestro ejemplo, C1 de TABA debe identificarse con C3 de TABB. Por lo tanto, la condición join será TABB-C1 = TABB-C3. Esta condición join elimina del resultado cruzado todos los registros para los cuales la entrada C1 no sea idéntica a la entrada de C3. No se requiere la columna de C3 en la vista.


Página 43 de 195

La condición join puede especificarse explícitamente en el mantenimiento de la vista. También es posible utilizar una clave externa existente. La condición join se genera automáticamente a partir de las definiciones de la clave externa:

2.5.6 Relación entre Clave Externa y Condición Join Se define una vista que contiene las tablas base TAB1 y TAB2. TAB1 es la tabla primaria de la vista y TAB2 la secundaria. TAB1 es la tabla de verificación de TAB2.

Se asignan los campos de clave externa a los campos de la tabla de verificación como se indica a continuación:

Campo de la tabla de verificación Campo de clave externa

TAB1-CAMPO_A TAB2-CAMPO_1

TAB1-CAMPO_B TAB2-CAMPO_2

La condición join de la vista generada para la clave externa será:

CREATE VIEW... AS SELECT... WHERE TAB2-CAMPO_1 = TAB1_CAMPO_A AND

TAB2-CAMPO_2 = TAB1_CAMPO_B.

También podemos generar condiciones join a partir de claves externas genéricas y constantes:

Campo tabla de verificación Campo clave externa

TAB1-CAMPO_A TAB2-CAMPO_1

TAB1-CAMPO_B Genérica

TAB1-CAMPO_C Constante: ‘C’

La condición join para la vista generada a partir de la clave externa en este caso sería:

CREATE VIEW... AS SELECT... WHERE TAB2-CAMPO_1 = TAB1_CAMPO_A AND

TAB2-CAMPO_2 = ‘C’.


Página 44 de 195

No se especifica ninguna condición join cuando la relación es genérica.

2.5.6.1 Proyección En algunas ocasiones, algunos campos de las tablas involucradas en una vista no tienen interés por algún motivo. El conjunto de campo utilizados en la vista pueden definirse explícitamente (proyección).

En nuestro ejemplo, el campo C4 no tiene interés y puede ocultarse.

2.5.6.2 Condiciones de Selección Se pueden definir condiciones de selección en una vista que se utilizarán como un filtro.

En este caso, sólo se utilizarán en la vista aquellos registros que satisfagan las restricciones. En tales condiciones de selección, se compara el campo de la vista con una constante utilizando el operador de comparación. Se pueden enlazar varias condiciones de selección mediante los operadores lógicos AND y OR.

En nuestro ejemplo, sólo se deben mostrar aquellos registros que tengan un valor A en C4. En este caso la condición de selección será TABB-C4 = ‘A’.

Como puede verse se puede formular una condición con un campo que no este contenido en la vista.


Página 45 de 195

2.6 Ayudas para Búsqueda Una ayuda para búsqueda, también denominada "matchcode", es un instrumento para facilitar la búsqueda de registros almacenados en el sistema que permite filtrar la información existente por determinados criterios.

Por ejemplo si no sabemos el DNI de una persona pero si su nombre, mediante este, podremos obtener el DNI.

Las ayudas de búsqueda se utilizan para asignar un valor de ayuda (F4) a los campos.


Normalmente el usuario sigue estos pasos cuando llama a la ayuda para introducir una entrada en un campo: 1. El usuario lanza la ayuda para ver los valores posibles para un campo. 2. El sistema ofrece al usuario una serie de plantillas de búsqueda. 3. El usuario selecciona una de las plantillas. Cada plantilla proporciona unas

restricciones para limitar el número de valores posibles de entrada. Estos valores se ofrecen mediante una ventana de diálogo.

4. El usuario introduce las restricciones requeridas y el sistema comienza la búsqueda.

5. El sistema determina los valores que cumplen con las restricciones introducidas y los muestra en forma de lista.

6. El usuario selecciona una línea de la lista. 7. El valor seleccionado se copia en la pantalla (posiblemente junto con otros valores).

Los pasos 2 y 3 serán omitidos si existe una única plantilla de búsqueda posible. En este caso la ventana de diálogo aparecerá inmediatamente para la selección de valores.

Este proceso puede definirse completamente creando una ayuda de búsqueda en el Diccionario de ABAP. Esta ayuda de búsqueda debe ser asignada a los campos de la pantalla para los cuales se debe ofrecer.

Existen dos tipos de ayudas de búsqueda: elemental y compuesta.

2.6.1 Ayuda para búsqueda elemental: Se corresponde con una plantilla de búsqueda. Debe definir desde dónde se van a leer los datos de la lista de aciertos (método de selección), cómo se implementa el intercambio de los valores entre la pantalla y el método de selección (parámetros) y cómo se diseña la ayuda on-line.

2.6.1.1 Método de Selección (Recolección de Datos) El método de selección describe cómo se deben leer los datos para formar la lista de aciertos. Existen tres formas diferentes de recolectar los datos:

• Tabla: Si todos los datos que se necesitan para la lista de aciertos pertenecen a una única tabla, sólo tendremos que definir esta tabla.

• Vista: Si lo datos que se necesitan para la lista de aciertos pertenecen a más de una tabla, debemos enlazar dichas tablas en una vista (vista de base de datos o vista de ayuda). Esta vista debe definirse como método de recolección de datos.

• Tabla con tabla de texto: Si los datos que se necesitan para la lista de aciertos pertenecen a una única tabla con la excepción del texto explicativo, esta tabla puede definirse junto con su Tabla de Texto.

2.6.1.2 Parámetros de Ayuda Si un campo del método de selección debe utilizarse para la recolección de datos, se debe incluir el mismo en la ayuda de búsqueda. Esto será necesario para los campos: • Que se necesitan para restringir la lista de aciertos, • Que deben ser mostrados en la lista de aciertos como una columna, • Cuyos valores deben copiarse en el campo de la pantalla.

Un parámetro puede clasificarse como: • Parámetro IMPORT: Aquel con el que pasaremos los datos introducidos por el

usuario en la plantilla de entrada a la ayuda de búsqueda. • Parámetro EXPORT: Aquel con el que pasaremos los datos desde la ayuda de

búsqueda a la plantilla de entrada de datos.

Página 46 de 195


Una ayuda de búsqueda puede contener parámetros que no sean IMPORT ni EXPORT. Tales parámetros pueden necesitarse, por ejemplo, para el proceso interno de la ayuda de búsqueda.

2.6.1.3 Descripción del Diseño On-line Podemos definir la ventana de diálogo para restringir los valores de selección. También podemos definir cómo aparecerá la lista de aciertos.

2.6.2 Definición de ayudas de búsqueda Las ayudas para búsqueda se crear, modifican y visualizan mediante la transacción SE11 que ya conocemos.

En la pantalla inicial del diccionario seleccionamos la opción "Ayudas p.búsqueda", introducimos el nombre del matchcode a tratar, SCITAIRP, y pulsamos el botón de visualizar:

Descripción breve: Texto explicativo del matchcode.

En este caso "Buscar aeropuesto vía ciudad (país)".

Método de selección: Nombre de tabla o vista del diccionario de datos de donde se obtendrán los datos a mostrar en la ayuda.

La tabla SCITAIRP contiene la asignación Ciudad-Aeropuerto.

Tabla de textos: Si la tabla que se usa para la selección tiene tabla de textos.

Página 47 de 195


2.6.2.1 Exit Ayuda p.búsq. Se utiliza si el proceso de entrada estándar F4 definido por la ayuda de búsqueda tiene que ser cambiado.

Los procesos de entrada F4 estándar están definidos por medio de ayudas de búsqueda. Si este proceso estándar no tiene las características requeridas, podemos cambiarlo utilizando una exit de ayuda de búsqueda.

Una exit de ayuda de búsqueda es un módulo de función que es llamado por el procesador de ayuda F4. Podemos almacenar nuestra propia lógica de programa en este módulo de función. Esta exit de ayuda de búsqueda debe tener la misma interfase que el módulo de función F4IF_SHLP_EXIT_EXAMPLE (se usa como modelo para todas las exits de ayuda de búsqueda que creemos). Podemos encontrar más información en la documentación para el módulo de función.

La exit de ayuda de búsqueda se llama en los siguientes casos:

Antes de mostrar la ventana de diálogo para seleccionar la ruta de búsqueda requerida.

Sólo es llamada para ayudas de búsqueda compuestas. Utilizando la exit de ayuda de búsqueda, el conjunto ayudas de búsqueda elementales por ejemplo puede restringirse dependiendo del contexto.

Antes de mostrar la ventana de diálogo para introducir las condiciones de búsqueda.

Podemos influir en el diálogo introduciendo condiciones de búsqueda o saltándonos todas.

Podemos también influir en la forma en que busca la pantalla de selección.

Antes de la selección de valores.

La selección de valores puede copiarse total o parcialmente desde la exit de ayuda de búsqueda

Antes de mostrar la lista de aciertos.

Podemos controlar la visualización de la lista de aciertos en este paso con la exit de ayuda de búsqueda. Podemos reducir el número de valores mostrados, por ejemplo podemos enseñar sólo aquellos valores para los cuales la persona que llama a la ayuda F4 tiene autorización. También podemos copiar la lista completa de aciertos desde la exit de ayuda de búsqueda.

Antes de devolver los valores seleccionados por el usuario a la plantilla de entrada.

Puede tener sentido intervenir en este momento si el control flujo posterior de la transacción depende del valor seleccionado. Un ejemplo típico es actualizar los parámetros SET/GET.

Página 48 de 195


2.6.2.2 Tipo de diálogo El tipo de diálogo de una ayuda de búsqueda elemental define la forma en la que se mostrará la lista de aciertos cuando se llame a la ayuda. Existen los siguientes tipos de diálogo: • Visualizar valores inmediatamente: La lista de aciertos se mostrará

inmediatamente. • Diálogo complejo con restricción de valores: Se ofrecerá inmediatamente la

ventana de diálogo para la selección de la ayuda de búsqueda. • Diálogo dependiente del número de valores: Si la lista de aciertos contiene

menos de 100 entradas, se mostrará inmediatamente. Si la lista contiene más de 100 entradas, se mostrará una ventana de diálogo para la selección de valores.

2.6.2.3 Tecla sensible La tecla sensible se utiliza para seleccionar una ayuda de búsqueda elemental de una ayuda de búsqueda compuesta y para introducir las restricciones directamente en el campo de entrada de la ventana de diálogo de restricción de valores. Si el usuario busca a menudo valores utilizando la misma ayuda de búsqueda, este procedimiento puede ahorrar tiempo. Si se accede a la ayuda de búsqueda mediante una tecla sensible, debemos definir un ID de una posición en este campo. Todas las ayudas de búsqueda elementales contenidas en una ayuda de búsqueda compuesta deben tener diferentes teclas sensibles.

Se debe introducir una abreviatura en el campo de entrada de acuerdo con la siguiente convención: =<Tecla sensible>.S1.S2.S3... Donde S1, S2, S3, etc. son las restricciones que queremos introducir en los correspondientes campos de la ventana de diálogo en el mismo orden.

Página 49 de 195


Página 50 de 195

Si la tecla sensible se define sin restricciones ( =<Tecla sensible>), se llamará a la ventana de diálogo para restringir los valores. Si se definen restricciones, se saltará la ventana de diálogo para restringir valores y se mostrará directamente la lista de aciertos. Si se encuentra únicamente un acierto, no se mostrará la lista de aciertos. En este último caso, los valores de la lista de aciertos se devolverán inmediatamente a la pantalla de plantilla de entrada.

2.6.2.4 Parám.Ayuda búsq. Formado por cada uno de los campos que se utilizarán para la búsqueda.

IMP: Flag de parámetro EXPORT, este campo se utilizará como campo en el que informar valores de condición para la búsqueda de registros. EXP: Flag de parámetro IMPORT, este campo se utilizará como parámetro de salida, es decir, se volcará el valor del registro seleccionado sobre el campo.

P.I.: Posición del parámetro lista de aciertos, indica la posición que ocupará el campo en la ventana de ayuda donde se mostrarán los registros seleccionados. (Si se indica ‘0’ o Blanco, significará que el campo no se muestra en la lista de aciertos).

PosS: Posición del parámetro en la ventana de condiciones de la selección (restricción de valores).

V.s: Si marcamos este flag el parámetro se convertirá en un campo de visualización (no modificable) en la ventana de restricción de datos.

Elemento de datos: el nombre del elemento de datos que describe el contenido del parámetro de la ayuda de búsqueda

Valor Propuesta: Valor por defecto que se asignará al parámetro si no se hace explícitamente.

En la Ayuda para búsqueda SCITAIRP los campos que se utilizan para la búsqueda de registros son SITY, COUNTRY y AIRPORT, y el valor que se volcará sobre la salida será AIRPORT


2.6.3 Ayuda para búsqueda compuesta Comprende varias ayudas de búsqueda elementales. Combina todas las plantillas de búsqueda que tienen sentido para un campo. En una ayuda de búsqueda compuesta, debe definirse el intercambio de valores entre la pantalla y el método de selección (parámetros) y deben indicarse las ayudas elementales que la forman. El valor de selección y las características para la ayuda on-line se toman de las ayudas de búsqueda elementales.

2.6.3.1 Parámetros de la Ayuda de Búsqueda Compuesta Los parámetros de la ayuda de búsqueda compuesta conforman la interfase entre la plantilla de entrada de datos y los parámetros de las ayudas de búsqueda elementales asignadas. Como para las ayudas de búsqueda elementales, los parámetros de una ayuda de búsqueda compuesta pueden marcarse como parámetros de importación o de exportación.

2.6.3.2 Ayudas de Búsqueda asignadas Una ayuda de búsqueda compuesta comprende varias ayudas de búsqueda elementales. Se agrupan en rutas de búsqueda mediante las cuales cobra sentido un F4 sobre un campo.

Se pueden incluir tanto ayudas de búsqueda elementales como otras ayudas de búsqueda en una ayuda de búsqueda compuesta. Si una ayuda de búsqueda compuesta contiene a su vez otra ayuda de búsqueda compuesta, se expanden al nivel de las ayudas de búsqueda elementales cuando se llama a la ayuda para F4.

Los parámetros de las ayudas de búsqueda incluidas deben asignarse a los parámetros de la búsqueda de ayuda. No todos los parámetros necesitan ser asignados, es decir, la asignación puede abrirse sólo para algunos parámetros.

Si se asigna más de una vez una ayuda de búsqueda elemental de una ayuda de búsqueda compuesta (por ejemplo, debido a que está contenida en dos ayudas de búsqueda compuestas), sólo se ofrecerá ésta cuando se seleccione la ruta de ayuda.

2.6.4 Enlace de una Ayuda de Búsqueda con un campo de pantalla Una ayuda de búsqueda puede ser asignada a un campo de una pantalla como sigue: • Enlazarla a un campo de tabla o estructura.

La ayuda de búsqueda se ofrecerá para todos los campos de pantalla donde aparezca el campo de la tabla. Para este tipo de enlace, debe asignarse cada

Página 51 de 195


parámetro de la ayuda de búsqueda a cada campo de la tabla o estructura. Esta asignación hace que se transporte un valor entre cada parámetro de la ayuda de búsqueda y su campo cuando se llama a la ayuda.

No todos los parámetros de la ayuda de búsqueda tienen que asignarse a un campo de la tabla. Podemos dejar abierta la asignación. También puede asignarse una constante o cualquier otro campo al parámetro de ayuda de búsqueda cuando llamamos a la ayuda F4.

• Enlazarla a una tabla. La ayuda de búsqueda se ofrecerá para todos los campos a chequear contra la tabla. También podemos definir una asignación entre los parámetros de ayuda de búsqueda y los campos.

• Enlazarla a un elemento de datos. La ayuda de búsqueda se ofrecerá para todos los campos de una tabla que hagan referencia al elemento de datos.

2.6.5 Jerarquía de la llamada a la Ayuda de Búsqueda Se pueden producir conflictos debido a las tres formas diferentes de enlace de las ayudas de búsqueda. Por ejemplo, la ayuda de búsqueda A puede asignarse aun campo, la ayuda de búsqueda B a un chequeo de tabla para un campo y la ayuda de búsqueda C a un elemento de datos.

Tales conflictos se resuelven definiendo una jerarquía para las ayudas de búsqueda asignadas.

Primero se intenta realizar la llamada de la ayuda de búsqueda del campo de la pantalla.

Si no existe, se llama a la ayuda de búsqueda del campo de la tabla.

Si tampoco existe, se utilizará la ayuda de búsqueda enlazada a la tabla de verificación (si se ha definido una clave externa). En este caso se deben distinguir dos casos: si la tabla de verificación tiene una ayuda de búsqueda, se mostrará ésta. En otro caso, sólo se mostrarán los valores clave de la tabla de verificación. Si existe una tabla de texto para la tabla de verificación, se incluirán dichos textos en el idioma en el que se entró al sistema.

Si no existe una tabla de verificación, se utilizará la ayuda de búsqueda enlazada al elemento de datos.

El siguiente gráfico muestra la jerarquía de llamada a la ayuda de búsqueda. El gráfico debe interpretarse de arriba abajo y de izquierda a derecha. En enlace de ayuda de búsqueda A tiene prioridad sobre el enlace de ayuda de búsqueda B si A está encima de B, o si A y B están al mismo nivel y A está más a la izquierda que B.

Por lo tanto, los enlaces de ayuda de búsqueda para los campos de pantalla tienen la prioridad más alta. En enlace de ayuda de búsqueda con el Diccionario ABAP tiene la siguiente prioridad.

Página 52 de 195


Página 53 de 195

2.7 Modificación de objetos El sistema R/3 trabaja interpretativamente, permitiendo que el Diccionario ABAP esté integrado activamente en el entorno de desarrollo. En lugar de ver los objetos originales, los intérpretes sólo ven la representación interna de esos objetos.

Estas representaciones internas se ajustan automáticamente cuando el sistema encuentra que se han realizado modificaciones en el Diccionario ABAP. Esto asegura que la pantalla y los intérpretes ABAP, las ayudas de entrada, la interfase con la base de datos, y las herramientas de desarrollo siempre acceden a los datos actualizados.


El siguiente programa ABAP lista las compañías aéreas y los IDs de compañías aéreas que están contenidos en la tabla SCARR.

DATA: SCARR_TAB TYPE SCARR.

SELECT * INTO SCARR_TAB FROM SCARR.

WRITE: / SCARR_TAB-CARRID, SCARR_TAB-CARRNAME.

ENDSELECT.

En el programa sólo se declara la estructura SCARR_TAB. Toda la información acerca de esta estructura, como por ejemplo los nombres de los campos, los tipos de datos y la longitud de los campos, se copian de la tabla SCARR, que está definida en el Diccionario ABAP. Esta información acerca de la tabla SCARR se obtiene del Diccionario de ABAP cuando se genera el programa.

Esto significa que el texto fuente del programa no necesitará ser actualizado cuando se realicen cambios en la tabla SCARR, por ejemplo si se varía la longitud de un campo de la tabla. La siguiente vez que se llame al programa, el sistema determinará automáticamente que ha cambiado la estructura de la tabla SCARR. Simplemente, se regenerará el programa, y de este modo se recuperará la información actualizada acerca de la tabla SCARR desde el Diccionario de Datos.

Cuando trabajamos con proyectos de desarrollo, se pueden modificar los objetos del Diccionario de ABAP cualquier número de veces antes de activarlos y hacer con ello que estén disponibles y operativos para el resto de los componentes del sistema. Los objetos pueden tener una versión activa e inactiva al mismo tiempo.

Los objetos inactivos del Diccionario ABAP es como si no existieran en el sistema en tiempo de ejecución (procesador ABAP, interfase con la base de datos). Esto permite que realicemos modificaciones sobre los objetos sin que perjudiquemos al sistema.

Versión Activa: Es con la que trabajamos actualmente. Es la versión que ven los demás objetos.

Versión Realizada: Es una version con alguna modificación pero sin estar activa. Hasta que no se activa no se trabaja con los cambios.

Runtime Object: Tiene (Elementos de datos, dominios y definición de tabla), esta información es almacenada en una tabla de forma que el programa de aplicación pueda acceder a esta información rápidamente. Se genera durante la activación de la tabla.

Al cambiar por ejemplo un dominio se actualizan los elementos de datos y los campos de las tablas implicadas. Esto asegura la consistencia.

Tipos de Activación

Activa: La activación se realiza desde el mantenimiento.

Masiva: La activación se realiza desde el programa RDDMASG0. Esto es típico en una importación. Se puede ejecutar en Background. Se recomienda especialmente para importaciones muy largas.

2.8 Tratamiento de los datos

2.8.1 Data browser Tambien es posible crear registros dentro de la tabla desde la definición de esta (Utilidades Crear entradas). (Sistema Servicios Actualizar tablas ??).

Página 54 de 195


2.8.2 Actualización de tablas Dentro del diccionario nos es posible crear mini interfaces para la entrada de datos en una determinada tabla (Entorno Generar.actual.tablas). Existen dos tipos de estas entradas:

1 Nivel: Toda la entrada se realiza desde la misma dynpro (Busqueda del registro+actualización).

2 Niveles: Se realiza la entrada en dos dynpros, 1ª busqueda del registro, 2ª actualizacion.

Para poder realizar esta operatoria directamente desde una transacción tendremos que crearla mediante el object repositoy, Transacciones Transacciones de parametros.

2.8.3 Transacciones: SM30, SM31. Estas transacciones nos permiten visualizar o actualizar el contenido de aquellas tablas que se crearon con permiso de actualización y para las que se generó la correspondiente superficie de actualización.

Una vez dentro de la transacción, podemos modificar o crear nuevas líneas para la tabla seleccionada.

Existen una serie de utilidades que es conveniente conocer: • Selección -> por contenidos. Nos permite seleccionar unas líneas determinadas de

la tabla por medio de su contenido. • Tratar -> Copiar como. Nos permite copiar la línea o líneas seleccionadas. • Botón icono Imprimir. Imprime el contenido de la tabla con todos sus campos. • Botón Lista variable. Nos permite seleccionar los campos a imprimir así como

editar su formato de salida (clasificación, posición, saltos de línea, longitud de títulos).

Página 55 de 195


Página 56 de 195

3 Creación de programas

3.1 Editor y Object Navigator Para poder desarrollar los programas tenemos un editor de lenguaje ABAP/4. Este editor nos permitirá escribir, verificar y generar los programas. Hay varias maneras de llegar al editor, pero el camino más habitual para crear un nuevo programa del tipo REPORT es (desde el menú principal de SAP) Herramientas Workbench ABAP Desarrollo Editor ABAP (SE38). La pantalla principal del Editor tiene el siguiente aspecto:

Desde esta pantalla podremos crear, visualizar, modificar y ejecutar (también podremos ejecutar en DEBUG mediante la opción , ya veremos su significado más adelante) los programas.

Los programas se identifican con un nombre que debe cumplir las siguientes reglas: • Debe empezar por Z o Y, y debe tener entre uno y cuarenta caracteres. • No se pueden usar los siguientes caracteres: punto, coma, espacio, paréntesis,

comilla sencilla, comilla doble, signo igual, asterisco, tanto por ciento ni subrayado.

Para crear un programa, escribiremos el nombre del programa, seleccionaremos la

opción ‘Texto fuente’ y seleccionaremos la opción de crear .

Deberemos introducir diversos datos administrativos. En primer lugar se deben determinar algunos atributos del programa: Título: Descripción de la función realizada por el programa, un texto breve apropiado. Aparecerá al lado del nombre técnico del programa en todas las búsquedas.

Tipo: Determina cómo se ejecuta el programa en el entorno cliente/servidor. El programa puede ser:

1 (on-line): ejecutable directamente


I (include): una pieza de código reutilizable

M (module pool): un conjunto de módulos que controlarán pantallas de diálogo. Se deben definir las pantallas a utilizar y se debe enlazar un código de transacción a la primera de ellas.

F (grupo de funciones): contiene funciones, no se pueden ejecutar directamente sino que tienen que ser llamadas por otros programas.

S (pool de subrutinas): contiene código compuesto por procedimientos no ejecutable, pero que puede ser llamado desde otros programas.

Status: Información sobre el estado de desarrollo.

Aplicación: Módulo o área de aplicación al que pertenece el programa.

Todos estos atributos pueden ser utilizados para buscar un programa particular en el Repository Information System. Una vez completado estos campos obligatorios pulsaremos el botón de grabar

(F11).

Ahora tendremos que asignar el programa a una clase de desarrollo, que clasifica el programa de manera lógica. Esta asignación sólo se realiza una vez, cuando el objeto es creado inicialmente.

Podemos escoger grabaremos como objeto local (botón para conseguir que no se transporte a otros sistemas. Si no es así, debemos asignar el objeto a un proyecto (change request). Esta es una clasificación cronológica, cuando el proyecto se acabe, podremos asignar el programa a otra change request.

3.2 Elementos de un programa De las opciones anteriores, crear y ejecutar se refieren al programa en general, mientras que podemos elegir qué parte del programa queremos modificar o visualizar. Cuando hablamos de parte del programa nos referimos a:

- Texto fuente: Se refiere al código del programa.

- Variantes: Para un programa con pantalla de selección podemos crear variantes que consiste en poner unos valores fijos en los campos de la pantalla de selección y guardarlos con un nombre -variante- de manera que cuando queramos ejecutar el programa para esos valores, sólo tendremos que llamar a la variante por su nombre -Ejecutar con variante-. Podemos obtener una lista de las variantes existentes para el programa actual pulsando F4.

- Atributos: Los atributos comprenden el título del programa, la base de datos lógica que trata, la aplicación, etc,...

El paso previo a trabajar con programas es mantener los atributos de un programa.

- Documentación: Apartado reservado para documentar funcional y técnicamente el programa con el fin de facilitar el trabajo a quien vaya a modificar o a quien quiera conocer el programa.

- Elementos de texto: Título y cabeceras que aparecerán en el automáticamente al inicio de cada página generada por el programa, en caso de que éste escriba un report.

Textos de selección asociados a las variables de selección para que aparezcan en la pantalla de selección del rango de datos a tratar.

Página 57 de 195


Textos identificados por tres caracteres (XXX) que se pueden utilizar como constantes en el código del programa mediante TEXT-XXX, en lugar de tener que codificar el texto entero.

Una ventaja es que podemos introducir el mismo texto en distintos idiomas, con lo que la ejecución del programa escribirá el texto en el idioma actual del sistema, sin tener que gestionarlo en el código.

3.3 Escribir código (texto fuente)

3.3.1 Elementos sintácticos básicos El código fuente de un programa ABAP está formado por sentencias y comentarios.

3.3.1.1 Sentencias Un programa de ABAP/4 consiste en una serie de sentencias. Cada sentencia comienza con una palabra clave y termina con un punto. Las palabras dentro de una sentencia deben estar siempre separadas al menos por un espacio. No hay restricciones de formato: una sentencia se puede indentar y puede ocupar varias líneas, y podemos escribir varias sentencias en una misma línea. Debemos aprovechar esta libertad de formateo para hacer más legibles nuestros programas.

DATA contador TYPE i.

DATA name(20).

MOVE 1

TO counter.

MOVE ‘abc’ TO name.

WRITE counter. WRITE name.

Se pueden concatenar sentencias consecutivas si tienen una primera parte idéntica (que se puede extender más allá de la palabra clave). Para conseguirlo escribimos la primera parte común de las sentencias una única vez, seguida de dos puntos. A continuación escribimos los restos de las sentencias individuales, separándolos por comas. Se debe poden un punto al final para marcar el final de la cadena. Se pueden insertar espacios en blanco antes y después de cualquiera de los signos de puntuación. El sistema sigue considerando que cada una de las partes de una sentencia concatenada es una sentencia independiente de las otras. WRITE counter.

WRITE name.

WRITE: counter, name.

ADD 1 TO counter1.

ADD 1 TO counter2.

ADD 1 RO counter3.

ADD 1 TO: counter1,

counter2,

counter3.

La palabra clave de una sentencia determina su categoría, que puede ser una de las siguientes:

Sentencias declarativas:

TYPES, DATA, TABLES

Definen tipos de datos o declaran objetos de datos que son usados por otras sentencias en el programa.

Sentencias de modularización:

START-OF-SELECTION

FORM … ENDFORM.

Definen bloques de proceso en el programa: pueden ser bloques de evento (no hay sentencia para concluirlos) o procedimientos (que se concluyen co la sentencia ENDxxxx.

Página 58 de 195


FUNCTION ... ENDFUNCTION.

Sentencias de llamada:

PERFORM, CALL, SUBMIT

Llaman a los bloques de proceso ya definidos desde el mismo programa o desde otros.

Sentencias operacionales:

WRITE, MOVE, ADD

Procesan los datos definidos con sentencias declarativas.

Sentencias de control:

IF, WHILE, CASE

Controlan el flujo de la ejecución dentro de un bloque de proceso de acuerdo a ciertas condiciones.

Sentencias de base de datos:

SELECT, INSERT, DELETE

Utilizan la interfase de base de datos para acceder a las tablas. Pueden pertenecer a Open SQL o a SQL nativo

3.3.1.2 Comentarios Los comentarios son textos que podemos escribir dentro del código de un programa para explicar el propósito de las sentencias que utilizamos. Son muy útiles para nuestra propia compresión del programa y para la de otros usuarios.

Existen dos formas de incluir comentarios en nuestro programa: • Precediéndolos con el carácter asterisco (*) como primer carácter de una línea (en

la columna 1): toda ella se considerará como comentario, el sistema la ignora. • Precediéndolos con una comilla doble (“) en una línea: todo lo que vaya a

continuación, hasta el final de la línea, se considerará comentario, el sistema lo interpreta como espacios en blanco.

DATA: suma TYPE p, “Campo de suma

contador TYPE i.

*Inicializar el campo suma

CLEAR suma.

3.3.2 Funciones de edición Se puede acceder a funciones de edición importantes usando los botones de la barra de herramientas. Éstos incluyen:

Visualizar <-> Modificar

Permite conmutar entre los modos de Visualización y Modificación

ENTER Divide la línea en la posición actual del cursor

Cortar Corta una línea o un bloque seleccionado de texto

Copiar Copia un bloque de texto seleccionado al buffer

Pegar Inserta el contenido del buffer en la posición actual del programa

Anular/Rehacer Deshace la última operación / Rehace la operación deshecha

Buscar/Continuar Busca o reemplaza un texto dentro del código / Continúa la búsqueda

Help Llama a la ayuda online

Página 59 de 195


Carga/Graba Carga el código fuente desde un fichero local / Graba el código fuente en un fichero local

Se puede acceder a todas las funciones del Editor usando la barra de menú.

El Editor ABAP se puede ejecutar en modos de funcionamiento diferentes: • Modo frontend: • Modo Backend: Modo PC con numeración de líneas. Delante de cada línea aparece

su número. Para insertar líneas bastará con pulsar la tecla RETURN. Modo PC sin numeración de líneas. Igual que el anterior pero sin numeración de líneas.

Para obtener ayuda sobre el editor podemos navegar a: Utilidades -> Ayuda para -> Ayuda Editor.

3.3.3 Patrones de instrucciones Tenemos la posibilidad de insertar código con un patrón predefinido, para ciertos elementos del lenguaje (ciertas sentencias, llamadas a procedimientos, llamadas a funciones, etc.). Sólo hay que pulsar el botón después de situarnos sobre la línea de código donde deseamos incluir la instrucción. Aparecerá la siguiente ventana en la que indicararemos el nombre del objeto a insertar:

3.3.3.1 Navegar a objeto Esta función, permite ‘navegar’ hasta el objeto seleccionado. Estos objetos pueden ser variables, procedimientos, símbolos de texto, etc. definidos dentro del propio programa; pero también pueden ser objetos definidos fuera del programa como transacciones, funciones o includes. Generalmente si el objeto al que pretendemos ‘navegar’ no existe, nos dará la posibilidad de crearlo en ese momento.

3.3.3.2 Diseño del programa Para escribir programas de calidad no sólo debemos seguir las convenciones de nomenclatura apropiadas, sino que también debemos guardar ciertas reglas estándar para el diseño de programas ABAP.

Las técnicas que se proponen para mejorar la calidad de los programas incluyen la inserción correcta de comentarios (mejor en líneas separadas para mejorar la legibilidad), el uso de las herramientas de modularización (subrutinas), y la

Página 60 de 195


identificación de los bloques de sentencias. Teniendo en cuenta estas recomendaciones se consiguen programas más legibles, más seguros y más fáciles de probar y cambiar.

El editor de ABAP incluye una herramienta, el Pretty Printer, que nos ayudará a mejorar la apariencia de nuestros programas fácilmente. Para ejecutar esta utilidad

basta pulsar el botón . Se puede configurar su manera de actuar mediante la opción de menú Utilidades->Opciones en la pestaña Editor / Pretty Printer.

3.4 Interacción con el usuario

3.4.1 Pantalla de selección Con la palabra clave PARAMETERS <name> definimos un diálogo de usuario que se llama pantalla de selección.

Las pantallas de selección sirven para solicitar del usuario criterios de selección que se utilizarán para filtrar información en el programa.

Cuando un usuario introduce un valor y ejecuta el programa, el valor se pasa automáticamente a un objeto de datos interno del programa que también tiene por nombre <name>. Sólo se permiten entradas que tengan un formato compatible con el definido en la instrucción PARAMETERS. Se puede definir con referencia a un objeto del Diccionario. REPORT z_parametro.

PARAMETERS pa_carr LIKE spfli-carrid.

Si se ha definido una ayuda de búsqueda en el Diccionario para el campo, el usuario dispondrá del botón F4 para conocer las entradas posibles.

3.4.2 Lista La manera más sencilla de presentar los resultados al usuario es utilizar la sentencia WRITE. Esta instrucción escribe el contenido de un objeto de datos de acuerdo a su tipo en forma de una lista.

Sentencias WRITE consecutivas escriben en la misma línea de salida hasta que está llena; entonces se continua en la siguiente. Se puede utilizar un dato de posición que determine la creación de una nueva línea (/), la longitud de salida del campo o la posición en la que se empieza a escribir dentro de la línea. Se puede escribir en diversos colores.

La lista completa aparece de manera automática cuando el programa finaliza su ejecución.

3.4.3 Mensajes Se utiliza la sentencia MESSAGE para enviar mensajes al usuario.

El comportamiento del sistema después de la aparición del mensaje viene determinado por el tipo de mensaje: de error (E), de información (I) o de aviso (W). El comportamiento depende de la pantalla donde aparece el mensaje.

Cada sentencia ABAP llena el valor de la tabla de sistema SY-SUBRC con un código de retorno que indica el éxito o fracaso de la instrucción. En general SY-SUBRC=0 indica que ha funcionado correctamente. Podemos hacer aparecer un mensaje en función de estos códigos de retorno…

Página 61 de 195


3.5 Interacción con la base de datos El lenguaje ABAP contiene un conjunto de sentencias llamado Open SQL. Las sentencias de Open SQL son un subconjunto de las sentencias SQL estándar que han sido modificadas especialmente para SAP. Se utilizan para acceder a la base de datos independientemente de cual sea el sistema gestor (RDBMS).

La sentencia más importante es SELECT. Lee ciertas columnas de ciertos registros de una tabla de la base de datos. Las tablas a las que queremos acceder en un programa deben pertenecer al Diccionario. DATA wa_spfli LIKE spfli.

...

SELECT SINGLE carrid connid cityfrom cityto

FROM spfli

INTO CORRESPONDING FIELDS OF wa_spfli

WHERE carrid = sdyn_conn-carrid

AND connid = sdyn_conn-connid.

Aquí se leen ciertas columnas de un registro concreto de la tabla spfli y se insertan en los campos del mismo nombre de la estructura wa_spfli.

3.6 Operaciones con programas Hay varias operaciones en el Navegador del Repositorio que se utilizan para editar cualquier objeto. Las más comunes usadas con programas son las siguientes:

Cambiar Edita un programa

Verificar Comprueba la sintaxis de un programa

Test Lanza y prueba un programa

Borrar Borra un programa

Copiar Copia un programa

Renombrar Renombra un programa

3.6.1 Verificación de sintaxis Para comprobar que el programa no tiene errores de sintaxis utilizaremos el botón de

verificar (Ctrl. + F2). Para verificar que no contiene errores de manera ampliada utilizaremos la opción de menú ‘Programa Verificar Verif. programa ampliada’. Nos llevará a la siguiente

pantalla, pulsaremos el botón para continiuar con la verificación.

Página 62 de 195


Página 63 de 195

3.6.2 Activación Para activaremos un programa y así hacerlo visible para el resto de componentes del

sistema utilizaremos la opción ‘Programa Activar’ o (Ctrl. + F3).

3.6.3 Ejecución Desde el editor, podemos ejecutar un programa. Para ello seleccionamos la opción de l menú ‘Programa Verificar’ o (F8).

3.7 Debugging La herramienta de debugging está pensada para encontrar errores semánticos en los programas. Para poder depurarlos, los ejecutamos pasando por las líneas del código escrito y viendo el resultado de cada una de ellas de forma individual, de esta forma podemos comprobar el efecto de cada una de las instrucciones escritas.

Hay diversas maneras de arrancar el ABAP Debugger.

• Desde el Object Browser, pulsando Test/Execute

• Desde el Editor ABAP, pulsando Debugging

• Desde la transacción que deseemos analizar, introduciendo /h en el campo de comandos donde introducimos las transacciones.

• Desde cualquier pantalla escogiendo en el menú Sistema->Utilidades->Debugging.

• Insertando breakpoints en el código y ejecutando después el programa.


Página 64 de 195

3.7.1 Pantalla La pantalla de Debugger tiene dos partes. En la superior se muestra el código del programa. En la inferior se muestra información adicional que depende de la vista que escojamos. Se pueden usar los botones de la parte superior para alternar entre las diferentes vistas.

Se puede expandir el área de código fuente escogiendo la función “Expandir código fuente”. Si se hace doble-click en una línea se visualiza ésta como primera de la pantalla.

En la vista de “Campos” hay una lista de hasta 8 campos, 4 de los cuales son visibles en todo momento. Nos podemos mover para visualizar el resto. Para que un campo aparezca en esta lista basta con hacer doble-click sobre su nombre en el código.

El icono indica la línea actual de programa (próxima instrucción a ejecutarse).

El icono indica que en esa línea de código hay un breakpoint.

3.7.2 Funciones importantes F5 Paso a paso Procesar la línea actual del programa.

Si es un procedimiento pasa a la primera línea de éste.

F6 Ejecutar Procesar la línea actual, todos los pasos correspondientes. Si es un procedimiento lo trata como una única sentencia.

F8 Continuar Continuar procesando hasta el siguiente breakpoint o hasta el fin del


programa,

F7 Entrar en procedimiento

Volver Vuelve al nivel superior de la jerarquía de llamadas para seguir procesando. Si no hay breakpoints, finalizamos la ejecución del procedimiento donde estamos.

F2 en línea Breakpoint Fijar un punto de ruptura en una línea

para conseguir que la ejecución se detenga en ella.

Watchpoint Permite interrumpir el proceso en función del valor de ciertas variables.

F2 en campo

Doble-click Ver el contenido de una variable en el marco de variables.

Replace Permite cambiar el contenido de un campo durante la sesión de debugging.

Podemos ver el contenido de tablas internas complejas y expandirlas con un doble-click.

Print Podemos mostrar resultados.

Datasets Estado de los ficheros

Reanudar Salir del debugger sin ejecutar el código.

3.7.3 Breakpoints Hemos visto que para fijar un breakpoint en una línea basta con hacer doble-click sobre ella. Aparece un símbolo de STOP delante de ella. Podemos ver la lista de todos los breakpoints del programa que estamos depurando con el botón “Breakpoints”.

Para borrar un breakpoint se puede volver a hacer doble-click sobre la línea o bien utilizar la opción de menú Breakpoint->Set/Delete.

Otra manera de fijar breakpoints en una línea es utilizar la sentencia BREAK-POINT dentro del código del programa. A parte de los breakpoints en líneas, podemos fijar puntos de ruptura en todas las líneas que contengan una cierta sentencia, o en ciertos eventos o en subrutinas. Para ello utilizamos la opción de menú.

Los Watchpoints son breakpoints basados en que haya cambios en el contenido de un campo o en que el campo tome cierto valor igual a otro campo o a una constante.

Página 65 de 195


4 Tipos de Datos y Objetos de Datos Los objetos de datos son las unidades físicas que un programa utilizará en tiempo de ejecución y, son tiras de bytes en el área de memoria del programa. Las sentencias ABAP acceden a su contenido utilizando su nombre. Las sentencias pueden, por ejemplo, escribir el contenido de un objeto de datos en una lista o en la base de datos, pueden pasarlo a una subrutina, pueden cambiarlo asignándole un nuevo valor o pueden compararlo en una expresión lógica.

Cada objeto de datos tiene un conjunto de atributos técnicos que son: el tipo de datos, la longitud y el número de posiciones decimales. El tipo de datos determina como serán interpretados los contenidos de un objeto por las sentencias ABAP.

Los tipos de datos existen como descriptores de las propiedades técnicas de los objetos de datos. Pero se pueden definir también de manera independiente y después se pueden utilizar enlazándolos a un objeto de datos. No se reserva espacio en memoria para ellos, son sólo descripciones. Pueden ser predefinidos o definidos por el usuario.

Los tipos de datos y los objetos de datos ocupan dos rangos de nombres diferentes, es decir, podemos utilizar un mismo nombre para un tipo de datos y para un objeto de datos.

4.1 Tipos de datos

4.1.1 Predefinidos En ABAP hay ocho tipos de datos predefinidos, tres de ellos (P,I,F) numéricos y cinco alfanuméricos (N,C,D,T,X):

Tipo Descripción V. Inicial Longitud defecto

Rango valores/

Longitud permitida

Utilidad

P Empaquetado 0 8 Máximo 16 bytes, 2 dígitos por byte, el último medio byte se usa para el signo.

Cantidades de dinero, longitudes, pesos

I Entero (Integer)

0 4 -2^31 a +2^31-1 Contadores, cantidades, índices, periodos de tiempo

F Coma flotante (Floating point)

0 8 -1E-307 a +1E308 Cálculos matemáticos, números muy grandes o muy pequeños

N Numeric Text 0...0 1 1 a 65535 Números en forma de texto

C Texto (Char) Blancos 1 1 a 65535 Cadena de caracteres

D Fecha (Date) 00000000 8 8 (AAAMMDD). Pasando Sumar días,

Página 66 de 195


a P es el número de días desde 01/01/1990.

calcular períodos.

T Hora (Time) 000000 6 6 (hhmmss) Hora: se pueden sumar/restar

X Hexadecimal x'0…0' 1 1 a 65535 Valor Hexa.

Observaciones:

Los cálculos con el tipo numérico I son los más económicos, seguidos de los tipos F y P. Con números de tipo F se pueden dar errores de aproximación, por ello no se deben comparar nunca dos campos de tipo F para ver si son iguales, sino que se aconseja comprobar que su diferencia no supera una cierta tolerancia. Sólo se deben usar estos números para cálculos matemáticos que admitan errores de aproximación; para cálculos de negocio, utilizar siempre el tipo P.

4.1.2 Definidos por el usuario Para definir tipos de datos en un programa se utiliza la palabra clave TYPES. Se puede hacer referencia:

• a un tipo predefinido o a otro tipo definido por el usuario con la palabra TYPE.

• a el tipo de un objeto de datos del programa o de un objeto del Diccionario usando la palabra LIKE.

TYPES <tipo>[(<longitud>)] TYPE <tipo_ant>.

TYPES <tipo> LIKE <objeto>.

Los nombres asignados a los tipos creados por el usuario pueden tener, como máximo, 30 caracteres (letras, números y “_”) que no pueden ser todos numéricos. Se recomienda empezar siempre por una letra y utilizar el “_” como separador si combinamos palabras en el nombre. TYPES: tipo_entero TYPE i,

fecha LIKE sflight-date,

nombre1(25),

tipo_empaquetado_2_dec Type P Decimals 2.

Si no se especifica tipo, se utiliza el tipo C. Si no se especifica longitud, se utiliza la estándar para el tipo de datos referenciado. Se puede especificar el número de posiciones decimales para el tipo P (hasta 14).

Los tipos definidos por el usuario pueden ser elementales o estructurados.

Los tipos elementales se basan en los tipos predefinidos o en otros tipos elementales. Permiten definir objetos de datos elementales que se pueden utilizar para transferir valores de entrada y de salida, como campos auxiliares en cálculos o para almacenar resultados intermedios.

Los tipos estructurados están compuestos por una secuencia de tipos elementales o de otros tipos estructurados. Se pueden anidar. Sirven para gestionar y procesar datos relacionados semánticamente bajo un único nombre. Permiten definir objetos de datos a los que se puede acceder como un todo o por sus componentes individuales. No existen tipos estructurados predefinidos, se deben definir en el programa o en el Diccionario.

Dentro de los tipos estructurados debemos diferenciar los tipos de estructura y los tipos de tabla. Los primeros están formados por componentes de cualquier tipo,

Página 67 de 195


mientras que los segundos están formados por líneas del mismo tipo (cualquiera que sea). TYPES: BEGIN OF <tipo>,

...

END OF <tipo>.

TYPES: <tipo> TYPE <tipo_estructurado>.

Los componentes de la estructura se definen dando el tipo y longitud deseados.

El estudio de los tipos de tabla interna lo aplazamos a un tema posterior.

Ver programa de ejemplo DEMO_TYPES_STATEMENT

4.1.3 Grupos de tipos En vez de definir tipos en un programa, se pueden definir en el Diccionario mediante los grupos de tipos. A estos objetos se les asigna un nombre de hasta 5 caracteres y a los tipos que contienen se les deben poner nombres que comiencen con estos mismos caracteres y un “_”. TYPE-POOL zmit.

TYPES: zmit_nombre(25),

Zmit_numero TYPE i.

Para usar las definiciones de tipos contenidas en el grupo en un programa ABAP se debe utilizar la sentencia TYPE-POOLS. REPORT zmireport.

TYPE-POOLS zmit.

DATA: nombre TYPE zmit_nombre.

...

4.1.4 Visibilidad Cuando hacemos referencia a los tipos de datos con la opción TYPE, debemos tener en cuenta su visibilidad:

Los tipos de datos predefinidos de ABAP C, D, F, I, N, P T, y X son siempre visibles. No podemos definir tipos de datos locales que se llamen igual en nuestros programas.

Los tipos de datos definidos en los procedimientos ocultan los tipos de datos que se llamen exactamente igual que hayan sido declarados en la parte global del programa.

Los tipos de datos locales ocultan a los tipos de datos que se llamen exactamente igual del Diccionario de datos.

El siguiente gráfico muestra la visibilidad de los tipos de datos que son locales en un programa determinado y los tipos de datos del Diccionario de ABAP:

Página 68 de 195


Página 69 de 195

El sistema busca de dentro hacia fuera. Si el TIPO1 está especificado mediante la opción TYPE en un programa, se utilizará el tipo del Diccionario tanto en sus procedimientos como en el programa principal. Si se especifica TIPO2 en un procedimiento, se utilizará el tipo local definido en el procedimiento. Si TIPO2 se especifica en el programa principal, se utilizará el tipo del programa principal, ya que el TIPO2 del Diccionario es invisible. Si se especifica TIPO3 en el programa principal, se utilizará el tipo del programa principal tanto en los procedimientos como en el programa principal, ya que el TIPO3 del Diccionario es invisible.

4.2 Objetos de datos Los objetos de datos pueden ser constantes o variables: el valor de los primeros no puede ser modificado durante la ejecución del programa, el de los segundos sí.

Decimals Número de decimales para un campo.

4.2.1 Variables Para declarar los objetos de datos variables se utiliza la palabra clave DATA. Para definir el tipo del objeto tenemos las mismas opciones que cuando definimos los tipos de datos: • Si lo declaramos de algún tipo predefinido por el sistema o definido por nosotros

mismos utilizaremos la palabra TYPE. • Si lo queremos declarar en referencia a otro campo, ya sea del Diccionario de datos

o uno propio definido con anterioridad en el programa, utilizaremos la palabra LIKE.

Si no se especifica el tipo, se usa el tipo predefinido C. Si no se especifica longitud se utiliza la que corresponde al tipo por defecto. Se puede indicar el número de posiciones decimales con DECIMALS para objetos del tipo P.

La novedad es que podemos indicar un valor inicial para los objetos de datos variables usando la palabra VALUE y a continuación un valor fijo. Si no se utiliza esta opción el objeto tendrá el valor inicial correspondiente a su tipo de datos. DATA <objeto> TYPE <tipo> [VALUE <literal>].


DATA <objeto2> LIKE <objeto1> [VALUE <literal>].

Los nombres de los objetos de datos pueden ser de hasta 30 caracteres (letras, dígitos y caracteres especiales). Los únicos caracteres que no se permiten son () + . , y :. SPACE es un objeto de datos predefinido. TYPES TC3(3) TYPE C.

DATA D1(3) TYPE C. “Predefinido

DATA D2(3) TYPE C VALUE ‘ABC’. “Predefinido

DATA D3 TYPE TC3. “Definido por el usuario

DATA D4 TYPE TC3 VALUE ‘DEF’. “Definido por el usuario

DATA D5 LIKE D4.

DATA D6 LIKE SY-DATUM.

Existen una serie de objetos de datos que están disponibles de forma automática y que no necesitan ser declarados: son los campos del sistema, de la tabla SYST. Podemos utilizarlos en cualquier parte de cualquier programa. SY-SUBRC, SY-DBCNT, SY-REPID, SY-DATUM, SY-UZEIT,…

De manera análoga a los tipos de datos, los objetos de datos también pueden ser elementales o estructurados, y los estructurados pueden ser estructuras (varios objetos componentes o campos) o bien tablas internas (varias líneas con idéntica estructura). DATA: BEGIN OF <estructura>,

…,

END OF <estructura>.

DATA: TABLES <estructura del Diccionario ABAP>

Para acceder a los campos individuales de una estructura en el programa se utiliza el nombre de la estructura seguido de un guión y el nombre del campo.

Ver programa de ejemplo DEMO_STRUCTURE

Las tablas internas las estudiaremos en un tema aparte.

Ejemplos: * Esto es una variable:

DATA CONTADOR TYPE NUMERO.

* Esto es un vector:

DATA:BEGIN OF REUNION,

HORA_INICIO TYPE T,

HORA_FIN TYPE T,

END OF REUNION.

*Defino con referencia a un campo de sistema

DATA HORA_ACTUAL LIKE SY-UZEIT.

4.2.2 Constantes y literales El contenido de un objeto de datos constante no variará durante toda la ejecución del programa. Se definen utilizando la sentencia CONSTANTS y la palabra VALUE es obligatoria para especificar el valor que tiene la constante. Solamente se pueden definir constantes para los tipos de datos, P, I, N, C. CONSTANTS <constante> LIKE/TYPE <tipo_o_campo> VALUE <’valor’>.

Página 70 de 195


Ejemplo: CONSTANTS C_PI TYPE P DECIMALS 5 VALUE ‘3.14159’.

Los literales en ABAP pueden ser de dos tipos: numéricos o de texto.

Los literales de texto se deben escribir entre comillas (‘texto’) y pueden tener hasta 255 caracteres. Para escribir una comilla, hay que ponerla dos veces.

Los símbolos de texto que vimos con anterioridad como elementos de un programa ABAP, son también literales de texto. Tienen la ventaja de que pueden incluir las traducciones a cualquier idioma, y de que se almacenan separadamente del código para facilitar el mantenimiento. Se accede a ellos poniendo TEXT-<xxx>.

Los literales que son números enteros se guardan con tipo I (hasta 9 dígitos) o con tipo P (a partir de 10 dígitos). Los números con decimales o de punto flotante se guardan como texto y después el procesador ABAP los convierte si es necesario.

4.2.3 Parámetros y selecciones También son objetos de datos dentro del programa. Se asemejan en el hecho de que utilizan las palabras TYPE y LIKE para definir el tipo. La diferencia entre las sentencias PARAMETERS y DATA es que los campos declarados con la primera aparecen en la pantalla de selección para que el usuario pueda introducir un valor. Otra diferencia es que para especificar un valor inicial para un parámetro se utiliza la palabra DEFAULT en vez de VALUE.

4.2.4 Tablas Con la sentencia TABLES se declara un objeto de datos interno que se utiliza cuando hay campo de pantalla que se refieren a campo de la tabla declarada. Define un área de trabajo en el programa para los datos que el usuario entra en pantalla o que el programa pasa a la pantalla.

4.2.5 Rangos Permiten almacenar conjuntos de valores de una forma normalizada, análoga a la utilizada en los SELECT-OPTIONS. Para declarar estos objetos se utiliza la palabra clave RANGES: RANGES <rango> FOR <campo>.

4.2.6 Atributos de objetos Para determinar la longitud, tipo y longitud de salida de un campo, utilizaremos la sentencia:

DESCRIBE FIELD <campo> [LENGTH <l> [TYPE <t>] [OUTPUT-LENGTH <o>] [DECIMALS <d>].

Para determinar la cantidad de líneas y el atributo occurs de una tablas utilizaremos la sentencia:

DESCRIBE TABLE <tabla> [LINES <líneas>]/ [OCCURS <atrib_occurs>].

Página 71 de 195


4.3 Field symbols Un field symbol es un puntero a un campo existente en tiempo de ejecución (son comparables a los punteros del lenguaje C).

Este tipo de datos se utiliza cuando no sabemos qué campo hemos de procesar en tiempo de ejecución.

Los fields symbols tienen una serie de características que los hacen muy flexibles: • Puede especificarse la posición y longitud del campo asignado por medio de una

variable. • Se puede asignar un field symbol a otro field symbol especificando posición y

longitud. • Un field symbol puede tener una estructura que se puede usar para apuntar a

componentes individuales de estructuras.

Para definir un field symbol usaremos:

FIELD-SYMBOLS <fs> [<TYPE>|<LIKE>]... En este caso, los caracteres ‘<’ y ‘>’, forman parte del nombre del field symbol.

Para asignar un objeto de datos de forma dinámica al field symbol, usaremos:

ASSIGN (<f>) TO <fs>. Ejemplo: REPORT ZPRUEBA.

DATA: MES(2) TYPE n,

CAMPO(15) TYPE c.

DATA: BEGIN OF PRIMAVERA,

MES04(5) TYPE c VALUE 'ABRIL',

MES05(5) TYPE c VALUE 'MAYO',

MES06(5) TYPE c VALUE 'JUNIO',

END OF PRIMAVERA.

FIELD-SYMBOLS: <MES_PRIMAVERA>

CAMPO = 'PRIMAVERA-MESXX'.

MES = 4.

WRITE / 'MESES DE PRIMAVERA:’.

WHILE ( MES <= 6 ).

CAMPO+13(2) = MES.

ASSIGN (CAMPO) TO <MES_PRIMAVERA>.

WRITE / <MES_PRIMAVERA>.

ADD 1 TO MES.

ENDWHILE.

Este programa mostraría lo siguiente en pantalla: MESES DE PRIMAVERA:

ABRIL

MAYO

JUNIO

Página 72 de 195


5 Procesamiento de Datos

5.1 Asignación y conversión Existen diversas sentencias ABAP con las que se pueden asignar valores a objetos de datos. La más importante es la sentencia MOVE. Funciona tanto para copiar objetos elementales como para copiar estructuras y tablas complejas.

Si la estructura de un objeto de datos no se corresponde con la del valor que les queremos asignar, se ejecutan ciertas reglas de conversión.

Los tipos compatibles pueden ser asignados sin conversión. Dos tipos elementales son compatibles si son idénticos en tipo y longitud (y número de decimales si son P). Dos tipos estructurados son compatibles si tienen la misma estructura y sus componentes son compatibles. Dos tablas son compatibles si sus tipos de línea son compatibles.

En el resto de casos se aplica una regla de conversión, si se ha definido para los tipos involucrados. Existen reglas para todos los tipos predefinidos, excepto entre T y D).

Los objetos de tipo C se almacenan alineados a la izquierda. Se rellena con espacios en blanco si el campo destino es demasiado largo, se trunca si el campo destino es demasiado corto.

Cuando se convierte un tipo C a tipo P sólo se permiten dígitos, un signo (+ o -) y un punto decimal.

Cuando se convierte un tipo P a C los ceros iniciales se convierten en espacios.

Type Lenght Value Type Lenght Value

C 1 A C 4 A___

C 4 ABCD C 2 AB

C 7 -47110 P 4 47110-

P 3 12345- C 7 12345-

C -47.110 P 47.11-

Hay también reglas para convertir: field strings en field strings, campos elementales en field strings, field strings en campos elementales.

Se pueden transportar valores entre estructuras, campo por campo, con la sentencia MOVE-CORRESPONDING. Sólo funciona si los campos que interesa copiar tienen los mismos nombres. El sistema busca todos los campos de la primera estructura <estr_1> cuyo nombre también aparece en la segunda <estr_2> y transporta <estr_1>-<nombre_campo> a <estr_2>-<nombre_campo> en los casos en que hay correspondencia. El resto de campos permanecen inalterados.

5.1.1 Sub-campos Se puede acceder y cambiar sub-areas de campos elementales especificando la posición y longitud del fragmento. Con algunas sentencias (MOVE, ASSIGN, WRITE TO,…) se pueden dar la posición y la longitud como variables.

Página 73 de 195


5.1.2 Inicialización Usamos la sentencia CLEAR para devolver a un objeto de datos el valor inicial correspondiente a su tipo. En las estructuras se inicializa cada uno de los campos que la componen.

Prescinde del valor que pudiéramos haber asignado inicialmente con la palabra VALUE.

5.2 Operaciones Numéricas

5.2.1 Aritméticas La sentencia para realizar cálculos tiene el siguiente formato: [COMPUTE] <campo> = <expresión aritmética>

La palabra clave COMPUTE es opcional.

En la expresión aritmética, los paréntesis y los operadores (+, -, *, / ) cuentan como palabras y por tanto se deben separar del resto mediante espacios. En cambio cuando el paréntesis se usa para indicar un parámetro de una función matemática debe ir junto al nombre de la función. Se pueden anidar expresiones con paréntesis hasta el nivel de profundidad que se quiera.

Hay una aritmética separada en el procesador ABAP para cada tipo de datos I, P, F. En una expresión se utiliza sólo una de las tres; para determinarla se mira cuál es el tipo más amplio en la secuencia I-P-F.

Los valores no numéricos son convertidos a numéricos antes de realizar la operación aritmética.

Los operadores DIV y MOD devuelven enteros (Ver documentación de compute).

STRLEN devuelve en un entero la longitud de una cadena.

Se pueden usar las palabras ADD, SUBSTRACT, MULTIPLY y DIVIDE para operaciones aritméticas sencillas.

- Add-corresponding, Subtract- corresponding, Multiply- corresponding, Divide- corresponding

5.3 Cadenas de caracteres Ver programa DEMO_DATA_STRING.

5.3.1 Concatenate Concatena un número de variables n en una variable destino.

Ex : Concatenate one two three into target [separated by space].

Target = I Like Abap/4.

Valores de error en la variable de sistema Sy-Subrc:

0 = Resultado satisfactoria.

4 = El resultado es demasiado largo solo se transferirán hasta la longitud definida.

5.3.2 Split Separamos un string, en varias variables de tipo C, separadas por espacios.

Ex: Split Target at space into one two three.

Página 74 de 195


Valores de error en la variable de sistema Sy-Subrc:

0 = Resultado satisfactorio.

4 = Uno de los campos destino no tiene la longitud suficiente

5.3.3 Shift

5.3.4 Replace

5.3.5 Condense

5.3.6 Translate

5.3.7 Overlay

5.3.8 Search

Página 75 de 195


6 Control del Flujo del Programa

6.1 Expresiones lógicas

6.1.1 Comparaciones EQ = Igual

NE <> No igual

GT > Mayor que

GE >=,=> Mayor o igual que

LT < Menor que

LE <=,=< Menor o igual que

BETWEEN f1 AND f2 Intervalo

IS INITIAL Valor inicial, es decir, blancos ó 0

Se pueden combinar expresiones lógicas con las palabras NOT, AND y OR. Se pueden anidar hasta el nivel deseado. Los paréntesis que marcan las subexpresiones se consideran palabras y deben ir separadas del resto por espacios.

6.1.2 Comparación de Strings Si se comparan campos de tipo C con longitud diferente el más corto se alarga hasta la del más largo antes de comparar. Se rellena desde la derecha con espacios.

6.2 Distinción de casos Las sentencias IF y CASE permiten hacer distinción de casos. Se pueden anidar.

6.2.1 If IF <expresión_lógica>

[bloque de sentencias]

ELSEIF <expresión_lógica>


ELSEIF <expresión_lógica>


ELSE.


ENDIF.

Si la expresión lógica se cumple, el bloque de sentencias situado en el interior se ejecuta. Si no se cumple se procesa el bloque de las sección ELSE o ELSEIF. Si no existen estas sentencias (son opcionales) se continúa la ejecución del programa.

Se puede incluir cualquier número de sentencias ELSEIF entre el IF y el ENDIF. Como máximo se ejecutará uno de los bloques.

Página 76 de 195


6.2.2 Case CASE <objeto>.

WHEN <objeto1>.


WHEN <objeto2> OR <objeto3>.


WHEN OTHERS.


ENDCASE.

Sólo uno de los bloques de sentencias se ejecuta. La sentencia WHEN OTHERS es opcional.

6.3 Bucles Como en otros lenguajes de programación, en ABAP se pueden realizar bucles con las palabras DO y WHILE. Se pueden anidar bucles.

El campo de sistema SY-INDEX tiene el valor 1 durante el primer paso del bucle y es incrementado en 1 a cada nuevo paso. El número de pasos no puede ser alterado mediante la modificación de este campo dentro del bucle.

6.3.1 Do DO [(n) TIMES].


ENDDO.

El parámetro (n) TIMES es opcional. Si no lo especificamos necesitaremos una instrucción para salir del bucle (ver Finalizar bucles).

6.3.2 While WHILE <expresión_lógica>.


ENDWHILE.

Se ejecuta el bloque de sentencias mientras se cumpla la expresión lógica.

6.4 Finalizar bucles

6.4.1 Continue

6.4.2 Check Si chequeamos una expresión lógica dentro de un bucle y es falsa, las sentencias siguientes no se ejecutarán y se salta a la siguiente vuelta. Si la expresión es cierta la instrucción no tiene efecto alguno.

Si por el contrario estamos dentro de una subrutina, chequeamos y el resultado es falso, saldremos de la subrutina.

Página 77 de 195


6.4.3 Exit En un bucle esta sentencia nos sacará del bucle. En una subrutina finalizará la ejecución de ésta.

Página 78 de 195


7 Pantalla de Selección La pantalla de selección es la parte del programa que nos permite diseñar la interfase interactiva de entrada de datos por parte del usuario.

Los datos introducidos por el usuario se pueden usar en el programa para filtrar la información de manera que sólo se procese aquella que cumpla con los criterios definidos en la pantalla de selección. Por ejemplo, si el programa crea una lista a partir de los datos de una tabla con muchos registros, el usuario puede entrar intervalos para algún campo clave y sólo los datos que estén en este rango son leídos y mostrados en la lista. Así se reduce considerablemente la carga del sistema.

Para poder entrar selecciones que reduzcan la cantidad de datos que de deben tratar existen los siguientes objetos de datos especiales: PARAMETERS que definen campos simples de entrada SELECT-OPTIONS con los que definimos selecciones más complejas: múltiples

valores, intervalos, valores excluidos, etc.

Con estas dos instrucciones podemos generar una pantalla de selección estándar para un programa ejecutable (la pantalla 1000). Se pueden generar otras pantallas de selección adicionales con SELECTION-SCREEN BEGIN OF SCREEN<nnn> y se las puede llamar con CALL SELECTION-SCREEN.

Los textos que aparecen en la pantalla de selección al lado de los campos de entrada son, por defecto, los nombres de las variables. Pero se pueden introducir textos más explicativos y traducirlos a diferentes lenguajes. Así se mostrarán en el lenguaje usado por el usuario en la conexión.

El sistema comprueba que los datos introducidos tienen un formato correcto; si el tipo no corresponde con el definido para el campo se mostrará un mensaje de error y el campo estará preparado para que se corrija la entrada. Si un campo de entrada se define con referencia a un campo del diccionario, se puede utilizar la ayuda de búsqueda que le corresponde pulsando F4.

Se pueden crear variantes para cualquier pantalla de selección. Son conjuntos de valores preasignados para los parámetros de entrada que se pueden grabar y reutilizar posteriormente.

7.1 Parameters Recogen un único valor como criterio de selección. Cuando el usuario introduce un valor en el parámetro de pantalla y ejecuta el programa, el valor se pasa al objeto de datos interno correspondiente.

Para incluir parámetros de selección en la pantalla de selección pondremos en el código del programa la palabra clave PARAMETERS seguida del nombre de parámetro y su tipo.

La forma de la sentencia es: PARAMETERS <parámetro>[(<long>)] [TYPE <tipo>] [DECIMALS <n>] [LIKE <f>]

[OBLIGATORY] [DEFAULT <valor>]

[AS CHECKBOX]

[RADIOBUTTON GROUP <grupo>].

Visualizaremos y ejecutaremos el programa DEMO_SELECTION_SCREEN_BASIC:

Página 79 de 195


La sentencia es declarativa, crea un objeto de datos. Como en el caso de la sentencia DATA podemos especificar el tipo del campo con TYPE o con LIKE.

El nombre del parámetro puede contener como máximo 8 caracteres.

7.1.1 Activación de parámetro obligatorio Opción: OBLIGATORY.

Cuando utilizamos esta opción, aparecerá una interrogación en el campo de entrada. El usuario no podrá abandonar la pantalla de selección hasta que no introduzca un valor para este campo.

7.1.2 Asignación de valores por defecto Opción: DEFAULT <valor>.

Para declarar valores iniciales de un parámetro se utiliza la palabra DEFAULT. Después podemos asignar el valor de estos parámetros a otras variables. <valor> puede ser un literal o el nombre de un campo.

También se puede asignar un valor inicial con la opción MEMORY ID <pid>. De esta manera se utiliza la memoria SAP y los parámetros SET/GET para poner un valor por defecto.

7.1.3 Supresión de la visualización Opción: NO-DISPLAY.

Se utiliza para suprimir la visualización de un parámetro en la pantalla de selección

Nota: Esta opción NO se puede utilizar junto con otras opciones.

7.1.4 Permitir mayúsculas y minúsculas como entrada Opción: LOWER CASE.

Si no utilizamos la opción LOWER CASE, la entrada introducida por el usuario se convertirá automáticamente a mayúsculas. Con esta opción, el parámetro se quedará tal y como lo tecleó el usuario.

7.1.5 Parámetro con apariencia de checkbox Opción: AS CHECKBOX.

Crea un campo de un carácter que puede contener un espacio en blanco o una ‘X’. Podremos evaluarlo durante el procesamiento dentro del programa.

Si añadimos DEFAULT ‘X’ el checkbox aparecerá marcado.

Página 80 de 195


Ejemplo: PARAMETERS:

A AS CHECKBOX,

B AS CHECKBOX DEFAULT X.

En este ejemplo, aparecerán dos checkbox en la pantalla de selección:

7.1.6 Parámetro con apariencia de radiobutton Opción: RADIOBUTTON GROUP <grupo>.

La máxima longitud para el nombre <grupo> es 4. El parámetro será de tipo C y longitud 1.

Sólo uno de los botones de un grupo puede estar activo.

Si añadimos DEFAULT ‘X’ el radiobutton aparecerá marcado.

Ejemplo: Diseñar una pantalla con 2 posibles grupos de selección de cada característica para el pelo. La primera característica es color(moreno, rubio) y la segunda su textura (liso, rizado, muy rizado). PARAMETERS:

C_MORENO RADIOBUTTON GROUP COLO,

C_RUBIO RADIOBUTTON GROUP COLO,

T_LISO RADIOBUTTON GROUP TEXT,

T_RIZADO RADIOBUTTON GROUP TEXT,

T_M_RIZA RADIOBUTTON GROUP TEXT.

Este ejemplo aparecería así en la pantalla de selección:

7.1.7 Asignación de ayudas de búsqueda Opción: MATCHCODE OBJECT <ayuda_de_búsqueda> …

El nombre de la ayuda de búsqueda no debe ir entre comillas. Utilizaremos esta opción cuando la ayuda de búsqueda no esté enganchada directamente a un campo.

7.2 Select-options Los criterios de selección se utilizan para que el usuario pueda realizar selecciones complejas para un campo. En la pantalla de selección aparecen dos campos de entrada del mismo tipo, de manera que el usuario puede introducir un rango de valores.

Se definen poniendo la palabra clave SELECT-OPTIONS seguida del nombre del rango de selección y el campo al que hace referencia. Su sintaxis es:

Página 81 de 195


SELECT-OPTIONS <tabla_selección> FOR <campo>.

El sistema chequeará las entradas de selección contra el campo que aparece después del FOR. Este campo debe estar definido en una sentencia DATA o TABLES. Los dos campos que aparecen en pantalla tienen los mismos atributos técnicos que éste.

Este tipo de parámetros se guardan dentro del programa en unas tablas internas con una estructura estándar, que permite crear conjuntos de valores de una forma normalizada. Los campos que la forman son: • SIGN: C(1). Campo que designa si el valor o intervalo es incluido o excluido de la

selección (I = inclusión, E = exclusión). • OPTION: C(2). Contiene el operador que puede ser

• EQ = igual, • NE = no igual, • GT = mayor que • GE = mayor o igual que • LE = menor o igual que • LT = menor que, • BT = entre, • NB = no entre, • CP = contiene patrón. • NP = no contiene patrón.

• LOW: Su tipo de datos es el mismo que el del parámetro. Si HIGH está vacío, el contenido de LOW define un único valor. En caso contrario, especifica el límite inferior de un intervalo.

• HIGH. Su tipo de datos es el mismo que el del parámetro. Especifica el límite superior de un intervalo.

Los campos sign y option se llenan por defecto con I y EQ para valores individuales y con I y BT para intervalos.

Cuando el usuario introduce diversos valores o intervalos de selección y ejecuta el programa, el sistema coloca los valores en esta tabla interna.

Existe una variante especial de la cláusula WHERE de las selecciones a la base de datos que permite utilizar esta tabla interna como posibles valores de un campo.

7.2.1 Asignación de valores por defecto Sintaxis: SELECT-OPTIONS <parámetro> FOR <campo> DEFAULT <g> [TO <h>]…

<g> y <h> deben ser literales (entre comillas simples) o los nombres de campos que contengan el valor con el queremos inicializar el parámetro. Sólo se puede inicializar la primera línea de la tabla de selección con los valores por defecto. • Para inicializar el campo LOW usar … DEFAULT <g>. • Para inicializar los campos LOW y HIGH, usar DEFAULT <g> TO <h>. • Para inicializar el campo OPTION añadiremos:

DEFAULT <g> [TO <h>] OPTION <op>. • Para inicializar el campo SIGN, añadiremos:

DEFAULT <g> [TO <h>] [OPTION <op>] SIGN <s>. Para poder inicializar más de una línea de la tabla del SELECT-OPTIONS tendremos que utilizar el evento INITIALIZATION.

Página 82 de 195


7.2.2 Supresión de la visualización Opción: NO-DISPLAY.

7.2.3 Permitir mayúsculas y minúsculas como entrada Opción: LOWER CASE.

Si no utilizamos la opción LOWER CASE, la entrada introducida por el usuario se convertirá automáticamente a mayúsculas. Con esta opción, el parámetro se quedará tal y como lo tecleó el usuario.

7.2.4 Asignación de ayudas de búsqueda Opción: MATCHCODE OBJECT <ayuda_de_búsqueda>.

El nombre de la ayuda de búsqueda no debe ir entre comillas y puede tener como máximo 4 caracteres

7.2.5 No permitir múltiples valores Opción: NO-EXTENSION.

Suprime el botón de selecciones múltiples.

7.2.6 No permitir intervalos Opción: NO-INTERVALS.

Suprime la entrada de límite superior de la pantalla de selección, pero se puede usar el botón de selecciones múltiples para introducir intervalos.

7.3 Asignación de descripciones a los campos de la pantalla de selección

Cuando definimos un parámetro (PARAMETER) o un criterio de selección (SELECT-OPTIONS) en la pantalla aparece únicamente el nombre que le hayamos dado al parámetro.

Por ejemplo, si definimos el campo siguiente: PARAMETER: P_MATERI LIKE MARA-MATNR.

En la pantalla de selección nos aparecería lo siguiente:

El nombre del campo no es demasiado descriptivo y esto puede confundir al usuario.

Para asignar una descripción a un campo de la mañana, desde el editor seleccionaremos la siguiente opción del menú Pasar a ⇒ Elementos de texto ⇒ Textos de selección. En la pantalla que aparece a continuación podemos incluir una descripción para los campos de la pantalla de selección de hasta 30 caracteres.

Para incluir una descripción para un campo tenemos las siguientes opciones: • Escribir la descripción directamente. • Utilizar la descripción del Diccionario de Datos. Para ello elegiremos la opción

“Referencia”.

Página 83 de 195


7.4 Diseño de la pantalla de selección Podemos hacer que la pantalla de selección tenga un aspecto más elaborado. Para ello tenemos la posibilidad de incluir marcos que agrupen selecciones lógicamente relacionadas, saltos de línea para espaciar parámetros, etc. Para conseguir estos efectos utilizaremos la palabra clave SELECTION-SCREEN. SELECTION-SCREEN BEGIN OF BLOCK <bloque>

[WITH FRAME <marco>] “Pinta un marco alrededor del bloque

[TITLE <texto>] “Especifica un título para el marco

SELECTION-SCREEN END OF BLOCK <bloque>.

Salta un numero <n> de líneas. SELECTION-SCREEN SKIP <N>.

Pinta una línea subrayada. SELECTION-SCREEN ULINE.

Para escribir varios parámetros en una misma línea del Selection-screen: SELECTION-SCREEN : BEGIN OF LINE

COMMENT “PERMITE INTRODUCIR TEXTOS (COMENTARIOS).

SELECTION-SCREEN: END OF LINE.

7.5 Eventos La pantalla de selección aparece después del bloque de evento INITIALIZATION.

El bloque AT SELECTION-SCREEN pertenece a la pantalla de selección. Cada vez que el usuario pulsa Enter o una tecla de función, o pulsa un botón del menú o escoge una opción del menú, el sistema realiza chequeos sobre el tipo de los campos de entrada. Si el tipo no es el correcto, se muestra un mensaje de error y el campo vuelve a estar preparado para rectificar la entrada. Cuando se han corregido los errores de tipo el sistema lanza el evento AT SELECTION-SCREEN. En el bloque correspondiente se pueden realizar otros chequeos y lanzar mensajes de error (con MESSAGE) y permitir la corrección de los campos erróneos. Cuando acaba el bloque sin errores se vuelve a mostrar la pantalla de selección.

Cuando se ejecuta el programa y se sale de la pantalla de selección, se procesa también el bloque AT SELECTION-SCREEN y después, si no hay errores, el bloque de evento START-OF-SELECTION.

7.6 Pantallas de selección definidas por el usuario Se pueden definir una pantalla de selección como un objeto independiente y usarla en programas utilizando la sentencia CALL SELECTION-SCREEN nnnn.

Para definirla, se deben crear las líneas que definen los parámetros y los criterios de selección dentro de un bloque delimitado por las sentencias:

SELECTION-SCREEN BEGIN OF SCREEN nnnn.

SELECTION-SCREEN END OF SCREEN nnnn.

Nnnn es el número de la pantalla de selección, cualquier secuencia de 4 dígitos excepto la 1000, que se reserva para la pantalla de selección estándar.

Igual que en el caso de la pantalla de selección estándar, se lanza el evento AT SELECTION-SCREEN con cada interacción del usuario. Si queremos distinguir el

Página 84 de 195


procesamiento para cada pantalla diferente, podemos comprobar el número de pantalla usando el campo SY-DYNNR.

7.7 Mensajes Hemos visto que para indicarle al usuario que los valores que ha introducido en una pantalla no son correctos se le pueden mostrar mensajes. Se utilizan en general para mostrar cualquier información al usuario. Los mensajes están almacenados en la tabla T100 organizados por lenguaje, un identificador y un número de tres dígitos. Si queremos crear mensajes propios sus identificadores deben comenzar por Y ó Z.

Los mensajes pueden contener hasta 4 variables, identificadas por &1, &2, &3 y &4. Se puede crear un texto descriptivo largo para cada mensaje; en éste, las variables correspondientes a las anteriores son &v1&, &v2&, &v3& y &v4&.

7.7.1 Uso de mensajes Para enviar un mensaje al usuario utilizamos la sentencia MESSAGE. Annn

Xnnn

MESSAGE Ennn WITH <campo1> <campo2> <campo3> <campo4>.

Wnnn

Innn

Snnn

Tenemos que haber declarado previamente la librería de mensajes que queremos utilizar en la sentencia REPORT: REPORT <nombre_programa> MESSAGE-ID <identificador>.

El identificador de mensajes así declarado será utilizado en todo el programa. El lenguaje que se utilizará para seleccionar el mensaje será el de la conexión del usuario.

En la sentencia MESSAGE sólo tenemos que indicar el número del mensaje (nnn) y el tipo (una letra delante del número), que determina cómo se muestra al usuario. El mensaje puede ser mostrado en la barra de status, o en forma de ventana. Existen los siguientes tipos de mensajes con diferente comportamiento:

A terminación Se finaliza la ejecución y el usuario debe reiniciar la transacción.

X salida Como el tipo A, pero se lanza un short dump MESSAGE_TYPE_X.

E error Se interrumpe la ejecución y el usuario debe corregir la entrada (si se muestra en AT SELECTION-SCREEN, si no es como el tipo A).

W aviso Se interrumpe la ejecución y el usuario puede corregir la entrada o confirmar con ENTER (si se muestra en AT SELECTION-SCREEN, si no es como el tipo A).

I informativo Se interrumpe la ejecución pero continúa cuando el usuario confirma el mensaje con ENTER.

S éxito Se muestra una información en la pantalla siguiente.

Para pasar valores a las variables del mensaje (que son como máximo cuatro), los ponemos a continuación de la palabra WITH. El campo al nivel i sustituye a la variable &i.

Página 85 de 195


Es posible usar mensajes sin declarar el identificador en la instrucción REPORT o usar mensajes de clases diferentes a la declarada con la siguiente variante de la sentencia: MESSAGE Tnnn(<identificador>) …

El identificador entre paréntesis a continuación del número del mensaje. Otra manera de crear un mensaje, que permite una llamada dinámica es la siguiente: MESSAGE ID <identificador> TYPE <tipo> NUMBER <número> WITH ...

En los campos de sistema SY-MSGID, SY-MSGTY, SY-MSGNO tendremos a nuestra disposición el identificador, el tipo y el número del mensaje si lo recibimos después de una llamada a otro programa. Podemos utilizarlos en una llamada dinámica como la anterior. SY-MSGV1, SY-MSGV2, SY-MSGV3, SY-MSGV4 contienen los valores de las variables.

7.7.2 Gestión de mensajes La definición del mensaje dentro de la clase consiste en un texto indicativo del mensaje junto a unos parámetros si los tiene: Por ejemplo, podríamos definir un mensaje con el número 001 de la clase ZZ ‘El cliente ‘& ‘No existe.

Página 86 de 195


8 Acceso a la base de datos Para poder leer una tabla de la base de datos en un programa es necesario declararla previamente con la sentencia TABLES <tabla>.

Para acceder a la base de datos se usan ciertas sentencias que utilizan la interfase de base de datos.

Buscar programas de ejemplo DEMO_SQL?

8.1 Open SQL vs SQL nativo Hay dos maneras de acceder a la base de datos del sistema SAP R/3 desde un programa ABAP: usando Open SQL o usando SQL nativo

Open SQL es un subconjunto de sentencias del SQL92 estándar, que forman parte del lenguaje ABAP. Permiten realizar operaciones (lecturas y modificaciones) con los registros de las tablas de la base de datos sin depender del sistema gestor concreto utilizado, de manera uniforme para todos los RDBMS. La interfase de base de datos convierte las sentencias a las instrucciones propias del sistema. Contiene en particular las sentencias del lenguaje de manipulación de datos (DML) SELECT, UPDATE, INSERT, DELETE y MODIFY. No contiene sentencias del lenguaje de definición de datos (DDL) porque estas funciones las cubre el Diccionario.

El SQL nativo permite usar en los programas ABAP sentencias propias del lenguaje específico del sistema gestor de base de datos utilizado en nuestra instalación. Estas instrucciones se pasan directamente de la interfase de base de datos al sistema gestor sin ser convertidas. Permite aprovechar las características propias de la base de datos y también se pueden realizar operaciones de definición (DDL). Pero no interesa utilizarlas en nuestros programas porque al ser específicas de un sistema de bases de datos no son portables. Además no vale la pena usar operaciones DDL porque no aprovechamos las funciones administrativas del Diccionario.

8.2 Lectura de datos: SELECT Para leer datos de una tabla de la base de datos utilizaremos la sentencia SELECT del Open SQL: SELECT <ámbito> FROM <tabla>

[INTO <destino>]

[WHERE <condición>]

[ORDER BY <orden>].

Esta sentencia, como vemos, tiene varias cláusulas:

Cláusula Descripción

SELECT <ámbito>

Define cuál va a ser el ámbito de selección: una línea o varias, todas las columnas (campos) o algunas, con líneas repetidas o no.

Si queremos seleccionar todos los campos de la tabla pondremos un *, y si queremos seleccionar sólo algunos campos determinados pondremos sus nombres: <campo1> … <campon>. Cuando leamos por columnas tendremos que tener un número de variables igual al número de columnas que hemos especificado. Estas variables harán la función de WA y tendrán que tener el mismo dominio que los campos de la tabla.

FROM <tabla> Especifica la tabla o vista de la base de datos que queremos leer.

Página 87 de 195


INTO <destino>

Especifica el objeto de datos interno del programa en el que colocaremos los datos seleccionados. Si usamos INTO CORRESPONDING FIELDS OF podemos llenar los campos que tengan igual nombre que los seleccionados en la estructura de destino.

WHERE <condición>

Especifica que líneas de la tabla vamos a leer en función de que cumplan la condición fijada.

<orden> Especifica el orden en el que se irán leyendo las líneas.

Se puede ordenar por clave primaria (BY PRIMARY KEY), o por campos determinados <campo1> … <campon>. Para las dos opciones determinadas se puede indicar orden ascendente (ASCENDING) o descendiente (DESCENDING).

8.2.1 Una o varias líneas Para leer una única línea de la tabla usaremos la cláusula SELECT SINGLE. Debemos especificar entonces los valores de todos los campos que forman la clave primaria en la cláusula WHERE, para asegurar que leemos un solo registro. Si el sistema encuentra un registro que cumple la condición, el campo SY-SUBRC devuelve el valor 0. SELECT SINGLE <f1> ... <fn>

FROM <dbtab>

INTO <wa>

INTO (<f1>, ..., <fn>)

INTO CORRESPONDING FIELDS OF <wa>

WHERE <key1> <op> <value1>... AND <key2> <op> <value2>...

SELECT SINGLE carrid connid cityfrom cityto

FROM spfli

INTO CORRESPONDING FIELDS OF wa

WHERE carrid EQ 'LH' AND connid EQ '0400'.

Ver programas de ejemplo:

DEMO_SELECT_SINGLE

DEMO_SELECT_SOME_COLUMNS

DEMO_SELECT_SINGLE_FIELDS

DEMO_SELECT_ALL_COLUMNS

Cuando no usamos la adición SINGLE, el sistema lee todos los registros de la tabla que cumplen las condiciones especificadas en la cláusula WHERE. El programa ABAP lee las líneas una por una en un bucle, guardando en cada paso los datos en el área indicada en la cláusula INTO. Para marcar el final del bucle debemos utilizar la sentencia ENDSELECT. Todas las instrucciones que se encuentran entre las sentencias SELECT y ENDSELECT se ejecutan para cada entrada leída.

SY-SUBRC vale 0 si el sistema ha podido leer al menos un registro. Después de ejecutar la sentencia SELECT en cada paso, el campo SY-DBCNT contiene el número de registros leídos hasta el momento. Después del ENDSELECT contiene el número de total de líneas leídas.

Página 88 de 195


SELECT <f1> ... <fn>

FROM <dbtab>

INTO <wa>

INTO (<f1>, ..., <fn>)

INTO CORRESPONDING FIELDS OF <wa>


ENDSELECT. DATA wa_spfli LIKE spfli.

SELECT carrid connid airpfrom airpto

FROM spfli

INTO CORRESPONDING FIELDS OF wa_spfli

WHERE carrid EQ 'LH'.

* <sentencias para cada registro leído>

ENDSELECT.

Se pueden guardar los registros en una tabla interna con la opción INTO TABLE. En este caso el sistema no realiza un bucle para leer los datos y no es necesario utilizar la instrucción ENDSELECT.

Para utilizar este método las dos tablas tienen que tener idéntica estructura. Esta opción es más eficiente que leer los registros en un bucle y añadir las líneas una a una a la tabla interna. SELECT <f1> ... <fn>

FROM <dbtab>

INTO TABLE <itab>

INTO CORRESPONDING FIELDS OF TABLE <itab>


DATA it_spfli LIKE TABLE OF spfli.

SELECT carrid connid airpfrom airpto

FROM spfli

INTO CORRESPONDING FIELDS OF TABLE it_spfli

WHERE carrid EQ 'LH'.

Ver programas de ejemplo DEMO_SELECT_INTO_TABLES y DEMO_SELECT_INTO_PACKAGE.

8.2.2 Más de una tabla Con un INNER JOIN se resumen varias tablas en una única tabla de resultados. El conjunto final contiene las entradas para las que existe al menos una entrada en cada tabla. La condición de unión puede contener campos que no sean clave.

Con un OUTER JOIN el conjunto de entradas posibles se guarda en una tabla primaria y la información adicional en tablas secundarias.

Estas uniones de tablas son normalmente la manera más eficiente de leer de la base de datos, pues la sentencia Open SQL se transforma en la base de datos y se utiliza su optimizador para decidir en qué orden se leen las tablas y qué índices se utilizan. Hay que tener en cuenta, no obstante, que conviene restringir el número de campos

Página 89 de 195


leídos: si se da el caso de que leemos muchos campos de la tabla de la izquierda y que la tabla de la derecha contiene muchas entradas correspondientes, estaremos leyendo muchos datos redundantes y ya no será un método eficiente de lectura.

8.2.3 Funciones de agregado Al igual que la lectura por columnas, cuando utilizamos funciones de agregado también utilizaremos variables. Las funciones de agregado son:

Min

Max

Count

Distinct

AVG

SUM

Las siguientes sentencias traspasan los valores de una tabla a otra siempre que tengan el mismo nombre y el mismo dominio. Select * from <itab> into corresponding fields of <WA>.

Se tienen que definir variables de destino. Select * from <table> into corresponding fields of <itab>.

Borra las entradas existentes en la internal table. Select * appending corresponding fields of table <itab>.

No es necesario endselect. No borra las entradas existentes en la internal table.

8.2.4 Selección (WHERE) Con rango: Select * from <table> where <table field> between <valor1> and <valor2>.

Con template: Select * from <table> where <table field> like '_R%'.

En este ejemplo se seleccionar los registros que tengan una r en la segunda posición. Esta variante solo se puede utilizar con campos tipo texto.

_ Indica un carácter.

% Indica secuencia de caracteres.

Con lista: Select * from <table> where <table field> in (123,1000).

Es como si utilizáramos un OR.

Con IN:

Con la palabra clave RANGES especificamos que los valores contenidos en una tabla interna son los rangos de selección. Select * from <table> where <table field> in <itab>.

Las condiciones guardadas en la tabla interna declarada con RANGES o SELECT-OPTIONS se interpretan de la siguiente manera: • Si la tabla interna está vacía, la condición <campo> IN <so> es siempre cierta..

Página 90 de 195


• Si la tabla interna contiene sólo condiciones inclusivas simples i1, ..., in, el resultado es la condición compuesta ( i1 OR ... OR in ).

• Si la tabla interna contiene sólo condiciones exclusivas simples e1, ..., em, el resultado es la condición compuesta ( NOT e1 ) AND ... AND ( NOT em ).

• Si la tabla interna contiene tanto condiciones inclusivas i1, ..., in como exclusivas e1, ..., em, el resultado es la condición compuesta ( i1 OR ... OR in ) AND ( NOT e1 ) AND ... AND ( NOT em ).

Ver programa de ejemplo DEMO_WHERE_IN_SELTAB.

8.2.5 Selecciones dinámicas Utilizamos un parámetro para indicar sobre que tabla realizaremos el select.

Necesitamos un WA para mostrar los resultados.

Es necesario utilizar INTO.

Este método es mas lento que un select estático.

El nombre dinámico es sensitive, es decir, hay diferencias entre majusculas y minúsculas.

Es posible que por este método algunos campos no se muestren correctamente.

Data: Begin of WA,

line(100),

end of WA.

Parameters: Tabname(10) default 'SPFLI'.

Select * from tabname into WA.


DEMO_SELECT_DYNAMIC_COLUMNS

DEMO_SELECT_DYNAMIC_CONDITIONS

DEMO_SELECT_DYNAMIC_DATABASE

8.2.6 Cláusula For All Entries Este método nos permite seleccionar de una tabla de diccionario filtrando con los valores contenidos en una tabla interna. Con este método es necesario igualar los campos. Es muy práctico para ahorrarnos condiciones muy largas.

Ver programas de ejemplo DEMO_SELECT_FOR_ALL_ENTRIES_1 y DEMO_SELECT_FOR_ALL_ENTRIES_2.

Select * from <table> for all entries in itab where

cityfrom = itab-cityfrom and

cityto = itab-cityto.

endselect.

8.2.7 Cláusula Order by En Abap/4 existe un Order by primary key.

Página 91 de 195


El orden por defecto es ascendente, al igual que con las tablas internas podemos ordenar un campo ascendentemente y otro descendentemente.

Se puede hacer en runtime en conjunción con una tabla interna. Para realizar esto los campos serán de tipo C y de un máximo de 72 caracteres. La lista de <itab> contendrá <f1...fn>. Select * from <table> order by primary key.

Ver programa de ejemplo DEMO_SELECT_ORDER_BY.

8.2.8 Cláusula Group by Todos las columnas especificadas deber ser las mismas que los indicados en la cláusula group by. Excepto las funciones de agregado. Esta cláusula solo se puede utilizar de modo estático. Select carrid min(price) max(price) into (carrid,resul_min,resul_max) from <table> group by carrid.

Ver programas de ejemplo DEMO_SELECT_GROUP_BY y DEMO_SELECT_GROUP_BY_HAVING.

8.2.9 Cláusula Bypassing buffer Es posible que algunas veces los datos recuperados al realizar un select, sean datos de buffers intermedios, si nos queremos asegurar que los datos que leemos son los de la BB.DD deberemos utilizar esta cláusula. Select * from sflight bypassing buffer.

8.3 Modificación de datos: INSERT/UPDATE/MODIFY/DELETE Todas estas sentencias dan un resultado a Sy-Subrc

0 Se han procesado correctamente.

<>0 Se ha producido algún tipo de error.

Update Si intentamos cambiar un registro que no existe se generara un error.

Modify Podemos modificar o crear con esta sentencia en Abap/4.

8.4 Confirmar/deshacer modificaciones: COMMIT/ROLLBACK

8.5 Rendimiento

Página 92 de 195


9 Bases de datos lógicas Programas de ejemplo DEMO_BDL

Para leer los datos de una tabla de la base de datos podemos utilizar dos métodos bastante diferentes: la sentencia SELECT (Open SQL, SQL nativo (Exec SQL) o Import/Export), o bien las bases de datos lógicas.

La función principal de las bases de datos lógicas es la reutilización del código que accede a la base de datos. SAP proporciona bases de datos lógicas para todas las aplicaciones. Éstas han sido configuradas para un rendimiento óptimo y contienen funciones extras como chequeos de autorización y ayudas de búsqueda.

Una base de datos lógica es un programa especial que lee datos de la base de datos. Combina los contenidos de ciertas tablas de la base de datos, relacionadas entre ellas mediante claves externas, de forma que establece una jerarquía entre ellas.

Para dar un ejemplo de las diferencias de los dos métodos de acceso, tomemos la base de datos lógica F1S, que tiene la siguiente estructura:

Una base de datos lógica es un programa auxiliar que sólo puede ser utilizado en conjunción con programas ejecutables de tipo 1. Se crea el enlace entre estos programas cuando se introduce el nombre de la BDL en los atributos del ejecutable. Una misma base de datos lógica se puede utilizar en varios programas ejecutables.

A partir de la versión 4.5a no es obligatorio enlazar la base de datos al programa ejecutable a través de los atributos. Ahora también es posible llamar a las bases de datos lógicas utilizando el módulo de función LDB_PROCESS. Esto nos permite llamar a varias bases de datos lógicas desde cualquier programa ABAP. También es posible llamar a las bases de datos lógicas más de una vez en un programa.

En resumen, para crear un listado mediante una BDL, necesitamos dos programas: uno que lee la tabla (la base de datos lógica) y un segundo que procesa los datos. Estos programas se comunican mediante los eventos PUT y GET.

El siguiente esquema muestra como se codificarían dos programas para acceder a un dato de la tabla SBOOK: Programa con SELECT: Programa con BBDD lógica:

REPORT … REPORT …

TABLES: SPFLI,

SFLIGHT,

SBOOK.

TABLES: SPFLI,

SFLIGHT,

SBOOK.

START-OF-SELECTION. START-OF-SELECTION.

SELECT * FROM SPFLI WHERE … GET SPFLI.

<bloque de procesamiento> <bloque de procesamiento>

SELECT * FROM SFLIGHT WHERE … GET SFLIGHT.

Página 93 de 195



SELECT * FROM SBOOK WHERE … GET SBOOK


ENDSELECT. END-OF-SELECTION.

ENDSELECT.

ENDSELECT.

Es apropiado utilizar una base de datos lógica siempre que las tablas que queremos leer se correspondan con la estructura y cuando el flujo de selección-lectura-procesamiento-visualización coincida con los requerimientos de la aplicación.

9.1 Partes de una BDL Una base de datos lógica se edita usando una herramienta del ABAP Workbench. Consta de las siguientes partes:

Estructura Determina las tablas de la base de datos a las que puede acceder. Adopta la jerarquía de las tablas definida por sus relaciones de clave externa. Controla también la secuencia en que se accede a las tablas.

Pantalla de selección Define los campos de entrada para filtrar los datos. Se muestra cuando se ejecuta el programa ejecutable asociado. Los campos también están disponibles en el programa; se les pueden asignar valores iniciales.

Programa de lectura Contenedor de subrutinas especiales en las que se leen los datos de la base de datos. El programa de sistema, que controla el flujo del programa ejecutable, llama a estas subrutinas en un orden determinado por la estructura.

9.2 Utilización clásica Cuando enlazamos una base de datos lógica con un programa ejecutable, el usuario puede introducir valores en la pantalla de selección. En la pantalla de selección solo aparecen los campos de entrada (criterios de búsqueda) que se han especificado en el programa ejecutable mediante la sentencia TABLES en la parte de declaraciones.

Antes de que el programa de sistema haga la solicitud de datos a la base de datos lógica, se produce el evento START-OF-SELECTION. Se ejecutan las instrucciones del programa ejecutable que están en este bloque de evento.

La estructura de la base de datos lógica determina la secuencia en la que se ejecutan sus bloques de proceso, las subrutinas PUT_<tabla>. Los datos leídos mediante sentencias OPEN SQL en estas subrutinas se devuelven al programa utilizando las estructuras (áreas de trabajo) definidas con la sentencia TABLES.

Cuando los datos han sido leídos desde la base de datos lógica se lanza el evento GET <tabla>. El programa ejecutable los procesa en el bloque de evento GET correspondiente, si existe. Los bloques de evento GET determinan la profundidad de lectura en la estructura de la base de datos lógica.

Cuando todas las tablas subordinadas a una dada han sido procesadas, y antes de que se lea la siguiente entrada de la tabla principal, se lanza el evento GET <tabla> LATE.

Página 94 de 195


Después de que se hayan producido todos los eventos de la base de datos lógica porque se han leído todas las entradas seleccionadas, se lanza el evento END-OF-SELECTION.

Para obtener más información acerca de las BDL consultar la ayudas o la transacción /n SE36.

9.3 Función LDB_PROCESS Cuando llamamos a una base de datos lógica utilizando el módulo de función LDB_PROCESS, no se muestra su pantalla de selección. En lugar de ello, tendremos que rellenar las selecciones utilizando los parámetros de la interfase del módulo de función. La base de datos lógica no lanzará ningún evento GET en el programa llamante, sino que devolverá los datos en las rutinas de vuelta.

No es necesario adaptar una base de datos lógica para utilizarla con LDB_PROCESS. La única excepción es que necesitemos utilizar el módulo de función para llamar a la misma base de datos lógica más de una vez. No se llama a la subrutina PAI cuando utilizamos LDB_PROCESS. Esto significa que no se realizará ninguna de las verificaciones programadas para la selección. Podemos tratar estas restricciones incluyendo las subrutinas LDB_PROCESS_INIT y LDB_PROCESS_CHECK_SELECTIONS en el programa de la base de datos.

9.3.1 Comportamiento en tiempo de ejecución Las subrutinas de la base de datos lógica son llamadas en la siguiente secuencia cuando llamamos al módulo de función LDB_PROCESS:

LDB_PROCESS_INIT

INIT

LDB_PROCESS_CHECK_SELECTIONS

PUT <nodo>

9.3.2 Parámetros de LDB_PROCESS El módulo de función tiene los siguientes parámetros IMPORT: LDBNAME

Nombre de la base de datos lógica que queremos llamar. VARIANT

Nombre de la variante para rellenar la pantalla de selección de la base de datos lógica. La variante debe estar ya asignada al programa de la base de datos de la base de datos lógica. Los datos se pasan de la misma forma que cuando utilizamos la opción WITH SELECTION-TABLE de la sentencia SUBMIT. EXPRESSIONS

En este parámetro, podemos pasar selecciones adicionales para los nodos de la base de datos lógica para la que están permitidas selecciones dinámicas. El tipo de datos del parámetro RSDS_TEXPR está definido en el grupo de tipos RSDS. Los datos se pasan de la misma forma que cuando utilizamos la opción WITH FREE SELECTION de la sentencia SUBMIT. FIELD_SELECTION

Podemos utilizar este parámetro para pasar una lista de los campos requeridos para los nodos de la base de datos lógica para la que se permitan selecciones dinámicas. El tipo de datos del parámetro es el de la tabla interna RSFS_FIELDS, definido en el

Página 95 de 195


grupo de tipos RFS. El componente TABLENAME contiene el nombre del nodo y el componente FIELDS contiene los nombres de los campos que queremos leer.

El módulo de función tiene los siguientes parámetros TABLES: CALLBACK

Utilizaremos este parámetro para asignar las rutinas de vuelta a los nombres de los nodos y eventos. El parámetro determina los nodos de la base de datos lógica de los que se van a leer los datos, y cuándo se van a devolver los datos al programa y en qué rutina de vuelta. SELECTIONS

Podemos utilizar este parámetro para pasar valores de entrada a los campos de la pantalla de selección de la base de datos lógica. El tipo de datos del parámetro se corresponde con el de la estructura RSPARAMS del Diccionario ABAP. Los datos se pasan de la misma forma que cuando utilizamos la opción WITH SELECTION-TABLE de la sentencia SUBMIT.

Si pasamos selecciones utilizando más de un parámetro de la interface, los valores pasados en SELECTIONS y EXPRESSIONS sobreescriben los valores de los mismos campos de VARIANT.

9.3.3 Profundidad de la Lectura y Rutinas de Vuelta Cuando enlazamos una base de datos lógica con un programa ejecutable, las sentencias GET determinan la profundidad para la que se leerá la base de datos lógica. Cuando llamamos al módulo de función LDB_PROCESS, determinamos esta profundidad especificando el nombre del nodo en el parámetro CALLBACK. Para cada nodo para el que queramos pedir datos, se puede ejecutar una rutina de vuelta en dos puntos. Estos se corresponden con los eventos GET y GET LATE de los programas ejecutables. En el parámetro CALLBACK, especificaremos el nombre de la rutina de vuelta y el punto de ejecución requerido para cada nodo. Una rutina de vuelta es una subrutina del programa llamante o de otro programa que se debe ejecutar en un punto determinado.

Para el evento GET, la rutina de vuelta se ejecuta directamente después de que se hayan leído los datos del nodo, y antes de que se procesen los nodos subordinados. Para el evento GET LATE, la rutina de vuelta se procesa después de que se hayan procesado los nodos subordinados.

El tipo de línea del parámetro de tabla CALLBACK es la estructura LDBCB del Diccionario ABAP. Tiene los siguientes componentes: LDBNODE: Nombre del nodo de la base de datos lógica a leer. GET: Un flag (contiene X o espacio), para llamar a la correspondiente rutina de vuelta

del evento GET. GET_LATE: Un flag (contiene X o espacio), para llamar a la correspondiente rutina de

vuelta del evento GET LATE. CB_PROG: Nombre del programa ABAP en el que se encuentra definida la rutina de

vuelta. CB_FORM: Nombre de la rutina de vuelta.

Si pasamos una tabla interna al parámetro CALLBACK, debemos rellenar al menos una de la columnas GET o GET_LATE con una X para cada nodo.

Una rutina de vuelta es una subrutina que debe tener definida la siguiente interface de parámetros: FORM <subrutina> USING <nodo> LIKE LDBCB-LDBNODE

Página 96 de 195


<at> [TYPE <t>]

<evento>

<check>.

Los parámetros son rellenados por el módulo de función LDB_PROCESS. Estos parámetros tienen el siguiente significado: <nodo> contiene el nombre del nodo. <at> es el área de trabajo de los datos leídos del nodo. El programa que llame al

módulo de función LDB_PROCESS y el programa que contenga la rutina de vuelta no tienen que declarar la interface de áreas de trabajo NODES o TABLES. Si la rutina de vuelta sólo se utiliza para un nodo, podemos utilizar TYPE para hacer referencia al tipo de datos del nodo del Diccionario ABAP. Sólo entonces podremos acceder directamente a los componentes individuales de los nodos estructurados en la subrutina. Si utilizamos la rutina de vuelta para más de un nodo, no podemos utilizar la referencia TYPE. En este caso, tendremos que acceder a los componentes de los nodos estructurados asignándolos uno a uno a un field-symbol.

<evento> contiene G o L, para GET o GET LATE respectivamente. Esto significa que la subrutina puede dirigir el flujo del programa utilizando el contenido de <evento>.

<verificar> permite que la rutina de vuelta pueda influir en cómo se comportará el programa después (pero sólo si <evento> contiene el valor G). Se asignará el valor X al parámetro cuando se llame a la subrutina. Si tiene el valor espacio cuando termina la subrutina, indica que los nodos subordinados no deberían de procesarse en el módulo de función LDB_PROCESS. Tiene el mismo efecto que cuando abandonamos el bloque del evento GET utilizando la sentencia CHECK en un programa ejecutable. Esto evita que se lean datos innecesarios, y mejora el rendimiento de nuestro programa.

9.3.4 Excepciones de LDB_PROCESS LDB_ALREADY_RUNNING: No se puede llamar a una base de datos lógica si aún se

está procesando en una llamada previa. Si esto ocurre, se lanza esta excepción. LDB_NOT_REENTRANT: sólo se puede llamar a una base de datos lógica

repetidamente si el programa de la base de datos contiene la subrutina LDB_PROCESS_INIT, en otro caso se lanzará esta excepción.

LDB_SELECTIONS_NOT_ACEPTED: se ha producido en error en el manejo de la subrutina LDB_PROCESS_CHECK_SELECTIONS del programa de la base de datos. El mensaje de error se coloca en los campos usuales del sistema (SY-MSG...)

Para una información más detallada acerca de otras excepciones, véase la documentación del módulo de función.

9.3.5 Ejemplo TABLES SPFLI.

Página 97 de 195


SELECT-OPTIONS S_CARR FOR SPFLI-CARRID.

TYPE-POOLS: RSDS, RSFS.

DATA: VUELTA TYPE TABLE OF LDBCB,

AT_VUELTA LIKE LINE OF VUELTA.

DATA: TABSEL TYPE TABLE OF RSPARAMS,

AT_TABSEL LIKE LINE OF TABSEL.

DATA: TEXPR TYPE RSDS_TEXPR,

CSEL TYPE RSFS_FIELDS.

AT_VUELTA-LDBNODE = 'SPFLI'.

AT_VUELTA-GET = 'X'.

AT_VUELTA-GET_LATE = 'X'.

AT_VUELTA-CB_PROG = SY-REPID.

AT_VUELTA-CB_FORM = 'VUELTA_SPFLI'.

APPEND AT_VUELTA TO VUELTA.

CLEAR AT_VUELTA.

AT_VUELTA-LDBNODE = 'SFLIGHT'.

AT_VUELTA-GET = 'X'.

AT_VUELTA-CB_PROG = SY-REPID.

AT_VUELTA-CB_FORM = 'VUELTA_SFLIGHT'.

APPEND AT_VUELTA TO VUELTA.

AT_TABSEL-KIND = 'S'.

AT_TABSEL-SELNAME = 'CARRID'.

LOOP AT S_CARR.

MOVE-CORRESPONDING S_CARR TO AT_TABSEL.

APPEND AT_TABSEL TO TABSEL.

ENDLOOP.

CALL FUNCTION 'LDB_PROCESS'

EXPORTING

LDBNAME = 'F1S'

VARIANT = ' '

EXPRESSIONS = TEXPR

FIELD_SELECTION = CSEL

Página 98 de 195


TABLES

CALLBACK = VUELTA

SELECTIONS = TABSEL

EXCEPTIONS

LDB_NOT_REENTRANT = 1

LDB_INCORRECT = 2

LDB_ALREADY_RUNNING = 3

LDB_ERROR = 4

LDB_SELECTIONS_ERROR = 5

LDB_SELECTIONS_NOT_ACCEPTED = 6

VARIANT_NOT_EXISTENT = 7

VARIANT_OBSOLETE = 8

VARIANT_ERROR = 9

FREE_SELECTIONS_ERROR = 10

CALLBACK_NO_EVENT = 11

CALLBACK_NODE_DUPLICATE = 12

OTHERS = 13.

IF ( SY-SUBRC <> 0.)

WRITE: 'Excepción con SY-SUBRC', SY-SUBRC.

ENDIF.

FORM VUELTA_SPFLI USING NOMBRE TYPE LDBN-LDBNODE

AT TYPE SPFLI

EVENTO TYPE C

VERIF TYPE C.

CASE EVENTO.

WHEN 'G'.

WRITE: / AT-CARRID, AT-CONNID, AT-CITYFROM, AT-CITYTO.

ULINE.

WHEN 'L'.

ULINE.

ENDCASE.

ENDFORM.

FORM VUELTA_SFLIGHT USING NOMBRE TYPE LDBN-LDBNODE

AT TYPE SFLIGHT

EVENTO TYPE C

VERIF TYPE C.

WRITE: / AT-FLDATE, AT-SEATSOCC, AT-SEATSMAX.

Página 99 de 195


ENDFORM.

El programa está escrito para leer información de la base de datos lógica F1S. La estructura de F1S es:

Se define una pantalla de selección específica al principio del programa. Esto requiere que incluyamos la sentencia TABLES. Después se definen las variables requeridas para la interface.

La tabla interna VUELTA se rellena para las diferentes rutinas de vuelta que se llamarán en el programa para los dos nodos SPFLI y SFLIGHT. Para SPFLI, la rutina se llamará para GET y GET_LATE, para SFLIGHT sólo se llamará para el evento GET.

La tabla interna TABSEL se rellena con los valores para el nodo SPFLI a partir de la tabla de selección S_CARR de la pantalla de selección específica del programa.

Después, el programa llama al módulo de función LDB_PROCESS con estos parámetros.

Las subrutinas VUELTA_SPFLI y VUELTA_SFLIGHT sirven de rutinas de vuelta. El parámetro AT se especifica completamente, y por lo tanto podremos acceder a los componentes individuales del área de trabajo. Los eventos GET y GET LATE se tratan de forma diferente en VUELTA_SPFLI.

El comienzo del listado de salida mostraría algo como esto:

Página 100 de 195


Página 101 de 195


10 Tablas Internas En el tema de objetos de datos ya hemos hablado de las tablas internas, que son secuencias de registros del mismo tipo.

Las tabla internas se utilizan normalmente para tener accesibles en la memoria del programa ciertos datos fuente o resultados del proceso. Ejemplos de usos típicos son:

Guardar temporalmente datos de tablas de la base de datos para procesarlos a continuación.

Guardar datos que se mostrarán después en un listado.

Almacenar datos para pasarlos a ficheros locales u otros destinos.

El número de líneas en una tabla interna no es predeterminado ni estático. El sistema las expande de manera dinámica en tiempo de ejecución en función de las necesidades. El único límite es el de capacidad máxima establecida durante la instalación. El espacio de memoria inicial reservado para una tabla interna son 8 Kb y si se necesita más memoria se expande en bloques de esta misma medida.

10.1 Atributos de las tablas Para describir una tabla interna usamos atributos, el principal de los cuales es el tipo de línea. El tipo de línea determina la estructura de los registros que se pueden guardar en la tabla: puede consistir en cualquier tipo de datos ABAP, incluidas otras tablas internas.

Otro atributo de las tablas internas el la clave. La clave es una secuencia de campos de la tabla que permite identificar registros en ella. Las claves pueden ser UNIQUE o NON-UNIQUE en función de si se permiten o no varias entradas con la misma clave.

Otro atributo seria el tipo de acceso de tabla, característica que hace referencia a la manera cómo se accede a los datos de la tabla. Existen tres tipos:

Las tablas estándar mantienen un índice o contador de registros interno. Se puede acceder a ellas por el índice o por la clave. La clave puede ser NON-UNIQUE.

Las tablas ordenadas se mantienen ordenadas respecto a la clave. También se mantiene un índice interno y se puede acceder a ellas por el índice o por la clave. La clave puede ser UNIQUE o NON-UNIQUE.

Las tablas hash no mantienen un índice interno, sólo se puede acceder a ellas por la clave. Requieren que la clave sea UNIQUE.

El tipo de tabla que escojamos dependerá del tipo de acceso que queramos realizar. Deberíamos usar tablas estándar si queremos acceder normalmente por el índice, tablas ordenadas si nos interesa acceder normalmente por la clave y tablas hash si sólo accederemos a los registros usando su clave.

En este curso sólo hablaremos de las tablas estándar.


DEMO_INTERNAL_TABLE

DEMO_INT_TABLES_*

Página 102 de 195


10.2 Operaciones y áreas de trabajo No está permitido el acceso directo a los registros de las tablas internas. Las operaciones se realizan mediante áreas de trabajo o “work areas”, que son un registro con la misma estructura que las líneas de la tabla interna.

Se pueden realizar las siguientes operaciones con las tablas internas:

Sentencia Efecto APPEND Añade los contenidos de un área de trabajo al final de una tabla

interna.

INSERT Insertar los contenidos de un área de trabajo en una cierta línea de una tabla interna (dada por el número de línea).

MODIFY Sobreescribe una cierta línea de la tabla interna con los contenidos de un área de trabajo.

DELETE Borra una cierta linea de una tabla interna.

LOOP AT Inserta los registros de la tabla interna uno a uno, en un bucle, dentro de un área de trabajo.

READ TABLE Inserta exactamente un registro de la tabla interna en un área de trabajo.

SORT Ordena una tabla interna

CLEAR Borra un área de trabajo o una tabla interna.

Veremos con más detalle estas sentencias en apartados posteriores.

10.3 Declaración: Tipos y Objetos En la declaración de un tipo de datos tabla interna o de un objeto de datos tabla interna debemos especificar sus atributos: tipo de tabla, tipo de línea, secuencia y tipo de clave. Para las tablas estándar no hace falta indicar el tipo.

También podemos especificar un tamaño inicial en número de registros para la tabla interna con la adición INITIAL SIZE. TYPES <ttabla> TYPE <tipo_tabla> OF <tipo_linea>

[ WITH {UNIQUE|NON-UNIQUE} KEY <def_clave> ]

[ INITIAL SIZE <n> ]

[ WITH HEADER LINE ].

DATA <otabla> TYPE <tipo_tabla> OF <tipo_linea>

[ WITH {UNIQUE|NON-UNIQUE} KEY <def_clave> ]

[ INITIAL SIZE <n> ]

[ WITH HEADER LINE ]

Las tablas internas se pueden definir con o sin cabecera (header-line).

Las primeras están formadas por un área de trabajo y el cuerpo de la tabla, y a ambos elementos se accede con el mismo nombre. La interpretación depende del contexto donde se encuentre el nombre. Para evitar confusiones se recomienda usar tablas sin cabecera, pero por otro lado la cabecera permite a menudo usar sentencias más cortas para ciertas operaciones.

Página 103 de 195


Para declarar una tabla interna con cabecera usamos la adición WITH HEADER LINE en la sentencia DATA.

Con el parámetro "occurs <n>" indicamos que es una tabla interna formada por <n> registro y 1 header line, si desconocemos el número de registros que va a contener nuestra tabla indicar "occurs 0".

Podemos crear una tabla con la misma estructura que una tabla del diccionario de Abap/4, es decir, copia la definición de la tabla del diccionario en nuestra tabla interna. También podemos hacer referencia a estructuras de reports internas con esta instrucción.

Data: Begin of <itab> occurs 5,

include structure sflight.

end of <itab>.

Para este tipo de tabla tendremos que definirnos previamente un field string que haga las funciones de header line, o lo que es lo mismo, de WA.

10.4 Añadir registros

10.4.1 Append Almacena el contenido del header line al final de la tabla interna. También es posible almacernarlo por un orden en concreto.

Ex. Append <itab> [sorted by <field>].

Si se ha sobrepasado el número de registros de la tabla interna se comenzaran a eliminar los últimos registros de la tabla.

En vez de utilizar el header line como línea auxiliar podemos introducir datos en una tabla interna con ayuda de un field string, pero tienen que tener la misma definición. A esto se le llama trabajar con un Work Area.

Ex. Append <WA> to <itab>.

Esto es mas rápido que asignar un <WA> al header line de la tabla y realizar posteriormente un append.

10.4.2 Collect Almacena el contenido del header line en la tabla interna, con la particularidad que si encuentra un registro con la misma clave, sumara el contenido de los campos numéricos si el registro los tuviera. Es decir, totaliza los campos numéricos.

Ex. Collect <itab>.

10.5 Leer registros

10.5.1 Loop Podemos procesar múltiples registros de una tabla interna con la sentencia de bucle LOOP. A cada paso del bucle se copia el siguiente registro de la tabla interna en el área de trabajo especificada por la palabra INTO o en la línea de cabecera de la tabla.

Se pueden determinar los registros a leer especificando algunos campos clave o indicando los índices. LOOP AT <tabla>

Página 104 de 195


[ INTO <area> ]

[ FROM <i1> TO <i2> ]

[ WHERE <campo_clave1> = <valor1> ...].

ENDLOOP.

Si no hay ningún registro que cumpla las condiciones especificadas en el bloque WHERE o en el rango de índices, el sistema devuelve un código de retorno SY-SUBRC <> 0.

En el campo de sistema SY-TABIX se encuentra el índice del registro que estamos leyendo en un cierto paso del bucle. Cuando acaba el bucle SY-TABIX recupera el valor que tenía antes del LOOP.

10.5.2 Read Permite leer un registro concreto de una tabla interna. Se pueden usar tanto los valores de los campos clave (WITH KEY) como el índice del registro (INDEX). Si se usa la adición FROM se toman los valores de búsqueda de los campos correspondientes del área indicada. El sistema lee el primer registro de la tabla que corresponde al criterio de búsqueda indicado. READ TABLE <tabla>

[ INTO <area> ]

[ WITH KEY <campo_clave> = <valor>]

[ FROM <area> ]

[ INDEX <indice>]

El contenido leído se guarda en el área de trabajo especificada con INTO o en la cabecera (header line) de la tabla interna.

Si la lectura tiene éxito, el campo SY-SUBRC contiene el valor 0, otros códigos de retorno indican que no se pudo realizar el acceso.

El campo SY-TABIX se llena con el índice del registro leído.

Ex. Read table <itab> with key 'LH 0400'. Leemos por clave primaria.

Read table <itab> index tab-index. Leemos por posición de fila.

10.6 Modificaciones Estas tres instrucciones permiten procesar registros concretos especificando su índice o especificando la clave.

10.6.1 Modify Sobrescribe el registro con índice i con los contenidos del área de trabajo. La línea i debe existir previamente. MODIFY <tabla> [ FROM <area> ] [INDEX <i>].

O modifica el registro que tiene los mismos campos clave que el área con el contenido de ésta. MODIFY TABLE <tabla> [ FROM <area> ].

Página 105 de 195


10.6.2 Insert Crea un nuevo registro en la posición anterior a la línea i usando los contenidos del área de trabajo. Si la tabla tiene i-1 registros, es equivalente a un APPEND, pues añadimos el nuevo registro al final de la tabla. INSERT [ <area> INTO ] <tabla> [INDEX <i>].

O inserta un nuevo registro en la tabla interna con el contenido del área. INSERT [ <area> INTO ] TABLE <tabla>.

10.6.3 Delete Borra el registro especificado de la tabla interna. Si no especificamos la cláusula "index <i>" borraremos el registro que concuerda con el que tenemos en la cabecera. También es posible borrar un rango de registros. DELETE <tabla> [INDEX <i>].

DELETE <tabla> where Carrid NE 'LH'. “Es posible borrar por un criterio.

DELETE <tabla> FROM <id1> TO <id2>. “Se borra por rango, incluidos los limites.

DELETE TABLE <tabla> [ FROM <area>].

10.7 Inicializar tablas

10.7.1 Refresh Borra todos los registros de la tabla. No descarga el espacio de memoria usado por esta. El header line se mantiene igual.

Ex. Refresh <itab>.

10.7.2 Clear Borra la cabecera de la tabla interna si existe. Si no borra toda la tabla.

10.7.3 Free Borra los registros de la tabla y libera el espacio de memoria usado por esta. El header line se mantiene igual.

Ex. Free <itab>.

10.8 Describir y ordenar

10.8.1 Atributos Permite obtener información acerca de una tabla interna mediante dos cláusulas:

Lines: Retorna el número de entradas que contiene la tabla. • • Occurs: Retorna en valor de Occurs de la definición.

Ex . Describe table <itab> [lines] resul_lines [occurs] resul_occurs.

Página 106 de 195


10.8.2 Sort Permite ordenar una tabla interna. Esta ordenación puede hacerse indistintamente ascendente o descendentemente por uno o varios campos. No es necesario que todos tengan el mismo orden, es decir podemos ordenar una tabla por un campo descendentemente y a su vez por otro ascendentemente. La secuencia de campos determina la jerarquía de ordenación. SORT <tabla> BY <f1> [{ASCENDING|DESCENDING} [AS TEXT]]

<f2> [{ASCENDING|DESCENDING} [AS TEXT]]...

Se pueden ordenas campos de texto con la adición AS TEXT. Esto permite ordenar en función del lenguaje de conexión. Si es necesario utilizar un cierto lenguaje podemos usar la sentencia SET LOCALE.

Ex. Sort <itab> by price fldate.

Sort <itab> by price ascending fldate descending.

Que pasa con los tipos P,I y F?

Página 107 de 195


11 Crear listas Las listas son pantallas de resultados que muestran datos de manera estructurada. Se definen formatean y llenan usando sentencias ABAP. El sistema muestra las listas definidas con sentencias ABAP en una pantalla especial de lista, cuya lógica de flujo es proporcionada por el sistema y permanece oculta para el programador.

Las listas son importantes porque sólo los datos en forma de lista pueden ser enviados al Spool de R/3 para su impresión.

Antes de decidir que crearemos un programa nuevo para proporcionarle un listado concreto a un usuario deberíamos buscar otros medios. Es posible que se pueda configurar un listado estándar para obtener lo que necesita, o que podamos utilizar herramientas como el ABAP Query.

Si no hay otra opción, crearemos un programa de tipo ‘1’.

En los programas ejecutables, de tipo 1, se muestra automáticamente una lista después de procesarlo siempre que se haya incluido una de las sentencias que genera líneas (WRITE, SKIP o ULINE).

Todas las líneas generadas se almacenan temporalmente en un buffer de lista hasta que acaba la ejecución. Entonces todos los datos se muestran en una pantalla de lista. Si no indicamos lo contrario, el listado estará formado por una única página continua de como máximo 60000 líneas. La máxima longitud de una línea son 1023 caracteres.

Veremos que hay muchas opciones para el diseño del listado: de escritura (posicionamiento, colores, separadores, iconos), de formato (ancho de la lista, clasificación) y de diseño de página (cabeceras, saltos de página, pie de página)

11.1 Lista estándar A continuación se describen los recursos y sentencias que nos ayudarán a obtener el formato deseado en el desarrollo de una lista.

11.1.1 Cabeceras y símbolos de texto Como función estándar de los programas ejecutables, el sistema genera por defecto dos líneas de cabecera (la cabecera estándar). La primera contiene el título del programa en la esquina izquierda superior y el número de página en la esquina derecha. La segunda línea es una línea horizontal continua. Las dos líneas permanecen en la ventana cuando nos desplazamos por el listado.

Cuando imprimimos un listado, la primera línea de cabecera tiene a la izquierda la fecha del sistema, en el centro el título del programa y a la derecha el número de página.

La lista estándar tiene una cabecera y hasta cuatro líneas de cabecera de columna que se pueden crear bien desde el Editor usando las herramientas de mantenimiento de los elementos de texto, o bien desde la propia lista una vez ejecutado el programa a través de la opción de menú (Sistema->Lista->Cabeceras). De esta segunda manera es más sencillo posicionar las cabeceras porque vemos la lista en pantalla.

Cuando no se ha creado un texto de cabecera se utiliza el título del programa.

Como estos textos forman parte de los elementos de texto del programa, se pueden traducir a varios lenguajes para que se muestren al usuario en el lenguaje escogido por él para la conexión. Esta posibilidad es muy interesante para compañías multinacionales.

Página 108 de 195


Los símbolos de texto son objetos literales que también forman parte de los elementos de texto del programa y se pueden traducir sin tener que cambiar el código fuente. Se utilizan escribiendo TEXT-xxx o ‘cadena’(xxx). Podemos así crear listas independientes del lenguaje.

11.1.2 WRITE Mediante la sentencia WRITE podemos mostrar mensajes, ver el contenido de un campo, encolumnar la salida de los datos, etc.

La sentencia WRITE tiene muchas opciones de formateo. Las principales son:

… AT <columna>[(longitud)] <campo>. Con esta sentencia escribimos el campo <campo> a partir de la columna <columna> con una longitud de (longitud). El número indicado entre paréntesis indica el numero de posiciones del campo que vamos a mostrar, técnicamente a esta operación se le denomina OFFSET. NO-GAP Suprime la escritura de espacios después del campo <f>. Los

campos que se escriben uno a continuación de otro aparecen sin separación.

NO-ZERO Si los contenidos del campo f son iguales a cero, sólo e escriben espacios. Si f es de tipo C o N, se sustituyen los ceros a la izquierda por espacios.

DD/MM/YY, Si f es un campo de fecha (tipo D), sus contenidos se procesan de acuerdo a los parámetros del usuario (y no según la opción especificada).

CURRENCY w Proceso adecuado del campo de importe según la moneda del campo w: esta moneda determina cuántas posiciones decimales se usarán para el importe (tabla TCURX).

UNIT w La unidad contenida en w determina a través de la tabla T00G cómo se escribe el campo f que contiene una cantidad (el número de decimales).

USING EDIT MASK <mascara>

Escribe f siguiendo la plantilla <mascara>

UNDER g La escritura del campo f empieza en la columna en la que se ha escrito g.

LEFT-JUSTIFIED Escritura justificada a la izquierda (es la opción por defecto para todos los tipos que no son I, P o F).

CENTERED Escritura centrada RIGHT-JUSTIFIED

Escritura justificada a la derecha (opción por defecto para los campos numéricos I, P y F)

• … COLOR <n>. Con esta sentencia escribimos el campo en un color determinado.

Se puede escoger entre siete colores de fondo a los que les corresponde un número o un nombre simbólico.

0 COL_BACKGROUND Fondos

1 COL_HEADING Cabeceras

2 COL_NORMAL Líneas de lista

3 COL-TOTAL Totales

4 COL_KEY Columnas clave

Página 109 de 195


5 COL-POSITIVE Valores positivos

6 COL_NEGATIVE Valores negativos

7 COL_GROUP Niveles de control

Write: /5 'Date, 20 Sy_DATUM.

Escribimos con un salto de línea date (Columna 5), y la fecha del sistema (Columna 20). La sentencia Write sin '/' no implica un salto de línea

Write: /10(4) nombre.

Write: sbook-forcurmon CURRENCY sbook-forcurkey.

Da formato de miles al campo sbook-forcurom con las especificaciones del campo sbook-forcurkey.

11.1.3 Iconos y símbolos Podemos utilizar la opción AS SYMBOL de la sentencia WRITE para incluir símbolos en listados. Los nombre simbólicos de estos símbolos están definidos en el include <SYMBOL>.

También podemos insertar iconos en el listado con WRITE <f> AS ICON. Para poder hacerlo se debe ligar el include <ICON> al programa

Si incluimos el include <LIST> podremos trabajar tanto con símbolos como con iconos.

11.1.4 Check-boxes y campos de entrada Si utilizamos la opción AS CHECKBOX, el campo <f> se escribe como un check-box.

El contenido del primer carácter de f se interpreta como la condición y puede ser cambiado en pantalla por acción del usuario sobre él. Si contiene un espacio no está marcado; si contiene una X está marcado.

Estos campos funcionan como campos de entrada y se pueden utilizar en listas interactivas. Para conseguir que un campo cualquiera sea de entrada podemos utilizar el parámetro adicional INPUT.

11.1.5 SKIP Escribe líneas en blanco.

Ex: Skip 2. Escribe dos líneas en blanco.

11.1.6 ULINE Escribe una línea subrayada.

Ex: Uline.

11.2 Diseño de la página Todos los programas de este tipo empiezan con la instrucción REPORT de ahí su nombre. Esta instrucción además de indicar el nombre e inicio del programa, permite señalar algunos de los atributos del programa como el alto y el ancho de listado, la clase de mensajes que utiliza, etc.

Página 110 de 195


Página 111 de 195

11.2.1 Dimensiones Por defecto ABAP/4 crea listados de 80 caracteres de ancho, y 65 líneas de largo. Estos valores se pueden modificar con los siguientes parámetros de la sentencia REPORT:

LINE-SIZE <n>: define el ancho de la lista, la n indica el número de columnas.

LINE-COUNT <m> <p>: define el número de líneas m de cada página de la lista. El valor especificado en p es el número de líneas reservadas para el pie de página (es opcional).

Nota: Para obtener ayuda sobre una instrucción, situando el cursor sobre ella pulsamos F1 nos saldrá una pantalla de ayuda con la sintaxis y opciones de cada una de ellas. Para la sentencia REPORT se muestra la ayuda:

En nuestro ejemplo añadiremos a la instrucción REPORT las siguientes opciones: REPORT zreporxx NO STANDARD PAGE HEADING LINE-SIZE 120 LINE-COUNT 80.

11.2.2 Cabeceras no estándar Si utilizamos la opción NO STANDARD PAGE HEADING de la sentencia REPORT suprimiremos la escritura de la cabecera del listado y de las cabeceras de columna.

Si queremos diseñar nosotros mismos la cabecera y el pie del listado, deberemos utilizar los eventos TOP-OF-PAGE y END-OF-PAGE.

La primera sentencia WRITE del programa lanza el evento TOP-OF-PAGE. En el bloque correspondiente a este evento podemos escribir lo que queremos que aparezca al inicio de cada nueva página del listado.

Si no usamos la opción NO STANDARD PAGE HEADING, las líneas que escribamos en el bloque de TOP-OF-PAGE aparecerán a continuación de las cabeceras estándar.

Las líneas generadas por TOP-OF-PAGE permanecen en la parte superior de la ventana de visualización de la lista mientras nos desplazamos verticalmente.


11.2.3 Columnas fijas Podemos utilizar SET LEFT SCROLL-BOUNDARY para fijar una serie de columnas del listado de manera que cuando nos desplacemos horizontalmente se mantengan en su lugar.

Si no especificamos la columna final con la adición COLUMN, el sistema utiliza la posición de escritura actual (SY_COLNO) como límite. El margen se debe especificar en cada nueva página; situaremos la instrucción en el evento TOP-OF-PAGE.

Podemos usar también NEW-LINE NO-SCROLLING para evitar el desplazamiento de la siguiente línea al movernos horizontalmente.

11.2.4 Salto de página La sentencia NEW-PAGE genera un salto de página.

Cuando generamos un listado, podemos utilizar los parámetros NO-TITLE o WITH-TITLE de la sentencia NEW-PAGE para desactivar o reactivar la escritura del título de manera dinámica.

Los parámetros NO-HEADING y WITH-HEADING sirven para controlar de manera análoga las cabeceras de columna.

Incluso cuando utilizamos la opción NO STANDARD PAGE HEADING en la sentencia REPORT podemos forzar la aparición de los títulos y cabeceras mediante los parámetros anteriores.

11.2.5 Pie de página El evento END-OF-PAGE permite que escribamos un pie de página al final de cada página. Si se debe crear una nueva página para seguir con el listado, el sistema procesa el bloque de evento correspondiente a END-OF-PAGE antes de ejecutar el salto de página.

No se produce el evento END-OF-PAGE cuando una sentencia NEW-PAGE lanza un salto de página. Este evento sólo se procesa cuando la sentencia REPORT contiene un parámetro LINE-COUNT que determina el número de líneas destinadas al pie de página.

11.2.6 Sentencias adicionales RESERVE <n> LINES. Se ejecuta un salto de página si no hay suficiente espacio

para n líneas durante la estructuración del listado.

BACK Sin RESERVE: Vuelve a la primera línea de la página actual después del TOP-OF-PAGE.

Con RESERVE: Vuelve a la primera línea escrita después del RESERVE.

SKIP TO LINE <n> La siguiente escritura se hará en la línea n. Se puede volver atrás del listado.

11.3 Sentencia FORMAT Se pueden fijar formatos con esta sentencia. Surten efecto en la siguiente escritura con WRITE. Todas sus opciones se pueden usar con la sentencia WRITE, pero entonces sólo afectan al campo que se escribe. En cada nuevo evento se inicializan todas las opciones de formato a sus valores iniciales.

Las opciones que se pueden utilizar son:

Página 112 de 195


COLOR n [ON|OFF] Colorea el fondo de la línea INTENSIFIED [ON|OFF] Afecta al color de fondo: cada color tiene dos

apariencias, la normal y la intensificada INVERSE [ON|OFF] Afecta a los colores de fondo y de letra HOTSPOT [ON|OFF] Afecta a la visualización del puntero del ratón y al

efecto de un solo click INPUT [ON|OFF] Genera un campo de entrada RESET Resetea todos los formatos a sus valores iniciales

11.4 Dibujar líneas Se puede generar una línea horizontal con la sentencia ULINE, o con el campo de sistema SY-ULINE en una sentencia WRITE o con más de un signo menos ‘-‘ en una sentencia WRITE.

Para generar líneas verticales debemos escribir el campo SY-VLINE en una sentencia WRITE. Una serie de líneas verticales SY-VLINE en líneas consecutivas aparecerá como una línea vertical continua.

Se pueden usar estos elementos para enmarcar una lista, separar títulos de una lista de líneas horizontales o separar columnas con líneas verticales. También para crear tablas y árboles.

11.5 Niveles de control Cuando extraemos datos de la base de datos, no los obtenemos en el orden y con el formato que deseamos mostrar en la lista. Por eso necesitamos un almacenamiento temporal en la memoria del programa.

Hay dos técnicas posibles para formatear los datos por niveles: usando tablas internas o usando extract datasets.

Página 113 de 195


11.5.1 Tablas internas Existen en ABAP estructuras de control especiales para los niveles de control en tablas internas. Todas empiezan con AT y terminan con ENDAT. Estas sentencias sólo se pueden usar dentro de un LOOP. AT FIRST. [SUM.] … ENDAT.

AT NEW <f>. [SUM.] … ENDAT.

AT END OF <f>. [SUM.] … ENDAT.

AT LAST. [SUM.] … ENDAT.

Los bloques de sentencias AT FIRST y AT LAST se ejecutan exactamente una vez, el primero en la primera vuelta del bucle antes de procesar las líneas y el segundo en la última vuelta, después de procesar todas las líneas.

Los bloques de sentencias AT NEW <f> y AT END OF <f> se ejecutan si el campo <f> de la tabla interna, o un campo a su izquierda, tiene un valor diferente en la línea actual del que tenía en la línea precedente o en la posterior, respectivamente.

Después del AT, dentro del nivel de control, todos los campos a su derecha se llenan con * o con los valores iniciales.

Al final del proceso del nivel de control, después del ENDAT, el contenido que había al principio de la vuelta del bucle es recuperado.

La sentencia SUM dentro de un bloque AT…ENDAT proporciona en el área de trabajo el total para el nivel de control correspondiente de todos los campos de tipo P, I y F. REPORT.

…

TYPES: BEGIN OF struct_conn,

cityfrom LIKE spfli-cityfrom,

cityto LIKE spfli-cityto,

carrid LIKE spfli-carrid,

deptime LIKE spfli-deptime,

...

END OF struc_conn.

DATA: itab_conn TYPE TABLE OF struc_conn,

wa_conn TYPE struc_conn.

...

SORT itab_conn.

LOOP AT itab_conn INTO wa_conn.

AT FIRST. [...]. ENDAT.

AT NEW cityfrom. WRITE wa_conn-cityfrom. ENDAT.

AT NEW cityto. WRITE AT /pos1 wa_conn-cityto. ENDAT.

WRITE AT /pos2 wa_conn-deptime,

pos3 wa_conn-carrid,

pos4 wa_conn-fltime ...

AT END OF cityto. SUM. WRITE AT /pos4 wa_conn-fltime. ENDAT.

AT END OF cityfrom. [...] ENDAT.

AT LAST. [...] ENDAT.

Página 114 de 195


ENDLOOP.

La jerarquía de los niveles de control se basa en el orden de los campos en la tabla interna. La tabla debe de estar ordenada de acuerdo a sus campos.

Cuando se implementan niveles de control, se debe seguir dentro del LOOP la secuencia de los campos de la tabla interna (que coincide con la secuencia de ordenación) tal como se ve en el ejemplo.

11.5.2 Extract datasets Existen objeto de datos, llamados extract datasets, que se declaran con la sentencia FIELD-GROUPS y que pueden contener sólo datos globales del programa. Se deben especificar los datos globales que se almacenarán en cada field-group con la sentencia INSERT… INTO. La sentencia INSERT no se considera declarativa, y se pueden expandir los field-groups en el curso del programa. La consecuencia es que tenemos diversos tipos de registros con campos que se pueden asignar dinámicamente, en contraposición al tipo de línea único y estático de las tablas internas.

Existe un field-group especial que se denomina HEADER, que contiene los campos utilizados para ordenar y que se sitúa delante de cada registro del dataset. Debe contener todos los campos que se desea utilizar en el procedimiento de ordenación.

Con la sentencia EXTRACT se escriben todos los campos del field-group como un registro al dataset secuencial pasando los valores entre campos del mismo nombre. Una vez que se ha ejecutado una sentencia EXTRACT ya no es posible expandir con INSERT el field-group. REPORT z_extracts.

…

FIELD-GROUPS: header, connections, flights.

INSERT: spfli-cityfrom spfli-cityto spfli-deptime INTO header,

spfli-carrid spfli-connid INTO connections,

sflight-price sflight-currency seatsfree INTO flights.

START-OF-SELECTION.

IF date=’X’.

INSERT: sflight-fldate INTO header.

ELSE.

INSERT: dummy INTO header,

sflight-fldate INTO flights.

ENDIF.

Página 115 de 195


GET spfli FIELDS cityfrom carrid connid cityto deptime arrtime.

EXTRACT connections.

GET spfli ...

EXTRACT flights.

END-OF-SELECTION.

SORT.

LOOP.

[...]

ENDLOOP.

Se puede ordenar el dataset con la sentencia SORT y procesarlo con LOOP.

La sentencia SORT sin adiciones ordena el dataset en orden ascendente de acuerdo a la secuencia de campos definida en el field-group HEADER. La adición BY <f1> …<fn> define una nueva secuencia de ordenación. Los campos indicados deben pertenecer al HEADER o a un field-group formado únicamente por campos del HEADER. Se pueden utilizar las opciones ASCENDING y DESCENDING como en las tablas internas.

Dentro del bucle LOOP … ENDLOOP se proporciona un registro en cada paso y los contenidos de los campos del dataset se pasan a los campos de datos globales correspondientes. No se pueden anidar bucles LOOP.

Cuando ya se ha procesado un dataset con SORT o LOOP no se pueden añadir más registros con EXTRACT. Esta es una desventaja respecto a las tablas internas, donde a parte de poder hacer más operaciones (modificar, borrar, etc) se pueden hacer en cualquier momento.

Los elementos de lenguaje para realizar niveles de control para los extract datasets son similares a los utilizados en tablas internas: AT FIRST, AT NEW <f>, AT END OF <f> y AT LAST. La diferencia ahora es que para procesar registros individuales se debe utilizar la sentencia AT <fg>, donde <fg> representa un field-group.

La secuencia de los niveles dentro del LOOP debe coincidir con la secuencia de ordenación del dataset, pero no depende de la secuencia de campos del HEADER. Por eso los extract dataset son apropiados para situaciones en las que interesa ordenar por varias claves.

Ahora no disponemos de la sentencia SUM, sino de un campo SUM(<campo>) que contiene el total del campo especificado cuando acaba un nivel de control. También existe en campo CNT(<campo_header>) que contiene al final del nivel el número de valores diferentes que registró el campo especificado en ese nivel. Los totales sólo se pueden calcular al final de un nivel de grupo (AT END OF, AT LAST).

11.6 Impresión Un listado se puede imprimir mientras se genera: desde la pantalla de selección (sin que aparezca en pantalla), desde el programa o en un proceso de fondo. También se puede imprimir después de la generación de la lista en pantalla.

Para imprimir una lista se deben introducir los parámetros de impresión, que controlan la salida: dispositivo de salida, número de copias, formato (líneas, columnas), portada, etc. Se puede utilizar el módulo de función SET_PRINT_PARAMETERS para inicializar los valores por defecto para la impresión de una lista online. Se pueden

Página 116 de 195


introducir en pantalla o seleccionarlos en el programa (con la sentencia NEW-PAGE PRINT ON). NEW-PAGE PRINT ON [PARAMETERS <par_impr> | <params>]

[NO DIALOG].

La sentencia NEW-PAGE PRINT ON lanza un salto de página y establece que todas las sentencias WRITE (y SKIP, ULINE, …) siguientes se redirijan al spool.

Con la opción NO DIALOG, el listado se envía a la impresora sin dar oportunidad al usuario de que cambie los parámetros de impresión en tiempo de ejecución. Si no se indica esta opción, se le presenta al usuario una pantalla con los parámetros de impresión donde aparecen como valores por defecto los introducidos en el programa.

La sentencia NEW-PAGE PRINT OFF lanza un salto de página y todas las sentencias WRITE siguientes se listan en pantalla.

Se aconseja trabajar con el atributo PARAMETERS en vez de introducir los parámetros individualmente (IMMEDIATELY, KEEP IN SPOOL, …) porque de esta manera el usuario puede cancelar la impresión sin cancelar el programa.

La estructura para el atributo PARAMETERS debe ser llenada utilizando el módulo de funciones GET_PRINT_PARAMETERS. REPORT z_print_params.

DATA: val, print_params LIKE pri_params.

...

CALL FUNCTION ‘GET_PRINT_PARAMETERS’

EXPORTING

immediately = ‘ ‘

release = ‘X’

receiver = sy-uname

list_text = ‘Datos de vuelo’

IMPORTING

out_parameters = print_params

valid = val.

IF val = ‘X’.

NEW-PAGE PRINT ON PARAMETERS print_params NO DIALOG.

ELSE.

MESSAGE i650 WITH val.

ENDIF.

...

Con esta función proporcionamos al usuario una pantalla de parámetros que se puede usar para modificarlos y contiene la opción de cancelar la impresión. Se devuelve el registro de parámetros en la estructura out_parameters y, en los casos con éxito, el parámetro de salida valid contiene una X. Si no se ha podido crear un nuevo registro con los parámetros, out_parameters estará vacío y valid contendrá un espacio.

Página 117 de 195


12 Listas interactivas Aunque el propósito principal de una lista es mostrar datos, en ocasiones los usuarios deben interactuar con ellos: por eso existe la posibilidad de que las listas reaccionen a clicks con el ratón y otras acciones (pulsar botones, teclas de función, opciones de menú, etc.). Llamamos listas interactivas a aquellas en las que el usuario puede realizar acciones que permiten, por ejemplo, navegar a otras listas más detalladas o a otras pantallas. El uso de listas de detalle permite una mejor distribución de la información y aumenta la velocidad de acceso a los datos porque sólo se leen los datos adicionales de una línea particular seleccionada de una lista básica.

El programa interno de sistema llamado procesador de listas es el responsable de mostrarlas y de interpretar las acciones del usuario en la lista. Un único programa puede ser responsable de hasta 21 listas, una básica y hasta 20 de detalle. Cada lista tiene su propia área de memoria o buffer de lista.

Cada vez que se el usuario realiza una acción (escoge una opción de menú o pulsa una tecla de función o un botón de la barra de herramientas) se lanza un evento. Si en el bloque correspondiente al evento se escribe información, se produce un nuevo nivel de lista, es decir, se escribe sobre una nueva hoja que está sobre la anterior. La hoja anterior permanece y podremos volver a ella con la flecha verde de retroceso o con la X roja de cancelación.

Nivel 0

Nivel 1

Nivel 2

El nivel de lista se controla con la variable SY-LSIND. Éste será incrementando después de cada acción del usuario. Si tras un evento de usuario queremos permanecer en el mismo nivel deberemos indicarlo decrementando en uno esta variable: SY-LSIND = SY-LSIND – 1.

12.1 Interfase (GUI) Para que pueda existir una interacción con el usuario necesitamos una interfase. La crearemos con el Menu Painter.

Todas las interfases de usuario contienen como subobjetos:

Barra de título Contiene el título de la pantalla, pantalla de selección o lista mostrada.

Barra de menús

Los menús contienen las funciones ejecutables del programa actual. Pueden contener submenús. Siempre están presentes los menús Sistema y Ayuda.

Barra de herramientas estándar

Contiene iconos para las funciones más usadas. La barra estándar R/3 contiene siempre los mismos iconos con las mismas funciones asignadas. Las que no son accesibles se muestran en gris.

Barra de pulsadores

Contiene iconos y botones para las funciones más usadas de la pantalla actual.

Definiciones de Asignación de teclas de función a las funciones de la pantalla actual.

Página 118 de 195


teclas de función

Idealmente todas las funciones de menú se deberían poder ejecutar con una tecla de función. Se pueden mostrar con un clic del botón derecho.

Lista de funciones

Son todos los códigos que se asocian a las teclas/botones/menús y que se utilizan en el programa para evaluar las acciones del usuario. Existen códigos de función estándar para las listas.

12.1.1 Status Un programa tiene una interfase con todos los elementos anteriores. Para objetos individuales del programa (pantallas, pantallas de selección o listas) se pueden utilizar vistas parciales de esta interfase. Éstas se denominan status. Un status determina qué funciones están activas y cuales no. Desde el punto de vista técnico es una referencia a una barra de menú particular, una barra de pulsadores y ciertas asignaciones de teclas.

Podemos crear y modificar status desde la lista de objetos del Repository Browser o usando el Menu Painter o navegando desde el editor ABAP.

Se pueden crear status propios desde cero o usando otros ya existentes o con una combinación de las dos técnicas.

Para crear un status nuevo primero se crear y después se añaden las barras de menú y las funciones de menú. Entonces el status está completo y los cambios que se realicen en él le afectarán a él únicamente.

Cuando referenciamos un status ya existente lo que hacemos es crear barras de menú, barras de pulsadores y asignaciones de teclas de función como elementos independientes. Creamos entonces nuestro propio status y referenciamos las barras y asignaciones que deseemos utilizar: el Menu Painter guarda estas referencias de manera que cualquier cambio en los elementos se propaga inmediatamente a todos los status que los utilizan. Este funcionamiento es muy útil en aplicaciones grandes para asegurar la consistencia de ciertas funciones independientes del status.

Cuando creamos un status debemos escoger un tipo (diálogo, lista, …) y esta elección determinará que ciertos tipos del funciones estén a nuestra disposición.

12.1.2 Funciones Las funciones se identifican por sus códigos de función. El tipo de función nos informa de su propósito: ‘ ‘ si es estándar, ‘E’ si es de salida, ‘S’ si es estándar de SAP o ‘T’ si es código de transacción.

Las funciones se pueden crear con textos estáticos o dinámicos y para las primeras se puede asignar un icono que se mostrará en vez del texto si utilizamos la función en un botón. Si queremos mostrar información adicional con un icono la introduciremos en el texto del icono.

Las funciones se asignan a teclas de función o a botones. Se pueden especificar teclas de acceso rápido a una función para evitar usar el ratón.

La definición de asignaciones de teclas consiste en tres secciones:

Teclas de función reservadas

Son teclas de función cuyos valores asignados no pueden ser cambiados. Las podemos activar o desactivar pero no cambiar sus textos ni iconos.

Definición teclas de función

Son valores asignados sugeridos que satisfacen las normas ergonómicas de SAP.

Página 119 de 195


Página 120 de 195

recomendada

Teclas de función disponibles

Asignación libre.

Las funciones que han sido asignadas a teclas de función pueden también ser asignadas a botones en la barra de pulsadores. La barra puede contener hasta 35 botones. Los botones pueden contener iconos o texto.

12.1.3 Barra de menús Cuando creamos la barra de menús podemos dejar que el sistema nos proponga una plantilla y después modificarla. La barra de menús puede contener hasta ocho menús, pero sólo podemos definir seis, ya que los menús Sistema y Ayuda son añadidos siempre de manera automática por el sistema.

Un menú puede contener hasta 15 entradas, que pueden ser funciones, separadores o menús (en cascada). La profundidad de anidamiento para los menús está restringida a tres niveles, donde el último sólo puede contener funciones y separadores. Se pueden


crear los menús con texto estático o dinámico: para los segundos hay que asignar un nombre de campo cuyos contenidos se mostrarán como texto del menú en tiempo de ejecución.

12.1.4 Usar status Utilizamos la sentencia SET PF-STATUS ‘<nombre>’ para escoger un status para una lista o para una pantalla. El nombre de un status puede tener hasta 20 caracteres (números o mayúsculas).

Si no se ha escogido una interfase GUI, se muestra la interfase estándar. Si queremos desactivar un status previamente introducido y utilizar el estatus estándar de lista basta con que usemos la sentencia SET PF-STATUS SPACE. El campo SY-PFKEY siempre contiene el nombre del status actual.

Podemos desactivar funciones en tiempo de ejecución con EXCLUDING <código>. Y si queremos desactivar varias funciones al mismo tiempo las debemos transferir previamente al sistema utilizando una tabla interna y después utilizar EXCLUDING <tabla>.

12.1.5 Título Se pueden crear y mantener títulos usando el Menu Painter.

Usando la sentencia SET TITLEBAR <título> asignamos un título a una pantalla. Sobrescribe el título estándar, si la lista o pantalla lo tenía. El nombre del título puede tener hasta 20 caracteres de longitud y se debe escribir en mayúsculas. El título actual siempre se encuentra disponible en el campo de sistema SY-TITLE.

Se pueden mostrar variables en el título GUI utilizando la adición WITH <f>.

12.2 Eventos Se puede crear una lista interactiva creando una lista básica con WRITE, SKIP y ULINE que llena el buffer de lista en el bloque de evento apropiado (por ejemplo en START-OF-SELECTION). Los eventos START-OF-SELECTION, GET, END-OF-SELECTION, TOP-OF-PAGE y END-OF-PAGE sólo se pueden utilizar para crear listas básicas. Cuando se abandona la lista básica estos eventos ya no se procesan.

Después necesitamos poder reaccionar a la acción del usuario para crear las listas detalladas. Para eso utilizamos ciertos eventos, los fundamentales son AT LINE-SELECTION y AT USER-COMMAND. Para crear cabeceras para listas detalladas disponemos del evento TOP-OF-PAGE DURING LINE-SELECTION.

12.2.1 AT USER-COMMAND En general la acción del usuario se traduce en el hecho de que el campo SY-UCOMM contiene el código de función seleccionado a través del menú o pulsando un botón o una tecla de función.

Algunos códigos de función están reservados para uso del sistema y por tanto cuando se activan no lanzan un evento interactivo que podamos tratar en el programa, sino que lanzan la correspondiente función de sistema. Todos los demás códigos de función, excepto ‘PICK’, lanzan el evento AT USER-COMMAND.

Para controlar la acción que ha originado el evento y poder realizar el proceso correspondiente, evaluaremos el campo de sistema SY-UCOMM en una estructura CASE.

Podemos lanzar manualmente el evento relacionado con la sentencia SET USER-COMMAND.

Página 121 de 195


12.2.2 AT LINE-SELECTION Este evento es asignado a una función de elección de línea (doble-click o F2), o a hotspots (líneas que aparecen resaltadas). Es independiente del evento AT USER-COMMAND. Sólo se especifica una vez dentro del código de una lista interactiva. Se ha de especificar PICK para activar esta funcionalidad en el apartado correspondiente del Menu painter.

Las líneas que se escriben dentro del bloque correspondiente a este evento pertenecen a una lista de un nivel superior en uno al nivel desde donde se ha realizado la acción. AT LINE-SELECTION.

CASE sy-lsind.

WHEN ‘1’. WRITE: ‘Lista detallada 1’(001), / ‘SY-LSIND: ‘(000), sy-lsind.

WHEN ‘2’. WRITE: ‘Lista detallada 2’(002), / ‘SY-LSIND: ‘(000), sy-lsind.

ENDCASE.

ENDAT.

Diferenciamos el proceso en niveles de listado diferentes mediante la variable de sistema SY-LSIND. Si el evento se lanza en el nivel 2, SY-LSIND aumenta a 3 pero como no se ejecuta ninguna sentencia WRITE no se crea la lista detallada 3 y el sistema devuelve el valor 2 a SY-LSIND y muestra de nuevo la lista detallada 2.

12.2.3 Top-of-page During line-selection Es el evento correspondiente a TOP-OF-PAGE de una lista básica. Es necesario ya que el sistema no lanza TOP-OF-PAGE ni crea cabeceras de página por defecto para las listas detalladas.

El evento TOP-OF-PAGE DURING LINE-SELECTION es lanzado con la primera sentencia WRITE que escribe en un nuevo listado.

El campo SY-LISEL nos puede ser útil como cabecera, ya que contiene la representación en caracteres de la línea de detalle seleccionada.

12.3 Variables del sistema

System field Information

SY-LSIND Índice de la lista creada en el evento actual (lista básica = 0)

SY-LISTI Índice de la lista desde la que se lanzó el evento

SY-LILLI Número absoluto de la línea desde la que se lanzó el evento.

SY-LISEL Contenido de la línea desde la que se lanzó el evento

SY-CUROW Posición de la línea en la ventas desde la que se lanzó el evento (se empieza a contar por 1)

SY-CUCOL Posición de la columna en la ventana desde la que se lanzó el evento (se empieza a contar por 2)

SY-CPAGE Número de página de la primera página mostrada de la lista desde la que se lanzó el evento.

SY-STARO Número de la primera línea de la primera página mostrada de la lista

Página 122 de 195


desde la que se lanzó el evento (se empieza a contar por 1). Esta línea puede contener la cabecera.

SY-STACO Número de la primera columna mostrada en la lista desde la que se lanzó el evento (se empieza a contar por 1)

SY-UCOMM Código de función que lanzó el evento

SY-PFKEY Status de la lista que se está mostrando.

12.4 Recuperar datos de la lista Por defecto, los datos de la lista básica no están disponibles para las listas detalladas.

12.4.1 HIDE Podemos usar la sentencia HIDE para almacenar los contenidos de los campos en un área separada con referencia a la línea: el sistema guarda el nombre del campo y el valor para cada campo.

Normalmente la sentencia HIDE se utiliza para guardar el contenido de los campos clave o información que se necesite para seleccionar información adicional. Para poder guardar los contenidos de una línea, la sentencia HIDE se debe introducir antes de empezar una nueva línea. Esto se debe al hecho de que los datos se guardan con referencia a la línea que se está mostrando actualmente (el campo de sistema SY-LINNO). Se pueden guardar en el área HIDE datos que no se muestran en la lista.

Cada lista tiene su propia área HIDE y permanece almacenada en el buffer de lista hasta que éste se borra: para las listas de nivel superior a la que se está mostrando se borra automáticamente el buffer.

Cuando se lanza un evento interactivo, los datos guardados para la línea seleccionada en el área HIDE se pasan a los campos correspondientes. GET spfli FIELDS carrid connid cityfrom cityto.

WRITE: / spfli-carrid, 10 spfli-cityfrom, (24) spfli-cityto.

HIDE: spfli-carrid, spfli-connid.

AT LINE-SELECTION.

SELECT * FROM sflight

WHERE carrid = spfli-carrid

AND connid = spfli-connid.

Cuando el usuario hace doble-click en la línea de la compañía LH, el sistema determina que se ha escogido la línea 6 utilizando el campo de sistema SY-LILLI. Busca entonces en el área HIDE el punto donde se han guardado los datos correspondientes a esta línea y inserta los valores guardados en los campos correspondientes. Después se procesa el bloque de evento AT LINE-SELECTION donde se crea la lista detallada.

Cuando se escoge una línea para la que no se han guardado datos en el área HIDE, la selección de línea es inválida. Las líneas inválidas incluyen las cabeceras y el pie de página.

Página 123 de 195


Podemos asegurar que no se crean listas detalladas para selecciones inválidas de línea inicializando los campos que se guardan con HIDE. Así al seleccionar una línea inválida el sistema no puede encontrar un valor para el campo en el área HIDE y el campo conserva su valor inicial. Entonces con una sentencia CHECK en el bloque de evento podemos salir sin que se genere ninguna lista detallada. GET spfli FIELDS carrid connid cityfrom cityto.

WRITE: / spfli-carrid, 10 spfli-cityfrom, (24) spfli-cityto.

HIDE: spfli-carrid, spfli-connid.

END-OF-SELECTION.

CLEAR spfli-carrid.

AT LINE-SELECTION.

CHECK NOT spfli-carrid IS INITIAL.

SELECT * FROM sflight

WHERE carrid = spfli-carrid

AND connid = spfli-connid.

CLEAR spfli-carrid.

12.4.2 GET CURSOR Con la sentencia GET CURSOR se pueden crear listas detalladas con referencia a la posición actual del cursor.

Con el parámetro FIELD se proporciona el nombre del campo, y con el parámetro VALUE su valor.

El código de retorno SY-SUBRC vale 0 si el cursor está sobre un campo, y 4 si no.

Se debe ser cuidadoso al utilizar el valor de retorno porque estará formateado como se muestra en pantalla. Por este motivo es más recomendable utilizar la técnica HIDE.

DATA: nombre_campo(30), valor_campo(50).

AT LINE-SELECTION.

GET CURSOR FIELD nombre_campo

VALUE valor_campo.

CASE nombre_campo.

WHEN ‘SPFLI-CARRID’.

SELECT carrname INTO wa_carrname...

WRITE: valor_campo NO GAP, ‘: ’, wa_carrname.

WHEN ‘SPFLI-CONNID’.

ENDCASE.

12.5 Leer listas Cuando se ejecuta una sentencia READ todos los valores que han sido almacenados en el área HIDE para la línea indicada se transfieren a los campos correspondientes y están entonces disponibles para el programa. READ LINE <l> [INDEX <i>]

Página 124 de 195


[FIELD VALUE <f1> INTO <g1> <f2> INTO <g2> ...]

[LINE VALUE INTO <wa>].

Con la adición INDEX <i> se pueden leer las líneas de un nivel particular <i> de lista. Cuando se omite esta adición se lee de la última lista mostrada.

Para indicar los campos que desean ser leídos se añade FIELD VALUE <f1> INTO <g1>. El contenido del campo <f1> se lee de la línea indicada de la lista y se copia a <g1>. Si el campo destino coincide con el origen, se puede abreviar con FIELD VALUE <fi>. Los valores se guardan como tiras de caracteres.

Con LINE VALUE INTO <wa> transportamos una línea completa al área de trabajo <wa>.

12.6 Modificar listas La sentencia MODIFY LINE permite modificar una línea de un listado. Los valores guardados para la línea en el área HIDE se insertan en los campos correspondientes y están de nuevo disponibles en el programa.

La sentencia MODIFY CURRENT LINE modifica la última línea leída con READ LINE o con una selección de línea (aunque corresponda a un nivel diferente). MODIFY LINE <l>.

MODIFY CURRENT LINE [LINE FORMAT <fm1> <fm2> ...]

[FIELD VALUE <f1> FROM <g1> <f2> FROM <g2> ...]

[LINE VALUE FROM <wa>]

La adición LINE FORMAT formatea la línea seleccionada según las especificaciones.

La adición FIELD VALUE sustituye el contenido de los campos <fi> de la línea de la lista por los valores actuales de <gi> (todos los valores convertidos a carácter). Los contenidos de <fi> en el programa no son modificados.

La adición LINE VALUE FROM <wa> permite reemplazar la línea entera con los contenidos actuales del área de trabajo <wa>.

12.7 Navegación Se puede utilizar el campo de sistema SY-LSIND para determinar el nivel de lista que estamos mostrando. Podemos modificar el valor de este campo para conseguir un nivel de lista se muestre en otra posición, pero los valores asignados a SY-LSIND no pueden ser nunca mayores que el que actualmente contiene. Por tanto, no podemos saltar niveles de listado en orden ascendente.

Sólo se debe cambiar SY-LSIND en la última sentencia antes de mostrar la lista, ya que el hecho de cambiar su valor no lleva directamente a un salto de nivel inmediato. El nuevo nivel se asigna a la lista al final, cuando se ha mostrada el buffer de lista completo.

12.8 Ventanas Podemos mostrar la lista detallada en una caja de diálogo modal utilizando la sentencia WINDOW STARTING AT. Aquí se aplican las mismas reglas que en la salida de listas. DATA: linea_sup TYPE i, linea_inf TYPE i.

AT LINE-SELECTION.

Página 125 de 195


Página 126 de 195

linea_sup = sy-lilli + 1.

linea_inf = linea_sup + 12.

WINDOW STARTING AT 10 linea_sup

ENDING AT 65 linea_inf.

WRITE: ...

Se indica la posición de la esquina superior izquierda dando los números de columna y fila. Si el número de fila es menor o igual a 0 se muestra la lista a pantalla completa en vez de la ventana.

Se puede utilizar el parámetro opcional ENDING para especificar el ancho y largo de la ventana dando el número de fila y columna de la esquina inferior derecha.


13 Modularización Los programas ABAP no son una unidad secuencial, sino que tienen una estructura modular. Están formados por un conjunto de bloques de procesamiento, de secciones que se procesan de forma secuencial cuando son llamadas. Son las unidades mínimas y no se pueden dividir ni anidar. Es importante que los programas estén estructurados correctamente, ya que entonces su estructura lógica será más fácil de identificar y su elaboración y mantenimiento serán más sencillos.

Cada programa consiste en dos partes:

• la parte de declaraciones de datos globales, clases locales y definición de pantalla de selección.

• La parte de bloques de procesamiento del programa

En un programa simple puede haber un solo bloque de proceso, a parte de la declaración de datos. En estos casos no es necesario declarar el bloque explícitamente. De hecho siempre se asignan todas las instrucciones sueltas al bloque START-OF-SELECTION. En programas más complejos, serán necesarios diversos bloques de proceso diferentes y deberemos especificar su nombre y su tipo.

Existen los siguientes tipos de bloques de proceso:

Eventos El sistema ABAP los llama en un orden predeterminado para producir una lista en los programas de tipo 1

Subrutinas Módulos con interfase internos a un programa que se llaman con una sentencia ABAP desde cualquier otro bloque

Módulos de función Módulos con interfase transparente disponibles en todo el sistema que se llaman con una sentencia ABAP desde cualquier bloque de cualquier programa

Módulos de diálogo Constituyen la lógica de flujo de las pantallas. Se puede escribir uno para cada estado de cualquier pantalla del programa.

Métodos de objeto

Podríamos clasificar los bloques de procesamiento en dos clases: aquellos que son llamados desde fuera del programa por el sistema de ejecución de ABAP (eventos, módulos de diálogo), y aquellos que pueden ser llamados por las sentencias ABAP en programas ABAP (subrutinas, módulos de función y métodos). Estos últimos se suelen identificar con el nombre de procedimientos.

Al llamar a un procedimiento, el sistema interrumpe el procesamiento del bloque desde donde se hace la llamada, procesa el bloque llamado y después se continúa la ejecución con la siguiente instrucción ABAP.

Hay otro tipo de modularización que consiste en utilizar módulos de código fuente.

Esta sección describe la modularización en eventos, en módulos de código fuente y en procedimientos.

Con los diversos tipos de modularización se evita la redundancia, se incrementa la reutilización del código fuente, y se permite el encapsulamiento de los datos.

Página 127 de 195


Página 128 de 195

Programas de ejemplo DEMO_SUBROUTINE

13.1 Declaración de datos globales El sistema reconoce las declaraciones globales como tales por las palabras clave ABAP que se utilizan en ellas. Y las considera agrupadas aunque estén distribuidas por el código del programa: cuando se genera un programa se procesan juntas todas las definiciones de datos que aparezcan antes del primer bloque de procesamiento o en bloques de eventos. De todas maneras, para conseguir más claridad, se aconseja situar todas las declaraciones de datos globales juntas y al principio del programa.

Las sentencias declarativas que se encuentran en procedimientos (subrutinas, módulos de función) forman la declaración de datos locales de estos bloques. Estos datos sólo son visibles dentro del procedimiento donde se declaran. En los bloques de eventos, en cambio, no es posible declarar datos locales.

Para utilizar tablas del diccionario de datos, es necesario hacer referencia a que tablas del diccionario se va a acceder desde el programa. Para ello será necesario indicar la palabra clave TABLES seguida del nombre o nombres de las tablas empleadas. TABLES: VBAK.

13.2 Eventos El ABAP es un lenguaje estructurado orientado a eventos. No es un clásico lenguaje de programación con estructura lineal (TOP-DOWN), sino que la secuencia de instrucciones depende del cumplimiento de ciertas condiciones.

Los eventos sirven para controlar el flujo lógico del programa de forma externa, de tal manera que el bloque de procesamiento asociado se ejecutará cuando ocurra una determinada circunstancia. La llamada a un bloque de evento es lanzada por un evento, el cual es lanzado a su vez por una acción de usuario o por un programa de sistema.


Sólo debemos definir bloques de evento para los eventos ante los que queremos que reaccione nuestro programa. Un programa no está obligado a reaccionar ante un evento particular: puede hacerlo o no. En este aspecto los eventos son diferentes de las subrutinas porque si existe una llamada a una subrutina, ésta debe estar definida.

Los bloques de eventos se declaran con una palabra clave de evento. Están delimitados por esta palabra y por el comienzo del siguiente bloque de proceso, no hay una palabra clave que marque el final. No importa el orden en el que los situemos los bloques de evento dentro del programa porque la secuencia en la que son procesados está determinada por el sistema de ejecución.

Los eventos que lanza el sistema o que puede lanzar el usuario en los programas tipo 1 son los siguientes:

Palabra clave de evento El evento se lanza…

INITIALIZATION Justo antes de que se muestre la pantalla de selección. Se usa para poner valores iniciales en parámetros.

AT SELECTION-SCREEN Justo después de que se haya procesado la/s entrada/s del usuario y cuando todavía está activa la pantalla de selección.

START-OF-SELECTION Justo después de procesar la pantalla de selección, y ésta ya no está activa.

GET <tabla> Cuando la BBDD lógica nos ofrece una línea de la tabla de la BBDD <tabla>

GET <tabla> LATE Después de procesar todas las tablas que están jerárquicamente subordinadas a la tabla de la BBDD <tabla>.

END-OF-SELECTION Después de procesar todas las líneas que ofrece la BBDD.

TOP-OF-PAGE Durante el procesamiento de una lista cuando comienza una nueva página.

END-OF-PAGE Durante el procesamiento de una lista cuando finaliza una página.

AT LINE-SELECTION Cuando el usuario ha seleccionado una línea de la lista

AT USER-COMMAND Cuando el usuario ha pulsado una tecla de función o ha introducido un comando en el campo de comandos.

AT PF <nn> Cuando el usuario ha pulsado una tecla de función con código de función PF<nn>.

Si en un programa no se declara ningún bloque de evento, el sistema considera que todo el código forma un único bloque START-OF-SELECTION.

13.2.1 INITIALIZATION Si nuestro programa tiene una pantalla de selección, y queremos ejecutar un bloque de procesamiento antes de que se muestre ésta, debemos usar el evento INITIALIZATION. Se suele utilizar para inicializar los valores que aparecerán por defecto en la pantalla de selección.

Página 129 de 195


13.2.2 START-OF-SELECTION Este evento se usa para codificar un bloque de procesamiento justo después de haber procesado la pantalla de selección y antes de acceder a la base de datos.

Este evento se lanza cuando se procesa la instrucción REPORT. En ese momento se empieza a ejecutar el código que se encuentra entre REPORT y la palabra START-OF-SELECTION. Inmediatamente después se procesa el bloque contenido dentro de este evento.

En este evento se sitúan las instrucciones de acceso a bases de datos. Una vez terminada este código se ejecuta el bloque correspondiente al evento END-OF-SELECTION.

Visualizaremos el código del programa DEMO_EVENTS_

13.2.3 END-OF-SELECTION. El código asociado a este evento se procesa cuando se termina la selección de datos de tablas o bases de datos lógicas, es decir, cuando termina el evento START-OF-SELECTION.

Visualizaremos el código del programa DEMO_EVENTS_

13.2.4 TOP-OF-PAGE Se ejecuta al inicio de cada nueva página.

Se suele utilizar para dar formato a la cabecera de página, cuando no se utilizan las definidas en ‘Títulos y cabeceras’. (Se añade la opción NO STANDARD PAGE HEADING).

Se le puede añadir la opción DURING LINE-SELECTION, este evento se producirá al inicio de una nueva página de un nivel de lista secundaria. (Reports interactivos).

Se pueden tener por tanto dos eventos,

TOP-OF-PAGE que actúa en el nivel inicial.

TOP-OF-PAGE DURING LINE-SELECTION que actúa en los de niveles superiores.

13.2.5 END-OF-PAGE Se ejecuta cuando una página finaliza bien porque no tiene más líneas bien porque se ejecuta la instrucción RESERVE n LINES. Este evento no se ejecutará si el nº de líneas de la página no está definido en la sentencia REPORT, tampoco se ejecutará se fuerza una nueva página con NEW-PAGE.

13.2.6 AT SELECTION-SCREEN Se utiliza para controlar la pantalla de selección.

Sus opciones permiten mostrar valores de ayuda en los campos de selección, mostrar/ocultar campos de selección, realizar chequeos mientras la pantalla aún está activa. Podemos mostrar mensajes de error, y controlar que el flujo no pasará de este punto hasta que todos los datos introducidos por el usuario sean correctos.

Visualizamos y ejecutamos el programa DEMO_SELECTION_SCREEN_EVENTS:

Las líneas: AT SELECTION-SCREEN. MESSAGE i888 WITH 'AT SELECTION-SCREEN'.

Consiguen que aparezca el mensaje de información cuando aparece la pantalla de selección.

Página 130 de 195


Las líneas: AT SELECTION-SCREEN OUTPUT. MESSAGE i888 WITH 'AT SELECTION-SCREEN' 'OUTPUT'.

Consiguen que aparezca el mensaje …

Las líneas: AT SELECTION-SCREEN ON sel_opt1. MESSAGE i888 WITH 'AT SELECTION-SCREEN' 'ON SEL_OPT1'.

Consiguen que aparezca el mensaje cuando modificamos el valor del campo de selección sel_opt1

Las líneas: AT SELECTION-SCREEN ON HELP-REQUEST FOR test1. MESSAGE i888 WITH 'AT SELECTION-SCREEN' 'ON HELP-REQUEST FOR TEST1'.

Consiguen que aparezca el mensaje cuando se pulsa F1 (ayuda) sobre el parámetro test1.

Las líneas: AT SELECTION-SCREEN ON VALUE-REQUEST FOR test1. MESSAGE i888 WITH 'AT SELECTION-SCREEN' 'ON VALUE-REQUEST FOR TEST1'.

Consiguen que aparezca el mensaje cuando se pulsa F4 (valores posibles) en el campo test1.

Los rangos de selección tiene implícitos dos valores el mínimo y el máximo, para que aparezca la ayuda en los dos es necesario añadir dos eventos, uno para cada valor. La funcionalidad en ambos casos es la misma por tanto es susceptible de ser introducida en un único procedimiento.

Para implementar este procedimiento, nos hemos ayudado con una función predefinida en el STANDARD. 'HELP_VALUES_GET_WITH_TABLE’. Esta función permite mostrar datos en una ventana y seleccionar uno de ellos. Permite mostrar información de más de un campo, para ello en la tabla interna de definición de campos añadiremos tantas entradas como campos deseemos visualizar. Para indicar los valores lo haremos de forma secuencial es decir, el la entrada uno, el valor para el campo 1 en la entrada 2 el valor para el campo 2 …así hasta completar todos los campos, a continuación otra vez la entrada para el campo 1, campo 2 y así sucesivamente para cada secuencia .

13.3 Módulos de código fuente Modularizar el código fuente consiste en colocar una secuencia de sentencias ABAP en un módulo. Así, en lugar de colocar todas las sentencias en nuestro programa principal, sólo tenemos que llamar al módulo. Cuando se genera el programa, el código fuente de las unidades de modularización es tratado como si estuviera físicamente presente en el programa principal.

Los módulos de código fuente nos ayudan a evitar la escritura repetida del mismo conjunto de sentencias y hacen que nuestros programas sean más fáciles de leer y entender. No se utilizan para modularizar tareas o funciones. Para este propósito utilizaremos los procedimientos.

Página 131 de 195


Página 132 de 195

ABAP contiene dos clases de módulos de código fuente. Los módulos locales se llaman macros y los módulos globales se llaman programas include.

13.3.1 Macros Si queremos reutilizar el mismo conjunto de sentencias más de una vez en nuestro programa, podemos incluirlas en una macro. Por ejemplo, esto puede ser útil para grandes cálculos o sentencias WRITE complejas. Sólo podemos utilizar las macros dentro del programa en el que están definidas, y sólo pueden llamarse desde las líneas del programa que sigan a su definición.

El siguiente bloque de sentencia define una macro <macro>: DEFINE <macro>.

<sentencias>

END-OF-DEFINTION.

Debemos definir sentencias completas entre el DEFINE y el END-OF-DEFINITION. Estas sentencias pueden contener hasta 9 & (&1, &2, …, &9). Debemos definir la macro antes del punto en el que queramos utilizarla.

Para utilizar una macro, utilizaremos la forma siguiente:

<macro> [<p1> <p2>… <p9>].

Cuando se genere el programa, el sistema sustituirá <macro> por las sentencias definidas en cada &i por el parámetro <pi>. Podemos utilizar macros dentro de macros. Sin embargo, una macro no puede llamarse a sí misma.

Ejemplo: DATA:

RESULTADO TYPE I,

N1 TYPE I VALUE 5,

N2 TYPE I VALUE 6.

DEFINE OPERACION.

RESULTADO = &1 &2 &3.

SALIDA &1 &2 &3 RESULTADO.

END-OF-DEFINITION.

DEFINE SALIDA.


WRITE: / 'El resultado de &1 &2 &3 es', &4.

END-OF-DEFINITION.

OPERACION 4 + 3.

OPERACION 2 ** 7.

OPERACION N2 - N1.

Este trozo de código produce la siguiente salida:

El resultado de 4 + 3 es 7

El resultado de 2 ** 7 es 128

El resultado de N2 – N1 es 1

En este ejemplo, se definen dos macros, OPERACIÓN y SALIDA. SALIDA está anidada en OPERACIÓN. OPERACIÓN es llamada tres veces con diferentes parámetros. Hay que indicar que las &1, &2, … se sustituirán en las macros.

13.3.2 Programas Include Los programas Include son objetos globales del Repository de R/3. Sólo se utilizan para modularizar el código fuente, y no poseen interfase de parámetros.

Tienen las siguientes funciones:

Reutilización: Nos permiten utilizar el mismo código fuente en diferentes programas. Por ejemplo, esto puede ser útil si tenemos declaraciones de datos muy grandes que debemos utilizar en diferentes programas.

Orden: Nos permiten gestionar programas complejos de forma ordenada. Dividen el código en unidades más pequeñas y manejables. Los grupos de funciones y los module-pool utilizan programas include para almacenar partes del programa. El Workbench de ABAP nos ayuda cuando creamos este tipo de programas complejos creando programas include de forma automática y asignándoles nombre únicos. Existen un include especial que es el include TOP de un programa. Si le nombramos de acuerdo a las convenciones de nomenclatura, se incluirá en la navegación del programa y en la verificación de sintaxis.

13.3.2.1 Definición Si creamos un programa include por nosotros mismos, debemos asignarle el tipo “I”. También podemos crear o cambiar un programa Include haciendo un doble click en el nombre del programa que se encuentra después de la sentencia INCLUDE. En este caso, si el incluye ya existe, el Workbench de ABAP navegará hasta él y si no existe el sistema lo creará por nosotros.

Un programa include no se puede ejecutar de forma independiente, sino que siempre se encontrará dentro de otros programas. Los programas include no pueden contener a otros include.

Las únicas restricciones para escribir el código fuente de un programa include son que los programas include no pueden llamarse a sí mismos y que los programas include deben contener sentencias completas. No hay relación técnica alguna entre includes y bloques de proceso.

Debemos asegurarnos que las sentencias de nuestro programa include tienen cabida lógica en el código fuente de los programas desde los que se le llama. Elegir la opción Verificar mientras editamos un programa include en el editor de ABAP normalmente no es suficiente para asegurar la lógica del programa que contiene el include. Para que la

Página 133 de 195


verificación de sintaxis produzca resultados válidos, debemos verificar la sintaxis desde el programa que contiene la sentencia include. ***INCLUDE TEST_INCL.

TEXTO = 'Hola!'.

En este caso, la verificación de sintaxis informa de un error debido a que no se ha declarado el campo TEXTO. Sin embargo, podemos incluir TEST_INCL en cualquier programa que tenga un campo llamado TEXTO con el tipo correcto.

13.3.2.2 Utilización Para utilizar un programa include en otro programa, introduciremos la sentencia:

INCLUDE <include>.

La sentencia INCLUDE tiene el mismo efecto que si copiáramos el código fuente del programa include <include> dentro de nuestro programa. En la verificación de sintaxis, el contenido del programa include se analizará también. Los programas include no se cargan en tiempo de ejecución, sino que se expanden cuando se genera el programa. Una vez se ha generado éste, la versión cargada contiene las versiones estáticas de todos los includes. Si, posteriormente, cambiamos un programa include, se regenerarán automáticamente todos los programas que lo utilicen.

La sentencia INCLUDE debe ser la única sentencia de la línea y no puede extenderse por más de una línea.

Supongamos que tenemos el siguiente programa: ***INCLUDE STARTTXT.

WRITE: / 'Programa lanzado por', SY-UNAME,

/ 'en el host', SY-HOST,

'fecha:', SY-DATUM, 'hora:', SY-UZEIT.

ULINE.

Podemos incluir este programa en cualquier otro programa ABAP para generar una cabecera de listado estándar: PROGRAM SAPMZTST.

INCLUDE STARTTXT.

...

Esto produciría la siguiente salida:

Programa lanzado por CAP01

en el host madsap1 fecha: 20/03/2000 hora: 10:00:39

______________________________________________________________

...

13.4 Procedimientos Los procedimientos contienen un conjunto de sentencias, y son llamados desde otros programas ABAP.

Página 134 de 195


Página 135 de 195

Los procedimientos se definen en los programas ABAP. Cuando se genera un programa, permanecen como módulos autónomos. Podemos llamar a los procedimientos desde el programa en el que fueron definidos, o desde programas externos. Los procedimientos tienen una interfase para el paso de datos, y también pueden contener datos locales.

ABAP contiene las siguientes clases de procedimientos:

Las subrutinas se utilizan generalmente para la modularización local, es decir, que generalmente se llaman desde el programa en el que fuero definidas. Podemos utilizar las subrutinas para escribir funciones que se utilicen repetidamente dentro del programa, o simplemente para hacer más legible el programa. Podemos definir las subrutinas en cualquier programa ABAP.

Los módulos de función se utilizan en la modularización a nivel global, es decir, siempre se les llama desde un programa diferente. Los módulos de función contienen funciones que se utilizan de la misma forma por muy diferentes programas. Son importantes en el sistema R/3 para la encapsulación de la lógica de proceso y para hacerla reutilizable. Los módulos de función deben definirse en un grupo de función, y pueden ser llamados desde cualquier programa.

Los métodos describen las funciones y el comportamiento de las clases y sus instancias de los Objetos ABAP. Los métodos se definen en las clases. Cuando los llamamos, debemos observar ciertas reglas especiales de la programación orientada a objetos.

Podemos llamar a los procedimientos interna o externamente. Si llamamos a los

procedimientos externamente, es importante que comprendamos cómo está organizada la memoria en el sistema R/3, cómo se procesan las pantallas y cómo se utilizan las áreas de trabajo de la interfase.

13.4.1 Subrutinas Las subrutinas son procedimientos que podemos definir y llamar en y desde cualquier programa ABAP. Normalmente, las subrutinas se llaman internamente, es decir, contendrán secciones de código o algoritmos que se utilizan frecuentemente de forma local. Si queremos que una función pueda ser utilizada en todo el sistema, deberíamos utilizar un módulo de función.


13.4.1.1 Definición Una subrutina es un bloque de código que comienza con “FORM <nombre_rutina> <definición_interfase>” y termina con “ENDFORM”. FORM <subr> [USING ... [VALUE(]<pi>[)] [TYPE <t>|LIKE <f>]... ]

[CHANGING... [VALUE(]<pi>[)] [TYPE <t>|LIKE <f>]... ].

...

ENDFORM.

<subr> es el nombre de la subrutina, que puede tener hasta 30 caracteres. Las opciones USING y CHANGING definen la interfase de parámetros. Deberíamos colocar las definiciones de las subrutinas al final del programa, especialmente en el caso de programas ejecutables (tipo 1).

Para insertar cabeceras de subrutinas y comentarios, podemos utilizar los patrones de instrucciones disponibles en el editor de ABAP. En la cabecera de la subrutina, explicaremos el propósito de la misma y daremos la información y referencias adecuadas.

Para que los programas sean sencillos de entender deberíamos situar todas las definiciones de rutinas al final del código. Es importante separarlas de los bloques de eventos.

13.4.1.2 Datos locales y globales Los datos globales de un programa son todos los objetos de datos declarados fuera de las subrutinas. Éstos son visibles en todos los bloques del programa; en particular todas las subrutinas tienen acceso a los datos globales del programa en el que han sido definidas.

Podemos utilizar la sentencia DATA dentro de una subrutina para declarar datos locales. Éstos sólo son visibles dentro de la subrutina y existen sólo mientras ésta se ejecuta. Si un objeto local tiene el mismo nombre que un objeto global, el global es invisible dentro de la subrutina: durante su ejecución sólo podremos acceder al objeto local.

También podemos conseguir una copia de ciertas variables globales utilizando la sentencia LOCAL. De esta manera podemos trabajar con la variable global y nos aseguramos de que al acabar el proceso de la subrutina ésta contiene el valor que tenía justo antes de llamarla.

13.4.1.3 Interfase de parámetros Dado que los datos globales son visibles, no necesitamos definir una interfase de parámetros si no queremos cambiar ningún dato en la subrutina, o si se ven involucrados pocos datos. FORM CABECERA.

WRITE: / 'Programa lanzado por', SY-UNAME,

/ 'en el host', SY-HOST,

'fecha:', SY-DATUM, 'hora:', SY-UZEIT.

ULINE.

ENDFORM.

Este ejemplo define una subrutina llamada CABECERA, que, como el ejemplo de programa Include, muestra una cabecera de listado.

Página 136 de 195


Sin embargo, si queremos que una subrutina realice operaciones complejas sobre los datos sin afectar a los datos globales del programa, debemos definir une interfase de parámetros a través de la cual pasaremos únicamente los datos necesarios. En interés de un buen estilo de programación y encapsulación, siempre deberíamos utilizar la interfase de parámetros, al menos cuando la subrutina cambia datos.

Llamaremos parámetros formales a los que se utilizan en la declaración de una subrutina y parámetros actuales a los que se pasan en una llamada concreta. Las opciones USING y CHANGING de la sentencia FORM definen los parámetros formales de una subrutina. El orden en el que deben aparecer las opciones es fijo. Cada opción puede estar seguida de una lista de cualquier número de parámetros formales. Cuando llamamos a una subrutina, debemos rellenar todos los parámetros formales con los valores de los parámetros actuales. Al final de la subrutina, los parámetros formales son devueltos a los correspondientes parámetros actuales.

Dentro de una subrutina, los parámetros formales se comportan como datos locales dinámicos. Podemos utilizarlos de la misma forma que los objetos de datos locales normales que declararíamos con la sentencia DATA. Ocultan a los objetos de datos globales con el mismo nombre. El valor de los parámetros de la subrutina se corresponde con el valor pasado para los parámetros actuales correspondientes.

Cuando definimos la interfase de parámetros declaramos a continuación de la palabra clave USING los parámetros que la subrutina necesita leer. Y declaramos con CHANGING todos los parámetros que la subrutina cambiará y los valores cambiados que se pasarán al programa que realice la llamada.

13.4.1.4 Tipificación de parámetros y chequeos Los parámetros formales pueden tener cualquiera de los tipos de datos de ABAP. Para tipificar los parámetros podemos utilizar los recursos habituales para declarar datos:

TYPE para que el parámetro se ajuste a un tipo predefinido o definido por el usuario.

LIKE para que el parámetro sea compatible con un objeto de datos del Diccionario.

Si especificamos el tipo de un parámetro formal, el sistema comprueba al llamar a la subrutina que el correspondiente parámetro actual es compatible. Para las subrutinas internas, el sistema comprueba esto en la verificación de sintaxis. Para subrutinas externas, no se puede realizar esta verificación hasta el momento de la ejecución.

El tipo de chequeo que se realiza en la llamada depende del tipo asignado al parámetro.

Se realizan chequeos completos para los tipos predefinidos D, F, I y T y para tipos definidos con LIKE o TYPE <definido >. En estos casos podremos acceder a sus atributos estáticamente en el programa, ya que éstos son reconocidos en el código fuente.

En cambio sólo se comprueba el tipo pero no la longitud ni el número de decimales para los tipos predefinidos C, N, P o X. Estas características se heredan del parámetro actual. Si se omite el tipo del parámetro o se especifica TYPE ANY, el sistema tomará todas las características técnicas del parámetro actual. También para todos los parámetros formales tipificados con TYPE * TABLE, se comprueba únicamente que el parámetro actual es una tabla interna, pero el resto de atributos (tipo de línea, clave, etc.) se heredan del parámetro actual. Los atributos se heredan de forma dinámica en tiempo de ejecución, no podemos acceder a ellos estáticamente en el código.

TYPES: BEGIN OF LINEA,

COL1,

Página 137 de 195


COL2,

END OF LINEA.

DATA: ATR TYPE LINEA,

TABI TYPE HASHED TABLE OF LINEA WITH UNIQUE KEY COL1,

CLAVE(4) VALUE 'COL1'.

ATR-COL1 = 'X'. INSERT ATR INTO TABLE TABI.

ATR-COL1 = 'Y'. INSERT ATR INTO TABLE TABI.

PERFORM DEMO USING TABI.

FORM DEMO USING P TYPE ANY TABLE.

...

READ TABLE P WITH TABLE KEY (CLAVE) = 'X' INTO ATR.

...

ENDFORM.

Se accede a la clave de la tabla dinámicamente en la subrutina. Sin embargo, el direccionamiento estático

READ TABLE P WITH TABLE KEY COL1 = 'X' INTO ATR.

es sintácticamente incorrecto, ya que el parámetro formal P no adopta la clave de la tabla TABI hasta el momento de la ejecución de la subrutina.

Parámetros formales estructurados

Ya que los parámetros formales pueden tener cualquier tipo de datos válido de ABAP, también pueden tener estructuras y tablas internas con un tipo de línea estructurado, con tal de que se especifique completamente el tipo del parámetro formal. Podemos acceder estáticamente a los componentes de la estructura en las subrutinas.

13.4.1.5 Pasar estructuras y tablas Para pasar estructuras de datos () se debe especificar su tipo en la declaración del parámetro formal, usando TYPE o LIKE.

Para pasar una tabla interna a una subrutina se debe especificar el tipo para el parámetro formal correspondiente. Se puede hacer de diversas maneras: con TYPE TABLE; con LIKE <objeto>, con TYPE <bd> o con LIKE <tipo_diccionario>. Las tablas internas se pasan sin línea de cabecera, por lo que deberemos definir un área de trabajo local.

Si pasamos genéricamente un parámetro actual estructurado a un parámetro formal cuyo tipo no se ha especificado correctamente, no podremos acceder estáticamente a los componentes de la estructura en la subrutina. Para tablas internas, esto significa que sólo es posible operar sobre líneas.

Para acceder a los componentes de una estructura pasada genéricamente, deberemos definir field-symbols, y utilizar la asignación

Página 138 de 195


ASSIGN COMPONENT <ind>|<nombre> OF STRUCTURE <e> TO <FS>.

<ind> se interpreta como el número del componente y el contenido de <nombre> se interpreta como el nombre del componente en la estructura genérica <e>. DATA: BEGIN OF LINEA,

COL1 VALUE 'X',

COL2 VALUE 'Y',

END OF LINEA.

DATA COMP(4) VALUE 'COL1'.

PERFORM DEMO USING LINEA.

FORM DEMO USING P TYPE ANY.

FIELD-SYMBOLS <FS>.

ASSIGN COMPONENT COMP OF STRUCTURE P TO <FS>.

WRITE <FS>.

ASSIGN COMPONENT 2 OF STRUCTURE P TO <FS>.

WRITE <FS>.

ENDFORM.

La salida es:

X Y

Los componentes COL1 y COL2 de la estructura P (pasados genéricamente) se asignan al field-symbol <FS>. No podemos acceder directamente a los componente ni estática ni dinámicamente.

Ajuste de Parámetros en Estructuras

En lugar de utilizar TYPE o LIKE, podemos especificar el tipo de una estructura como se indica a continuación:

... <pi> [STRUCTURE <e>] ...

donde <e> es una estructura local del programa (un objeto de datos no un tipo) o una estructura del Diccionario de ABAP. El parámetro formal estará estructurado de acuerdo con <e>, y podremos acceder a sus componentes individuales dentro de la subrutina. Cuando se pase el parámetro actual, el sistema sólo verificará que el parámetro actual es al menos tan largo como la estructura. Por lo tanto, STRUCTURE nos permite forzar una visión estructurada de cualquier parámetro actual. DATA: BEGIN OF LINEA,

COL1,

COL2,

END OF LINE.

DATA TEXTO(2) VALUE 'XY'.

PERFORM DEMO USING TEXTO.

Página 139 de 195


FORM DEMO USING P STRUCTURE LINEA.

WRITE: P-COL1, P-COL2.

ENDFORM.

La salida es:

X Y

La cadena TEXTO se ajusta a la estructura LINEA.

Para asegurar la compatibilidad con las versiones anteriores, aún sigue estando permitida la siguiente opción (que ha de colocarse antes de USING y CHANGING):

FORM <subr> TABLES ... <tabii> [TYPE <t>|LIKE <c>] ...

Los parámetros formales <tabii> se definen como tablas internas estándar con líneas de cabecera. Si utilizamos una tabla interna sin línea de cabecera como el correspondiente parámetro actual de un parámetro formal de este tipo, el sistema crea una línea de cabecera local para el parámetro formal en la subrutina. Si pasamos una tabla interna como línea de cabecera, el cuerpo y el área de trabajo de la tabla se pasarán a la subrutina. Los parámetros formales definidos utilizando TABLES no pueden ser pasados por referencia. Si queremos acceder a los componentes de las líneas estructuradas, debemos especificar el tipo del parámetro TABLES de forma adecuada.

Desde la versión 3.0, debemos utilizar USING o CHANGING en vez de la opción TABLES para las tablas internas.

13.4.1.6 Clases de parámetros Se pueden clasificar los parámetros en función de la forma en que se utilicen: por valor, por referencia o por valor y resultado.

Valor Usando la opción VALUE(<nombre del parámetro>) en el lugar del nombre del parámetro en la cláusula USING conseguimos que el sistema realice una copia local del parámetro actual. Se reserva un espacio de memoria donde se copia su valor. Esto implica que las modificaciones realizadas sobre el parámetro formal no afectarán al parámetro actual.

Referencia Si no se usa VALUE, no se reserva espacio de memoria para una copia local del parámetro, se utiliza la localización en memoria (dirección) del parámetro actual. Esto implica que se trabajas directamente sobre el campo del programa llamante. Si el valor del parámetro formal es modificado, el contenido del parámetro actual también cambiará.

En una llamada por referencia, USING y CHANGING son equivalentes, pero deberíamos utilizar USING para parámetros de entrada que no van a ser cambiados en la subrutina, y CHANGING para parámetros de salida que serán cambiados en la subrutina.

Form Name using value(fi) Por valor.

Form Name using (fi) Por referencia.

Form Name using changing value (fi) Por valor y resultado.

Se puede llamar a una rutina chequeando o no los parámetros, para forzar esta comprobación, definir el tipo de dato en la declaración de la rutina. En ambos casos obtenemos mensajes de error si los datos son incompatibles.

Página 140 de 195


Se pueden pasar, fields strings, header lines, tablas... Para pasar las estructuras o fields strings como registros y tratarlos como tales se ha de especificar like o type.

Form write-sflight using rec like sflight. De esta manera también se realizan chequeos.

Endform.

Sino realizamos esto no nos podremos referenciar a un campo del field string o registro.

Perform calc_write1 using tab[]. Solo pasaremos el cuerpo.

Perform calc_write2 table tab. Pasamos cuerpo y cabecera.

Form calc_write1 using tabbody like tab[].

Form calc_write2 tables itab structure tab.

Mediante el segundo método, pasamos esta tabla por referencia. Con STRUCTURE asignamos un tipo a la tabla.

13.4.1.7 Llamada Llamaremos a las subrutinas desde cualquier bloque de proceso utilizando la sentencia: PERFORM.<nombre_subrutina>.. [USING ... <pi>... ]

[CHANGING... <pi>... ].

Las subrutinas pueden llamar a otras subrutinas (llamadas anidadas) y también pueden llamarse a sí mismas (llamadas recursivas). Una vez que una subrutina ha finalizado su ejecución, el programa llamante recobra el control con la siguiente sentencia que aparezca después del PERFORM.

El número de parámetros actuales usados en la llamada debe coincidir con el de parámetros formales declarados en la definición de la subrutina. No se pueden definir parámetros opcionales.

Es crucial la secuencia de los parámetros en la llamada, ya que se asignan los valores a los parámetros formales en el orden en que son listados en la sentencia PERFORM. Si una subrutina contiene el parámetro TABLES en su interfase, debemos especificar la opción TABLES en la sentencia PERFORM antes de utilizar los parámetros USING y CHANGING. Los parámetros TABLES se admiten sólo para asegurar la compatibilidad con las versiones anteriores, y ya no deberían utilizarse en los nuevos desarrollos.

El sistema también comprueba que los tipos de los parámetros actuales sean compatibles con los de los parámetros formales. Para ello realiza diferentes chequeos en función del tipo del parámetro, como ya hemos visto.

13.4.1.8 Llamada externa Con la sentencia PERFORM, podemos llamar a las subrutinas que estén codificadas en el mismo programa ABAP (llamadas internas), o a subrutinas que estén codificadas en otros programas ABAP (llamadas externas).

Mientras que para llamar a una subrutina definida en el mismo programa, sólo necesitamos especificar su nombre en la sentencia PERFORM, para llamar a una subrutina externa debemos indicar el nombre del programa que la contiene con la adición IN PROGRAM <programa>.

La principal función de las subrutinas es la modularización y estructuración lógica de los programas. Sin embargo, las subrutinas también pueden ser llamadas

Página 141 de 195


externamente desde otros programas ABAP. En un caso extremo, podemos tener un programa ABAP que sólo contenga subrutinas. Estos programas no pueden ejecutarse por sí mismos, sin que son utilizados por otros programas ABAP como pools de subrutinas externas.

Sin embargo, si queremos hacer que una función esté disponible en cualquier parte del sistema, deberíamos utilizar los módulos de función en lugar de subrutinas externas. Los módulos de función están almacenados en una biblioteca central.

13.4.1.9 Llamada dinámica Podemos especificar el nombre de una subrutina dinámicamente y, en el caso de llamadas externas, el nombre del programa en el que se encuentra, como se indica a continuación: PERFORM (<subr>)[IN PROGRAM (<prog>)][USING ... <pi>... ]

[CHANGING... <pi>... ]

[IF FOUND].

Los nombres de la subrutina y del programa externo serán los contenidos de los campos <subr> y <prog> respectivamente. Si utilizamos la opción IF FOUND, podemos evitar que se lance un error en tiempo de ejecución desde el programa <prog> si no contiene una subrutina con el nombre <subr>. Si quitamos los paréntesis se vuelve igual que la variante estática.

Supongamos que tenemos un programa que contiene las siguientes subrutinas: PROGRAM FORMPOOL.

FORM SUB1.

WRITE: / 'Subrutina 1'.

ENDFORM.

FORM SUB2.

WRITE: / 'Subrutina 2'.

ENDFORM.

Especificación dinámica de subrutinas: PROGRAM TEST_FORM.

DATA: NOMBRE_PROGRAMA(8) VALUE 'FORMPOOL',

NOMBRE_SUBRUTINA(8).

NOMBRE_SUBRUTINA = 'SUB1'.

PERFORM (NOMBRE_SUBRUTINA) IN PROGRAM (NOMBRE_PROGRAMA) IF FOUND.

NOMBRE_SUBRUTINA = 'SUB2'.

PERFORM (NOMBRE_SUBRUTINA) IN PROGRAM (NOMBRE_PROGRAMA) IF FOUND.

Se produce la siguiente salida:

Subrutina 1

Subrutina 2

El campo de caracteres NOMBRE_PROGRAMA contiene el nombre del programa en el que se encuentran las subrutinas. Los nombres de las subrutinas se asignan al campo de caracteres NOMBRE_SUBRUTINA.

Página 142 de 195


Llamada a subrutinas de una lista: Podemos llamar a una subrutina a partir de una lista como se indica a continuación: PERFORM <ind> OF <subr1> <subr 2>... <subr n>.

El sistema llama a la subrutina especificada en la lista de subrutinas que se encuentre en la posición <ind>. Sólo podemos utilizar esta variante de la sentencia PERFORM para llamadas internas a subrutinas, y sólo para subrutinas sin interfase de parámetros. El campo <ind> puede ser una variable o un literal. PROGRAM TEST_FORM.

DO 2 TIMES.

PERFORM SY-INDEX OF SUB1 SUB2.

ENDDO.

FORM SUB1.

WRITE / 'Subrutina 1'.

ENDFORM.

FORM SUB2.

WRITE / 'Subrutina 2'.

ENDFORM.

Este programa produce la siguiente salida:

Subrutina 1

Subrutina 2

En este ejemplo, las dos subrutinas internas, SUB1 y SUB2, se llaman consecutivamente a partir de una lista.

Podemos especificar los parámetros actuales especificando desplazamiento y longitud de variables. PROGRAM TEST_FORM.

DATA: A1 TYPE P DECIMALS 3,

A2 TYPE I,

A3 TYPE D,

A4 TYPE SPFLI-CARRID,

A5 TYPE C.

...

PERFORM SUBR USING A1 A2 A3 A4 A5.

...

PERFORM SUBR CHANGING A1 A2 A3 A4 A5.

...

PERFORM SUBR USING A1 A2 A3

CHANGING A4 A5.

...

FORM SUBR USING VALUE(F1) TYPE P

VALUE(F2) TYPE I

F3 LIKE A3

CHANGING VALUE(F4) TYPE SPFLI-CARRID

Página 143 de 195


F5.

...

ENDFORM.

Este ejemplo define una subrutina SUBR con una interfase de parámetros que contiene cinco parámetros formales F1 a F5. La subrutina es llamada internamente tres veces. Los parámetros actuales son los objetos de datos A1 a A5. Las tres llamadas a la subrutina son igualmente válidas. Existen otras sentencias PERFORM que también son igualmente válidas, con tal de que la secuencia de los parámetros actuales permanezca fija. En cada llamada, A1 se pasa a F1, A2 a F2, y así sucesivamente. Cuando termina la subrutina, A3, A4 y A5 reciben respectivamente los valores de F3, F4 y F5. La tercera de las llamadas a la subrutina sólo cambia A4 y A5. Si A3 cambia o no dependerá de la forma en que se programe la subrutina.

El siguiente ejemplo muestra cómo los parámetros formales definidos de forma genérica heredan sus atributos técnicos de los correspondientes parámetros actuales.

REPORT FORMTEST.

DATA:

FECHA1 TYPE D, FECHA2 TYPE T,

STRING1(6) TYPE C, STRING2(8) TYPE C,

NUMERO1 TYPE P DECIMALS 2, NUMERO2 TYPE P,

CONT1 TYPE I, CONT2 TYPE I.

PERFORM TEST_TIPO USING FECHA1 STRING1 NUMERO1 CONT1.

SKIP.

PERFORM TEST_TIPO USING FECHA2 STRING2 NUMERO2 CONT2.

FORM TEST_TIPO USING AHORA

TXT TYPE C

VALUE(NUM) TYPE P

INT TYPE I.

DATA: T.

DESCRIBE FIELD AHORA TYPE T.

WRITE: / 'El tipo de AHORA es', T.

DESCRIBE FIELD TXT LENGTH T.

WRITE: / 'La longitud de TXT es', T.

DESCRIBE FIELD NUM DECIMALS T.

WRITE: / 'Los decimales de NUM son', T.

DESCRIBE FIELD INT TYPE T.

WRITE: / 'El tipo de INT es', T.

ENDFORM.

Página 144 de 195



El tipo de AHORA es D

La longitud de TXT es 6

Los decimales de NUM son 2

El tipo de INT es I

El tipo de AHORA es T

La longitud de TXT es 8

Los decimales de NUM son 0

El tipo de INT es I

Se llama dos veces a la subrutina interna TEST_TIPO con diferentes parámetros actuales. Todos los parámetros actuales y formales son compatibles y no se produce ningún mensaje de error durante la verificación de sintaxis. Si hubiésemos declarado CONT2 de tipo F en lugar de tipo I, la verificación de sintaxis hubiese devuelto un error, ya que el parámetro formal INT se ha especificado como de tipo I. Los parámetros formales con tipos genéricos adoptan atributos técnicos diferentes dependiendo de sus correspondientes atributos técnicos.

13.4.1.10 Fin de subrutina Normalmente, una subrutina finaliza con la sentencia ENDFORM. Sin embargo, podemos hacer que termine antes utilizando las sentencias EXIT o CHECK. Cuando finalizamos una subrutina con estas sentencias, los valores actuales de los parámetros de salida (parámetros CHANGING) son devueltos a los correspondientes parámetros actuales.

Utilizaremos EXIT (fuera de un bucle) para finalizar una subrutina de forma incondicional. El programa llamante recupera el control en la siguiente sentencia que aparezca después del PERFORM. PROGRAM TEST_FORM.

PERFORM FINALIZAR.

WRITE 'Fin'.

FORM FINALIZAR.

WRITE '1'.

WRITE '2'.

WRITE '3'.

EXIT.

WRITE '4'.

ENDFORM.


1 2 3 Fin

En este ejemplo, la subrutina FINALIZAR termina después de la tercera sentencia WRITE.

Utilizaremos CHECK (fuera de un bucle) para finalizar una subrutina de forma condicional. Si la expresión lógica de la sentencia CHECK es falsa, la subrutina

Página 145 de 195


finalizará, y el programa llamante continuará el procesamiento después de la sentencia PERFORM. PROGRAM TEST_FORM.

DATA: NUM1 TYPE I,

NUM2 TYPE I,

RES TYPE P DECIMALS 2.

NUM1 = 3. NUM2 = 4.

PERFORM DIVIDE USING NUM1 NUM2 CHANGING RES.

NUM1 = 5. NUM2 = 0.


NUM1 = 2. NUM2 = 3.


FORM DIVIDE USING N1 N2 CHANGING R.

CHECK N2 NE 0.

R = N1 / N2.

WRITE: / N1, '/', N2, '=', R.

ENDFORM.


3 / 4 = 0.75

2 / 3 = 0.67

En este ejemplo, el sistema abandona la subrutina DIVIDE en la segunda llamada después de la sentencia CHECK, ya que el valor de N2 es cero.

Si las sentencias EXIT o CHECK se encuentran dentro de un bucle de una subrutina, se aplicarán al bucle, y no a la subrutina. EXIT y CHECK finalizan los bucles de formas diferentes, pero se comportan de forma idéntica cuando finalizan subrutinas.

13.4.2 Funciones Los módulos de función son procedimientos externos porque pueden ser llamados desde cualquier programa del sistema con la sentencia CALL FUNCTION. Se dice que tienen una interfase transparente porque sus parámetros no forman parte de su código ABAP sino que son creados a parte y pueden ser mantenidos de manera independiente. Gracias a la existencia de parámetros opcionales se puede modificar la interfase sin tocar las sentencias ABAP.

Los módulos de función se definen en grupos de funciones. Los grupos de funciones actúan exclusivamente como contenedores de varios módulos de función que, por su temática, deben estar juntos. Los grupos de funciones y los módulos de función se crean en la Biblioteca de Funciones (SE37), una de las herramientas del ABAP Workbench.

Los módulos de función nos permiten encapsular y reutilizar funciones globales en el sistema R/3, operaciones susceptibles de ser utilizadas en muchos programas. Además de evitar que se repita el mismo código en diferentes programas (el código se escribe una sola vez en la Biblioteca, no en los programas que lo llaman), se facilita el mantenimiento del proceso ya que las modificaciones que se realicen en un módulo de función afectan a todos los programas que lo utilicen.

Están almacenados centralmente en el Repositorio ABAP. El Sistema R/3 contiene un gran número de módulos de función predefinidos que podemos llamar desde cualquier

Página 146 de 195


programa ABAP. Los podemos localizar mediante el sistema de información del Repositorio.

Los módulos de función también juegan un papel importante en las actualizaciones de la base de datos y en las comunicaciones remotas entre Sistemas R/3 o entre un Sistema R/3 y otro que no lo sea.

La definición de la interfase ABAP permanece oculta para el programador. Podemos definir los parámetros de entrada de un módulo de función como opcionales. También podemos asignar valores por defecto para ellos. Los módulos de función también admiten el tratamiento de excepciones. Esto nos permite tratar ciertos errores mientras se está ejecutando el módulo de función. Además, podemos probar los módulos de función sin tener que incluirlos en un programa.

El Constructor de Funciones también tiene un proceso de liberación de módulos de función. Esto nos asegura que no se puedan realizar cambios incompatibles en cualquier módulo de función que ya haya sido liberado. Esto se aplica especialmente a la interfase. Los programas que utilizan un módulo de función liberado no dejarán de funciones si se cambia el módulo de función.

13.4.2.1 Grupos de funciones Los grupos de funciones son recipientes para módulos de función en los que se agrupan por el tipo de tarea que realizan (por ejemplo los módulos de SCAL realizan cálculos con fechas). Un grupo de funciones es un programa ABAP especial de tipo F que no se puede ejecutar. Es accesible en el sistema en cuanto se ha activado. Cuando llamamos a un módulo de función, el sistema carga la totalidad del grupo de funciones en una sesión interna del programa llamante (si no había sido cargada ya).

El siguiente diagrama muestra la estructura de un grupo de funciones. El nombre del grupo de función puede tener hasta 30 caracteres y solo puede contener alfanuméricos y “”. Debe comenzar por Z o Y. Este nombre se utiliza para crear los componentes del grupo (el programa principal y los correspondiente programas include). Cuando creamos un grupo de funciones o un módulo de función, se genera automáticamente el programa principal y los programas include.

Página 147 de 195


Página 148 de 195

El programa principal SAPL<grpf> no contiene más que sentencias INCLUDE para los siguientes programas include: L<grpf>TOP. Este include contiene la sentencia FUCTION-POOL (equivalente en un

grupo de funciones de la sentencia REPORT o PROGRAM) y las declaraciones de datos globales para la totalidad de grupo de funciones.

L<grpf>UXX. Este include contiene sentencias INCLUDE adicionales para los programas L<grpf>U01, L<grpf>U02,... Estos includes contienen los módulos de función.

Los programas include L<grpf>F01, L<grpf>F02,... pueden contener el código de subrutinas que pueden ser ejecutadas mediante llamadas internas a subrutinas desde cualquiera de los módulos de función del grupo.

La creación de estos programas include se puede realizar mediante navegación avanzada (por ejemplo, la creación de un include de subrutinas se puede realizar haciendo un doble click sobre el nombre de la subrutina en una sentencia PERFORM de un módulo de función).

No podemos declarar una COMMON PART en un grupo de funciones. Los grupos de funciones tienen sus propias áreas de trabajo de tablas (TABLES). Los grupos de funciones encapsulan los datos. A este respecto, son los precursores de los Objetos ABAP.

Todos los módulos de función que pertenezcan al mismo grupo de funciones pueden acceder a los datos globales del grupo. Por esta razón, debemos colocar los módulos de función que utilicen los mismos datos en un único grupo de funciones. Por ejemplo, si tenemos un conjunto de módulos de función que utilicen la misma tabla interna, deberíamos colocarlos en un grupo de funciones que contenga la definición de la tabla como dato global.

Al igual que los programas ejecutables (tipo1) y los module-pool (tipo M), los grupos de funciones pueden contener pantallas, pantallas de selección y listas. Las entradas del usuario se procesan tanto en módulos de diálogo como en los bloques de eventos correspondientes en el programa principal del grupo de funciones. Estos son


Página 149 de 195

programas include especiales en los cuales podemos escribir este código. De esta forma, podemos utilizar los grupos de funciones para encapsular pantallas o secuencias de pantallas.

Seleccionaremos ‘Grupo de funciones’, pondremos el nombre del grupo de funciones a Crear

Ej ‘ZCXX’.

Aparecerá una ventana el la que definir los atributos del grupo de funciones.

Grupo de funciones: Nombre del grupo de funciones.

Texto breve: Descripción del grupo de funciones.

Ej: ‘Asignación de números’.

Responsable: Usuario responsable del grupo de funciones.

13.4.2.2 Llamada a funciones Para llamar a un módulo de función utilizaremos la sentencia CALL FUNCTION: CALL FUNCTION <módulo>

[EXPORTING f1 = a 1.... f n = a n]

[IMPORTING f1 = a 1.... f n = a n]

[CHANGING f1 = a 1.... f n = a n]

[TABLES f1 = a 1.... f n = a n]

[EXCEPTIONS e1 = r 1.... e n = r n [ERROR_MESSAGE = r E]

[OTHERS = ro]].

Podemos especificar el nombre del módulo de función tanto mediante un literal como con el contenido de una variable. Cada parámetro de la interfase <fi> se asigna explícitamente a un parámetro actual <a i>. Podemos asignar un valor de retorno <r i> a cada excepción <e i>. La asignación siempre tiene la forma <parámetro de la interfase> = <parámetro actual>.

Después de EXPORTING, debemos suministrar valores a todos los parámetros Import

que no sean opcionales con los valores apropiados de su tipo. Podemos pasar valores a los parámetros Import opcionales si lo deseamos

Después de IMPORTING, podemos recibir los parámetros Export del el módulo de función asignándolos a las variables del tipo apropiado.

Después de CHANGING o TABLES, debemos suministrar valores a todos los parámetros Changing no opcionales o Tablas. Cuando el módulo de función termine su ejecución, los valores cambiados serán devueltos a los parámetros actuales. Podemos pasar valores a los parámetros Changing o Tablas que sean opcionales.


Podemos utilizar la opción EXCEPTIONS para manejar las excepciones del módulo de función. Si se produce una excepción <e i> mientras se está ejecutando el módulo de función, el sistema finaliza el módulo de función y no pasa ningún valor desde el módulo de función al programa, excepto aquellos que se pasen por referencia. Si se especifica <e i> en la opción EXCEPTION, el programa llamante tratará la excepción asignando <r i> a SY-SUBRC. <r i> debe ser un literal numérico.

Si especificamos ERROR_MESSAGE en la lista de excepciones podemos influir en el tratamiento de los mensajes del módulo de función. Normalmente, sólo deberíamos llamar a los mensajes de un módulo de función utilizando la sentencia MESSAGE... RAISING. Con ERROR_MESSAGE podemos forzar que el sistema trate los mensajes que se han llamado sin la opción RAISING en un módulo de función. Para ello: Los mensajes de las clases S, I, y W son ignorados (pero se escriben en el log de un

job que se ejecute en fondo. Los mensajes de las clases E y A detiene la ejecución del módulo de función como si

se hubiera producido la excepción ERROR_MESSAGE (SY-SUBRC se pone a <r E>

Si especificamos OTHERS después de EXCEPTIONS, el sistema asignará un único código de retorno para todas las excepciones que no hayamos especificado explícitamente en la lista.

Podemos asignar el mismo número <r i> para varias excepciones.

La forma recomendada y más fácil de llamar a un módulo de función es utilizar la función ‘Insertar Patrón’ del Editor de ABAP. Si seleccionamos el radiobutton CALL FUNCTION y especificamos el nombre del módulo de función (está disponible la ayuda F4), el sistema inserta la sentencia CALL FUNCTION con todas las opciones del módulo de función en el código fuente del programa.

Las partes opcionales de la llamada a la función se insertarán como comentarios. En el ejemplo anterior, STRING y POS son parámetros obligatorios. Por otra parte,

Página 150 de 195


LANGU, es opcional. Su valor por defecto es SY-LANGU (campo del sistema que contiene el idioma en el que se entró al sistema). El tratamiento de los parámetros Export es opcional. El tratamiento de las excepciones es también teóricamente opcional. Sin embargo, siempre deberíamos tratarlo. Esta es la razón por la cual se han quitado los comentarios de las líneas de EXCEPTIONS

Podemos lanzar las excepciones en el módulo de función tanto con RAISE como con MESSAGE... RAISING. Si el programa llamante trata la excepción, ambas sentencias devuelven el control al programa. La sentencia MESSAGE... RAISING no visualizará el mensaje en este caso. En lugar de ello, actualiza los siguientes campos del sistema:

Clase de Mensaje ⇒ SY-MSGID

Tipo de Mensaje ⇒ SY-MSGTY

Número de Mensaje ⇒ SY-MSGNO

De SY-MSGV1 a SY-MSGV4 (contenido de los campos <f1> a <f4>, incluidos en un mensaje).

Podemos utilizar los campos del sistema para lanzar el mensaje desde el programa llamante.

Para asegurar que utilizamos los tipos de datos correctos para los parámetros actuales, debemos ir a la interfase del módulo de función. Para ello haremos un doble click en el nombre del módulo de función desde el código fuente de nuestro programa. El sistema navegará al código fuente que se encuentra en el Constructor de Funciones. Podemos visualizar la interfase eligiendo la opción del menú ‘Pasar a ⇒ Interfase’.

Por ejemplo, en el caso anterior

STRING, STRING1 y STRING2 tienen el tipo genérico C. Los parámetros actuales deben tener también el tipo C, pero su longitud no importa,

POS y POS_NEW tienen un tipo I especificado completamente. Los parámetros actuales deben ser también del tipo I.

LANGU también tiene un tipo definido completamente, ya que hace referencia al campo del Diccionario de ABAP SY-LANGU. El parámetro actual debe tener el mismo tipo.

Una llamada al módulo de función STRING_SPLIT_AT_POSITION podría ser algo parecido a lo siguiente: PROGRAM CALL_FUNCTION.

DATA: TEXTO(10) TYPE C VALUE '0123456789',

TEXTO1(6) TYPE C,

TEXTO2(6) TYPE C.

PARAMETERS POSICION TYPE I.

CALL FUNCTION 'STRING_SPLIT_AT_POSITION'

EXPORTING

STRING = TEXTO

POS = POSICION

IMPORTING

Página 151 de 195


STRING1 = TEXTO1

STRING2 = TEXTO2

EXCEPTIONS

STRING1_TOO_SMALL = 1

STRING2_TOO_SMALL = 2

POS_NOT_VALID = 3

OTHERS = 4.

CASE SY-SUBRC.

WHEN 0.

WRITE: / TEXTO, / TEXTO1, / TEXTO2.

WHEN 1.

WRITE '¡Campo destino 1 demasiado corto!'.

WHEN 2.

WRITE '¡Campo destino 2 demasiado corto!'.

WHEN 3.

WRITE '¡Posición de división no válida!'.

WHEN 4.

WRITE '¡Otro tipo de error!'.

ENDCASE.

El módulo de función divide un campo de entrada a partir de una posición determinada en dos campos de salida. Si el contenido de POSICION es un intervalo [4,6], se ejecutará el módulo de función sin que se produzca ninguna excepción. Para los intervalos [1,3] y [7,9], el sistema lanza respectivamente las excepciones STRING1_TOO_SMALL y STRING2_TOO_SMALL. Para el resto de los valores de POSICION, se lanza la excepción POS_NOT_VALID.

13.4.2.3 Buscar módulos de función Antes de programar una nueva función o crearla, deberíamos comprobar si no existe ya un módulo de función que realice la misma tarea. Por ejemplo, si buscamos módulos de función que procesen cadenas de caracteres, introduciremos *STRING* como criterio de búsqueda. Este es un extracto de los módulos de función encontrados:

El título CSTR es el del grupo de funciones. Existe un programa principal SAPLCSTR que contiene estos módulos de función. Si seleccionamos un módulo de función, podemos visualizar sus atributos. Los atributos más importantes son: Documentación: La documentación describe el propósito del módulo de función, la lista

de los parámetros para pasar y recibir datos de los módulos, y las excepciones. Nos dice cómo pasar datos y recibir datos del módulo de función y que errores maneja.

Página 152 de 195


Interfase de parámetros y excepciones: Esta sección ofrece una información adicional acerca de la interfase de parámetros y excepciones, y cómo utilizar el módulo de función. Los módulos de función pueden tener los siguientes parámetros en su interfase:

Parámetros Import. Se les deben suministrar datos cuando llamamos al módulo de función, a menos que se trate de parámetros opcionales. No podemos cambiarlos en el módulo de función.

Parámetros Export. Devuelven los datos desde el módulo de función al programa llamante. Los parámetros Export son siempre opcionales.

Parámetros Changing. Se les deben suministrar datos cuando llamamos al módulo de función, salvo que se trate de parámetros opcionales. Pueden ser cambiados en el módulo de función. Los valores cambiados son devueltos al programa llamante.

Parámetros Tablas. Los utilizaremos para pasar tablas internas. Son tratados como los parámetros CHANGING. Sin embargo, también podemos pasar tablas internas con otros parámetros si especificamos el tipo de parámetros de forma apropiada.

Podemos especificar los tipos de la interfase de parámetros, tanto haciendo referencia a los tipos del Diccionario ABAP como a los tipos elementales de ABAP. Cuando llamamos a un módulo de función, debemos asegurarnos que son compatibles los parámetros actuales y la interfase de parámetros.

Por defectos, los parámetros de la interfase son pasados por valor. Sin embargo, también pueden ser pasados por referencia. Los parámetros tabla sólo se pasan por referencia.

Las excepciones se utilizan para el tratamiento de errores que tienen lugar dentro de los módulos de función. El programa llamante debe verificar si se ha producido algún error y responder a él adecuadamente.

Antes de incluir un módulo de función en un programa, podemos probarlo.

13.4.2.4 Crear módulos de función Podemos crear módulos de función y grupos de funciones utilizando la Biblioteca de Funciones del Workbench de ABAP.

Ruta de acceso: ( En el menú principal de SAP ) ‘Herramientas Workbench ABAP4-Desarrollo Biblioteca funciones’ (SE37).

Página 153 de 195


Página 154 de 195

Un modulo de función esta formado por unos datos administrativos, su interfase, su código fuente y su documentación.

Desde esta pantalla se pueden crear, modificar o visualizar todas las partes de un módulo de función marcando las distintas opciones de objetos parciales.

Para crear un módulo de función se deberá especificar el nombre en la pantalla inicial

y pulsar el botón de crear con la opción ‘Gestión’ activada. El nombre de una función puede tener hasta 30 caracteres que solo pueden ser alfanuméricos o “”.

Aparecerá una pantalla en la que se debe indicar el grupo de funciones a la que pertenece el módulo de función junto con la descripción de su funcionalidad.

Se deberán informar los siguiente datos de gestión del módulo de función

Clasificación:

Aplicación: Módulo al que pertenece el programa ( FI , HHRR … ).

Forma ejec.: Normal o Apoyo Remote Function Call si la función puede ser ejecutada desde otros sistemas externos (WWW, otro R/3, programas propios JAVA, C++, Visual Basic) usando RFC.

Actualizable: Se puede lanzar la ejecución de una función de manera asíncrona o paralela. Aquí se puede especificar el modo de tratamiento de la tarea de actualización (inicio inmediato, inicio inmediato sin actualización posterior, inicio retardado o lanzamiento colectivo).

Al finalizar la introducción de los datos de gestión se deberá grabar el módulo de función. El modulo de función estará disponible en el sistema cuando lo activemos. En ese momento también se generará el grupo de funciones al que pertenece.


13.4.2.5 Interfase de la función Hemos dicho anteriormente que la interfase de los módulos de función se describe como transparente porque se mantiene de manera independiente del código. Tenemos de hecho una pantalla específica para introducir los parámetros donde se deben indicar las listas de parámetros de entrada y de salida. Los parámetros import son los que se le pasan a la función desde el programa que llama y los parámetros export son los que la función devuelve al programa que llama.

Como los módulos de función se pueden utilizar desde cualquier parte del sistema, su interfase sólo puede hacer referencia a los tipos de datos declarados en el sistema. Estos son los tipos de datos elementales de ABAP, los tipos genéricos, tales como ANY TABLE, y los tipos definidos en el Diccionario de ABAP. No podemos utilizar LIKE para hacer referencia a los tipos declarados en un programa principal.

Los métodos para pasar parámetros son análogos a los utilizados en las subrutinas: por valor o por referencia. Como en esos procedimientos, se puede forzar el chequeo del tipo del parámetro, y si no se indica tipo, el parámetro formal hereda los atributos del actual.

Una diferencia fundamental con los parámetros de las subrutinas es la posibilidad de tener parámetros opcionales.

Se debe documentar la interfase de un módulo de función con unas descripciones breves de los parámetros y de las excepciones, pero además es posible crear una documentación más extensa.

Parámetro: Nombre de los parámetros de entrada.

Tipificación: Tipo de dato del parámetro.

Como ‘campo/estructura’, podemos introducir una columna de una tabla de la base de datos, un componente de una estructura del diccionario, o una estructura completa del Diccionario.

Página 155 de 195


Tipo Ref. Tipo de referencia ( Solo se indicará una de estas dos últimas ).

En ‘Tipo ref.’ podemos poner cualquier tipo genérico o cualquier tipo de datos que sea válido en todo el sistema. En este ejemplo, los parámetros Import se han definido en referencia a tipo de datos elementales del Diccionario de ABAP (elementos de datos).

Valor Propuesto: Valor por defecto cuando se declara como opcional.

Flag opc. Indicador de parámetro no obligatorio.

Flag. Tras. Indicación de que el parámetro se recibe por valor/referencia.

Son los parámetros de salida de función.

Parámetros de entrada y salida del módulo de función. Estos parámetros devuelven el valor de salida al finalizar la ejecución del módulo de función sin errores, manteniendo el valor de entrada en caso contrario.

Ej.: Se crea el parámetro import ‘BUKRS’ con el campo de referencia ‘ZCLIENXX-BUKRS’ para recibir la sociedad del cliente, y el parámetro export ‘NCLIE’ con el campo de referencia ‘ZCLIENXX-NCLIE’ para devolver el número de cliente.

13.4.2.6 Tablas Además de los parámetros de entrada y salida definidos anteriormente, también se pueden traspasar tablas por referencia en la llamada al módulo de función.

Parámetro tabla: Nombre del parámetro de tabla.

Tipificación : Tipo de datos de la tabla

Tipo ref.: Estructura de referencia del diccionario de datos para especificar la estructura del parámetro de tabla.

Opcional: Si se activa este flag no será obligatorio informar el parámetro de tabla en la llamada al módulo de función.

Página 156 de 195


13.4.2.7 Excepciones Las excepciones son una serie de errores predefinidos en los módulos de función que devuelven un valor de retorno concreto en la variable del sistema SY-SUBRC.

El objetivo es anticipar los posibles errores y así evitar que éstos produzcan errores en tiempo de ejecución. Se da un nombre a cada posible error en la interfase del módulo de función y se lanzan los errores desde el código fuente con la sentencia RAISE. El valor de retorno que se pasa al programa llamante depende de la posición de la excepción en la tabla de excepciones.

Por defecto siempre existe la excepción ‘OTHERS’, aunque aparezca definida, que se utiliza para devolver un error genérico y devuelve en la variable SY-SUBRC el valor siguiente al de la última excepción creada.

Para devolver una excepción desde el código del modulo de función se utiliza la sentencia RAISE <excepción>, finalizando así la ejecución de la función y devolviendo el código asociado a la excepción en la variable SY-SUBRC. En caso de devolver una excepción no se actualiza el valor de salida de los parámetros CHANGING.

El efecto de esta sentencias depende de si el programa llamante trata las excepciones o no. Si el nombre <excepción> de la excepción u OTHERS aparece en la opción EXCEPTIONS de la sentencia CALL FUNCTION, el control del error se realizará en el programa llamante. Si no aparece en el programa llamante, la sentencia RAISE finaliza el programa.

Podemos asegurarnos de que el sistema muestra un mensaje de error cuando se produce la excepción aunque no la tratemos: mediante la sentencia MESSAGE... RAISING. La forma en la que continúe el procesamiento depende del tipo de mensaje. Si el programa llamante no trata la excepción no se visualizará el mensaje; en lugar de ello rellenará los campos del sistema SY-MSGID, SY-MSGTY, SY-MSGNO y SY-MSGV1 a SY-MSGV4.

13.4.2.8 Datos globales Las definiciones globales de datos son compartidas por todos los módulos de función de un grupo de funciones. Las definiciones de objetos globales se mantienen a través de la opción de menú ‘Pasar a Datos globales’.

Nota: Las definiciones globales y el texto fuente del módulo de función se codifican realmente en el editor ABAP/4 utilizando los mismos comandos que en la codificación de listados.

Podemos utilizar las sentencias TYPES y DATA para crear tipos y objetos de datos locales. Los parámetros de la interfase también se comportan como objetos de datos locales. Además, podemos acceder a todos los datos globales del programa principal. Estos datos están definidos en el programa include L<grpf>TOP. Para abrir este include, elegiremos la opción del menú ‘Pasar a ⇒ Datos globales’. La primera vez que llamamos al módulo de función de un grupo de funciones determinado, los datos se cargarán en la memoria. Estos datos pueden ser leídos y modificados por cualquiera de los módulos de función del grupo. El sistema retendrá los valores hasta que se llame de nuevo al módulo de función.

Ej.: Se define la tabla estándar de sociedades ‘T001’ en la que se chequeará que la sociedad recibida como parámetro es correcta, y la tabla de clientes ‘ZCLIENXX’ para seleccionar los números de cliente existentes.

Include LZCLITOP:

FUNCTION-POOL ZCLI. "MESSAGE-ID ..

Página 157 de 195


************************************************************************

* Definición de tablas

************************************************************************

TABLES: T001, " Sociedades

ZCLIENXX. " Clientes

Los parámetros definidos en el módulo de función son locales, por lo tanto solo son visibles en el cuerpo principal de la función. Para que puedan ser utilizados en las subrutinas, sin necesidad de pasarlos como parámetros, se deberán globalizar utilizando la opción de menú ‘Tratar Interfase Globalizar parám.’ en la pantalla de mantenimiento de parámetros de entrada/salida. Para eliminar la globalización se utiliza la opción de menú ‘Tratar Interfase Localizar parám.’.

13.4.2.9 Código fuente Una vez definida la interfase de parámetros y las excepciones, podemos escribir el código fuente de nuestro módulo de función. Para hacer esto, pulsaremos el botón ‘Código fuente’. Esto abrirá el editor para el programa include L<grpf>U<xx>.

El código del módulo de función se escribirá entre las sentencias FUNCTION y ENDFUNCTION. Las definiciones de la interfase de parámetros y de las excepciones se mostrarán como líneas de comentario de manera automática. Hay que recordar que es la definición de la interfase la que vale y no estas líneas de comentarios. No se deben cambiar éstas manualmente ya que se actualizan al modificar la interfase.

Al crear una subrutina, haciendo doble click sobre el nombre en la llamada, el sistema propondrá la creación de un Include que contendrá todas las subrutinas del grupo de funciones.

Al finalizar la introducción del texto fuente se deberá grabar, verificar y activar el módulo de función.

13.4.2.10 Test Cuando ya se ha definido y activado un módulo de función, se puede probar en la misma Biblioteca de Funciones. Se debe utilizar la opción de menú ‘Utilidades Entorno test’ (F8) o bien pulsar el botón en la pantalla inicial.

Aparecerá una plantilla de entrada donde podremos introducir los parámetros IMPORT. El resultado se transfiere a los parámetros EXPORT y se muestra en otra pantalla. Si ocurre un error el sistema muestra la excepción que se ha producido.

Se muestra también el tiempo de ejecución del módulo de funciones en microsegundos. Como este tiempo está sujeto a condicionantes como la carga de la máquina en el momento de la ejecución, se deberá repetir la prueba varias veces en condiciones diferentes para obtener una medida con sentido.

Se pueden guardar los datos utilizados para el test en un directorio de datos. Y se pueden crear secuencias de tests.

13.4.2.11 Llamada Para ejecutar un módulo de función desde un programa se utiliza la sentencia CALL FUNCTION <función>. Es necesario que exista una versión activa del módulo de función para poder llamarlo.

Para que el sistema nos proponga la sentencia de la llamada a una función con toda su interfase (parámetros y excepciones) utilizaremos el botón (patrón de instrucción) del Editor ABAP. Marcando la opción ‘CALL FUNCTION’ y especificando

Página 158 de 195


el nombre de la función el sistema inserta la sentencia completa en la posición actual del cursor. Sólo faltará completar los nombres de los parámetros actuales (a la derecha de los parámetros formales) y, si es necesario, escribir las sentencias que controlen los errores lanzados mediante excepciones (CASE SY-SUBRC). En el caso de los parámetros opcionales, no es obligatorio indicar un parámetro actual y se pueden borrar las líneas que los contienen.

Nota: Los campos que se utilizan en la llamada a un módulo de función deben ser del mismo tipo que los parámetros a los que hacen referencia (definidos en el módulo de función), sino se pueden producir errores en la ejecución del programa.

13.5 Llamadas a otros programas Para realizar llamadas a otros programas desde un programa se utilizan las siguientes sentencias:

13.5.1 SUBMIT SUBMIT <listado> AND RETURN: Realiza una llamada a un listado. Si no se especifica la cláusula ‘AND RETURN’ finalizará el programa actual y se ejecutará el listado sin regresar al programa actual.

Esta sentencia inicia un report, por defecto no visualiza la selection screen. (VIA SELECTION-SCREEN para que aparezca). Esta es su sintaxis:

Submit <report>

and return

vía selection-screen

and return exporting list to memory

with <p> <op> <f1>

with <p> between <f1> and <f2>

with <p> in <tab>

using selection-set <v> Ejecuta un report con variantes.

using selection-sets of program <prog>

using selection-table <seltab>

Descripción de indicadores

<P> Nombre de una tabla de selección o un campo de parámetro <show database <dba>.

<Op> Operador relacional.

<F1..Fn> Nombre de campo o constante.

<Seltab> Tabla interna de la estructura rsparams.

<V> Nombre de una variante de selección.

<Tab> Tabla interna declarada por rangos.

Mediante RANGES, declaramos una tabla interna con la misma estructura que una tabla interna creada con select-options.

Mediante WITH y USING pasamos valores de selección para el report que recibe la llamada.

Página 159 de 195


13.5.2 CALL TRANSACTION CALL TRANSACTION <transacción>: Realiza una llamada a una transacción.

Ej.:Se incluirá un pulsador en la pantalla de altas de clientes para ejecutar el listado de visualización de facturas de clientes.

Se incluye un pulsador en la barra de pulsadores el Status ‘STA_9000’ con el código de función ‘FACT’ de tipo ‘E’ (Comando Exit) y el texto ‘Visualizar clientes’ asociado a la tecla de función ‘F6’

Transacción: Grupo de dynpros que tienen sentido dentro de un conjunto, y que por ellas mismas carecen de este. Podemos asociar una transacción a un modulpool, reports…Desde el menú de Workbench Abap Desarrollo Mas herramientas Transacciones .

/o Te crea un nuevo modo al llamar a una transacción.

/n Te lleva a otra pantalla dentro de la actual transacción.

Transacciones de interés:

/Libs Transacción de muestras de salida de reports (Guia de estilo).

/Se09 Relacionado con las ordenes de transporte. Ordenes de preparación.

/Se10 Relacionado con las ordenes de transporte. Customizing.

/Bibs Transacción de muestras de modulpool.

Call transaction <trancod> [using <itab>]

[AND SKIP FIRST SCREEN].

Mediante la adición USING <itab> puedes ejecutar un batch input parecido a procesar el paso de una tabla interna.

Mediante la adición AND SKIP FIRST SCREEN, la primera pantalla de la transacción que recibe la llamada no se visualiza. Para realizar esta operación tendremos que llenar los campos requeridos.

13.6 Parámetros de memoria Para intercambiar datos entre diferentes programas se puede utilizar la memoria SAP y la memoria ABAP. La primera es un área de memoria específica para cada usuario que se utiliza para almacenar valores que son retenidos durante la sesión y a la cual tienen acceso todas las ventanas o modos de SAPGui. Los valores almacenados en la memoria ABAP, en cambio, solamente son retenidos durante la ejecución de un programa. Esta memoria es utilizada para la transferencia de datos entre dos programas cuando uno de ellos realiza una llamada al otro.

13.6.1 SAP Los programas de aplicación que utilizan memoria SAP deben utilizar los parámetros SPA/GPA (también conocidos como parámetros SET/GET). La utilización más frecuente de los parámetros SPA/GPA es rellenar los campos de entrada de una pantalla.

En la memoria SAP se pueden almacenar valores asociados a un identificador de tres caracteres, que se mantienen disponibles hasta que finalice la sesión.

En los campos de las pantallas existen tres atributos relacionados con los parámetros de memoria:

Página 160 de 195


Id-parám.: Identificador de parámetro para los valores del campo en la memoria SAP. Si el campo está referenciado al diccionario de datos, se informará con el identificador asociado al dominio del campo del diccionario.

SET Parám.: Al activar este atributo, el sistema almacenará en la memoria SAP el valor que contiene al campo bajo el identificador asociado.

GET Parám.: Al activar este atributo, el campo se inicializará con el valor definido en la memoria SAP bajo el identificador asociado en lugar de utilizar el valor inicial en función del tipo de dato del campo.

Desde un programa se pueden almacenar y recuperar datos de la memoria SAP con las siguientes sentencias:

SET PARAMETER.

La sentencia SET PARAMETER ID <identificador> FIELD <campo> almacena el valor del campo en la memoria SAP asociado al identificador especificado.

GET PARAMETER.

La sentencia GET PARAMETER ID <identificador> FIELD <campo> almacena el valor asociado al identificador en la memoria SAP en el campo especificado.

Los parámetros de memoria se inicializan al comenzar una sesión con los valores almacenados en los parámetros de usuario, que se mantienen desde la opción de menú ‘Sistema Valores prefijados Datos propios’ (SU3).

Idp: Identificador de parámetro.

Valor parámetro: Valor asociado al identificador.

En la memoria de SAP se pueden almacenar los valores debajo de los parámetros ID. Estos son almacenados para cada sesión de usuario y son conservados en el transcurso de la sesión.

Página 161 de 195


El parámetro SET copia el contenido del campo PAI a la memoria SAP, mientras que el parámetro GET copia el contenido del campo al final del PBO desde la memoria SAP (solamente si el campo de la pantalla tiene valor inicial).

Los parámetros ID'S se pueden definir en la tabla TPARA.

13.6.1.1 Valores iniciales en pantallas Para rellenar un parámetro utilizaremos:

SET PARAMETER ID <idp> FIELD <c>.

Esta sentencia guarda el contenido del campo <c> en el parámetro con ID <idp> de la memoria SAP. El código <idp> puede tener hasta 20 caracteres. Si ya existe algún valor almacenado en <idp>, éste se sobreescribirá. Si el <idp> no existe, haremos un doble click sobre <idp> desde el editor de ABAP para crear el nuevo parámetro.

Para leer el valor que contiene un parámetro, utilizaremos la sentencia:

GET PARAMETER ID <idp> FIELD <c>.

Esta sentencia lee el valor almacenado el parámetro con ID <idp> y lo guarda en la variable <c>. Si el sistema no encuentra un valor en el <idp> de la memoria SAP, pondrá la variable del sistema SY-SUBRC a 4, en caso contrario la pondrá a 0.

Para rellenar la pantalla inicial de un programa utilizando los parámetros SPA/GPA, normalmente sólo necesitaremos utilizar la sentencia SET PARAMETER.

Los campos que se vean implicados deben estar enlazados con un parámetro SPA/GPA.

En una pantalla de selección podemos traer los valores de los parámetros utilizando la opción MEMORY ID de la sentencia PARAMETERS o SELECT-OPTIONS. Si especificamos un parámetro SPA/GPA cuando declaramos un parámetro o criterio de selección, el correspondiente campo de entrada estará enlazado con el parámetro de memoria SAP indicado. Cuando un campo de entrada está enlazado con un parámetro SPA/GPA, se inicializará su valor con el contenido del parámetro cada vez que se muestre la pantalla. Esta es la razón por la cual los campos de las pantallas de SAP R/3 a menudo contienen ya valores cuando llamamos a un programa más de una vez.

También podemos controlar los contenidos de los parámetros desde nuestro programa utilizando la sentencia SET PARAMETER antes de llamar al programa que deseemos ejecutar. Esta técnica es particularmente útil si queremos saltar la pantalla inicial del programa llamado y ésta contiene campos obligatorios.

Si queremos actualizar los parámetros SPA/GPA antes de llamar al programa, necesitamos conocer qué parámetros están enlazados con cada campo de la pantalla inicial. Una forma sencilla de hacer esto es lanzar el programa que queremos llamar, colocar el cursor sobre los campos de entrada y pulsar F1 seguido de Datos Técnicos. El campo ID parámetro contiene el nombre del correspondiente parámetro SPA/GPA. También podemos buscar esta información desde el Screen Painter.

Ejemplo: La información técnica de la pantalla de entrada de la transacción del editor ABAP (transacción SE38) muestra algo como esto:

Página 162 de 195


Página 163 de 195

El parámetro SPA/GPA para el campo de entrada ‘Programa’ tiene el ID RID.

El siguiente programa ejecutable va a llamar a editor de ABAP pasándole el nombre del programa seleccionado por el usuario: REPORT ZPRUEBA2 NO STANDARD PAGE HEADING.

TABLES D010SINF.

START OF SELECTION.

WRITE: ‘Selecciona un programa’,

/’----------------------‘.

SKIP.

SELECT * FROM D010SINF WHERE ( PROG LIKE ‘Z%’ ). “Empieza por Z

WRITE / D010SINF-PROG.

HIDE D010SINF-PROG.

ENDSELECT.

AT LINE-SELECTION.

* Este evento se ejecuta cuando el usuario selecciona una línea

SET PARAMETER ID ‘RID’ FIELD D010SINF-PROG.

CALL TRANSACTION ‘SE38’.


Página 164 de 195

El listado muestra todos los programas que empiezan por Z. El nombre de cada programa se almacena en el área HIDE de cada línea.

Si el usuario selecciona una línea haciendo doble click sobre ella, el sistema lanza el evento AT LINE-SELECTION y toma los datos almacenados en el área HIDE para rellenar con este valor el parámetro SPA/GPA de la pantalla inicial de la transacción. Justamente después se llama a la transacción. En el campo ‘Programa’ aparecerá el que haya sido seleccionado por el usuario.

13.6.2 ABAP Al realizar una llamada a un programa desde otro programa, se pueden intercambiar datos a través de la memoria ABAP de la sesión utilizando las sentencias EXPORT/IMPORT. Los datos que se encuentran en esta área permanecen inalterados durante todo el tiempo que dura la secuencia de llamadas a programa

Para pasar datos a un programa al que estemos llamando, se colocarán los datos necesarios en la memoria ABAP antes de realizar la llamada:

EXPORT <objeto> TO MEMORY ID <identificador>.

Esta sentencia almacena el objeto en la memoria ABAP/4 asociado al identificador especificado, que puede tener una longitud de 32 caracteres. Cada vez que se exportan datos bajo un mismo identificador se sobrescriben los anteriores.

La sesión interna del programa llamado reemplazará a la del programa llamante. El programa llamado puede entonces leer los datos que se encuentran en la memoria ABAP:

IMPORT <objeto> FROM MEMORY ID <identificador>.

Esta sentencia recupera el objeto asociado al identificador especificado de la memoria ABAP/4.

FREE MEMORY ID <identificador>.

Libera de la memoria ABAP/4 los datos almacenados bajo el identificador especificado. Si no se especifica la cláusula ‘ID’ se liberará toda la memoria ABAP/4.

Export: Nos permite almacenar en una memoria de usuario especificada los objetos que deseemos. Este método es valido para todos los objetos de Abap/4.

Export <field1> [from <fieldA>]

<field2> [from <fieldB>]

[To memory id <id>]. Los valores de fieldA se guardaran bajo el nombre de <field1>.


Export tab spfli f1 to Memory [id 'flug']. <-- En que lugar de la memoria se almacenara.

Import: Permite recuperar los objetos cuyos valores queremos utilizar. Los objetos deben ser idénticos entre el programa que realiza la llamada y el que la recibe (tipo,longitud,estructura). La variable de sistema SY-SUBRC<>0 cuando la memoria esta vacía.

Import <field1> [to <fieldA>]

<field2> [to <fieldB>]

[From memory id <id>]. Introducimos los valores recuperados de <field1> en fieldA.

Página 165 de 195


Página 166 de 195

14 ALV El control ALV (ALV = SAP List Viewer) es una herramienta flexible para la presentación gráfica de listados. Proporciona operaciones que frecuentemente se necesitan para trabajar con listas (en forma de funciones genéricas) y puede ser mejorado definiendo opciones personalizadas. Esto permite utilizar el ALV en gran variedad de programas.

Un control ALV consiste en una barra de herramientas, un título y una tabla de salida mostrada en una parrilla. El usuario puede ocultar el título y las funciones estándar de la barra de herramientas.

14.1 Funcionalidad Con un control ALV se puede:

Mostrar listas de manera consistente con un diseño moderno.

Disponer de las funciones típicas de las listas (como ordenar o filtrar) sin realizar ningún esfuerzo extra de programación.

Adaptar las funciones predefinidas de lista y sus mejoras.

Programar respuestas a acciones de usuario (como hacer doble-click en una línea) de manera individual.

Se pueden ver ejemplos prácticos de uso del ALV en el paquete SLIS.

14.2 Trabajar con ALV Como mínimo se debe preparar la siguiente información para mostrar datos con ALV:

• Una tabla interna con los datos a mostrar (tabla de salida), que normalmente contiene datos previamente seleccionados de tablas de la base de datos.

• Una descripción de la estructura de esa tabla que se declara al control ALV a través de un catálogo de campos o de la correspondiente estructura del Diccionario ABAP. El catálogo de campos es una tabla que contiene información sobre los campos a mostrar: por ejemplo el ALV utiliza esta tabla para identificar el tipo de un campo. Además se pueden utilizar ciertos campos especiales del catálogo para determinar el formato de número o las propiedades de la columna de la lista que se ha de escribir.

Describiremos la manera más sencilla de mostrar una lista con datos en un control ALV. El sistema R/3 dispone de varias funciones para generar listas ALV con pocas


instrucciones. Aprenderemos a usar las más comunes: REUSE_ALV_LIST_DISPLAY y REUSE_ALV_FIELD_CATALOG_MERGE.

En la mayoría de los casos tendremos un programa que lee de la base de datos en el bloque de evento START-OF-SELECTION y los almacena en una tabla interna. En el evento END-OF-SELECTION, donde deberíamos tratar los datos y mostrarlos en pantalla, utilizaremos las funciones que acabamos de presentar.

14.3 Función REUSE_ALV_LIST_DISPLAY Utilizando el patrón de instrucciones insertamos en nuestro código la llamada a REUSE_ALV_LIST_DISPLAY. CALL FUNCTION 'REUSE_ALV_LIST_DISPLAY'

* EXPORTING

* I_INTERFACE_CHECK = ' '

* I_BYPASSING_BUFFER =

* I_BUFFER_ACTIVE = ' '

* I_CALLBACK_PROGRAM = ' '

* I_CALLBACK_PF_STATUS_SET = ' '

* I_CALLBACK_USER_COMMAND = ' '

* I_STRUCTURE_NAME =

* IS_LAYOUT =

* IT_FIELDCAT =

* IT_EXCLUDING =

* IT_SPECIAL_GROUPS =

* IT_SORT =

* IT_FILTER =

* IS_SEL_HIDE =

* I_DEFAULT = 'X'

* I_SAVE = ' '

* IS_VARIANT =

* IT_EVENTS =

* IT_EVENT_EXIT =

* IS_PRINT =

* IS_REPREP_ID =

* I_SCREEN_START_COLUMN = 0

* I_SCREEN_START_LINE = 0

* I_SCREEN_END_COLUMN = 0

* I_SCREEN_END_LINE = 0

* IMPORTING

* E_EXIT_CAUSED_BY_CALLER =

* ES_EXIT_CAUSED_BY_USER =

TABLES

t_outtab =

* EXCEPTIONS

* PROGRAM_ERROR = 1

Página 167 de 195


* OTHERS = 2

.

IF sy-subrc <> 0.

* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO

* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.

ENDIF.

No será necesario utilizar todos los parámetros de la función. Son indispensables:

T_OUTTAB: Tabla interna que contiene los datos a listar. Puede contener más campos de los que se quieren mostrar, sólo se escribirán los que aparezcan en el catálogo de campos.

IT_FIELDCAT: Tabla interna en la que guardamos el catálogo de campos, las descripciones de los campos a listar. Se construye en el programa, manualmente o con la ayuda de la función REUSE_ALV_FIELDCATALOG_MERGE.

I_STRUCTURE_NAME: Nombre de la estructura del diccionario de datos que describe a la vez los campos de salida y la estructura de la tabla que contiene los datos. Si se usa esta opción no es obligatorio el catálogo de campos

Describimos a continuación algunos de los parámetros opcionales:

I_CALLBACK_PROGRAM: Nombre del programa que llama al módulo de función. No debemos pasar directamente la variable sy-repid (porque cambia de valor al entrar a la función); crearemos una variable con el valor sy-repid para pasarla como parámetro.

I_CALLBACK_PF_STATUS_SET: Nombre de una subrutina del programa actual en la que cambiamos el status GUI del listado de salida (por defecto se usa el estándar: SPACE). FORM set_pf_status USING rt_extab TYPE slis_t_extab.

SET PF-STATUS usrstatus EXCLUDING rt_extab.

I_CALLBACK_USER_COMMAND: Nombre de una subrutina del programa actual en la que tratamos las acciones que realice el usuario en el listado. FORM user_command USING r_ucomm LIKE sy-ucomm

rs_selfield LIKE slis_selfield.

I_CALLBACK_TOP_OF_PAGE: Nombre de una subrutina del programa actual con la que se crea un encabezado de página en el listado de salida. Si se especifica, la subrutina debe comenzar con FORM top_of_page.

IS_LAYOUT: Especificaciones de disposición del listado. Las detallaremos posteriormente.

IT_EXCLUDING: Nombre de una tabla interna con los nombres de las funciones que se incluyen en el código y que no se usarán en el listado.

IT_SORT: Usando la tabla interna aquí indicada, la función determina el orden del listado y/o de los subtotales.

IT_FILTER: Podemos pasar una tabla interna con un criterio de filtrado para la salida.

I_DEFAULT: ‘X’ = Se puede definir una variante de visualización inicial. Por defecto no.

I_SAVE: ‘U’ = Las variantes de visualización se graban sólo como específicas de usuario. ‘X’ = Las variantes de visualización se graban sólo como estándar. ‘A’ = Se puede escoger entre grabación específica o estándar. ‘ ‘ = No se pueden grabar variantes de visualización.

Página 168 de 195


IS_VARIANT: Para pasar a la función la variante de visualización que queremos inicialmente para el listado.

IT_EVENTS: Podemos usar la función REUSE_ALV_EVENTS_GET ver su documentación) para obtener una tabla de eventos posibles para el tipo de lista. Aquí indicaremos qué rutina procesa cada uno de los que queremos tratar. La estructura a pasar contiene los campos NAME y FORM

IT_EVENT_EXIT: Tabla interna usada para indicar los códigos de función estándar para los que queremos recuperar el control en el programa fuente, antes y/o después de su ejecución en el USER_COMMAND. Los campos de la estructura son UCOMM, BEFORE y AFTER.

IS_PRINT: Estructura con parámetros de control sobre la impresión. Podemos utilizar los campos PRINT, NO_PRINT_SELINFOS, NO_PRINT_LISTINFOS, NO_CHANGE_ PRINT_PARAMS.

I_SCREEN_START_COLUMN, I_SCREEN_START_LINE, I_SCREEN_END_COLUMN, I_SCREEN_END_LINE: Coordenadas para mostrar la lista. Sólo se requiere si la lista se muestra como diálogo.

14.3.1 Especificar disposición Los parámetros de la tabla IS_LAYOUT son descritos y agrupados en las siguientes categorías:

14.3.1.1 Opciones de visualización - COLWIDTH_OPTIMIZE: 'X' = Optimiza el ancho de columna para asegurar que el contenido es mostrado completamente.

- NO_COLHEAD: 'X' = No imprime cabeceras de columna.

- ZEBRA: ‘X’= Colorea alternativamente los registros.

- NO_VLINE: ‘X’=Separa las columnas por espacios, no por líneas verticales.

14.3.1.2 Excepciones - LIGHTS_FIELDNAME: Nombre de un campo de la tabla interna de salida con los valores 1, 2 o 3. 1 = semáforo en rojo, 2 = semáforo en amarillo , 3= semáforo en verde.

14.3.1.3 Totales: - NO_TOTALLINE: 'X' = no se mostrará ninguna línea de totales. Si se requieren, los subtotales pueden ser calculados y mostrados. Los campos que se utilizan para los cálculos subtotales deben ser marcados con "DO_SUM = 'X'" en el catálogo del campos.

- NO_SUBTOTALS: ‘X’=no se permite el cálculo de subtotales.

- TOTALS_TEXT: Posibles valores:

‘ ‘ = en la primera columna, el sistema estándar indica el nivel de totales mostrando un número adecuado de '*' para el total absoluto. Después de los asteriscos, el sistema muestra la secuencia 'total' a condición de que la anchura de la primera columna de la salida sea bastante grande. Si la anchura de columna no es suficiente, sólo se exhiben los asteriscos.

‘string’= Después de que el nivel de totales sea indicado por medio de '*', el sistema muestra la cadena pasada, a condición de que la anchura de columna sea suficiente.

Página 169 de 195


- SUBTOTALS_TEXT: Similar al anterior, pero para el nivel de subtotales.

- NUMC_SUM: ‘X’=Será posible calcular, en general, los totales para los campos de tipo NUMC. Podemos usar el parámetro FIELDCAT-NO_SUM para controlar el nº columnas NUMC que serán o no calculadas.

14.3.1.4 Interacción: - BOX_FIELDNAME: Si queremos que nuestro listado tenga algún ‘checkbox’ al principio de cada línea (para permitir selección múltiple), se debe rellenar este parámetro con el nombre del campo de la tabla interna de salida que represente la columna de la selección para seleccionar líneas con la ayuda de los ‘checkbox’.

- BOX_TABNAME: si se rellena el anterior, indicar nombre de la tabla interna de salida.

- F2CODE: Valores posibles: SPACE o código de función. Si queremos asignar un código de función a una pulsación F2 (doble-click), lo indicamos en este parámetro.

- CONFIRMATION_PROMPT: ' X ' = si una de las funciones 'Back(F03)', 'Exit(F15)' o 'Cancel(F12)' se acciona, el sistema pregunta al usuario si desea salir del listado.

- KEY_HOTSPOT: las columnas definidas como claves en el catálogo de campos (FIELDCAT-KEY=’X’) son mostradas como ‘hotspots’ (es decir, si hacemos click en ese campo –que estará en color-, se ejecuta la función asignada a F2.

14.3.1.5 Pantalla de detalles - DETAIL_INITIAL_LINES: ‘ X ' = el contenido inicial del campo también se muestra en la pantalla de detalle.

- DETAIL_TITLEBAR: ‘ ' = el sistema muestra 'Detalle: Vista' como el título de la pantalla del detalle. 'string' = el sistema muestra la cadena pasada como el título de la pantalla del detalle.

14.3.1.6 Color - INFO_FIELDNAME: Rellenamos con el nombre de un campo de la tabla interna de salida que contiene el código de color para cada registro de la lista. No cambia el color de las columnas clave. El campo que indicamos debe ser de tipo CHAR(3); el código de color debe ser de la forma: Cxy ; siendo x = nº de color (1-9) e y = Intensidad (0: off, 1: on).

- COLTAB_FIELDNAME: Se pueden colorear celdas individualmente indicando aquí el nombre del campo de la tabla interna de salida (de tipo SLIS_T_SPECIALCOL_ALV) que contiene en una estructura: el campo a colorear (FIELDNAME), el número de color (COLOR-COL), la negrita (COLOR-BOLD), el inverso (COLOR-INV) y la marca de ignorar el color de clave (NOKEYCOL).

14.3.2 Parámetros de retorno E_EXIT_CAUSED_BY_CALLER: Elimina lista en parámetro CALLBACK_USER_COMMAND.

ES_EXIT_CAUSED_BY_USER: Señala el modo en que el usuario abandona la vista de listado. Si se incluye código para “Back”, “Cancel” o “Exit”, el sistema sale del listado actual. La estructura ES_EXIT_CAUSED_BY_USER se rellenará:

- ES_EXIT_CAUSED_BY_USER-BACK = 'X' si el usuario pulsa ‘Back’.

- ES_EXIT_CAUSED_BY_USER-CANCEL = 'X' si el usuario pulsa ‘Cancel’.

- ES_EXIT_CAUSED_BY_USER-EXIT = 'X' si el usuario pulsa ‘Exit’.

Página 170 de 195


14.3.3 Ejemplo simple Usando una estructura del diccionario (en este caso SIMLISTRUC) es muy sencillo generar un listado ALV.

REPORT Z_ALV_1.

TABLES: SPFLI.

TYPES: BEGIN OF t_con.

INCLUDE STRUCTURE SIMLISTRUC.

TYPES: END OF t_con.

DATA: it_con TYPE TABLE OF t_con.

START-OF-SELECTION.

SELECT * FROM spfli INTO CORRESPONDING FIELDS OF TABLE it_con.

END-OF-SELECTION.

CALL FUNCTION 'REUSE_ALV_LIST_DISPLAY'

EXPORTING

I_STRUCTURE_NAME = 'SIMLISTRUC'

TABLES

t_outtab = it_con

EXCEPTIONS

PROGRAM_ERROR = 1

OTHERS = 2

.

IF sy-subrc <> 0.

MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO

WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.

ENDIF.

14.4 Función REUSE_ALV_FIELDCATALOG_MERGE Si el listado que queremos mostrar no se corresponde exactamente con una estructura del Diccionario, o si queremos controlar los títulos de la tabla de salida, podemos utilizar el catálogo de campos.

Necesitaremos declarar al inicio del programa un Grupo Tipos y una variable global para el catálogo. TYPE-POOLS: SLIS.

DATA: it_fcat TYPE slis_t_fieldcat_alv.

Página 171 de 195


En vez de utilizar el parámetro I_STRUCTURE_NAME en la llamada a la función REUSE_ALV_LIST_DISPLAY, usaremos el parámetro IT_FIELDCAT, al que le pasaremos el catálogo de campos contenido en it_fcat.

Pero antes deberemos construir el catálogo de campos. Podemos hacerlo de forma manual teniendo en cuenta cuál es la información mínima necesaria:

CAMPOS OBLIGATORIOS DEL CATÁLOGO:

FIELDNAME: Nombre del campo de la tabla interna a listar.

Para campos definidos con referencia al Diccionario:

REF_TABNAME: Nombre de la tabla del Diccionario.

REF_FIELDNAME: Nombre del campo (sólo si no coincide con el de la tabla interna)

Para campos sin referencia al Diccionario:

OUTPUTLEN: Ancho de columna.

DATATYPE: Tipo de datos del campo

SELTEXT_L: Descripción larga del campo (40).

SELTEXT_M: Descripción media del campo (20).

SELTEXT_S: Descripción corta del campo (10).

Otros campos que forman el catálogo son:

row_pos(0-3, cuando tenemos más de una fila, se puede indicar en qué linea lo queremos o si la ponemos por defecto con un '0')

col_pos(columna en la que debe salir),

cfieldname/ctabname('currency' campo/tabla. Cuando tenemos un campo tipo importe, este debe hacer referencia a un campo que contenga la moneda, para formatear correctamente el número de posiciones decimales. Con estos campos le podemos especificar dicho campo),

qtabname/qfieldname (al igual que cfieldname/ctabname con campos tipo cantidad), outputlen (ancho de columna que se debe mostrar),

key ('X' marca la columna como clave. Esto hace que esta columna no pueda ser ocultada),

key_sel (lo marcamos con una 'X' si queremos que aun siendo campo clave se pueda ocutlar),

no_out ('X' para no mostrarlo por pantalla, pero se podrá mostrar si lo pide el usuario),

tech (campo técnico, no se mostrará y no se podrá mostrar interactivamente),

emphasize (si marcamos 'X' la realzará, si ponemos un código tipo 'Cxyz' -> color 1-9, negrita 0-1 e inverso 0-1 podremos cambiarle el aspecto),

hotspot (con 'X' se comportará como un campo enlace),

fix_column(fija la columna para que no se le pueda hacer scroll),

do_sum ('X' muestra la columna sumarizada),

no_sum('X' no permite la suma del campo),

icon('X' indica que el campo contiene un código de icono y mostará el icono en vez del valor),

symbol(('X' indica que el campo contiene un código de símbolo y mostará el símbolo

Página 172 de 195


en vez del valor),

just (justificación R, L o C),

lzero (si un campo es de tipo carácter-numérico y lo marcamos con 'X' el campo se mostrará con los ceros iniciales),

edit_mask(formatea el campo. Funciona de forma análoga al como se usa en la sentencia 'Write'),

seltext_l/m/s (texto largo, medio y corto para la cabecera de lista),

reptext_ddic(texto en cabecera de lista),

ddicttxt(se marca en blanco para poner el texto por defecto en la cabecera, 'S' para el corto, 'M' para el medio o 'L' para el largo),

datatype (indicamos el tipo de datos para los campos no referenciados a un campo de la tabla de base de datos),

ddic_outputlen(longitud de salida del campo de diccionario),

intlen(longitud de salida del campo que no es de diccionario),

rollname(muestra la ayuda del campo referenciado al pulsar F1).

La función REUSE_ALV_FIELDCATALOG_MERGE nos facilita la creación del catálogo de campos correspondiente a una tabla interna o a una estructura del Diccionario: CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE'

* EXPORTING

* I_PROGRAM_NAME =

* I_INTERNAL_TABNAME =

* I_STRUCTURE_NAME =

* I_CLIENT_NEVER_DISPLAY = 'X'

* I_INCLNAME =

* I_BYPASSING_BUFFER =

* I_BUFFER_ACTIVE =

CHANGING

ct_fieldcat =

* EXCEPTIONS

* INCONSISTENT_INTERFACE = 1

* PROGRAM_ERROR = 2

* OTHERS = 3

.

IF sy-subrc <> 0.

* MESSAGE ID SY-MSGID TYPE SY-MSGTY NUMBER SY-MSGNO

* WITH SY-MSGV1 SY-MSGV2 SY-MSGV3 SY-MSGV4.

ENDIF.

Describimos brevemente sus parámetros:

I_PROGRAM_NAME: Nombre del programa (se recomienda usar una variable con el valor de SY-REPID).

Página 173 de 195


I_INTERNAL_TABNAME: Nombre de la tabla interna de salida (se recomienda mejor usar una estructura de diccionario de datos). Sólo se consideran los campos que se definen con referencia al Diccionario.

I_STRUCTURE_NAME: Nombre de la estructura del Diccionario de datos que usamos para la salida (que será la misma que teníamos en la llamada a REUSE_ALV_GRID_DISPLAY).

I_CLIENT_NEVER_DISPLAY: Ocultar campos de cliente (tipo CLNT).

I_INCLNAME: Si la declaración de la tabla interna de datos de salida no está asignada en el include TOP, el nombre del include puede especificarse aquí.

CT_FIELDCAT: Nombre de la tabla interna para el catálogo de campos (en nuestro ejemplo, it_fcat).

La llamada a la función llena el catálogo de campos con los atributos de los campos de la estructura o de la tabla interna indicada. Si queremos modificar alguno de los atributos de algún campo, podemos hacer un LOOP a la tabla interna del catálogo de campos (en nuestro caso ‘it_fcat’) y modificaremos los campos apropiados.

Por ejemplo, para modificar la descripción que se muestra en el listado, basta con cambiar los campos seltext_l (formato largo), seltext_m (formato medio) y seltext_s (formato corto) o bien reptext_ddic (texto diccionario). REPORT Z_ALV_2.

TYPE-POOLS: SLIS.

TABLES: SPFLI.

TYPES: BEGIN OF t_con.

INCLUDE STRUCTURE SIMLISTRUC.

TYPES: END OF t_con.

FIELD-SYMBOLS: <fs_fcat> TYPE slis_fieldcat_alv.

DATA: it_fcat TYPE slis_t_fieldcat_alv.

DATA: it_con TYPE TABLE OF t_con.

DATA: pid LIKE sy-repid.

START-OF-SELECTION.

pid = sy-repid.

SELECT * FROM spfli INTO CORRESPONDING FIELDS OF TABLE it_con.

END-OF-SELECTION.

CALL FUNCTION 'REUSE_ALV_FIELDCATALOG_MERGE'

EXPORTING

I_PROGRAM_NAME = pid

I_STRUCTURE_NAME = 'SIMLISTRUC'

CHANGING

ct_fieldcat = it_fcat

EXCEPTIONS

INCONSISTENT_INTERFACE = 1

Página 174 de 195


PROGRAM_ERROR = 2

OTHERS = 3

.

IF sy-subrc <> 0.



ENDIF.

LOOP AT it_fcat ASSIGNING <fs_fcat>.

IF <fs_fcat>-fieldname = 'CONNID'.

<fs_fcat>-seltext_l = 'Conexión'.

<fs_fcat>-seltext_m = 'Conexión'.

<fs_fcat>-seltext_s = 'Con'.

MODIFY it_fcat FROM <fs_fcat>.

ENDIF.

ENDLOOP.

CALL FUNCTION 'REUSE_ALV_LIST_DISPLAY'

EXPORTING

I_CALLBACK_PROGRAM = pid

* I_STRUCTURE_NAME = 'SIMLISTRUC'

IT_FIELDCAT = it_fcat[]

TABLES

t_outtab = it_con

EXCEPTIONS

PROGRAM_ERROR = 1

OTHERS = 2

.

IF sy-subrc <> 0.



ENDIF.

14.5 Otras funciones Con otras funciones del grupo SALV se pueden generar otros tipos de listados.

Con REUSE_ALV_GRID_DISPLAY sólo cambia la apariencia, la interfase para esta función es exactamente la misma que para REUSE_ALV_LIST_DISPLAY. Los datos se muestran en una tabla en vez de en un listado:

Página 175 de 195


En otros casos cambia la estructura del listado. Entonces, además de la tabla interna con la información a mostrar (T_OUTTAB) y la estructura (I_STRUCTURE_NAME) o el

e y T_OUTTAB_ITEM.

catálogo de campos (IT_FIELDCAT) se debe pasar información adicional a la función.

Con REUSE_ALV_HIERSEQ_LIST_DISPLAY se pueden mostrar listados jerárquicos. En el catálogo de campos se debe indicar qué campos son de cabecera y cuáles de detalle. Se deben indicar los nombres de las tablas internas o bien estructuras que contienen los registros de cabecera (I_TABNAME_HEADER/ I_STRUCTURE_NAME_ HEADER) y los de detalle (I_TABNAME_ITEM/ I_STRUCTURE_NAME_ITEM). La función debe conocer también la relación entre las dos tablas (IS_KEYINFO). No spasa una tabla de información sino dos: T_OUTTAB_HEADER

Con REUSE_ALV_BLOCK_LIST_DISPLAY se pueden mostrar listados de bloques. Se debe utilizar previamente la función REUSE_ALV_BLOCK_LIST_INIT para inicializar el listado y para cada bloque que deseemos añadir se debe llamar a la función REUSE_ALV_BLOCK_LIST_APPEND pasándole como mínimo el catálogo de campos y los datos.

Página 176 de 195


Página 177 de 195

Con REUSE_ALV_POPUP TO SELECT se pueden mostrar listados en pop-up.


15 Tratamiento de Ficheros

15.1 Del servidor de aplicación Para poder trabajar con ficheros secuenciales que se encuentren en el servidor de aplicación, disponemos de las siguientes instrucciones básicas:

Operación Sentencia

Abrir para lectura OPEN DATASET <fichero> FOR INPUT

IN [TEXT|BINARY] MODE.

Abrir para escritura OPEN DATASET <fichero> FOR OUTPUT IN [TEXT|BINARY] MODE.

Abrir para añadir líneas

OPEN DATASET <fichero> FOR APPENDING

IN [TEXT|BINARY] MODE.

Recibir mensajes del sistema operativo

OPEN DATASET <fichero> ...

MESSAGE <mensaje>.

Cerrar CLOSE DATASET <fichero>.

Borrar DELETE DATASET <fichero>.

Leer una línea READ DATASET <fichero> INTO <registro>.

Escribir una línea TRANSFER <registro> TO <fichero>.

La variable de sistema SY-SUBRC retorna valores de error para todas las sentencias de tratamientos de ficheros, si su valor es 0 la operación se ha realizado se ha realizado correctamente.

15.1.1 Abrir OPEN DATASET nfich .

Abre un fichero para su tratamiento, si no se añade ninguna opción abre el fichero para lectura en modo binario.

Las principales opciones son:

.. FOR OUTPUT Abre el fichero para escritura. Si el fichero existe lo borra y lo crea nuevamente.

.. FOR INPUT Abre el fichero para lectura.

.. FOR APPENDING.

Abre un fichero para escritura si el fichero no existe se crea. Si ya existe, se comenzará a escribir al final del fichero.

..IN BINARY MODE.

Abre el fichero en modo binario , es decir, la información se tratará por bloques. De tal modo que en cada lectura se leerán /escribirán n caracteres.

..IN TEXT MODE.

Abre el fichero en modo texto, es decir, la información se tratara línea a línea. Cada lectura/escritura procesará una línea del fichero.

..MESSAGE d_mes

Página 178 de 195


Almacena en ‘d_mes’ el mensaje devuelto por el sistema operativo.

..AT POSITION d_pos.

Sitúa el puntero de escritura en la posición d_pos (bytes) desde el inicio del fichero. (Esta opción , no tiene sentido emplearla para tratamientos en modo texto).

.. TYPE Permite definir atributos del fichero.

.. FILTER Permite ejecutar comandos propios del sistema operativo.

15.1.2 Leer READ DATASET nfich INTO wa.

Lee un bloque de información del fichero y los coloca en una estructura o tabla interna. Hay que tener en cuenta la longitud de los campos, ya que sino a la hora de leer se pueden coger caracteres de otros campos.

Si el fichero se abre en modo TEXTO:

Se lee una línea completa de tal forma que si el campo ‘wa’ es de menor tamaño que la línea , se perderá su contendido , en caso contrario se completará con blancos. El puntero de lectura se situará al comienzo de la línea siguiente.

Si el fichero se abre en modo BINARIO:

Se lee del fichero tantos bytes como tamaño tenga el campo ‘wa’.

15.1.3 Escribir TRANSFER wa TO nfich.

Escribe el contenido del campo WA en el fichero abierto para escritura.

Si en modo texto:

Escribe una línea completa.

Si en modo binario:

Escribe tantos bytes como tenga el campo ‘wa’.

15.1.4 Cerrar CLOSE DATASET nfich.

Cierra un fichero abierto para lectura o escritura.

DELETE DATASET nfich.

Borra el fichero nfich.

15.1.5 Autorizaciones El sistema R/3 realiza automáticamente las siguientes comprobaciones cuando trabajamos con ficheros secuenciales: verifica la autorización en el objeto S_DATASET y verifica la tabla SPTH para comprobar si el fichero especificado está registrado para su acceso desde ABAP

El objeto S_DATASET nos permite asignar autorizaciones de acceso para ficheros determinados desde programas determinados. Contiene los siguientes campos:

Nombre del programa ABAP: Nombre del programa ABAP para el que se permite el acceso, desde el que se va a abrir el fichero. Esto nos permite restringir el acceso a

Página 179 de 195


los ficheros para los programas que deseemos.

Actividad: Tipo de acceso. Los valores posibles son:

33 : Lectura del fichero

34 : Escritura o borrado del fichero

A6 : Lectura del fichero mediante filtros (comando del sistema operativo)

A7 : Escritura del fichero mediante filtros (comando del sistema operativo).

Nombre del fichero: nombre del fichero del sistema operativo. Esto nos permite restringir los ficheros para los que van a tener acceso los usuarios.

En cualquier caso, deberíamos comprobar en nuestro programa la autorización antes de acceder al fichero mediante el módulo de función AUTHORITY_CHECK_DATASET, que nos permite verificar si el usuario está autorizado para acceder al fichero antes de que el sistema intente abrirlo. Esto previene que se produzca un posible error en tiempo de ejecución que, en otro caso, se produciría cuando se realizase la verificación de autorización automática.

El módulo de función como parámetros IMPORT el programa y la actividad a realizar, los campos del objeto S_DATASET.

En la tabla SPTH, podemos controlar el acceso de lectura o escritura para ficheros especificados de forma genérica, independientemente del concepto de autorización de R/3. Para el resto de los ficheros (es decir, para aquellos cuyo acceso de lectura o escritura está permitido de acuerdo con la tabla SPTH), debemos utilizar el concepto de autorización de R/3 para verificar las autorizaciones. Para que podamos hacer esto, debemos especificar grupos de autorizaciones en la tabla SPTH para verificaciones de autorizaciones de usuario independientes de programa.

SPTH contiene los siguientes campos para este propósito:

PATH

Contiene el nombre del fichero genérico. Esto significa que los ficheros que se encuentren en el servidor de aplicaciones a los que se aplique una entrada en este campo, retienen los atributos especificados en los restantes campos de la línea.

SAVEFLAG

Si se activa este flag, los ficheros especificados en el campo PATH serán incluidos en los procedimientos de seguridad.

FS_NOREAD

Si se activa este flag, los ficheros especificados en el campo PATH no se podrá acceder para nada a los ficheros desde ABAP. Este flag elude todas las autorizaciones que tenga el usuario. Si activamos FS_READ, se activará automáticamente FS_NOWRITE.

Si no se activa este flag, se hace posible el acceso a los ficheros desde ABAP si se pasan con éxito los chequeos de autorización.

FS_NOWRITE

Si se activa este flag, los ficheros especificados en el campo PATH no se podrá acceder para escribir en los ficheros desde ABAP. Este flag elude todas las autorizaciones que tenga el usuario.

Si no se activa este flag, se hace posible cambiar los ficheros desde ABAP si se pasan con éxito los chequeos de autorización.

FSBRGRU Esta columna contiene los nombres de los grupos de autorización.

Página 180 de 195


Un grupo de autorización se corresponde con el primer campo (RS_BRGRU) del objeto de autorización S_PATH. Podemos utilizar el segundo campo del objeto de autorización S_PATH (ACTVT) para comprobar si el usuario tiene autorización para leer (valor 3) o cambiar (valor 2) los ficheros de su grupo de autorización.

Las entradas de FSBRGRU especifican grupos de ficheros en el servidor de aplicaciones. Podemos controlar el acceso a los ficheros asignando autorizaciones para el objeto de autorización S_PATH.

A diferencia de las verificaciones de autorización mediante el objeto de autorización S_DATASET, la verificación de autorización contra el objeto de autorización S_PATH es independiente del programa ABAP utilizado para acceder a los ficheros. Además, las verificaciones no se restringen a ficheros individuales, sino que se extienden a todos los ficheros especificados genéricamente en la columna PATH.

Si no existe ninguna entrada en la columna FSBRGRU, los ficheros de la columna PATH no serán asignados a un grupo de autorización, y no se realizará ninguna verificación de autorización contra el objeto de autorización S_PATH.

Si falla una verificación automática para un acceso a un fichero, se producirá un error en tiempo de ejecución.

Ejemplo: Supongamos que la tabla SPTH contiene las siguientes entradas:

PATH SAVEFLAG FS_NOREAD FS_NOWRITE FSBRGRU

* X X

/tmp

/tmp/files X FILE

Entonces las entradas son válidas como se indica a continuación:

Primera línea: todos los ficheros del servidor de aplicaciones aparte del path ‘/tmp’.

Segunda línea: todos los ficheros del servidor de aplicaciones en el path ‘/tmp’ aparte del fichero ‘tmp/files’

Tercera línea: el fichero del servidor de aplicaciones ‘tmp/mifichero’

Con estas características, los programas ABAP no pueden acceder a ningún fichero del servidor de aplicaciones salvo a aquellos del path /tmp. Todos los programas ABAP pueden leer y escribir en los ficheros de este path. Sólo los usuarios con autorización para el grupo de autorizaciones FILE pueden utilizar un programa ABAP para leer o escribir en los ficheros del path ‘/tmp/files’. Estos ficheros también se incluirán en el proceso de seguridad.

Con las entradas anteriores, el siguiente trozo de programa provocaría un error en tiempo de ejecución para cualquier usuario: DATA: NOMBREF(60).

NOMBREF = '/system/files'.

OPEN DATASET FNAME FOR OUTPUT.

15.2 Del servidor de presentación Vamos a ver como trabajar con ficheros locales, entendiendo como tales aquellos que se encuentran dentro del terminal (en una unidad de disco, disco de red…).

Página 181 de 195


Existen dos funciones estándar que nos permiten importar y exportar datos a ficheros locales:

GUI_DOWNLOAD and GUI_UPLOAD

Escribiremos en un fichero el contenido de una tabla interna, o leeremos el contenido de un fichero en una tabla interna.

15.2.1 Escritura

Diálogo con el usuario Para escribir datos desde una tabla interna a un fichero que se encuentre en el servidor de presentación manteniendo un diálogo con el usuario utilizaremos el módulo de función DOWNLOAD.

Parámetros IMPORT importantes:

Parámetro Función

BIN_FILESIZE Longitud del fichero para ficheros binarios.

CODEPAGE Sólo para escribir ficheros bajo DOS: Valor IBM.

FILENAME Nombre del fichero (valor por defecto para el diálogo con el usuario)

FILETYPE Tipo de fichero (valor por defecto para el diálogo con el usuario)

Se utiliza para especificar el modo de transferencia. Los valores posibles son: BIN: ficheros binarios. Debemos especificar la longitud del fichero.

La tabla interna debe contener una única columna del tipo de datos X.

ASC: ficheros ASCII. DAT: ficheros Excel. Las columnas estarán separadas mediante

tabuladores. Las líneas se separan por rupturas de línea. WK1: ficheros Excel y Lotus. Los ficheros se salvan en una hoja

de cálculo WK1.

ITEM Título para la ventana de diálogo.

MODE Modo de escritura (blanco = sobreescribir, ‘A’ = añadir).

Parámetros EXPORT importantes:

Parámetro Función

ACT_FILENAME Nombre del fichero (como se introdujo en el diálogo con el usuario).

ACT_FILETYPE Tipo de fichero (como se introdujo en el diálogo con el usuario).

FILESIZE Número de bytes transferidos.

Parámetros TABLES:

Parámetro Función

Página 182 de 195


DATA_TAB Tabla interna que contiene los datos

Parámetros EXCEPTIONS:

Parámetro Función

INVALID_FILESIZE Parámetro BIN_FILESIZE no válido

INVALID_TABLE_WIDTH Estructura de tabla no válida

INVALID_TYPE El valor de FILETYPE es incorrecto

Ejemplo: Supongamos que el servidor de presentación se está ejecutando bajo Windows 95, y hemos escrito el siguiente programa: PROGRAM ZTSTFICH.

DATA: NOMB_FICH(128),

TIPO_FICH(3),

TAM_FICH TYPE I.

DATA: BEGIN OF TABI OCCURS 0,

COL1 TYPE I,

COL2 TYPE I,

END OF TABI.

DO 5 TIMES.

TABI-COL1 = SY-INDEX.

TABI-COL2 = SY-INDEX ** 2.

APPEND TABI.

ENDDO.

CALL FUNCTION 'DOWNLOAD'

EXPORTING

CODEPAGE = 'IBM'

FILENAME = 'c:\temp\testsap.xls'

FILETYPE = 'DAT'

ITEM = 'Test para Fichero Excel'

IMPORTING

ACT_FILENAME = NOMB_FICH

ACT_FILETYPE = TIPO_FICH

Página 183 de 195


FILESIZE = TAM_FICH

TABLES

DATA_TAB = TABI

EXCEPTIONS

INVALID_FILESIZE = 1

INVALID_TABLE_WIDTH = 2

INVALID_TYPE = 3.

WRITE: 'SY-SUBRC:', SY-SUBRC,

/ 'Nombre:', (60) NOMB_FICH,

/ 'Tipo :', TIPO_FICH,

/ 'Tamaño:', TAM_FICH.

El programa muestra la siguiente ventana de diálogo:

Aquí, el usuario puede cambiar los valores que aparecen por defecto. Cuando el usuario pulsa el botón Transferir, el sistema escribe los datos de la tabla interna TABI rellenada en el programa, al fichero C:\temp\textsap.xls. Si el fichero ya existe, el sistema preguntará al usuario si desea reemplazar la versión existente. El sistema inserta tabuladores entre las columnas, y saltos de línea al final de cada línea.

En las salida aparecería algo como esto:

Ahora, podemos abrir el fichero C:\temp\testsap.xls utilizando Excel. Aparecería algo como esto:

Página 184 de 195


Sin diálogo Para escribir datos de una tabla interna en el servidor de presentación sin mantener un diálogo con el usuario, utilizaremos el módulo de función WS_DOWNLOAD. Los parámetros más importantes se listan más abajo.


Parámetro Función

BIN_FILESIZE Longitud del fichero para ficheros binarios.








de cálculo WK1.

MODE Modo de escritura (blanco = sobreescribir, ‘A’ = añadir).

Parámetros EXPORT:

Parámetro Función

FILELENGHT Número de bytes transferidos.

Parámetros TABLES:

Parámetro Función

DATA_TAB Tabla interna que contiene los datos


Parámetro Función

FILE_OPEN_ERROR El fichero no se puede abrir

FILE_WRITE_ERROR No se puede escribir en el fichero

INVALID_FILESIZE Parámetro BIN_FILESIZE no válido


INVALID_TYPE EL VALOR DE FILETYPE ES INCORRECTO

Página 185 de 195


Ejemplo: Supongamos que el servidor de presentación está ejecutándose bajo Windows 95, y hemos escrito el siguiente programa:

PROGRAM ZTSTFICH.

DATA: LONG_FICH TYPE I,

TAB(80) OCCURS 5.

APPEND 'Esta es la primera línea de mi texto. ' TO TAB.

APPEND 'La segunda línea. ' TO TAB.

APPEND ' La tercera línea. ' TO TAB.

APPEND ' La cuarta línea. ' TO TAB.

APPEND ' La quinta y última línea. ' TO TAB.

CALL FUNCTION 'WS_DOWNLOAD'

EXPORTING

CODEPAGE = 'IBM'

FILENAME = 'c:\temp\testsap.txt'

FILETYPE = 'ASC'

IMPORTING

FILELENGTH = LONG_FICH

TABLES

DATA_TAB = TAB

EXCEPTIONS

FILE_OPEN_ERROR = 1

FILE_WRITE_ERROR = 2

INVALID_FILESIZE = 3


INVALID_TYPE = 5.

WRITE: 'SY-SUBRC :', SY-SUBRC,

/ 'Longitud fichero:', LONG_FICH.

La salida muestra lo siguiente:

El sistema ha escrito las cinco líneas de la tabla TAB en el fichero ASCII c:\temp\testsap.tx. Ahora abrir este fichero utilizando cualquier editor del servidor de presentación. En este ejemplo hemos utilizado el editor de DOS:

Página 186 de 195


Página 187 de 195

15.2.2 Lectura

Diálogo con el usuario Para leer un fichero que se encuentra en el servidor de presentación en una tabla interna manteniendo un diálogo con el usuario utilizaremos el módulo de función UPLOAD. Los parámetros más importantes de este módulo de función se indican a continuación.


Parámetro Función

CODEPAGE Sólo para leer ficheros bajo DOS: Valor IBM.







de cálculo WK1.

ITEM Título para la ventana de diálogo.


Parámetros EXPORT importantes:

Parámetro Función

ACT_FILENAME Nombre del fichero (como se introdujo en el diálogo con el usuario).

ACT_FILETYPE Tipo de fichero (como se introdujo en el diálogo con el usuario).

FILESIZE Número de bytes transferidos.

Parámetros TABLES:

Parámetro Función

DATA_TAB Tabla interna (destino de la lectura)


Parámetro Función

CONVERSION_ERROR Error en la conversión de los datos


INVALID_TYPE El valor de FILETYPE es incorrecto

Ejemplo: Supongamos que el servidor de presentación se está ejecutando bajo Windows 95, y contiene el siguiente fichero Excel:

Si esta tabla se salva en el fichero de texto “C:\temp\pelis.txt” con tabuladores entre las columnas, el siguiente programa podría leer la tabla: PROGRAM ZTSTFICH.


TIPO_FICH(3),

TAM_FICH TYPE I.

DATA: BEGIN OF TABI OCCURS 0,

COL1(10) TYPE C,

COL2(10) TYPE C,

Página 188 de 195


COL3(10) TYPE C,

END OF TABI.

CALL FUNCTION 'UPLOAD'

EXPORTING

CODEPAGE = 'IBM'

FILENAME = 'c:\temp\pelis.txt'

FILETYPE = 'DAT'

ITEM = 'Test Lectura de Fichero Excel'

IMPORTING

FILESIZE = TAM_FICH

ACT_FILENAME = NOMB_FICH

ACT_FILETYPE = TIPO_FICH

TABLES

DATA_TAB = TABI

EXCEPTIONS

CONVERSION_ERROR = 1


INVALID_TYPE = 3.


/ 'Nombre :', (60) NOMB_FICH,

/ 'Tipo :', TIPO_FICH,

/ 'Tamaño :', TAM_FICH.

SKIP.

LOOP AT TABI.

WRITE: / TABI-COL1, TABI-COL2, TABI-COL3.

ENDLOOP.

El programa mostraría la siguiente ventana de diálogo:

Página 189 de 195


Página 190 de 195

Aquí, el usuario puede cambiar los valores que aparecen por defecto. Cuando el usuario pulsa el botón ‘Transferir’, el sistema importa los datos del fichero C:\temp\pelis.txt a la tabla interna TABI.

La salida muestra los siguiente:

El contenido de la tabla interna TABI es exactamente el mismo que el contenido de la tabla original de Excel.

Sin diálogo Para leer los datos de un fichero que se encuentre en el servidor de presentación en una tabla interna sin mantener diálogo con el usuario, utilizaremos el módulo de función WS_UPLOAD. Los parámetros más importantes de este módulo de función se listan a continuación.


Parámetro Función








de cálculo WK1.

Parámetros EXPORT:

Parámetro Función

FILELENGHT Número de bytes transferidos.

Parámetros TABLES:


Parámetro Función

DATA_TAB Tabla interna (destino de la lectura)


Parámetro Función

CONVERSION_ERROR Error en la conversión de los datos

FILE_OPEN_ERROR El fichero no se puede abrir

FILE_READ_ERROR No se puede leer el fichero


INVALID_TYPE EL VALOR DE FILETYPE ES INCORRECTO

Ejemplo: Supongamos que el servidor de presentación se está ejecutando bajo Windows 95, y contiene el siguiente fichero de texto:

El siguiente programa leería el fichero de texto:

PROGRAM ZTSTFICH.

DATA: LONG_FICH TYPE I.

DATA: TABI(80) OCCURS 5 WITH HEADER LINE.

CALL FUNCTION 'WS_UPLOAD'

EXPORTING

FILENAME = 'c:\temp\mitexto.txt'

FILETYPE = 'ASC'

IMPORTING

FILELENGTH = LONG_FICH

TABLES

DATA_TAB = TABI

EXCEPTIONS

CONVERSION_ERROR = 1

Página 191 de 195


FILE_OPEN_ERROR = 2

FILE_READ_ERROR = 3


INVALID_TYPE = 5.


/ 'Longitud :', LONG_FICH.

SKIP.

LOOP AT TABI.

WRITE: / TABI.

ENDLOOP.

En la salida aparece lo siguiente:

15.2.3 Verificación de ficheros del Servidor de Presentación Para recuperar información acerca de los ficheros que se encuentran en el servidor de presentación y el sistema operativo del servidor de presentación, utilizaremos el módulo de función WS_QUERY. A continuación, se listan los parámetros más importantes de este módulo de función.


Parámetro Función

FILENAME Nombre del fichero para comandos de pregunta ‘FE’, ‘FL’ y ‘DE’.

QUERY Comando de pregunta. Los comandos más importantes son: CD: devuelve el directorio actual. EN: devuelve las variables de entorno. FL: devuelve la longitud del fichero especificado en FILENAME. FE: devuelve si existe el fichero especificado en FILENAME. DE: devuelve si existe el directorio especificado en FILENAME. WS: devuelve el sistema Windows del servidor de presentación. OS: devuelve el sistema operativo del servidor de presentación.

Parámetro EXPORT:

Parámetro Función

RETURN Resultado de la pregunta (‘0’ = no, ‘1’ = sí)

Página 192 de 195


Página 193 de 195

Parámetro EXCEPTION:

Parámetro Función

INV_QUERY QUERY o FILENAME contienen un valor incorrecto.

Ejemplo: Supongamos que el servidor de presentación se está ejecutando bajo Windows 95, y el fichero SYSTEM.INI existe como se indica a continuación:

El siguiente programa devolvería algunos de los atributos del sistema operativo y del fichero:

PROGRAM ZTSTFICH.


RESULTADO(30),

LONG_FICH TYPE I.

NOMB_FICH = 'C:\WINDOWS\SYSTEM.INI'.

CALL FUNCTION 'WS_QUERY'

EXPORTING

*>> Preguntamos por el sistema operativo:

QUERY = 'OS'

IMPORTING

RETURN = RESULTADO

EXCEPTIONS

INV_QUERY = 1.

IF ( SY-SUBRC = 0 ).

WRITE: / 'Sistema Operativo:', RESULTADO.

ENDIF.


EXPORTING


*>> Preguntamos por la versión de Windows:

QUERY = 'WS'

IMPORTING

RETURN = RESULTADO

EXCEPTIONS

INV_QUERY = 1.


WRITE: / 'Windows:', RESULTADO.

ENDIF.


EXPORTING

FILENAME = NOMB_FICH

*>> Preguntamos si existe el fichero:

QUERY = 'FE'

IMPORTING

RETURN = RESULTADO

EXCEPTIONS

INV_QUERY = 1.


WRITE: / '¿Existe el fichero?', RESULTADO.

ENDIF.


EXPORTING

FILENAME = NOMB_FICH

*>> Preguntamos por la longitud del fichero:

QUERY = 'FL'

IMPORTING

RETURN = LONG_FICH

EXCEPTIONS

INV_QUERY = 1.


WRITE: / 'Longitud fichero:', LONG_FICH.

ENDIF.

Página 194 de 195


La salida del programa mostraría lo siguiente:

Para una información más detallada acerca de las abreviaturas utilizada para los sistemas operativos, colocaremos el cursor en el campo QUERY de la pantalla de documentación del módulo de función y pulsaremos Ayuda.

Página 195 de 195

Documents

3. Manual Abap4 - i