a) El procesamiento en background debería esencialmente separar tareas periódicas y que insumen mucho tiempo de aquellas de interacción de usuarios. 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 . El administrador planifica los jobs de background y monitorea la correcta ejecución de los mismos.
1) Work processes 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. Limita el máximo tiempo de ejecución de un paso de diálogo en un work process de diálogo. 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.
*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.
Un job de background consiste de uno o más pasos (steps).
- Un programa ABAP
- Un comando externo
- Un programa externo
Los jobs de background pueden ser planificados con diferentes prioridades:
- Clase A (Prioridad alta)
- Clase B (Prioridad media)
- Clase C (Prioridad normal)
Esta preferencia solamente aplica si múltiples jobs con la misma prioridad solicitan el procesamiento en background al mismo tiempo, por ejemplo, porque se planificaron para que se ejecuten a la misma hora. 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.
Un paso dentro de un job puede ejecutar una de estas tres acciones:
- Un programa ABAP pude planificarse como un paso de un job. Si el programa ABAP tiene una o más pantallas de selección, tendremos que crear las entradas previamente en una variante. Los valores almacenados en la variante son luego utilizados durante la ejecución del programa. Si un programa ABAP tiene una pantalla de salida como resultado, esto es dirigido a una lista de spool. Debemos especificar una impresora para la creación de la lista de spool, aunque no necesariamente tenga que ser impreso en un dispositivo de salida como resultado del procesamiento en background.
- Un comando externo es un llamado a un script predefinido, un comando, o un programa a nivel del sistema operativo.
Podemos usar también el concepto de autorización de SAP para proteger la ejecución de un comando externo. El concepto de autorización de SAP solamente especifica si un usuario puede llamar un programa externo o no.
- El concepto de autorización de SAP solamente especifica si un usuario puede llamar un programa externo o no. Una asignación más detallada de autorizaciones, por ejemplo a nivel de los nombres de programa, 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.
2) Podemos utilizar la transacción SM36 para definir nuevos jobs. La transacción SM36 al igual que la SM36WIZ son utilizadas para la creación de Jobs tanto standar como propios, permitiendo definir más de un paso de ejecución en cada uno. Definición de uno o más pasos Definición de una condición de inicio La transacción SM37 nos permite monitorear los jobs. Podemos seleccionar los jobs utilizando diversos criterios en la pantalla inicial de esta transacción.
Podemos utilizar la transacción SM36 para definir nuevos jobs. La transacción SM36 al igual que la SM36WIZ son utilizadas para la creación de Jobs tanto standar como propios, permitiendo definir más de un paso de ejecución en cada uno. Definición de uno o más pasos Definición de una condición de inicio La transacción SM37 nos permite monitorear los jobs. Podemos seleccionar los jobs utilizando diversos criterios en la pantalla inicial de esta transacción.
Para el análisis de jobs, una columna que no se visualiza por defecto y es importante, es la columna de servidor de ejecución. Muchas veces algún problema en la ejecución de un job puede estar relacionado al servidor de aplicación donde se ejecuta.
Un job puede tener los siguientes estados:
- Planificado (Scheduled): Los pasos que requieren la creación del job han sido definidos ya, de todas formas la condición de inicio aún necesita ser definida.
- Liberado (Released): Solamente un administrador o un usuario con las autorizaciones necesarias para el procesamiento de background puede liberar un job.
- Listo (Ready): 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 (Active): El job está siendo ejecutado y no puede ser borrado ni modificado. Luego podemos finalizar el job definitivamente o liberarlo nuevamente.
- Finalizado (Finished): todos los pasos del job fueron ejecutados sin problemas.
- Cancelado (Canceled): El job finaliza anormalmente, esto puede suceder de dos maneras:
- 1. El administrador deliberadamente termina el job en la transacción SM37 mediante la selección de Job → Cancel active job.
- 2. Un paso del job terminó con error.
Podemos modificar un job mientras este tenga los estados Planificado o Liberado. Si el job tiene programas ABAP que crean listas de salida, estas se almacenan en las listas de spool. Desde el menú selecciona Job Copy.