Capítulo 6

Procesamiento en fondo
Conceptos de procesamiento en fondo

Además de la opción de ejecutar programas y transacciones

online, SAP nos da la posibilidad de ejecutar procesos en fondo.
Podemos encontrarnos con otros términos para referirse al mismo
concepto como procesamiento batch o procesamiento en segundo
plano. Simplemente consiste en la ejecución de un proceso sin
interacción con el usuario, es decir, que lanzamos el proceso y el
sapgui nos devuelve el control aunque el programa todavía no ha
acabado de ejecutarse.

Este modo de ejecución de procesos adquiere una importancia

vital cuando tratamos con programas que tardan mucho tiempo en
completarse. Tradicionalmente se considera un buen tiempo de
respuesta para un sistema online el hecho de que no transcurran mas
de dos segundos entre dos acciones del usuario sobre el programa.
Parece poco probable que un usuario este esperando más de cinco
minutos a la respuesta del sistema sin pensar que se ha quedado
bloqueado o que ha fallado el programa, por eso, cuando se prevea
que un proceso va a durar más tiempo debería ser lanzado en fondo.

El lanzamiento de programas en fondo nos permite mejorar el

rendimiento de las transacciones online ya que podemos determinar
que la prioridad de los mismos sea menor ya que el usuario no esta
esperando respuesta inmediata. Lo mas aconsejable es lanzar los
programas en fondo durante la noche, cuando la carga de usuarios
que actúan online es casi nula. Esto ultimo se deberá hacer cuando
los procesos no sean críticos para la obtención de datos en tiempo
real; es la dirección de la empresa la que debe decidir, por ejemplo, si
sus pedidos de compra deben emitirse online o por el contrario
pueden esperar todos a la noche.

Definición de Job

Un Job es conjunto de uno o más programas que se lanzan

consecutivamente en proceso de fondo. Para crear un Job 1
utilizaremos la transacción SM36, a la que se llega a través de
Herramientas-> CCMS-> Job-> definición, y que nos muestra la
pantalla de la figura 6.1
Figura 6.1: Pantalla inicial de definición de Job.

La definición de un Job tiene tres áreas principales:

 información general

 Hora de inicio o evento de ejecución

 Pasos

información general

La información general conforma la base de la definición del

Job. Primeramente debemos darle un nombre que defina el propósito
que tiene. Este nombre no es único, lo que significa que podemos
crear varios Job que se llamen actualizar estadísticas enero. Esto se
produce porque SAP asigna un numero interno a cada Job con el que
diferencia a unos de otros pero para nosotros esa clave es
desconocida y solo podremos referirnos al Job por su nombre.
1SAP utiliza la palabra definir para la acción de crear un Job.

Otro dato de información general es la clase de Job que indica a

SAP la prioridad de ejecución de los procesos que le mandamos y en
función de ello asigna los recursos adecuadamente. Las clases
posibles son:
 A.- La más alta prioridad. Se utiliza para procesos que son
críticos para el funcionamiento del sistema.

B.- Prioridad media. Para procesos periódicos que

aseguran el mantenimiento del sistema.

C.- Prioridad normal. Es la clase normal que se asigna a

los Job de usuario.

El administrador del sistema puede decidir reservar colas de

BTC especıficas para los Job de clase A de manera que nunca tenga
que esperar un proceso de este tipo a que haya recursos libres para
su ejecución.

Por ultimo, tenemos la posibilidad de determinar

específicamente el servidor de aplicaciones que dará curso a nuestra
petición de proceso de fondo. Si no indicamos ninguna instancia por
la que deba ejecutarse entonces el sistema elegirá la primera
disponible.

Hora de inicio o evento

Una vez definidas la características generales del Job tenemos

que indicar cuando debe ejecutarse. Esta indicación puede hacerse
de diversas formas:

 ejecución inmediata. Como su propio nombre indica nos

permite iniciar el Job en el momento de acabar su
definición.

 ejecución por fecha/hora. Deberemos indicarle un día y

una hora en la que queramos que comience el Job.
además podemos marcar el Job como periódico, es decir,
que se repetirá su ejecución cada cierto periodo de
tiempo (cada día, cada 35 minutos. . .). Esta opción es
muy útil para la planificación de Job de mantenimiento o
de recolección de estadísticas, de hecho, al instalar SAP
ya existen una serie de Job de estas características.

 Por Job. Con esta indicación de comienzo podemos

encadenar unos Job con otros, es decir, indicaremos al Job
B que empiece a ejecutarse cuando acabe el Job A.
también podemos especificar que solo comience cuando
la finalización del Job A sea correcta, en caso de que el Job
A haya sido cancelado en mitad de su ejecución el Job B
no se ejecutara.

 Por evento. El Job comenzara cuando se produzca en el

sistema el evento que le indiquemos.
 Un evento es un suceso se produce automáticamente en el
sistema R/3 o que podemos provocar manualmente. Previamente, el
evento debe estar definido en la correspondiente tabla. SAP viene con
una serie de eventos predefinidos como pueden ser, el arranque o
parada de las instancias, el cambio de modo de operación de
nocturno a diurno, etc. El administrador o los desarrolladores pueden
crear otros eventos a conveniencia. Estos pueden dispararse desde
programas en ejecución o podemos lanzarlos manualmente a través
del menú Herramientas-> CCMS->Job-> Lanzar evento.

Pasos

Tras definir como y cuando queremos que se procese el Job, por

ultimo, vamos a decirle que es lo que queremos que haga. Los pasos
de un Job los componen los diferentes programas que queremos que
se ejecuten. Estos programas pueden ser de tres tipos:

 Un programa ABAP estándar o creado por nosotros al que

le indicaremos una variante que contenga los parámetros
de selección de ese programa.

 Un comando externo que se ejecutara en el sistema

operativo donde este el servidor de aplicaciones que
procesa el Job. Este tipo de pasos son dependientes del
sistema operativo, no sirven los mismos comandos para
Unix que para Windows NT. Un ejemplo clásico es la
ordenación de un fichero que ha creado un programa en
un paso previo y que lo necesita otro programa de un
paso posterior.

 Un programa externo que reside en otro sistema distinto

a R/3. Se utiliza cuando tenemos otros sistemas de
gestión distintos a SAP y necesitamos tener interfases
entre ellos.

Los pasos de un Job constituyen un proceso unificado, esto

implica que si el primero de un Job de tres pasos sufre un
cancelación, ninguno de los otros dos pasos restantes se procesara.
Es como si creáramos tres Job encadenados con dependencia de
status con un paso cada uno.

Análisis de Job

Una vez definido completamente el Job podemos analizar y

monitorizar su situación a través de la transacción SM37 o por el
menú Herramientas-> CCMS-> Job-> actualización que nos muestra
la pantalla de la figura 6.2.

Figura 6.2: Pantalla inicial de selección de Job.

Inicialmente tendremos que introducir los criterios de selección

de los Job que queremos analizar porque pueden existir cientos de Job
definidos en un momento dado y nosotros estaremos interesados en
unos pocos. La selección se hace principalmente por nombre del Job,
usuario creador del Job, fecha y hora de comienzo y estado actual en
el que se encuentra. Una vez introducidos los datos y tras pulsar
enter veremos la pantalla de la figura 6.3. En ella vemos un listado de
los Job con diversos datos sobre el. La información que más nos
interesa es el estado en el que se encuentra, en la siguiente sección
hablamos de los diferentes estados de un Job.

Estados de un Job

Una vez definido un Job lo que nos interesa conocer en todo

momento su estado. Los posibles estados en los que se puede
encontrar un Job son los siguientes:

Previsto: Es el estado inicial en el que se encuentra cuando

hemos definido los datos generales y los pasos del Job pero no
hemos dicho nada acerca de cuando debe ejecutarse. La
elección del nombre no es muy acorde a su significado real
porque un Job que esta previsto no se ejecutara nunca a menos
que lo liberemos o modifiquemos la sección de datos de inicio.

Liberado: Cuando definimos completamente un Job con la

transacción SM36 o liberamos un Job que estaba en estado
previsto, entonces pasa a liberado. En este estado permanecerá
 hasta que se cumpla la condición de su fecha de inicio o se
produzca el evento que lo lanza.

Listo: Una vez se han cumplido las condiciones de inicio del Job
pasa al estado listo en el que estará esperando a que haya
recursos libres en el sistema para ejecutarse. Normalmente no
veremos Job en este estado a menos que tengamos el sistema
tan cargado que no haya suficientes colas de batch para
atender a todos los Job que están en estado listo.

Activo: El Job se esta procesando. Podemos ver el Log desde

este momento y ver lo que esta haciendo.

Finalizado: El Job completo su ejecución correctamente.

Cancelado: algún problema hizo que el Job finalizara de

manera incorrecta. Normalmente se producen cancelación por
errores de los programas que componen el Job o problemas de
acceso a la base de datos. En el Log del Job podemos ver el
motivo de la cancelación.

Operaciones sobre Job

El listado de la figura 6.3 es en realidad un completo centro de

control de los procesos en fondo. Si pulsamos en el menú Job
veremos todas las operaciones posibles que podemos hacer para
alterar el estado o composición de un Job.

Figura 6.3: Resumen de Job seleccionados.

 Vamos a describir alguna de las operaciones que podemos
realizar sobre los procesos en fondo:

Verificar status: En alguna ocasiones podemos descubrir que

un Job que creemos que esta activo – porque la transacción
SM37 así nos lo dice – realmente no lo esta. Esto puede
suceder cuando el proceso del sistema operativo
correspondiente a la cola BTC por donde va el Job es cancelado
o el servidor de aplicaciones tiene algún problema de
rendimiento. Con esta opción forzamos a SAP a comprobar que
el estado que nos da para el Job es realmente el que tiene en el
sistema operativo. Cuando comprueba la actividad de un Job
que vemos como activo y no recibe respuesta del sistema
operativo nos dirá que el proceso ya no esta en activo y nos
pregunta si queremos pasarlo a estado cancelado.

Cancelar Job activo: Con esta opción detenemos un Job activo

y lo pasamos directamente a estado cancelado. Si tuviera un
Job encadenado a continuación este no se procesara.

Borrar: Una vez terminado o cancelado un Job podemos

borrarlo manualmente de la lista con este punto del menú.

Liberado->Previsto: Para poder deshacer la liberación de un

Job utilizaremos esta opción. Es muy útil para no tener que
borrar y redefinir un Job que hemos liberado a una hora
concreta y después nos hemos dado cuenta de que no
queremos lanzarlo aun.

Copiar: Si queremos que un Job se ejecute dos o tres veces lo

copiaremos con esta opción y liberaremos cada una de las
copias convenientemente. Si queremos que se ejecute mas
veces deberíamos pensar en la posibilidad de crear un Job
periódico.

Modificar: Siempre y cuando no haya comenzado la ejecución

del Job (mientras este en previsto o liberado) podremos
modificar cualquier dato de la definición del mismo.

Repetir: previsión Esta opción es muy similar a la de copiar

pero además nos pide los datos de inicio del Job, es decir, es
como si copiamos un Job y liberamos inmediatamente la copia.

Traslado a otro servidor: Con esta opción cambiamos el

servidor de destino de un Job que no este activo.

Capturar Job activo: Para comprobar en que punto va la

ejecución del proceso que hemos lanzado podemos capturar un
Job que este activo. Al pulsar este opción se nos abre un modo
nuevo con el depurador (debugger) de ABAP/4 parado en el
punto del programa que estuviera en ese momento. Solo tiene
hacer esto sentido si conocemos y entendemos el código fuente
del programa que se procesa. además hay
que ser cauteloso con esta opción ya que hay determinadas
fases de un programa ABAP en las que el hecho de activarse el
debugger provoca una cancelación con dump debido a un
commit work implícito en la base de datos.

Detalles de Job aquí podemos ver datos internos del Job. El

mas interesante es comprobar en que servidor de aplicaciones
se esta procesando y en numero de cola BTC para poder
monitorizar su estado y/o rendimiento con la transacción SM51.