Reportez-vous à la documentation de Mise en oeuvre
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 :
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é associé au code précédent. |
Bloc numéro 2
| 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 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
| 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
| 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. |
| 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 :
Un retard nul indique que la tâche n'a pas de contrainte de délai pour son démarrage. |
| 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. |
| 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). |
| 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. |
| 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. |
|   |
| 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
| 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. |
| 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. |
| 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
Afin d’être conforme aux standards du développement Web, une tâche batch doit répondre aux critères suivants:
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.