BATCH-INPUTS
1.INTRODUCCIÓN 2.FASE DE GENERACIÓN 3.OPERACIONES
4.FASE DE PROCESAMIENTO
1. INTRODUCCIÓN:
• 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 nose genera log, nipueden tratarse errores a posteriori.
• El proceso tiene2 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.
errores (mucho más sencillo con el método batch-input “clásico”).
2. 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 en Sistema – 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”).
• Paraobtener 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 ambosmé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.
• 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_OKCODEen FNAM, y en FVAL el código para pasar a la pantalla siguiente, como ‘EXIT’, ‘/2’ (para F2), ...
• Tras cadaAPPEND 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)’ TOtabla-fnam. Conviente crear una subrutina para rellenar la tabla. Llamada típica:
PERFORM llenardynpro USING ‘SAPM38M’ ‘0100’ ‘X’. • Ejemplode tabla.
PROGRAM DYNPRO DYNBEGIN FNAM FVAL
SAPM38M 0100 X
RS38M-program ZBCA07F1 BDC_OKCODE ‘/2’
. . . . . .
SAPM38M 0200 X
. . . . . .
3. 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 include BDCRECXX hay subrutinas como la OPEN_GROUP ya preparadas que llaman a estas funciones. En el programa nose puede abrir otra sesión si hay alguna ya abierta. Hay que usarlo antes de insertar ningún dato.
◦ 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 de la BDCDATA
EXCEPTIONS internal_error not_open
queue_error tcode_invalid
◦ Cerrar sesión:Una vez completado el lote de batch-input, se cierra la sesión con el módulo de funciónBDC_CLOSE_GROUP, una vez transferidos todos los datos al juego de datos.
CALL FUNCTION ‘BDC_CLOSE_GROUP’ EXCEPTIONS not_open queue_error
◦ CALL TRANSACTION código USING bdc_tabla [ MODEA | E | N] [UPDATES |A|L][MESSAGESINTOtabla_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).
4. FASE DE PROCESAMIENTO:
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 noestá 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.
