Exploitation > Serveur batch > Gestion des tâches 

Cette fonction permet de créer de nouvelles tâches batch, ou de modifier les caractéristiques des tâches existantes.

Pré-requis

SEEREFERTTO Reportez-vous à la documentation de Mise en oeuvre

Gestion de l'écran

Ecran de saisie

Présentation

La gestion des tâches batch se fait sur un seul onglet. Une tâche batch est caractérisée par un code qui permettra de l’appeler, et par un certain nombre de caractéristiques techniques définissant le processus à lancer. Une tâche batch peut être :

  • soit un programme adonix (traitement)
  • soit un état (impression)
  • soit une tâche système défini par un fichier de commande (shellscript sous UNIX™, script Windows™)

Une tâche batch est définie soit par le nom d’une fonction, soit par le nom d’un traitement. Si la tâche est définie comme une fonction, on hérite des conditions de passage de paramètres et d’habilitation (sites autorisés, entre autres). Une tâche de ce type peut être incluse dans un groupe de tâches batch.

La plupart des fonctions batch sont dans ce cas, mais quelques rares fonctions, définies par le nom d’un traitement, ne le sont pas.

La création de nouvelles tâches batch de type Traitementsuppose de créer un traitement normalisé avec l’AGL adonix, ainsi que de décrire la fonction associée.

Un traitement batch peut avoir besoin de paramètres saisis dynamiquement à chaque soumission de tâche dans un écran de dialogue (cet écran pourra aussi être appelé si la tâche est lancée en direct). La normalisation du développement des tâches batch gère l’appel à un écran de saisie des patramètres, et renvoie les valeurs correspondantes pour l’exécution, soit directement (si la tâche est lancée en direct), soit de façon différée.

Fermer

 

Champs

Les champs suivants sont présents dans cet onglet :

Bloc numéro 1

Une tâche "batch" est un programme qui peut être exécuté par le serveur périodiquement ou à la demande d'un utilisateur.

  • Intitulé (champ ZDES)

Intitulé associé au code précédent.

Bloc numéro 2

  • Actif (champ ENAFLG)

Cette case à cocher permet d'activer ou de désactiver la fiche courante sans pour autant perdre son contenu.

Une fiche désactivée ne peut pas être utilisée (par appel de son code) dans d'autres fiches (documents, paramétrages...), ou lors de traitements de masse.

Les habilitations sur une fonction donnée peuvent interdire la création d'une fiche active. Dans ce cas, la case est désactivée par défaut, et est modifiable uniquement par un utilisateur autorisé, ou via un circuit de signature défini par Workflow.

  • Module (champ MODULE)

Module d'appartenance du paramétrage. Ce champ permet de renseigner si l'écran doit être créé dans la base de données du dossier. Il l'est si le module auquel l'écran est rattaché est actif pour le dossier.

Bloc numéro 3

  • Type tâche (champ TYPTAC)

Indique s'il s'agit d'un traitement adonix ou d'un script exécuté sur le système d'exploitation (script DOS, shellscript).

Bloc numéro 4

  • Time-out (minutes) (champ TIMOUT)

Permet de spécifier un temps maximum en minutes pour l'exécution de la tâche. Au bout de ce temps, le serveur tuera la tâche (si 0, il n'y a pas de time-out).

Attention, cette durée est la durée minimale. Le délai réel au bout duquel la tâche sera arrêtée dépend aussi des paramètres généraux du serveur : en effet, le test d’arrêt des tâches est fait à un intervalle régulier de temps qui peut être défini par paramétrage.

  • Retard admissible (minutes) (champ RETARD)

Permet de spécifier le retard admissible pour le démarrage d'une requête. Une requête qui n'a pas été exécuté à la date prévue de démarrage + retard sera marquée 'hors délai'.

La requête peut ne pas démarrer à l'heure pour plusieurs raisons :

  • arrêt du serveur de requêtes.
  • priorité trop faible si plus de tâches en attente que d'exécutions simultanées autorisées par la licence.
  • blocage si elle appartient à un groupe.
  • ...

Un retard nul indique que la tâche n'a pas de contrainte de délai pour son démarrage.

  • Niveau autorisation (champ NIVEAU)

Ce niveau sera comparé au niveau d'accès de chaque utilisateur qui essaiera de déclencher cette tâche. Il y aura refus si le niveau de l'utilisateur est insuffisant.

  • Priorité (champ PRIO)

Cette priorité est un numéro de 0 à 49 qui affecte une priorité système à la tâche. La codification est utilisée par le système d'exploitation quand elle a un sens (Sous UNIX™, cela correspond à la nice value d’un processus : 49 est le moins prioritaire).

  • Service (champ SERVICE)

Ce champ permet de forcer l'utilisation d'un service adonix. S'il n'est pas renseigné, le service par défaut de l'application est utilisé.

Ce code permet d'associer une contrainte horaire d'exécution à la tâche pour limiter ses horaires d’exécution possibles quand elle est soumise directement au serveur batch.

Quand elle est soumise par un groupe de tâches, ce sont uniquement les contraintes horaires attachées au groupe qui s’appliquent.

Il en va de même lorsqu’on passe par un abonnement : les heures d’exécution ne sont alors pas contrôlées vis à vis du code de contrainte de la tâche, mais par le calendrier d’exclusion qui est défini directement sur l’abonnement.

Bloc numéro 5

Lorsqu'une tâche batch correspond à l'exécution d'une fonction, on la définit ici. Ceci permet d'initialiser le contexte et la vérification des droits d'accès.

  • Script (champ TRAIT)

On indique ici le nom du traitement ou du script système, lorsque la tâche n'est pas définie par un code fonction.

  • champ AIDE

 

  • champ PARAM

Lorsqu'une tâche batch est définie par une fonction, et que cette fonction admet un paramètre (code # dans la fonction), on saisit ici la valeur de ce paramètre (l'intitulé défini dans le champ Aide de saisiede la fonction est indiqué devant le champ pour guider l'utilisateur).

Bloc numéro 6

  • Multi-dossier (champ MULTIDOS)

Si cette case est cochée, la tâche peut être lancée sur un autre dossier que le dossier courant. On précisera alors le dossier et le code utilisateur au lancement de la requête. 

  • Mono-utilisateur (champ MONO)

Si ce paramètre est à oui, la tâche ne pourra être exécutée qu'en mono utilisateur : elle ne s'exécutera pas si le passage en mono-utilisateur est impossible.

  • Message - Utilisateur (champ MESSAGE)

En répondant "oui" à cette question, l'utilisateur qui a lancé la tâche sera averti de sa bonne fin ou non.

Bloc numéro 7

Fermer

 

Boutons spécifiques

Messages d'erreur

Il n'y a pas de message d'erreur autre que les messages d'erreur génériques.

Tables mises en oeuvre

SEEREFERTTO Reportez-vous à la documentation de Mise en oeuvre

Annexe technique

Afin d’être conforme aux standards du développement Web, une tâche batch doit répondre aux critères suivants:

  • La fonction qui la définit doit faire référence à une action de type "traitement standard" (GTRAITE) qui ne comporte pas de fenêtre principale.
  • Elle peut comporter ou non une boîte de dialogue initiale.
  • L'action "OUVRE_BATCH" doit comporter les ouvertures de tables nécessaires aux étiquettes de contrôles de ladite boîte de dialogue.

L’ancienne méthodologie d’écriture de tâches batch décrite dans la version 120 reste valable, mais elle conduit à l’écriture de traitements qui ne fonctionneraient qu’en mode client-serveur. Elle est donc fortement déconseillée.