An Indra company

Sistema R / 3.
ABAP / 4.

Transferencia de datos.

Enero de 2019
Índice

1. Introducción a los Batch Inputs ..................................................................................................................3

2. Características especiales de los Batch Inputs ..........................................................................................8
3. Call Transaction. Grabación de Batch Inputs ...........................................................................................12
4. Manejo de ficheros: Upload, Download y Transfer...................................................................................13

An Indra company 2
1. Introducción a los Batch Inputs
Cambiando el sistema estándar SAP
Visión general de las tareas

Las razones para transferir datos sin que exista diálogo interactivo con el usuario son:
- Los ficheros son grandes y ya existen sobre un soporte de datos electrónico.
- Los datos son transferidos a otro sistema y sólo entonces son importados al sistema SAP.

Visión general del problema

No se debe transferir datos externos directamente a la base de datos SAP. Antes deben ser chequeados.

Visión general de la técnica

Grandes cantidades de datos son transferidas al sistema SAP usando BATCH INPUT.
Batch input es un procedimiento automático. A menudo es conocido como BDC (Batch data Communication).
Para garantizar la consistencia, los datos transferidos están sujetos a las mismas comprobaciones y
modificaciones que los datos proporcionados interactivamente por el usuario. Por ejemplo: comprobaciones
de formato, comprobaciones automáticas de rango de valores (contra tablas de chequeo o rango de valores),
conversión de datos de usuarios a datos de programa y viceversa, y valores de campos por defecto.
Los datos transferidos son almacenados temporalmente en forma de ‘sesiones batch input’ en un ‘fichero
cola’. Una sesión de batch input es un conjunto de transacciones.
Un diálogo de usuario es simulado en un procedimiento batch input.

Visión general de la técnica de pantalla

En el sistema SAP, los procesamientos de diálogo y en background son controlados por programas de
pantallas.
Un programa de pantalla controla un paso de diálogo.
Los componentes de un paso de diálogo son:
- Un PBO ( Process Before Output), evento que prepara la pantalla para visualizarla.
- La entrada del usuario.
- Un PAI (Process After Input), evento que procesa la entrada del usuario.

Procesamiento Batch Input

Batch input o BDC es un procedimiento automático para transferir datos al sistema SAP sin que exista diálogo.
Un diálogo de usuario es simulado para este procedimiento para que las mismas comprobaciones y
modificaciones sean ejecutadas.
Un componente central de este procedimiento es el ‘ fichero cola’.
Para cargar los datos en las bases de datos SAP, Se debe procesar las sesiones con la función batch input
(System -> Services -> Batch input, Transacción SM35).

An Indra company 3
Programa Batch Input

Los datos son transferidos al ‘fichero cola’ por programas batch input.
Estos programas ejecutan las siguientes funciones:
- Proporcionan áreas de trabajo, estructuradas en forma de tabla interna (tabla BDC), para los datos
que van a ser transferidos.
- Leen los datos.
- Colocan los datos en la tabla BDC.
- Transfieren la tabla BDC llena al ‘fichero cola’.
- La tabla BDC recibe la entrada para las transacciones de transferencia de datos.

‘Fichero cola’ Batch Input

El ‘fichero cola’ recoge las pantallas individuales y las combina en sesiones.

Se deben procesar estas sesiones con la función batch input. Cuando se ejecutan funciones de aplicación en
la interface de diálogo, ésta envía los datos al fichero log. Cuando, seguidamente se ejecuta una modificación,
los datos alcanzan las bases de datos SAP relevantes. La función batch input comienza las funciones de
aplicación especificadas en la sesión relevante (indicadas por sus códigos de transacción).
Los datos de la sesión son ahora copiados a las pantallas pertenecientes a la transacción On-Line
especificada.

Formato de una sesión batch input.

Una sesión batch input consta de una parte de cabecera y una parte de datos. La parte de cabecera es
almacenada en la estructura APQI del Diccionario ABAP/4 y la parte de datos es almacenada en la estructura
APQD.

Creación de una sesión batch input

Toda sesión batch input debe ser abierta y cerrada.

Los datos para las funciones de aplicación (transacciones) son insertados en la sesión batch input.
Un programa batch input puede generar varias sesiones consecutivas de batch input. La generación paralela
no es posible.

Módulos de función para un programa batch input

Existen módulos de función (grupo de función SBDC) disponibles para crear sesiones batch input.

Módulo de función BDC_OPEN_GROUP

Se abre una sesión batch input con el módulo de función BDC_OPEN_GROUP.

Los parámetros que se deben especificar obligatoriamente son los siguientes:
-CLIENT (cliente),
- GROUP (nombre de sesión),
- USER (nombre de usuario).
La especificación de los siguientes parámetros es opcional:

An Indra company 4
 - HOLDDATE (fecha inicial de comienzo de sesión),
- KEEP indica si la sesión debería ser borrada tras su procesamiento,
- KEEP=’ ‘: Borrar sesión (valor por defecto),
- KEEP=’X’: No borrar sesión.
Se reciben varios valores de retorno vía EXCEPCIONES. Se pueden leer con SY-SUBRC.
El usuario siempre debe ser especificado. El tipo de usuario debería ser BDC.
En el procesamiento On-Line, el usuario On-Line (y no el nombre de usuario especificado), es usado para la
comprobación de autorizaciones.

Módulo de función BDC_INSERT

Se usa el módulo de función BDC_INSERT para insertar los datos para una transacción en una sesión.
Para transferir los datos, se requiere una tabla interna (tabla BDC).
Se debe especificar los siguientes parámetros:
- TCODE (código de transacción),
- DYNPROTAB (tabla BDC).

Tabla BDC

La tabla BDC contiene los datos para una transacción.

Los contenidos de la tabla BDC son luego pasados al ‘fichero cola’.
Una línea de la tabla incluye la siguiente información:
Nombre de programa, número de pantalla, identificador de comienzo, nombre de campo, valor de
campo.
El identificador de comienzo ‘X’ está siempre al principio de una nueva pantalla. Los valores de entrada son
ahora introducidos para cada campo en la tabla para esta pantalla.
Por razones de claridad, una línea de la tabla debería sólo incluir el nombre del programa, el número de la
pantalla, y el identificador de comienzo, o el nombre del campo y su valor. En principio, sin embargo, toda la
información puede ser incluida en una línea.

Definiendo la tabla BDC

Se declara la tabla BDC como una tabla interna con la estructura ‘BDCDATA’ del Diccionario ABAP/4.
El campo FVAL de la tabla BDC distingue entre mayúsculas y minúsculas, pero los campos PROGRAM y
FNAM no.

Llenado de la tabla BDC

La tabla BDC es llenada línea a línea. Al igual que con las tablas internas, esto se hace con las sentencias
MOVE y APPEND.
Los campos de la cabecera de la tabla deberían ser reseteados a su valor inicial con CLEAR.

Módulo de función BDC_CLOSE_GROUP

Se cierra una sesión batch input con el módulo de función BDC_CLOSE_GROUP.

An Indra company 5
Se reciben los distintos valores de retorno vía EXCEPCIONES. Se puede usar SY-SUBRC para evaluar el
código de retorno de la excepción.

Ejemplo: Modificar datos clientes

La función de aplicación ‘Modificar datos cliente’ (Transacción TFBA) muestra la creación de un programa
BDC.
Aquí, la dirección de un cliente puede ser modificada.
Antes de escribir un programa BDC para una función de aplicación, se debe conocer dicha función de
aplicación (para que el programa BDC pueda simularla).

Preparativos para un programa BDC

Primero ejecutas (paso a paso), la función de aplicación a simular.

Toma nota de:
- El nombre del programa y el número de pantalla, para cada pantalla.
- El nombre de cada campo que vayas a llenar.
- El número de cada tecla de función presionada.
- La secuencia de pantallas del programa.
Para conseguir esto, usas la función Sistema -> Status y la función de ayuda ‘Datos Técnicos’.
Preparaciones para el programa BDC – Screen Painter

En el Screen Painter (elegimos Herramientas -> Workbench ABAP/4 -> Screen Painter, o llamamos a la
transacción SE51), podemos obtener una lista completa de campos para una pantalla particular. Esta es una
alternativa a la función de ayuda On-Line.

Estructura de la tabla BDC

Antes de escribir el programa batch input, se tiene que ejecutar la transacción y anotar los números de
pantalla, la secuencia de pantallas y los nombres de los campos de las pantallas que se van a referenciar
posteriormente en el programa. Se introducen estos datos en la tabla BDC.
El nombre del campo para el código OK es el mismo para todas las pantallas: BDC_OKCODE. El valor para
el código OK consta de una barra ‘/’ y el número de la tecla de función (p.e. ‘/11’).

Sección de declaración

En la sección de declaración del programa BDC, definimos la tabla BDC y una estructura para introducir los
datos.

Introduciendo datos y creando sesiones

Necesitamos los módulos de función para abrir y cerrar sesiones.

Para insertar los datos en la sesión, llenamos la tabla BDC en una subrutina y llamamos al módulo de función
BDC_INSERT.
Llenamos la tabla BDC y llamamos a la subrutina en un LOOP para leer los datos con READ DATASET.

An Indra company 6
Funcionalidad de la transacción SM35

Podemos procesar sesiones con la función Batch input (elegimos Sistema -> Servicios -> Batch Input, o
llamamos a la transacción SM35). La información que se proporciona en el Status es la secuencia de
pantallas, los contenidos de la pantalla, el usuario que está realizando el proceso, el modo de proceso,
servidor, así como el usuario usado para el chequeo de autorizaciones.
La función Modo Experto desactiva los mensajes de error 344 ‘Los datos Batch Input no existen para esta
pantalla’ por proceso de sesión interactivo. Esta opción es de particular interés si queremos irnos a otro
proceso de transacción, que no corresponde a la secuencia de pantallas en el programa batch input.
La función Registro extendido nos permite grabar mensajes W, I y S además de los E. Esta opción está
disponible también si estamos procesando sesiones en fondo.

Copiando datos a las pantallas

Cuando procesamos una sesión con la transacción SM35, el sistema usa el código de transacción para buscar
la pantalla inicial. Sólo los datos relevantes de la sesión se copian a esta pantalla inicial.
La siguiente pantalla se procesa entonces. Primero los datos se leen de la base de datos SAP y entonces los
datos de sesión se copian a la pantalla.
Cuando la transacción ha sido procesada, el sistema busca el siguiente código de transacción en la sesión y
empieza la transacción.

Modos de proceso

En el modo ‘Proceso en primer plano’, se muestran todas las pantallas de una transacción. Se aplican las
autorizaciones del usuario realizando el proceso. Si una sesión termina de forma extraña en el modo de test,
podemos usar la función Reinicio para llegar directamente a la vista general de la sesión (donde podemos
reiniciar el proceso).
En el modo ‘Visualizar sólo errores’, las pantallas se muestran sólo cuando ocurre un error. Una transacción
contiene un error si aparece un error tipo E o tipo A. Se aplican las autorizaciones del usuario realizando el
proceso.
En el modo ‘Proceso en fondo’, la sesión se procesa en fondo. Nuestra pantalla está disponible para introducir
datos tan pronto como la sesión haya sido pasada al sistema de control de fondo. Las autorizaciones del
usuario BDC especificadas en la parte de la cabecera de la sesión se aplican.
Cuando procesamos una sesión, el modo de actualización siempre es síncrono (p.e. la siguiente transacción
se llama sólo cuando la actualización para la transacción precedente ha sido completada).

Proceso Batch Input

En modo de corrección (‘Proceso en fondo’ o ‘Visualizar sólo errores’), podemos controlar el proceso de
nuestra sesión eligiendo Sistema -> Servicios -> Batch input o introduciendo un comando en el campo de
comandos).

Estado de sesión

A una sesión se le asigna un Status durante y después de cada proceso.

Básicamente, el sistema identifica transacciones que no pueden ser procesadas debido a errores. Estas
transacciones permanecen en la sesión (que se convierte en una sesión de error). Podemos entonces
procesar estas sesiones de nuevo y corregir los errores.

An Indra company 7
Creando y procesando sesiones

Cuando creamos programas batch input, debemos tener en cuenta que la creación de sesiones y el proceso
de sesiones tienen lugar en diferentes momentos (t1 y t2). Lo que se procesa en el momento t2 está
planificado ya en el momento t1.
Ejemplo: en el momento t2, el sistema de batch input no puede responder a los mensajes de diálogo (excepto
a través de la entrada de usuario en el modo de corrección).
El sistema de batch input no toma ningún parámetro SPA/GPA en el momento t2.

Resumen de las preparaciones de usuario

Cuando creamos un programa batch input, debemos saber la transacción en la que está basado.
Ejecutamos la transacción y anotamos los números de pantallas, la secuencia de pantallas y los nombres de
los campos de pantalla que se van a referenciar más tarde en el programa.
Introducimos estos datos en la tabla BDC.

2. Características especiales de los Batch Inputs

Ejemplo: Mostrar y cambiar vuelos

La transacción TCF2 es usada para modificar la tabla SFLIGHT añadiendo nuevos datos de vuelos.

Preparativos para un programa BDC – SFLIGHT

Primero ejecutas (paso a paso), la función de aplicación a simular.

Toma nota de:
- El nombre del programa y el número de pantalla, para cada pantalla.
- El nombre de cada campo que vayas a llenar.
- El número de cada tecla de función presionada.
- La secuencia de pantallas del programa.
Para conseguir esto, usas la función Sistema -> Status y la función de ayuda ‘Datos Técnicos’.
La pantalla para los datos de vuelos es un Table Control.

Ejemplo: Estructura de la tabla BDC

Se introduce la información encontrada con la función de ayuda en la tabla BDC.

Para los campos de un Table Control, se debe especificar el número de la línea del Table Control entre
paréntesis, como sufijo del nombre del campo. Las líneas de un LOOP son direccionadas de la misma forma.
También se puede posicionar el cursor. Para ello, se usa el nombre de campo ‘BDC_CURSOR’. Para el valor
del campo, se especifica el nombre del campo sobre el que el cursor va a ser posicionado.
Para el campo de comando, se puede usar el código de función en vez del número de la tecla de función.
Para averiguar el código de función ó la tecla de función, se usa la ayuda On-Line (F1).

An Indra company 8
Creación de Sesiones: Parte de declaración

En la parte de declaración del programa BDC, se define la tabla BDC.

Se introduce el nombre de la sesión en el parámetro NAME.

Creación de Sesiones

Se requieren los módulos de funciones para abrir y cerrar sesiones.

Para insertar los datos en la sesión, se coloca la tabla BDC en una subrutina y se llama al módulo de función
BDC_INSERT.

Campos Especiales

En un programa batch input, se puede direccionar el OK code, los campos del Table Control/Loop y el cursor.
Al llenar la tabla BDC se aplican las siguientes reglas:
El nombre del campo para el OK code es siempre ‘BDC_OKCODE’.
Un campo de un Table Control/Loop debe tener un número válido de línea.
El nombre del campo para el cursor es ‘BDC_CURSOR’.

Fin de transacción en batch input

En el procesamiento batch input, se puede finalizar una transacción de dos formas: a través de una
modificación, o retornando al menú principal del SAP.
Una transacción no soporta batch input si ha comenzado con LEAVE TO TRANSACTION <código de
transacción>, con CALL TRANSACTION <código de transacción> o con ‘/n<código de transacción>’ en el
campo de comando.
La función ‘ Delete mode’ no es soportada en batch input.

Report RSBDCSUB

Se usa el report RSBDCSUB para programar el procesamiento de sesiones.

Procede como sigue:
- Crea una variante,
- Crea un ‘background job‘ para el report RSBDCSUB con la variante que has definido.

Procesamiento de sesiones batch input

Se puede elegir procesar sesiones de forma On-Line o en background.

Comienzo de la sesión On-Line:
Las autorizaciones del usuario hacen que el proceso sea chequeado.
Comienzo de la sesión en background:
Se usan las autorizaciones del usuario batch input.

An Indra company 9
Autorizaciones para el procesamiento batch input

El objeto de autorización S_BDC_MONI es usado para el chequeo de autorizaciones en el procesamiento

batch input.
Se puede usar este objeto de autorización para restringir el procesamiento a sesiones particulares. También
se pueden proteger actividades específicas en el procesamiento batch input.

Aplicaciones específicas de programas batch-input

Visión general

Cuando el procedimiento batch input es usado para importar datos desde un sistema cliente, el programa
batch input generalmente transfiere los datos desde un fichero secuencial.
Se crea el fichero secuencial con un programa de transferencia del cliente. Luego, se usa un programa batch
input (el programa de transferencia de SAP) para transferir los datos desde el fichero secuencial al ‘fichero
cola’ de SAP.
El sistema SAP ofrece programas batch input estándares para muchos casos de transferencia de datos. Esto
significa que no se tiene que escribir un programa batch input propio. Sin embargo, los datos que se
proporcionan deben ajustarse al formato predefinido de SAP.

Fichero secuencial en formato SAP

Los registros de datos de un fichero secuencial deben tener un formato que pueda ser leído por un programa
batch input estándar de SAP.
Las aplicaciones proporcionan descripciones de las estructuras para los programas batch input estándar de
SAP en el Diccionario de ABAP/4.
Las descripciones de las estructuras y la estructura del fichero secuencial dependen de la aplicación. Éstas
están descritas en la documentación de los programas batch input estándar de SAP.
Ejemplo: En Contabilidad Financiera, hay tres tipos diferentes de registros de datos:
Tipo 0: Datos de cabecera de sesión (Por ejemplo: nombre de sesión).
Tipo 1: Datos de cabecera de transacción (Por ejemplo: código de transacción).
Tipo 2: Datos de la tabla SAP (Por ejemplo: nombre de la tabla, nombre del campo, contenidos del campo,...)

Análisis de datos

Al principio de cada transferencia de datos tiene lugar un análisis de datos.

En el análisis de datos, se decide qué datos pueden ser transferidos y cómo.
Procede como sigue:
- Compara los datos antiguos con los campos de los datos del sistema SAP.
- Define qué campos de los datos antiguos pueden ser transferidos directamente al sistema SAP.
- Diseña reglas para llenar los campos de los datos del sistema SAP, donde los datos antiguos no
pueden ser directamente usados.

An Indra company 10
Programa de transferencia

La tarea de un programa de transferencia personalizado es crear registros de datos en formato SAP y

transferirlos a un fichero secuencial. De esta forma, los datos pueden ser leídos por un programa batch input
estándar de SAP.

Importación de estructuras SAP

Se requieren las descripciones de las estructuras SAP en el programa de transferencia. Si se escribe el

programa de transferencia en ABAP/4, se usa la sentencia TABLES para transferir las descripciones de las
estructuras directamente desde el Diccionario de ABAP/4.
El sistema SAP también soporta la creación de programas de transferencia en otros lenguajes de
programación (COBOL, C, PL/1): Se generan las descripciones de las estructuras en los respectivos lenguajes
de programación usando el programa RDDSRCG0 de ABAP/4. Estas descripciones de estructuras están
disponibles en un fichero secuencial y se pueden incluir en el programa de transferencia.

Inicialización y conversión

Para cada campo pasado en la estructura batch input, se deberá tomar una decisión en función de si el valor
del campo es inicial o si el batch input no es necesario para este campo.
Si los datos batch input no son asignados a ningún campo en el sistema SAP, el programa estándar batch
input espera un carácter especial (etiqueta NODATA). El carácter especial por defecto es ‘/’, pero se puede
definir su propio carácter con el campo BGR00-NODATA. Luego, deberás inicializar las estructuras batch
input de SAP con este carácter especial.
Si los campos con las estructuras antiguas son de una longitud o tipo diferente a los campos con las
estructuras SAP, el programa de transferencia debe realizar las conversiones. Los campos con las estructuras
batch input de SAP son siempre tipo C.

Otras tareas de un programa de transferencia

Existen otras tareas que los programas de transferencia del cliente pueden realizar. Ejemplos:
Comprobaciones de los datos del cliente (para ver si los datos deberían ser en realidad transferidos, por
ejemplo). Conversión de datos de acuerdo con reglas definidas. Escritura de los datos incorrectos en una
tabla de error del cliente después del chequeo de datos.

Batch input, CALL TRANSACTION y Direct Input

Como alternativa al batch input, hay programas de aplicaciones específicas que usan la técnica del direct
input. Cuando transfieres grandes volúmenes de datos (más de 10000 transacciones), se puede conseguir
una mejora considerable en la ejecución usando direct input.
Al igual que usando CALL TRANSACTION el direct input conlleva una modificación inmediata de los datos.
Sin embargo, a diferencia del CALL TRANSACTION y del batch input, los datos son importados llamando a
módulos de función que chequean los datos y los transfieren directamente a las tablas. Ya que el direct input
ofrece un mecanismo de reinicio en caso de error, el programa sólo puede correr como ‘background jobs’. Se
controlan y se ejecutan estos jobs con el report RBMVSHOW o con la transacción BMV0.

An Indra company 11
3. Call Transaction. Grabación de Batch Inputs
Vista general

Al contrario que en los batch input, la sentencia CALL TRANSACTION nos permite pasar datos directamente
a las interfaces de diálogo (sin usar un fichero de cola). Para almacenar datos temporalmente, usamos una
tabla interna (una tabla BDC que tiene la misma estructura que la del batch input). Entonces, llamamos a la
transacción deseada en nuestro programa y el sistema copia los datos temporalmente almacenados en la
tabla BDC a las pantallas de la transacción.

La sentencia CALL TRANSACTION

Como en los batch input, podemos elegir un modo de visualización particular para procesar la transacción.
Al contrario que en los batch input, podemos especificar un modo de actualización. En procesos de
actualización asíncronos, la transacción llamada no espera a que la base de datos actualice, sino que pasa
la actualización a la tarea de actualización. En procesos de actualización síncronos, espera hasta que la
actualización se ha completado. Aunque la actualización asíncrona es más lenta, es más segura porque la
transacción llamada puede informar de errores al programa llamado. En batch input, el modo de actualización
es siempre ‘S’ (síncrono).
Los parámetros MODE y UPDATE son opcionales. Por defecto, ambos tienen ‘A’ (asíncrono).
La opción MESSAGES INTO <messtab> nos permite almacenar cualquier mensaje de salida por la
transacción llamada en una tabla interna. La tabla interna <messtab> debe tener la estructura BDCMSGCOLL.

Definir la tabla BDC

Definimos la tabla BDC en la parte de declaraciones del programa.

Llenamos la tabla BDC como en batch input.
Luego, llamamos a la transacción deseada.

Códigos de retorno y campos de sistema

Para encontrar si el proceso de la transacción llamada ha sido satisfactorio o no, podemos leer el valor del
código de retorno. Hay también otros campos de sistema que contienen el número, ID, tipo y variable del
mensaje de diálogo mostrado por la transacción llamada. Podemos usar esta información para visualizar el
texto del mensaje.
Si queremos ver todos los mensajes mostrados por la transacción, debemos usar la opción MESSAGES INTO
<messtab> y entonces evaluar los contenidos de <messtab>.

Mensajes de salida

La sentencia MESSAGE nos permite mostrar un mensaje de diálogo de la transacción llamada a través del
programa llamado.
Sin embargo, el mensaje que informa del éxito o fallo del proceso se muestra automáticamente. Se
recomienda usar la sentencia MESSAGE si ejecutamos el programa en fondo. En este caso, el mensaje se
ve en el registro.

An Indra company 12
Batch Input / CALL TRANSACTION - Resumen

Los Batch Input y la sentencia CALL TRANSACTION son dos opciones diferentes para copiar datos a
pantallas en una transacción de aplicación.
Batch Input CALL
TRANSACTION
Código de retorno No Sí
Registro de errores Sí No
Proceso Después de un tiempo Inmediatamente

4. Manejo de ficheros: Upload, Download y Transfer

Visión general

Los programas de ABAP/4 corren sobre la aplicación servidor y tienen acceso a sus ficheros secuenciales.
También se puede usar un programa de ABAP/4 para procesar ficheros locales (que pertenecen a la
presentación servidor).
Se procesan ficheros secuenciales sobre la aplicación servidor en programas de ABAP/4 con las sentencias
READ DATASET y TRANSFER, las cuales nos permiten copiar datos desde/a un campo cadena.
Se procesan ficheros secuenciales locales sobre la presentación servidor con (UPLOAD y DOWNLOAD)
módulos de función. Éstos copian datos desde/a una tabla interna.

DOWNLOAD y UPLOAD

El módulo de función DOWNLOAD baja el contenido de una tabla interna a un fichero secuencial local.
El módulo de función UPLOAD sube el contenido de un fichero secuencial local a una tabla interna.
Para el fichero local, Se debe especificar el nombre absoluto. El directorio debe ser conocido en la
presentación servidor. La elección de un nombre de fichero adecuado es responsabilidad del cliente.
El sistema requiere el nombre del fichero y el tipo de fichero interactivamente.
Los datos son convertidos de acuerdo con el tipo de fichero.

Módulo de función DOWNLOAD

Para el módulo de función DOWNLOAD, se necesita una tabla interna para transferir los datos. Se define esta
tabla de acuerdo con las estructuras de datos, al principio del programa, y luego se llenan con datos.
Se usa el parámetro MODE para definir el modo de escritura (‘A’ para ampliar un fichero, ‘ ‘ para crear uno
nuevo).
La especificación de valores por defecto para el nombre de fichero, el tipo y la cabecera, para el diálogo de
fichero, es opcional.
Los parámetros IMPORT especifican los valores introducidos realmente por el usuario para el nombre de
fichero, el tipo de fichero, y el número de bytes bajados.
Sólo se especifica un valor para el parámetro de exportación CODEPAGE cuando se realiza un DOWNLOAD
a DOS (el único valor posible es ‘IBM’). En otro caso este parámetro no se usa.
Todos los parámetros de exportación son opcionales.

An Indra company 13
Si se quiere generar un fichero binario, se debe especificar la longitud del fichero. En este caso, la tabla de
transferencia debe constar de una columna de tipo ‘X’.

Formatos

Con UPLOAD y DOWNLOAD, otros formatos disponibles para la conversión aparte de ASC (ASCII) y BIN
(binario) es DAT para Excel. Con DOWNLOAD, WK1 está también disponible para Excel y Lotus.
Para el formato DAT, las columnas de las tablas están separadas por tabuladores, y las líneas, por retornos
de carros.
Para el formato WK1, los datos de una tabla son introducidos en una hoja de cálculo específica de WK1.

Módulo de función UPLOAD

Para el módulo de función UPLOAD, se necesita una tabla interna para transferir los datos. Se define esta
tabla de acuerdo a las estructuras de datos, al principio del programa.
La especificación de valores por defecto para el nombre de fichero, el tipo y la cabecera, para el diálogo de
fichero, es opcional.
Sólo se especifica un valor para el parámetro de exportación CODEPAGE cuando se realiza un DOWNLOAD
a DOS (el único valor posible es ‘IBM’). En otro caso este parámetro no se usa.

Programa ejemplo: DOWNLOAD

Cuando hacemos DOWNLOAD, es suficiente bajar la tabla con los datos para el fichero. Sin embargo, también
se puede especificar valores por defecto para el nombre de fichero, el tipo y la cabecera, para el diálogo de
fichero. Si no se hace ninguna especificación acerca del modo, el fichero es siempre re-creado (Parámetro
MODE= ‘ ‘).

UPLOAD y DOWNLOAD como funciones estándar

Se puede hacer DOWNLOAD desde un listado (eligiendo Sistema -> Listado -> Grabar -> Fichero local) o
desde el editor de ABAP/4 para bajar un listado o un programa de ABAP/4 a un fichero local.
Este proceso soporta varios formatos.
Se puede hacer UPLOAD desde el editor ABAP/4 para subir un programa de ABAP/4 desde un fichero local
al editor ABAP/4.

Fichero secuencial y fichero local

Se puede usar READ DATASET y DOWNLOAD para copiar los contenidos de un fichero secuencial a un
fichero secuencial local vía una tabla interna.
Del mismo modo, se puede usar UPLOAD y TRANSFER para transferir datos desde un fichero secuencial
local a un fichero secuencial.

UPLOAD / DOWNLOAD – Resumen

Los módulos de función UPLOAD y DOWNLOAD constituyen una forma adecuada para procesar ficheros
locales, ya que realizan todas las actividades necesarias de forma automática. El usuario debe proporcionar,
interactivamente, el nombre y el tipo de fichero.
Existen, también, otros módulos de función para procesar ficheros:

An Indra company 14
WS_DOWNLOAD y WS_UPLOAD: Como DOWNLOAD / UPLOAD, excepto que el nombre y el tipo del fichero
no son especificados interactivamente, y las excepciones deben ser manejadas por el programa que llama.
WS_QUERY: Comprueba la existencia y tamaño de un fichero, además de otras variables de entorno.
WS_EXECUTE: Comienza un programa sobre la presentación servidor.

Ficheros secuenciales
Visión general

Se pueden procesar ficheros secuenciales con la sentencia READ DATASET (para operaciones de lectura) y
TRANSFER (para operaciones de escritura).
El fichero secuencial debe ser visible a la aplicación servidor. Los ficheros en la presentación servidor actual
no pueden ser procesados con TRANSFER o READ DATASET.

Importar y exportar datos

Los ficheros secuenciales son una interface entre un sistema cliente y el sistema R/3.
Los ficheros secuenciales son el medio para importar datos desde un sistema cliente al sistema R/3 y para
exportar datos desde el sistema R/3 a un sistema cliente.

Procesamiento de ficheros

Antes de que los registros de datos puedan ser escritos o leídos desde un fichero secuencial, el fichero debe
ser abierto.
Después del procesamiento, el fichero debe ser cerrado.
En el programa, se llama al fichero por su nombre absoluto. El nombre absoluto consta del camino exacto y
del nombre del fichero actual.
El formato de los nombres de los ficheros depende en gran medida del Sistema Operativo.

Abriendo un fichero

Para abrir un fichero, se usa la sentencia OPEN DATASET <nombre fichero>. La variable sy-subrc valdrá 0
si la operación se realizó sin problemas. En otro caso, tomará el valor 8. Los errores son ignorados.
Si no se especifica nada, el fichero es abierto para lectura.
Opciones posibles:
- FOR OUTPUT: Abre el fichero para escritura. Si el fichero ya existe, su contenido es borrado, pero
esto sólo se aplica una vez finalizado el programa. Si la sentencia aparece en el programa, el cursor
simplemente se posiciona al principio del fichero. Se debe especificar CLOSE DATASET para que el
fichero sea borrado. Si el fichero no existe, es generado.
- FOR INPUT: Abre un fichero existente para lectura. Si el fichero ya está abierto, el cursor es
posicionado al principio. No tiene que especificar FOR INPUT explícitamente.
- FOR APPENDING: Abre el fichero para escribir al final del mismo. Si el fichero no existe, es
generado. Si el fichero ya está abierto, el cursor es posicionado al final.

An Indra company 15
Abriendo un fichero (Modo texto y binario)

Se puede abrir un fichero en modo binario o en modo texto.

Opciones posibles:
- IN BINARY MODE: Los datos no son interpretados por las operaciones de lectura y escritura READ
DATASET y TRANSFER. Las áreas de datos especificadas para estas palabras clave son entrada y
salida directamente. No tiene que especificar IN BINARY MODE explícitamente.
- IN TEXT MODE: Si se abre el fichero con esta opción, el sistema asume que el fichero tiene una
estructura de línea. Cada vez que las sentencias READ DATASET y TRANSFER son ejecutadas, una
línea es leída o escrita y los datos son siempre procesados hasta el fin de línea. Si el área de datos
es demasiado grande para la línea leída, el área restante es rellenada con blancos. Si es demasiado
pequeña, el final de la línea se pierde.
Por defecto, el fichero es abierto en modo binario.

Modo binario y modo texto

En modo texto, el carácter fin de línea específico del sistema operativo es establecido después de cada
registro de datos.
Los blancos al final de cada registro de datos no son suprimidos en modo texto.

Abriendo un fichero – AT POSITION

Encontramos las siguientes adiciones para la sentencia OPEN:

- AT POSITION <posición>: Con esta adición, se puede especificar una posición (en bytes) del fichero
desde el principio del fichero. La siguiente operación de lectura o escritura tiene lugar en este punto.
No se puede posicionar el cursor antes del inicio del fichero.
Aunque esta adición puede ser usada junto con la sentencia IN TEXT MODE, esto tiene poco sentido
ya que el formato físico de un fichero de texto depende en gran medida del sistema operativo.
- MESSAGE <field>: Si se produce un error al abrir el fichero, el mensaje del sistema operativo
asociado es almacenado en el campo <field>.

Transferencia de registros de datos

Cada sentencia TRANSFER transfiere un registro de datos a un fichero secuencial.

Después de TRANSFER, se debe colocar el registro de datos en un campo o en una estructura.
Algunas estructuras posibles son campos cadena o áreas de trabajo de tablas.
La ejecución de la sentencia TRANSFER depende del modo:
- Modo Binario: Escribe la longitud del campo o estructura.
- Modo Texto: Escribe una línea.
Si el fichero especificado no está abierto, la sentencia TRANSFER intenta abrirlo FOR OUTPUT (IN BINARY
MODE) o usando las adiciones de la última sentencia OPEN DATASET para este fichero.
Los errores que tienen lugar durante la sentencia TRANSFER provocan la terminación del programa.
El parámetro adicional LENGTH <length> de la sentencia TRANSFER nos permite especificar una longitud
en bytes (con el formato TRANSFER <structure> TO <filename> LENGTH <length>). En este caso, el número
exacto de caracteres especificado en <length> es transferido. Si la estructura es más corta, el registro es
rellenado (con blancos en modo texto y ceros en hexadecimal en modo binario). Si la estructura es más larga,
el registro es truncado.

An Indra company 16
Lectura de registros de datos

Cada sentencia READ DATASET lee un registro desde un fichero secuencial a un campo o a una estructura.
Algunas estructuras posibles son campos cadena o áreas de trabajo de tablas.
La ejecución de la sentencia READ DATASET depende del modo:
- Modo Binario: Lee la longitud de la estructura.
- Modo Texto: Lee una línea.
Si el fichero especificado no está abierto, READ DATASET intenta abrirlo (IN BINARY MODE FOR INPUT o
con las opciones de la última sentencia OPEN DATASET para este fichero).
Si hemos alcanzado el final del fichero, SY-SUBRC vale 4. En otro caso, vale 0. Si el fichero no ha podido ser
abierto, SY-SUBRC vale 8. Los errores provocan la terminación del programa.
READ DATASET, al igual que TRANSFER, no realiza conversiones implícitamente. Los datos son leídos tal
y como fueron escritos.
El parámetro adicional LENGTH <length> de la sentencia READ DATASET nos permite especificar una
longitud en bytes (con el formato READ DATASET <filename> INTO <structure> LENGTH <length>). En este
caso, el número exacto de caracteres especificado en <length> es leído desde el registro de datos a la
estructura. Si la estructura es más corta, el registro es rellenado (con blancos en modo texto y ceros en
hexadecimal en modo binario). Si la estructura es más larga, el registro es truncado.

Cierre y borrado de un fichero secuencial

Usamos la sentencia CLOSE DATASET <filename> para cerrar un fichero secuencial explícitamente.
Al igual que ocurría con OPEN DATASET, los errores son ignorados.
En un programa, todos los ficheros abiertos son implícitamente cerrados cada vez que la pantalla cambia, y
luego son reabiertos exactamente donde estaban, cuando se reanuda el proceso.
Al finalizar un programa, todos los ficheros son cerrados.
Abrir y cerrar ficheros explícitamente mejora la legibilidad. Otra ventaja de usar OPEN DATASET es que se
puede usar la adición MESSAGE para evitar que un programa termine si se produce un error al abrir el fichero
(SY-SUBRC = 8). Además, se debería tener en cuenta, que en los casos en que un fichero es leído, o
generado y leído, varias veces en el mismo report, sólo abrir y cerrar ficheros explícitamente garantiza que el
cursor sea reposicionado al principio del mismo.
Un fichero no es cerrado implícitamente cuando la sentencia READ DATASET alcanza el final del fichero.
Se puede usar la sentencia DELETE DATASET <filename> para borrar un fichero secuencial explícitamente.
Si la operación se realiza sin problemas, SY-SUBRC toma el valor 0.
Se puede mostrar el estado actual del fichero en debugging eligiendo GOTO -> SYSTEM -> SYSTEM AREAS
y luego seleccionando DATASETS.

Ejemplo: Creación de un fichero

Primero se define la estructura que va a ser transferida.

Después, se llena la estructura. En principio, todas las sentencias que realizan una asignación de un valor
pueden ser usadas aquí. (MOVE, COMPUTE, MOVE-CORRESPONDING, MOVE TO y WRITE TO).
Por último, transfieres la estructura con la sentencia TRANSFER.

Ejemplo: Estructuras en el Diccionario ABAP/4

An Indra company 17
También se puede usar estructuras del Diccionario de ABAP/4 para transferir datos. Para hacer esto,
declaramos las estructuras con TABLES.
Luego, en el programa, se puede hacer lo siguiente:
Usar el área de trabajo declarada con TABLES.
Copiar la estructura, para su variable cadena, con INCLUDE STRUCTURE.
Se puede visualizar la estructura del Diccionario de ABAP/4 en el editor de ABAP/4 con el comando
SHOW.

Ejemplo: Lectura de un fichero

Primero se define la estructura a ser leída.

La estructura usada para leer con READ DATASET debe concordar con la estructura usada para escribir con
TRANSFER.
Luego, se leen los registros de datos en su estructura dentro de un LOOP y se procesan.
READ DATASET no requiere una base de datos lógica.

Ejemplo: Ampliación de un fichero

Para añadir registros de datos al final de un fichero, se usa la adición FOR APPENDING de la sentencia
OPEN DATASET.

Ejemplo: Formato variable (Generación)

Se pueden generar ficheros secuenciales con registros de datos de diferentes estructuras.

Una etiqueta debería indicar la estructura del siguiente registro.

Definición de estructuras – Resumen

En un programa de procesamiento de ficheros, primero se definen las estructuras requeridas para los registros
de datos con las sentencias TABLES o DATA. El programa usa estas estructuras como buffers internos para
los registros de datos.
Luego, se abre el fichero secuencial para lectura o escritura con la sentencia OPEN.
Cuando se escribe en el fichero, se transfieren las estructuras llenas al fichero con la sentencia TRANSFER.
Cuando se lee del fichero, se llenan las estructuras con READ DATASET.
Para cerrar el fichero secuencial, se abandona el procesamiento del fichero con la sentencia CLOSE
DATASET.

An Indra company 18
 An Indra company

Persona de contacto
pgarciap@minsait.com

Pedro García Parra

Senior Consultant
Sistemas de Gestión Empresarial

Avda. de la Innovación, Edificio Renta Sevilla 5ª Planta

41020 Sevilla, España
Tel. Directo: (+34) 954369742
Tel. Centralita: (+34) 954998610 Extensión 242742