✒️SAP BASIS Los jobs de background

Unidad 7. Lección 5. Jobs de Background.

1. Fundamentos.

Los work process de dialogo deberían estar disponibles para responder a las solicitudes de los usuarios rápidamente. Los recursos de diálogo deberian 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 limita el máximo tiempo de ejecución de un paso de dialogo en un work process de dialogo.

Tx 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.

Esto deberia asegurar que los procesos de dialogo no sean bloqueados por programas que requieren demasiado tiempo de ejecución, interfiriendo la operación online. Luego de que el máximo tiempo se ha superado, el programa es terminado.

Nota: la forma en que trabaja el parametro rdisp/max_wprun_time, se describe en la nota de SAP 25528.

Podemos utilizar porocesos de background para tareas que consuman mucho tiempo. Tambien se conocen como procesos de batch. Normalmente los procesos de background no se utilizan solamente para ejecuciones largas, sino que tambien para tareas repetitivas. Ejemplos osn los backups diarios de la base de datos o los cierres de mes financieros y contables.

Un job de background consiste de uno o mas pasos (steps). Un paso puede ser:

• Un programa ABAP
• Un comando externo
• Un programa externo

Cada job se preocesa sin interrupción por un unico 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)

Si un job es planificado para ser ejecutado en un servidor particular o un grupo de servidores, este tendrá preferencia con respecto a otros jobs de la misma clase. Esta preferencia solamente aplica si multiples jobs con la misma prioridad solicitan el procesamiento en background al mismo tiempo, por ejemplo, orque se planificaron para que se ejecuten a la misma hora.

Nota. Deberiamos 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. Esto debería aplicar para el 90% o mas de todas las tareas de background.

Un paso dentro de un job puede ejecutar una de estas tres acciones:

• Un programa ABAP. Puede planificarse como un paso de un job. Si el programa ABAP tiene una o mas pantallas de seleccion, tendremos que crear las entradas previamente en una variante. Una variante hace posible ejecutar un programa ABAP en background aunque el programa requiera valores de entrada. 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. Podriamos tambien especificar un recipiente de email para esta lista de spool durante la definición del job. Debemos especificar una impresora para la creación de la lista spool, aunque no necesariamente tenga que ser impreso en un dispositivo de salida como resultado del procesamiento en background. Esto por ejemplo podría hacerse posteriormente.
  
• Un comando externo. es un llamado a un script predefinido, un comando, o un programa a nivel del sistema operativo. con comandos externos, podemos enmascarar llamadas al sistema operativo y guardarlos en el sistema SAP bajo un nombre. Podemos usar también el concepto de autorizacon de SAP para proteger la ejecución de un comando externo. Esto permite que podamos determinar que usuarios estan permitidos a ejecutar que comandos externos (sobre que servidores y/o sistemas operativos)
• Un programa externo. Es un comando del sistema operativo. El concepto de autorización de SAP solamente especifica si un usuario puede llamar un programa externo o no. Una asignación mas detallada de autorizaciones, por ejemplo a nivel de los nombres de programa, no es provista con la ejecución de programas externos. Utilicemos comando externos para esto.

Un Job puede ser iniciado:

• Mediante la planificación en una fecha y hora particular (esto incluye el inicio inmediato, si no hay background work processes libres disponibles al momento en que debe iniciar el job segun lo planificado)
• Mediane 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.

TIP. Los modos de operación estan totalmente ligados al balanceo de procesos de dialogo y procesos de background. Los procesos de background se pueden recomendar al usuario cuando vemos que esta utlizando muchos recursos, y revisen los resultados en la Tx SP02. Todo proceso de background genera un resultado que lo manda a una impresora, la tx SP02 es para ver las ordenes de spool propias, de modo que al configurar un job podemos crear una impresora que no exista de modo que nunca imprima nada en papel y los usuarios puedan revisar los resultados en el spool propio. De este modo, no importa cuanto tiempo demoren los reportes, podran ver el resultado al final sin necesidad de modificar el tiempo de corrida de los procesos de dialogo.

2. Planificación y Monitoreo.

Podemos utilizar la Tx SM36 para definir nuevos jobs. Puedes llamar al Asistente de Job, Tx SM36WIZ o desde la Tx SM36 tambien.

Tx SM36 y SM36WIZ. Son utilizadas para la creación de Jobs tanto standar como propios, permitiendo definir mas de un paso de ejecución en cada uno.

Especificaciones de un job:

• Especificaciones generales tales como nombre de job, prioridad del job (por defecto es C) y opcionalmente un servidor de ejecución o grpo.
• Definición de uno o mas pasos.
• Definición de una condición de inicio (de tiempo o controlada por evento.)

El asistente de job nos ayuda en la creación del job guiándonos de manera fácil a través del proceso de creación. El metodo de creación de un job de background (clasico o mediante el asistente) no tiene incidencia en el resultado. Algunas funciones (especificar el usuario SAP en la definición del paso de job, modificación del orden de ejecución de los pasos) no estan disponibles para el asistente de Job.

Tx SM37. nos permite monitorear los jobs. Podemos seleccionar los jobs utiizando diversos criterios en la pantalla inicial de esta transacción. Algunas opciones serian visualizar los jobs que conetiene un paso determinado, que tienen un estudio particular o que reaccionan a un evento definido.

Luego de que seleccionamos Execute, una vista de job aparece que es creada por el Visor de Listas SAP (SAP List Viewer: ALV). seleccionando del menu Settings podemos determinar las columnas que se mostrarán y el orden, entre otras cosas. Podemos también configurar si será el diseño (layout) estándar para el usuario actual o todos los usuarios.

Para el análisis de jobs, una columna que nos se visualiza por defecto y es importante, es la columna de servidor de ejecución. Muchas veces algun problema en la ejecución de un job puede estar relacionado al servidor de aplicación donde se ejecuta.

Podemos también navegar a otras vistas específicas del job desde la visualización de job mostrada en la figura:

Lista de Spool contiene las listas de salida de los programas ABAP (si es que existen)

Detalle del Job contiene, etre otras cosas, información sobre la definición del job, duración del procesamiento del job y la fecha y hora de inicio del job.

Todos los mensajes de salida por un programa de background son almacenados en el log del job. Podemos visualizar el loga para obtener información sobre un programa que finalizó con error o para realizar una investigación detallada sobre la ejecución de un job de background.

Estados de un job:

• Planificado (Scheduled): Los pasos que requieren la creacion del job han sido definidos ya, de todas formas la condición de inicio aun necesita ser definida.
• Liberado (Released). El job ha sido completamente definido, incluyendo la condición de inicio. Un job no puede ser liberado sin una condición de inicio. Solamente un administrador o un usuario con las autorizaciones necesarias para el procesamiento de background puede liberar un job. Esto asegura que usuarios sin autorizacion no puedan ejecutar jobs sin aprobación.
• 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.
• Acitivo (Active). El job esta siendo ejecutado y no puede ser borrado ni modificado. Si un job activo no se ejecuta normalmente, por ejempllo, demora mucho mas del tiempo normal, podemos analizar el job en modo de depuración. Luego podemos finalizar el job definitivamente o liberarlo nuevamente. Para esto, en la Tx SM37, seleccionamos Job -> Capture: active job.
• Finalizado (Finished). Todos los pasos del job fueron ejecutados sin problema.
  
• Cancelado (Canceled). El job finaliza anormalmente, esto puede suceder de dos maneras:

1. El administrador deliberamente termina el job en la Tx SM37 mediante la seleccion de Job->Cancel active Job
2. Un paso del job termino con error.

Podemos modificar un job mietras este tenga los estados de planificado o liberado. Si la ejecución de un job ya ha comenzado, podemos monitorear el procesamiento en el log del job. Si el job tiene programas ABAP que crean listas de salida, estas se almacenan en las listas de spool.

Podemos crear un nuevo job copiando otro existente, desde el menu selecciona Job->Copy

Nota. Para capturar un job de background, debemos iniciar sesión en el servidor SAP donde el job esta corriendo.