✒️SAP BASIS La administración de jobs

Unidad 7.

1.Planificacion basada en tiempo

Un job puede ser iniciado de forma dependiente de tiempo o de un evento. En el caso de inicio basado en tiempo, podemos seleccionar entre las siguientes opciones:

- El job debe ejecutarse inmediatamente.

- El job debe de ser ejecutado en una fecha y hora particular.

- El job debe ejecutarse en un dia laboral determinado.

- Puedes seleccionar que el job sea recurrente. Esto significa que el job será ejecutado nuevamente despues de un periodo de tiempo definido. Tambien es posible especificar excepciones, tal como posponer al siguiente dia laboral en el caso de un feriado en el calendario.

El job es iniciado en la fecha y hora indicado, en concordancia con la prioridad del job y disponibilidad del work processes de background.

Puedes especificar tambien un periodo de tiempo en el cual el job debe iniciarse. Para esto, especificamos un tiempo luego del cual el job no debe de ejecutarse. Con esta funcion, podemos prevenir la ejecucion de jobs periodicos en un momento no conveniente, entre otras cosas.

Por ejemplo, un job de reorganizacion que deberia solamente ejecutarse durante la noche demora su inici por falta de disponibilidad de work process de background, Con una ventana de tiempo de inicio, podremos evitar que este job se ejecute durante el dia, cuando los usuarios de dialogo estan activos y hay menos recursos disponibles.

Cola fifo (1ero en ingresar 1ero en salir).

2. Balanceo de carga

El parametro de perfil rdisp/bctime especifica el periodo de tiempo en el cual el planificador de jobs dependientes de tiempo esta activo. La ejecucion de jobs con una condicion de inicio inmediata usualmente evita el planificador.

En este cado, el work process de dialogo del usuario que solicita el inicio inmediato es quien planifica el job. Solo si no hay recursos libres, el job es planificado de forma basada en tiempo. La fecha y hora planificada de inicio corresponde al momento en el tiempo en el que deberia haber iniciado.

Los work processes de background pueden ser configurados en cada instancia del sistema SAP utilizando el parametro de perfil rdisp/wp_no_btc.

El # de work processes requeridos en el sistema SAP depende del # de tareas que se realizaran en batch. Si el sistema de transporte es utilizado, debe haber al menos dos work processes de background en el sistema. La combinacion de Job ID y el nombre de job definen el job de manera univoca en el sistema.

En cada instancia SAP en la que existen work processes de background definidos, el planificador de job basado en tiempo corre la cantidad de segundos definidos en rdisp/btctime (el valor por defecto es 60). Este es un programa ABAP (SAPMSSY2) que corre automaticamente en un work process de dialogo.

NOTA: A partir de netweaver 7.0 el planificador de job tambien se inicia luego de que un job ha finalizado. Esto incrementa la tasa de salida para el procesamiento de background considerablemente dependiendo de cuantos jobs hay planificados y recursos disponibles. La nota de SAP 923228, describe como podemos activar esto para sistemas SAP, con una version a partir de Basis de 4.6C.

El planificador de job basado en tiempo verifica la tabla de planificacion de jobs en la bd y busca jobs que esten esperando a ser ejecutados. Estos jobs son transferidos a work processes de background que se encuentren libres en la instancia de SAP, de acuerdo a la prioridad y servidor de ejecucion.

Los jobs que no son asignados a ningun servidor en particular para la ejecucion pueden ser ejecutados con cualquier work process de background libre. Esto significa que la carga de trabajo es automaticamente distribuida entre las instancias SAP.

Si un job es explicitamente asignado a ser ejecutado ya sea en una instancia seleccionada o un grupo de instancias algunas caracteristicas particulares se derivan de esto, tal como asegurarnos que el job se ejecuta en un S.O. particular o en un mismo servidor donde corre la bd. Esto significa de todas maneras, que no contamos con la ventaja de la distribucion de carga automatica del sistema.

3. Jobs estandar

Los jobs estandar son jobs de background que deberian ejecutarse regularmente en un sistema de produccion SAP. Estos jobs principalmente realizan ciertas tareas de limpieza en el sistema, tal como el borrado de spool requests obsoletos o el procesamiento de informacion estadistica y de monitoreo. Presiono F4

En la transaccion de definicion de jobs (SM36), pueden acceder a una seleccion de jobs estandar importantes que puedes planificar, monitorear y editar seleccionando Standar Jobs.

Si queremos planificar todos los jobs estandar, seleccionamos Default Scheduling. Todos los jobs estandar que estan definidos en la tabla REORGJOBS son planificados con una variante y periodo especifico.

Para planificar jobs individuales, selecciona el job y especifica el periodo de ejecucion.

Para definir un job estandar adicional que no esta disponible en la seleccion (tabla REORGJOBS), podems seleccionar Predefine new job.

NOTA: Para informacion sobre job estandar, podemos consultar las notas: 16083 - Standard Jobs, reorganizacion de jobs y 1034532 - Changes for standar jobs.

4. Planificacion basada en eventos

Un evento es una seña para el sistema de procesamiento en background que indica que un estado particular se ha alcanzado en el sistema SAP. El sistema de procesamiento en background recibe eventos y luego inicia todos los jobs que estan vinculados a este evento.

Un job dependiente de evento puede ser planificado con una de las siguientes condiciones de inicio:

- Luego de un evento: El job inicia despues de que un evento definido en el sistema SAP es recibido.

- Modo de operacion: Con esta opcion, puedes vincular un job a la activacion de un modo de operacion cuando planificamos el job.

- Luego de un job: De esta manera, podemos crear cadenas simples de jobs donde la ejecucion del job sucesor puede ser dependiente del estado con el que finalizo el job predecesor.

5. Eventos

Nuevos eventos son definidos por el administrador del sistema en CCMS, transaccion SM62. Cuando se hace esto, el administrador diferencia entre eventos de sistema y eventos de usuario. Los eventos de sistema son predefinidos por SAP y no deberiamos modificar o disparar.

Los eventos pueden ser disparados de dideferentes formas:

- Manualmente en CCMS, para propositos de prueba (transaccion SM64).

- Con un programa ABAP, mediante el uso del modulo de funcion BP_EVENT_RAISE o el metodo RAISE de la clase CL_BATCH_EVENT.

- Fuera del sistema SAP a nivel de S.O. usando el programa sapevt.

Un parametro puede tambien ser transferido cuando un evento se dispara. De esta manera, podremos definir jobs que esperan por la ocurrencia del evento junto con el parametro especifico. Tambien podemos acceder al historial de eventos de la transaccion SM62.

La sintaxis del programa sapevt es:

sapevt

are multiple individual switches based on:

{ | event=} [{-p } | param=

NOTA: la nota SAP 802172, explica los parametros en detalle.

La salida de sapevt se escribe a un archivo de traza dev_evt. Para que pueda reaccionar a eventos externos, el sistema SAP debe estar activo. De otra manera, un evento que se haya disparado por un programa externo se pierde.

Un ejemplo de ejecucion del programa sapevt podria ser:

sapevt event=NUEVO_ARCHIVO_INTERFAZ name=DEV mshost=twdf5000.wdf.sap.corp.

Si el nombre del evento contiene espacios, debemos utilizar comillas (" ") cuando llamamos al programa sapevt. Por ejemplo:

sapevt

"MY EVENT" name=QAS mshost=twdf9999.wdf.sap.com