✒️ABAP El Batch Input utilizando Call transaction
ABAP El Batch Input utilizando Call transaction
- Un ”batch-input” es un método seguro, fiable y rápido de transferir grandes cantidades de datos a un sistema SAP, para hacer muchas altas, modificaciones o borrados. Se simula un proceso on-line (transacción donde interacciona el usuario), para someter a los datos a todos los chequeos y validaciones que sufrirían si se metieran manualmente, para salvaguardar la integridad de los mismos (cosa que no ocurriría con un MODIFY directo a una tabla del D.D., eso es lo importante de los batch-inputs). Pero en cambio no requieren interacción.
- Hay 2 métodos de batch-input: “clásico” y “call transaction”. En el método “clásico” se genera una “sesión batch-input”. Se tiene un fichero con los datos, y un programa Abap/4 de conversión que crea la sesión (datos, pantallas, transacciones, comandos, .. es un juego de datos), que simulan la existencia de un usuario que introduciría los datos), que se almacena y se puede procesar. Este método es asíncrono: se procesan los datos ahora pero se actualizan más tarde. Permite múltiples transacciones. Se genera un log para cada sesión, pero no se pueden generar en paralelo desde el mismo programa (sólo puede abrirse un juego de datos cuando se cierra el anterior).
- En el método “call transaction” los datos se crean on-line al ejecutar el programa de conversión, en lugar de crear una sesión. Es mucho más rápido, pero poco útil para gran cantidad de datos (se perderían datos si hay errores, pues no se guardan en la sesión batch-input). Se usa para dar de alta rápidamente pocos datos. Es un método síncrono, válido para una transacción, rápido, pero no se genera log, ni pueden tratarse errores a posteriori.
- El proceso tiene 2 fases:
- Fase de Generación: Un programa abap/4 genera un lote batch-input con los datos a cargar o modificar (llamado ‘juego de datos’). La base de datos todavía no se modifica. Subtareas de esta fase: Análisis de los datos a transferir (saber qué datos hay que cargar), generación de estructuras en D.D. para los nuevos datos (opcional), creación de un fichero de texto plano con los datos, desarrollo de un programa batch-input para la lectura, conversión y procesado de los datos. En las primeras tareas colabora el cliente.
- Fase de Procesamiento:El lote de batch-input se procesa, es decir, se ejecuta el batch-input (el juego de datos), haciéndose efectivas las modificaciones en la base de datos. Subtareas: Procesado de los datos con el programa batch-input anterior, lanzamiento del juego de datos (esta tarea no existe con el método “call transaction”), análisis de los resultados y posibles errores (mucho más sencillo con el método batch-input “clásico”).
-
FASE DE GENERACIÓN:
- Es necesario codificar un programa Abap/4 de carga para que use, de forma automática y con los datos que se deseen, la transacción SAP que se necesita utilizar en cada caso para la carga o modificación masiva de los datos. Pero antes hay que asegurarse de que no exista ya en SAP un programa estándar (IBIP) que haga lo mismo, para así usar éste directamente. Se le llama desde la transacción IBIP. Puede generarse un juego de datos real, o un testeo con datos de prueba. Necesita como entrada un fichero de texto con los datos a cargar, con un formato especial dado. Debe indicarse por qué IBIP’s se va pasardo, en orden, y qué transacciones.
- La información que se requiere conocer para escribir este programa es: identificación de la transacción a usar (para conocer su código, pulsar en cualquier dynpro de la misma enSistema – Status – Datos repository – Transacción), nombre del(os) programa(s) que ejecuta(n) la transacción, dynpros (pantallas) que se atraviesan (para conocer su código, pulsar en cada una de ellas en Sistema – Status. También veremos el nombre del module pool), ylos campos que se utilizan (para conocer sus nombres técnicos, situarse sobre ellos y pulsar F1– Datos técnicos, y leer el “nombre de campo para batch-input”).
- Para obtener toda esta información hay que seguir todos los pasos que haría el usuario. Hacer una prueba e ir anotando los nombres de los comandos, dynpros, … que se usan. Esto para cada pantalla a procesar. Lo mismo si aparece una ventana de diálogo (pop-up). El tipo y la longitud de un campo se consigue mirando en la tabla correspondiente, a la que se llega haciendo doble clic sobre dicho campo. Los códigos para pasar de una pantalla a otra pueden ser un ENTER, un botón, … Se ven pulsando F1– Datos técnicos – Código de función. Otra forma de conseguir la información es a través del Screen Painter, viendo la lista de campos de cada dynpro.
- En el programa hay que declarar (para ambos métodos de batch-input) una tabla interna con una estructura especial para ir guardando en ella toda la información anterior, que estructura los datos a transferir. Es como un registro de todas las pantallas y campos por los que va a ir avanzando la simulación de la transacción. Debe tener la misma estructura de la estructura SAP delDiccionario de Datos llamada BDCDATA:
DATA BEGIN OF tabla OCCURS 0.
INCLUDE STRUCTURE BDCDATA.
DATA END OF tabla. - Los campos que componen esta tabla / estructura son 5: PROGRAM (8 caracteres. Nombre del module pool de la transacción), DYNPRO (4 caracteres. Su número),DYNBEGIN(1 carácter. Una 'X' indica nueva pantalla), FNAM(35 caracteres. Nombre del campo de la pantalla), FVAL (80 caracteres. Valor para dicho campo de la pantalla). Hay que guardar una entrada por cada dynpro, rellenando PROGRAM, DYNPRO y DYNBEGIN, y luego usar APPEND. Y por cada campo de pantalla que se use en la transacción hay que guardar otra entrada, rellenando los campos FNAM y FVAL, y luego usar APPEND o COLLECT.
- Relleno de esta tabla: Para indicar nueva pantalla (o la primera), guardar el nombre del programa (en PROGRAM), nº dynpro (en DYNPRO) y ‘X’ en DYNBEGIN (los otros 2 campos en blanco) Y para cada campo de esa pantalla rellenar su nombre técnico (en FNAM) y su valor (en FVAL), que es uno de los datos a transferir al sistema. En la última entrada de por cada pantalla (salvo la última) se guarda el comando BDC_OKCODE en FNAM, y en FVAL el código para pasar a la pantalla siguiente, como ‘EXIT’, ‘/2’ (para F2), ...
- Tras cada APPEND tabla hay que hacer un CLEAR tabla, para no dejar valores basura para la siguiente entrada. Caso especial: campos repetidos varias veces en una dynpro (tienen el mismo nombre). Para especificar qué campo concreto se debe rellenar, indicar entre paréntesis el nº de línea donde está. Ejemplo: MOVE ‘sbook-connid(3)’ TO tabla-fnam. Conviente crear una subrutina para rellenar la tabla.
Llamada típica:PERFORM llenardynpro USING 'SAPM38M' '0100' 'X'.
OPERACIONES:
- Abrir sesión:Para abrir o crear una sesión de batch-input (es decir, crear un juego de datos nuevo, vacío) se usa el módulo de función BDC_OPEN_GROUP. En el includeBDCRECXX hay subrutinas como la OPEN_GROUP ya preparadas que llaman a estas funciones. En el programa no se puede abrir otra sesión si hay alguna ya abierta. Hay que usarlo antes de insertar ningún dato.
CALL FUNCTION 'BDC_OPEN_GROUP' * EXPORTING * CLIENT = "mandante sobre el que se ejecutará el batch-input. * GROUP = "nombre de sesión, con el que se identifica el juego de datos * HOLDDATE = "no se ejecutará la sesión batch-input hasta la fecha indicada, salvo el administrador * KEEP = "si es 'X', la sesión será retenida, (podrá ser borrada por un usuario con permiso) * USER = "usuario propietario de la sesión * EXCEPTIONS * CLIENT_INVALID = 1 "mandante incorrecto * DESTINATION_INVALID = 2 * GROUP_INVALID = 3 * HOLDDATE_INVALID = 4 * INTERNAL_ERROR = 5 * QUEUE_ERROR = 6 "error de bloqueo * RUNNING = 7 . - Insertar datos:El módulo de función BDC_INSERT guarda en el juego de datos el contenido de la tabla interna de estructura de BDCDATA, una vez rellena. Hay que realizar esta operación una vez por cada transacción a almacenar.
CALL FUNCTION 'BDC_INSERT' * EXPORTING * TCODE = "código de la transacción a ejecutar pop_local TABLES dynprotab = "tabla interna con estructura BDCDATA * EXCEPTIONS * INTERNAL_ERROR = 1 * NOT_OPEN = 2 * QUEUE_ERROR = 3 * TCODE_INVALID = 4 .
- Cerrar sesión:Una vez completado el lote de batch-input, se cierra la sesión con el módulo de función BDC_CLOSE_GROUP, una vez transferidos todos los datos al juego de datos.
CALL FUNCTION 'BDC_CLOSE_GROUP' * EXCEPTIONS * NOT_OPEN = 1 * QUEUE_ERROR = 2 * OTHERS = 3 .
- CALL TRANSACTION código USING bdc_tabla [ MODEA | E | N ] [ UPDATES | A | L ][ MESSAGESINTO tabla_mensajes ].
Para el método call transaction se usa esta sentencia Abap/4. Parámetros:
- MODE: Indica el tipo de ejecución: A (en visible. Se ven todas las pantallas por las que se pasa. Útil para testeo), E (visualización sólo errores), N (invisible).
- UPDATE: Tipo de actualización: A (asíncrono), S (síncrono: no continua el proceso hasta que no se actualiza la base de datos), L (local).
- MESSAGES INTO: Consigue que todos los mensajes que aparecerían al hacer la transacción manualmente (pero que no se ven en batch-input) se guarden en la tabla indicada, para luego mostrarlos o procesarlos (para poder conocer qué errores se han producido). Necesita una tabla interna con la estructura de BDCMSGCDL. Campos de esa tabla: MSGTYP (tipo del mensaje), MSGID (clase del mensaje), MSGVi (parámetro & número i), MSGNR (número de mensaje).
FASE DE PROCESAMIENTO:
- La transacción que procesa los lotes de batch-input es la SM35, o bien por menú: Sistema – Servicios – Batch-input – Tratar. Con esta transacción pueden consultarse, eliminarse y procesarse (haciendo doble clic en ella) todas las sesiones batch-input (los juegos de datos, que pueden ser: a procesar, erróneos, procesados, en tratamiento y en background). Otra manera de lanzar sesiones batch-input es ejecutar el report RSBDCSUB. Con él es posible procesar un batch-input justo después de ser generado, llamando a este report con los parámetros adecuados desde el mismo programa abap/4 que ha generado el lote.
- Antes de procesar una sesión de batch-input puede comprobarse si los datos de entrada y la secuencia de pantallas programada es la esperada. Para ello, desde la transacción SM35 elegir la sesión a analizar y Pasar a – Análisis Juego de datos. Con doble clic en cada una de las dynpros pueden visualizarse éstas.
- Log: Cuando el sistema ejecuta un batch-input, se va generando un log con el resultado de cada transacción individual. Se guarda la hora de inicio de la sesión, la hora de inicio de cada transacción, los mensajes que se generan (los mismos que si se hiciera la transacción on-line). Al final se generan unas estadísticas: número de transacciones que componen el lote, nº de ellas procesadas con éxito y nº de ellas erróneas.
- Cancelarejecución: Por el menú Sistema – Servicios – Batch-Input – Cancelar se puede finalizar la ejecución de un batch-input (no hay otra forma). Se continuaría ésta con “Siguiente transacción”.
- Caída de sesión: Si se cae el sistema durante la ejecución de un batch-input, al rearrancarlo aparecerá éste como ‘procesando’, pero no está haciendo nada, aunque tampoco hemos perdido los datos. Hay que liberar la sesión, yendo a la transacción SM35, indicar la sesión en cuestión y elegir Juego de datos – Liberar. Entonces ya pueden ejecutarse las transacciones que resten.
- Tipos de procesamiento de un batch-input:
- Visible: Se procesa cada transacción viendo todas las dynpros por las que se pasa. Hay que pulsar ENTER para pasar de una a otra. Se pueden modificar los valores que automáticamente se van introduciendo en los campos. Se puede saltar alguna transacción que no se desee procesar (poniendo /N en la barra de comandos), o bien para retrasar su ejecución.
- Invisible: El proceso se hace de forma transparente al usuario, en background, sin mostrar ninguna pantalla. Se debe esperar a que acabe la ejecución, o bien cancelar ésta. Para ver el resultado se debe consultar el log (que también se puede ver mientras se está procesando el juego de datos).
- Visualización sólo errores: El batch-input se ejecuta en modo invisible salvo cuando se produzca un error: entonces se detiene el proceso en la dynpro que contiene el campo erróneo, para así poder corregirlo manualmente, o cancelar esa transacción individual. Tras esto, continua el proceso en modo invisible (hasta el siguiente error, o hasta acabar).
Sobre el autor
Publicación académica de Juan Carlos Ayala Chira, en su ámbito de estudios para la Carrera Consultor ABAP.
SAP Master
Juan Carlos Ayala Chira
Profesión: Ingeniero de Sistemas E Informática - Peru - Legajo: KQ70J
✒️Autor de: 97 Publicaciones Académicas
🎓Egresado de los módulos:
Certificación Académica de Juan Ayala
Disponibilidad Laboral: PartTime 
