Cinemática de funcionamiento del servidor batch

Presentación

El servidor batch integrado en la aplicación permite el lanzamiento en segundo plano, en el servidor de aplicación:

• las tareas definidas en la tabla correspondiente. Una tarea puede ser un tratamiento estándar de la aplicación (por ejemplo una función cuya acción asociada es de tipo Tratamiento estándar), un scrip (Unix o DOS según el tipo de servidor sobre el que se ha lanzado). Un caso particular de tarea de tipo tratamiento es el lanzamiento de una impresión.
• grupos de tareas. Se trata de varias tareas que se ejecutan de forma secuencial, con la condición de que la tarea anterior acabe sin errores.
• tareas o grupos de forma regular, por medio de abonos.

El arranque del servidor batch puede realizarse directamente desde la aplicación, pero también por una orden directa desde el sistema.

Una tarea de vigilancia permite visualizar las tarea independientemente de de cual sea su estado (en espera, en curso, terminada), modificar los parámetros de lanzamiento si no han arrancado, detenerlos cuando se repiten o visualizar el fichero de traza cuando terminan.

Las entrega de tareas para ejecución para su ejecución a través del servidor de batch puede realizarse de distintos modos:

• directamente por una función de via une fonction de presentación de peticiones.
• creando un abono de tareas activo.
• presentando ficheros de petición en un repertorio dedicado definido en los parámetros del servidor batch. Este tipo de presentación puede ser desactivado globalmente, ou reservado a ciertos usuarios en función del valor del parámetro usuario EXTBATCH vinculado al grupo SUP. En el anexo técnico se indica con detalle el funcionamient de este modo de presentación, que puede así realizarse por medio de un autómata de presentación.

Cinemática detallada

Los esquemas que aparecen a continuación describen la cinemática de funcionamiento del servidor batch. Los rombos simulan test lógicos, en los que las cajas amarillas serían acciones simples y las cajas verdes de las acciones más complejas descritas en otro esquema. El título de cada esquema se da un cuadrado azul. Las cajas rojas simulan una acción terminal.

El servidor es un proceso ADONIX que funciona en un dossier SERVX3 dedicado. Utiliza un conjunto de tablas que se encuentran en el dossier supervisor (y por eso mismo visible para el conjunto de los dossieres). En un momento dado sólo hay proceso de servidor en funcionando. El lanzamiento de la tarea servidor se realiza según el proceso siguiente:

Una vez realizadas las verificaciones y las inicializaciones, los ficheros se colocan en sub directorios del directorio SERVX3:

• se coloca un fichero run en el sub directorio FIL. Este fichero no basta para determinar que el servidor está activo (la tarea podría haberse visto interrumpida de forma brutal). Para verificar que el servidor sigue funcionado, se emplea una técnica de polling. Por otro lado, el hecho de que el fichero run no esté en ese punto, indica que el servidor no funciona.
• se crea un fichero servidor.pid en el directorio tmp que da el número de proceso del servidor.
• La traza del servidor está abierta en el directorio TRA del dossier.

Por otro lado, se verifica el número de peticiones que pueden lanzarse de forma simultanea, por un lado en función de la parametrización y por otra, en función del número de procesos batch autorizados por la licencia. 

El bucle principal de funcionamiento del servidor batch se resume a continuación:

Hay que tener en cuenta que la presencua de un fichero kill en el directorio FIL del dossier SERVX3 provoca que se detengan todas las tareas batch aún en curso, y la presencia de un fichero stop en ese mismo directorio provoca que se pare el servidor. Si se deseo detener el servidor batch deteniendo todas las peticiones, hay que colocar estos dos ficheros en el directorio, empezando por el primero, pero con una diferencia de 2 segundos, con el fin de que el servidor comience por detener las tareas y después se pare.

Las tareas a ejecutar se buscan en orden cronológico creciente: La prioritaria es la más antigua, puesto que el retraso admisible en el lanzamiento (tal y como se define, en horas, en la ficha tarea) no se ha superado. Por esto hay que tener en cuenta las limitaciones horarias dadas definen una hora de lanzamiento del programa para la tarea. Ver el capítulo relativo a la gestión de limitaciones horarias a continuación.

Un retraso en el "tratamiento" permite definir un retraso al final del cual el servidor se activa de forma periódica para tratar las nuevas peticiones recibidas (un retraso de entre 30 segundos y un minuto es en la mayoría de los casos razonable, puesto que cada dos segundos se ejecuta un tratamiento de polling que responde a las solicitudes de los procesos que interrogan el servidor para verificar que aún está en funcionamiento.

El lanzamiento de una petición se realiza tal y como muestra el esquema a continuación:

En el dossier SERVX3, se lanza un proceso ADONIX en el dossier correcto, y se recupera el número de procesos para actualizar los datos correspondientes. Si la petición se ha entregado por fichero, se actualizan los ficheros correspondientes.

En el dossier objetivo, la ejecución del proceso asociado a la petición empiea por abrir la traza, verificar las limitaciones de ejecución (en mono usuario, ¿el usuario tiene todas las habilitaciones?). Después se lanza el tratamiento o el script, y se ejecuta el tratamiento de fin de tarea:

Hay que tener en cuenta que aparte del cierre del fichero de traza y la actualización de los ficheros relativos a los lanzamientos por fichero, el fin de la tarea activa la tarea siguiente de un grupo si no hay error, y pasa a las tareas siguientesne un estado abortado.

Los tratamientos complementarios no descritos a continuación afectan para empezar al polling (se borran un fichero stat en el sub directorio FIL del dossier SERVX3, si éste ha sido creado por una tarea para probar que el servidor está en funcionamiento), y el tratamiento de las peticiones en time-out. Se puede definir un retraso más importante que el del primero para evitar las pruebas de peticiones para verificar si han superado el retraso definido. Como este tratamiento es pesado, se puede proponer un retras del orden de 5 minutos por ejemplo (esto supone que se admite que se supere como máximo en 5 minutos el retraso máximo autorizado para esta tarea):

La actualización de la lista de peticiones puede realizarse por medio del intermediario de ficheros externos (la caja de lectura de los ficheros de entrega de peticiones indicados en el bucle principal del servidor). Este tratamiendo lo describe el esquema que se muestra a continuación:

Por último, el último tratamiento presente en el bucle de ejecución del servidor afecta al tratamiento de los abonos. Esto se resume a continuación:

Gestión de las limitaciones horarias

Es posible definir las limitaciones horarias para el lanzamiento de una tarea o de un grupo de tareas. Estas limitaciones se tienen en cuenta sólo para el lanzamiento de la tarea. Un ejemplo:

• Una tarea que sólo puede ejecutarse entre las 18 y las 22 horas, no podrá lanzarse para su ejecución a las 17:00 (se deberá definir las 18:00 como hora de lanzamiento).
• Por otro lado, si tras la ejecución de otras tareas en retraso, y debido al número limitado de tareas simultaneadas, el servidor batch no está en condiciones de lanzar la tarea más que a las 22:30, se lanzará igualmente, excepto si se ha indicado que un retraso de 4 horas no permite lanzar la tarea en cuestión.
• del mismo modo, es imposible indicar un time-out de ejecución de la tarea: este retraso time-out se refiere a la hora de lanzamiento efectiva de la tarea: permite por tanto limitar su duración efectiva de ejecución.
• de este modo, si la tarea anterior debe terminarse de forma imperativa a las 22:00, y si se sabe que su ejecución no lleva más que una hora, se admitirá un retraso máximo de 3 horas y una hora de time-out. Si esta tarea está programada a las 18:00, se terminará a las 22:00, o se interrumpirá o no se lanzará.

Las limitaciones horarias vienen definidas por una tabla dedicada común a todos los dossieres que permite definir horarios para los días laborables y para los festivos. Se puede asignar un código de limitación horaria a una tarea, pero también a un grupo de tareas. Es importante tener en cuenta las reglas siguientes:

• el control de limitación horaria de una tarea lanzada directamente (por fichero de petición o por sumisión directa) se realiza en función del código de limitación horaria que tiene asociado: la tarea sólo puede lanzarse a la primera hora posible, si el día lo permite.
• si una tarea forma parte de un grupo, no se comprueban sus limitaciones horarias propias, sino sólo las del grupo (el grupo se lanza conforme al código de limitación horaria; las tareas que lo componen se lanzan sucesivamente para realizar la tarea precedente sin ningún control de limitación horaria).
• si una tarea (o un grupo de tareas) se activa a partir de un abono, la única limitación verificada es la limitación vinculada a los calendarios de exclusión. De hecho, en este caso, se da directamente en el abono una hora (o una frecuencia) de ejecución, y no se realiza ningún control de limitaciones horarias a la tarea o el grupo de tareas que figuran sobre el abono.

Tablas utilizadas

Hay que tener en cuenta que las tablas afectadas se situan en el dossier supervisor; este dossier puede tomar distintos nombres según el producto instalado: X3, PAYE, GX por ejemplo. Son comunes a todos los dossieres.