Cinematica di funzionamento del server batch

Presentazione

Il server batch integrato al software permette di lanciare in background sul server applicativo:

• dei job definiti nella tabella corrispondente. Un job può essere un'elaborazione standard del software (cioè, una funzione la cui azione associata è di tipo Programma standard), uno script (Unix o DOS secondo il tipo di server su cui viene lanciato). Un caso particolare di job di tipo programma è il lancio di una stampa.
• dei gruppi di job. Si tratta di più job che si eseguono in sequenza, a condizione che il job precedente sia terminato senza errore.
• dei job o dei gruppi in modo regolare, tramite le schedulazioni.

L'avvio del server batch può essere fatto direttamente dal software, ma anche tramite un comando direttamente dal sistema.

Un job di controllo permette di visualizzare i job a prescindere dal loro stato (in attesa, in corso, terminato), di modificare i parametri di lancio se i job non sono partiti, di arrestarli quando girano o di visualizzare il file di traccia quando sono terminati.

La sottomissione dei job per esecuzione tramite il server batch si può fare in varie maniere:

• direttamente mediante una funzione di sottomissione di richieste.
• creando una schedulazione di job attivi.
• deponendo dei file di richiesta in una directory dedicata definita nei parametri del server batch. Questo tipo di sottomissione può essere disattivato interamente o riservato ad alcuni utenti in funzione del valore del parametro utente EXTBATCH collegato al gruppo SUP. Nell'allegato tecnico si trova il dettaglio del funzionamento di questo modo di sottomissione, che può essere realizzato tramite un robot di gestione.

Cinematica dettagliata

Gli schemi qui sotto descrivono la cinematica di funzionamento del server batch. I rombi corrispondono a test logici, i box gialli a delle semplici azioni, i box verdi a azioni più complesse descritte in un altro schema. Il titolo di ogni schema viene dato in un quadrato blu. Infine, i box rossi corrispondono ad una azione terminale.

Il server è un processo ADONIX che funziona su un dossier SERVX3 dedicato. Utilizza un insieme di tabelle che si trovano nel dossier supervisore (quindi visibili dall'insieme dei dossier). In un determinato momento gira un solo processo server. Il lancio del job server si fa secondo il seguente processo:

Realizzate le verifiche e effettuate le inizializzazioni, i file vengono sistemati nelle sotto-directory e della directory SERVX3:

• un file run è posizionato nella sotto-directory FIL. Questo file non basta per determinare se il server è attivo (il job può essere stato interrotto bruscamente). Viene attuata una tecnica di polling per verificare che il server funzioni sempre. In compenso, il fatto che il file run non sia presente, indica che il server non funziona.
• un file serveur.pid, che dà il numero di processi del server, viene creato nella directory tmp.
• La traccia del server è aperta nella directory TRA del dossier.

Inoltre, si verifica il numero di richieste che possono essere lanciate simultaneamente, da una parte in funzione della parametrizzazione realizzata e d'altra parte in funzione del numero di processi batch autorizzati dalla licenza. 

Il ciclo principale di funzionamento del serveur batch è riassunto qui in basso:

Si osservi che la presenza di un file kill nella directory FIL del dossier SERVX3 provoca l'arresto di tutti i job batch ancora in corso, e la presenza di un file stop in questa stessa directory provoca l'arresto del server. Se si vuole arrestare il server batch arrestando tutte le richieste, occorre posizionare i due file nella directory, iniziando dal primo, ma in modo ravvicinato (nel termine di 2 secondi), in modo che il server inizi ad arrestare i job per poi arrestarsi.

I job da eseguire sono ricercati in un ordine cronologico crescente: il primo è il più vecchio, fino a quando il ritardo ammissibile al lancio (così com'è definito, in ore, nella scheda job), non viene superato. Si noti a questo proposito che i vincoli orari dati definiscono un'ora di lancio programmata per il job. Vedere il capitolo che riguarda la >gestione dei vincoli degli orari qui di seguito.

Si noti che un tempo « di elaborazione » permette di definire un termine di tempo alla fine del quale il server si attiva periodicamente per elaborare le nuove richieste che arrivano (un termine compreso tra i 30 secondi ed 1 minuto è spesso ragionevole, con la consapevolezza che ogni 2 secondi si esegue un'elaborazione di polling che risponde alle sollecitazioni dei processi che interrogano il server per verificare che sia sempre in vita.

Il lancio di una richiesta si effettua come illustrato dallo schema qui in basso:

Sul dossier SERVX3, si lancia un processo ADONIX sul dossier giusto, e si recupera il numero del processo per aggiornare le informazioni corrispondenti. Se la richiesta è stata sottomessa da file, si aggiornao i file corrispondenti.

Sul dossier interessato, l'esecuzione del processo associato alla richiesta inizia con l'aprire la traccia, verificare i vincoli di esecuzione (si è in mono-utenza, l'utente ha sempre il diritto di esecuzione ?). Poi si lancia l'elaborazione o lo script, e si esegue l'elaborazione di fine job:

Si noti che oltre alla chiusura del file di traccia e l'aggiornamento dei file relativi ai lanci da file, la fine del job attiva il job successivo di un gruppo se non ci sono stati errori, e passa i job successivi allo stato fallito in caso contrario.

Le elaborazioni complementari non descritte qui in basso riguardano essenzialmente il polling (si cancella un file stat nella sotto-directory FIL del dossier SERVX3, se è stato creato da un job che desidera testare che il server sia sempre attivo), e l'elaborazione delle richieste in time-out. Si noti che può essere definito un termine superiore al primo termine di elaborazione, per evitare il test delle richieste che verifica se hanno superato il termine impartito. Essendo questa elaborazione pesante, si può proporre, per esempio, un termine nell'ordine di 5 minuti (si suppone che si ammetta un superamento al massimo di 5 minuti oltre il termine massimo autorizzato da questo job):

L'aggiornamento dell'elenco delle richieste può essere fatto utilizzando file esterni (è il box di lettura dei file della sottomissione di richieste indicato nel ciclo principale del serveur). Questa elaborazione è descritta tramite lo schema qui in basso:

Infine, l'ultima elaborazione presente nel ciclo di esecuzione del server riguarda l'elaborazione delle schedulazioni. Viene descritta qui di seguito:

Gestione dei vincoli di orari

E' possibile definire dei vincoli di orari per il lancio di un job o di un gruppo di job. Questi vincoli sono considerati solo per il lancio del job. Si prenda un esempio:

• un job che è possibile eseguire solo dalle 18 alle 22 non potrà essere lanciato alle 17 (si dovrà definire 18 come ora di lancio).
• in compenso, se in seguito all'esecuzione di altri job in ritardo, e a fronte di un numero limitato di job simultanei, il server batch riesce a lanciare il job solo alle 22.30, sarà comunque lanciato, salvo se è stato indicato che un ritardo di 4 ore non permetterebbe più di lanciare il job in questione.
• è possibile anche indicare un time-out di esecuzione del job : questo time-out si riferisce all'ora di lancio effettiva del job : permette quindi di limitare la sua durata effettiva di esecuzione.
• così, se il job precedente deve obbligatoriamente essere terminato alle 22 e se si sa che non deve impiegare più di un'ora di esecuzione, si ammetteranno 3 ore massimo di ritardo e 1 ora di time-out. Se questo job è programmato alle 18, sarà terminato alle 22 o sarà interrotto o non verrà mai lanciato.

I vincoli di orario sono definiti da una tabella dedicata comune a tutti i dossier, che permette di definire degli orari per i giorni lavorativi e degli orari diversi per i giorni festivi. Può essere assegnato un codice di limitazione di orario ad un job, ma anche ad un gruppo di jobs. E' importante notare le seguenti regole:

• il controllo del vincolo di orario di un job lanciato direttamente (tramite file di richiesta o tramite sottomissione diretta) si fa in funzione del codice del vincolo orario che gli è associato: il job può essere lanciato solo alla prima ora possibile se il giorno lo permette.
• se un job fa parte di un gruppo, non si testano più i vincoli di orario individuali, ma solo quelli del gruppo (il gruppo è lanciato conformemente al codice di vincolo di orario trovato, perchè i jobs che lo compongono sono lanciati in seguito al completamento del job precedente senza nessun altro controllo di limitazione di orario).
• se un job (o un gruppo di job) è attivato a partire da una schedulazione, l'unica limitazione verificata è quella collegata ai calendari di esclusione. Infatti, in questo caso, nella schedulazione si dà direttamente un'ora (o una frequenza) di esecuzione e non viene più fatto nessun controllo di vincoli di orario sul job e sul gruppo di job che figurano sulla schedulazione.

Tabelle utilizzate

Si osservi che le tabelle coinvolte sono presenti solo nel dossier supervisore, e questo dossier può assumere dei nomi diversi a seconda del prodotto installato: per esempio X3, ABELX3, GX. Sono quindi comuni a tutti i dossier.