Procesar juegos de datos de batch input

Llamamos batch input a un tipo de proceso que se lanza en fondo y mediante el cual podemos simular la introducción de datos en una transacción tal y como lo haríamos si la estuviésemos procesando manualmente. La diferencia es que mediante batch input podemos hacer esto proceso de forma repetitiva, cosa que si tuviéramos que llevarlo a cabo manualmente se convertiría en un proceso muy tedioso.

Imagen base de artemtation

Típicamente la programación de un batch input se utiliza para la carga masiva de datos en SAP. Sin embargo, el resultado de un programa de batch input no es la transferencia de datos directamente a SAP, sino la generación de un juego de datos. En este juego se guarda toda la información de la transacción relevante para la carga (pantallas por las que se pasa, datos que se deben poner en cada campo y las teclas que se pulsan).

En este post explico cómo tratar estos juegos de datos generados de modo que la información contenida en éstos se transfiera completamente al sistema.

Procesado on-line

Al crear un juego de datos podemos decidir si lo queremos procesar al momento o sólo crear el “fichero” del juego de datos para su procesamiento posterior. Si decidimos procesarlo inmediatamente, mediante una técnica de programación de batch inputs denominada de CALL TRANSACTION, entonces la transferencia de información será inmediata.

Procesado en fondo

Si, por el contrario, decidimos procesar el juego de datos posteriormente, entonces debemos ir a

Herramientas / Gestión / Monitor / SM35 – Batch input

Esto es lo que vemos en esta transacción:

• Campos para la selección de nuestro juego de datos: podemos filtrar entre los juegos de datos creados por usuario (campo ‘Autor), en un rango de fechas (campos ‘De’ ‘a’) o según el nombre del juego de datos (campo ‘JD’).
  
  

  

  
  
• Del resultado de nuestro filtro vemos todos los juegos de datos que existen en el sistema, con su estado (nuevo, en ejecución, ejecutado correctamente, ejecutado con errores, etc.). Son especialmente interesantes los campos ‘Cantidad total de transacciones’, ‘transacciones procesadas con errores’, ‘transacciones procesadas’ y ‘dynpros’.
• Cantidad total de transacciones: nos informa sobre el total de transacciones que se ejecutarán en nuestro juego de datos. Por ejemplo, si estamos dando de alta el precio de compra de un registro info, entonces nos informa del número de veces que se llamará a la transacción ME11.
• Transacciones procesadas con errores: una vez lanzado el juego de datos, los errores que han generado cada una de las transacciones se acumulan en este campo.
• Transacciones procesadas correctamente: igual que el anterior, pero que han finalizado con éxito.
• Dynpros: nos indica el número de pantallas que se han procesado durante la ejecución del juego de datos.
  
  

  

  
  
• También vemos una serie de pestañas. En cada una de ellas, los juegos de datos se observan según su estado. En la pestaña inicial observamos todos los juegos de datos, en la pestaña ‘nuevo’ sólo aquellos juegos de datos aún no procesados, en ‘erróneos’ aquellos juegos de datos que han dado al menos un error durante su procesamiento, etc.
  
  

  

  
  

¿Y cómo procesamos nuestro juego de datos?

• Marcamos el juego de datos que queremos ejecutar y pulsamos el botón ‘Ejecutar’.
• Automáticamente nos abre tres posibilidades:
• Ejecutar visible: esta opción nos permite observar paso a paso cada una de las pantallas por las que va pasando. Recomendada cuando estamos haciendo pruebas pero totalmente desaconsejada cuando queremos hacer una carga muy grande de información. Si queréis salir de la ejecución en visible podéis pararla escribiendo /bend en la ventana de comandos.
• Visualizar sólo errores: en este caso la transferencia de información se realizará sin que nosotros lo veamos directamente, pero se deterndrá cuando detecte un error en la información contenida en el juego de datos. Nos permite corregir el error directamente cuando sucede. Se puede utilizar con cargas no muy grandes de información, pero no en procesos muy largos ya que nos obliga a estar delante del ordenador.
• Invisible: es la opción que se utiliza comunmente. Nos permite proceso el juego de datos en fondo sin ninguna intervención por nuestra parte. Los resultados y posibles errores ya los veremos en el log de la transacción de batch inputs SM35. Mientras se está realizando la transferencia de información el juego de datos pasa a la pestaña ‘En tratamiento’. Sabremos que el proceso ha finalizado cuando nuestro juego de datos pase a la pestaña  de ‘Procesado’.
  
  

  

Si todo ha resultado correcto el status del juego de datos se marcará como ‘procesado’ y pasará a la pestaña correspondiente. De lo contrario, se marcará como ‘erróneo’ y pasará a la pestaña ‘erróneos’.

¿Cómo ver qué ha ido mal?

• Hacemos doble click sobre el juego de datos.
• Marcamos la pestaña ‘Logs’. Buscamos aquellas líneas resaltadas ya que serán las que contienen el mensaje de error.

Planificación del procesado en fondo

Finalmente, si decidimos procesar el juego de datos con posterioridad al lanzamiento del batch input, pero además deseamos hacerlo en una fecha y hora determinadas, entonces el camino a seguir es diferente. No podemos hacerlo directamente a través de la transacción SM35. En este caso lo haremos mediante el programa RSBDCSUB.

Herramientas / Workbench ABAP / Desarrollo / SE38 - Editor ABAP

• Escribimos el nombre de nuestro programa RSBDCSUB y ejecutamos.
• Escribimos el nombre del juego de datos a planificar y la fecha en que se creó.
• Seleccionamos en el menú Programa / Ejecutar en proceso de fondo.
• Introducimos los parámetros de impresión (si queremos que se imprima el log de resultado).
• Escribimos la fecha y hora en que queremos que se inicie el procesado del juego de datos.

Para ver si hemos creado correctamente el job de fondo:

Sistema / Servicios / Jobs / Resumen jobs

Y, de nuevo, para ver el estado en que se encuentra el proceso del juego de datos:

Herramientas / Gestión / Monitor / SM35 – Batch input