Procesamiento en background o de fondo:
El procesamiento en background debería ser para separar tareas periódicas y que insumen mucho tiempo, y se deben programar mediante jobs.
Un requisito importante para conseguir este objetivo es un dimensionamiento apropiado del sistema, ya que demasiados procesos de background podría terminar compitiendo por recursos compartidos con procesos de diálgoo (MP, CPU).
Fundamentos:
Los recursos de diálogo no deberían ser utilizados para ejecuciones prolongadas ya que pueden provocar cuellos de botella en el tiempo de respuesta de diálogo.
El parámetro rdisp/max_wprun_time existe por este motivo, ya que limita el tiempo máximo de ejecución de un paso de diálogo en un work process de diálogo.
Transacción RZ11: La transacción RZ11 es utilizada para visualizar parámetros del sistema y la modificación de los que el sistema permita editar sin reinicio de instancia.
Esto debería asegurar que los procesos de diálogo no sean bloqueados por programas que requieren demasiado tiempo de ejecución, interfiriendo la operación online.
Podemos utilizar los procesos de background (o batch) para tareas que consuman mucho tiempo o para tareas repetitivas.
Un job de background consiste de uno o más pasos (steps), los cuales pueden ser:
- Un programa ABAP
- Un comando externo
- Un programa externo
Cada job se procesa sin interrupción por un único background work process. Los jobs de background pueden ser planificados con diferentes prioridades:
- Clase A (prioridad alta)
- Clase B (prioridad media)
- Clase C (prioridad normal)
Pasos de un job:
Programa ABAP: Si un programa ABAP tiene una o más pantallas de selección, hay que crear las entradas previamente en una variable. Una variante hace posible ejecutar un programa ABAP en background aunque el programa requiere valores de entrada.
Si un programa ABAP tiene una pantalla de salida como resultado, esto es dirigido a una lista de spool (requerirá de una impresora). También se puede especificar un recipiente de email para esta lista de spool durante la definición del job.
Comando externo: Es un script predefinido, un comando, o un programa a nivel del SO. Con un comando externo se puede enmascarar llamadas al SO y guardarlos en el sistema SAP bajo un nombre.
Programa externo: Es un comando del SO. El concepto de autorización de SAP solamente especifica si un usuario puede llamar a un programa externo o no. Una asignación más detallada de autorizaciones no es provista con la ejecución de programas externos.
Un job puede ser iniciado:
- Mediante la planificación en una fecha y hora particular.
- Mediante la ocurrencia de un evento particular definido en el sistema SAP. Esto incluye jobs que se iniciarán luego de la finalización de otros jobs o en los cambios de modo de operación.
Planificación y Monitoreo:
Podemos utilizar la transacción SM36 para definir nuevos jobs, o también llamar al asistente de jobs mediante la transacción SM36WIZ
Las especificaciones que requiere la definición de un job son:
- Especificaciones generales tales como nombre de job, prioridad, etc.
- Definición de uno o más pasos.
- Definición de una condición de inicio.
Transacción SM37: Nos permite monitorear los jobs.
Un job puede tener los siguientes estados:
- Planificado: Los pasos que requieran la creación del job han sido definidos ya, de todas formas la condición de inicio aún no necesita ser definida.
- Liberado: El job ha sido completamente definido, incluyendo la condición de inicio. Solo un admin puede liberar un job.
- Listo: La condición de inicio de un job liberado se ha cumplido. Sin embargo el job se encuentra en la cola de espera por un work process de background libre.
- Activo: El job está siendo ejecutado y no puede ser borrado ni modificado.
- Finalizado: Todos los pasos del job fueron ejecutados sin problemas.
- Cancelado: El job finaliza anormalmente, esto puede deberse a que el administrador terminó un job o un paso del job terminó con error.
Podemos modificar un job mientras este tenga como estado "planificado" o "liberado"