Batch input

• 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 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 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”).

• Es necesario codificar un programa ABAP 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. Hay que indicar, en orden, por qué pantallas y transacciones se va pasando.
  
• 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), y los 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 del Diccionario de Datos llamada BDCDATA:

  1
  2
  3
  4
  5
  6
  7
  * Forma clásica
  DATA: BEGIN OF tabla OCCURS 0.
          INCLUDE STRUCTURE bdcdata.
  DATA: END OF tabla.
  
  * Forma actual, sin cabecera
  DATA lt_bdcdata TYPE STANDARD TABLE OF bdcdata.

• Los campos que componen esta tabla / estructura son 5: PROGRAM (40 caracteres; 8 en R/3 antiguo. Nombre del module pool de la transacción), DYNPRO (4 caracteres. Su número), DYNBEGIN(1 carácter. Una 'X' indica nueva pantalla), FNAM (132 caracteres. Nombre del campo de la pantalla), FVAL (132 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 cada pantalla, también la última, se guarda el comando BDC_OKCODE en FNAM, y en FVAL el código para pasar a la pantalla siguiente, como ‘/00’ (Intro), ‘/2’ (F2) o ‘=SAVE’ para grabar en la última pantalla.
  

• 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. Conviene crear una subrutina para rellenar la tabla.
  Llamada típica:

  1
  PERFORM llenardynpro USING 'SAPM38M' '0100' 'X'.

• Ejemplo de tabla.

  PROGRAM	DYNPRO	DYNBEGIN	FNAM	FVAL
  SAPM38M	0100	X
  			RS38M-program	ZBCA07F1
  			BDC_OKCODE	'/2'
  			. . .	. . .
  SAPM38M	0200	X
  			. . .	. . .

• 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 no se puede abrir otra sesión si hay alguna ya abierta. Hay que usarlo antes de insertar ningún dato.

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13
  14
  15
  16
  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.

  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
     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.

  1
  2
  3
  4
  5
  6
     CALL FUNCTION 'BDC_CLOSE_GROUP'
  *    EXCEPTIONS
  *      NOT_OPEN          = 1
  *      QUEUE_ERROR       = 2
  *      OTHERS            = 3
               .

• CALL TRANSACTION código USING bdc_tabla [ MODE A | E | N ] [ UPDATE S | A | L ] [ MESSAGES INTO tabla_mensajes ].

Para el método call transaction se usa esta sentencia ABAP. 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 BDCMSGCOLL. Campos de esa tabla: MSGTYP (tipo del mensaje), MSGID (clase del mensaje), MSGVi (parámetro & número i), MSGNR (número de mensaje).