Que es el procesamiento en background o de fondo?
El procesamiento en background deberia esencialmente separar tareas periódicas y que insumen mucho tiempo de aquellas de interacción de usuarios. Tareas que requieran mucho tiempo y opcuparían un Work Process en dialogo pueden ser secuencialmente procesadas en background sin afectar el performance de dialogo.
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álogo.
Fundamentos:
Las siguientes presuntas responderemos en esta lección:
- Por qué necesitamos procesamiento en background?
- Qué es un job de background?
- Qué podemos realizar en background?
- Qué condiciones de inicio existen?
- Cómo son planificados y monitoreados los jobs?
- Qué estados puede tener un job?
Work process de diálogo deberían estar disponibles para responder a las solicitudes de los usuarios rápidamente. Los recursos de diálogo deberían por lo tanto no 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 justamente. Limita el máximo tiempo de ejecución de un paso de diálogo en un work process de diálogo.
"La transacción RZ11 es utilizada para la visualización de parámetros del sistema y la modificación de los que el sistema permita editar sin reinicio de la instancia."
Podemos utilizar los procesos de background para tareas que consuman mucho tiempo. También se conocen estos como procesos de batch.
Normalmente los procesos de background no se utilizan solamente para ejecuciones largas, sino que también para tareas repetitivas. Ejemplos de estas son los backups diarios de base de datos o los cierres de mes financieros y contables.
Un job de background de uno o más pasos, un paso puede 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.
"Deberíamos asegurarnos que la mayor parte de los jobs de background sean planificados con prioridad normal, clase C, sin especificación de servidor de ejecución.
Estos debería aplicar para el 90% o mas de todas las tareas de background".
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 o jobs con inicio inmediato si existen background work processes libres al momento.
Planificación y Monitoreo
Podemos utilizar la transacción SM36 para definir nuevos jobs, se puede llamar al asistente job en la transacción SM36WIZ o desde la transacción SM36.
"La transacción SM36 al igual que la SM36WIZ son utilizadas para la creación de jobs tanto estandar com propios, permitiendo definir más de un paso de ejecución en cada uno".
"La transacción SM37 nos permite monitorear los jobs."