Tâches planifiées (Scheduler)

Généralités

Ewt intègre un scheduler qui permet d'exécuter des tâches planifiées. Par défaut le moteur va chercher les tâches à exécuter dans la table
ewt_scheduler. Celle-ci doit au minimum avoir les colonnes suivantes (les éventuelles colonnes supplémentaires sont ignorées).

ewt_scheduler
  taskName       VARCHAR(50)
  scriptName     VARCHAR(100)
  scriptParams   CLOB
  taskStart      TIMESTAMP
  taskPeriod     INTEGER
  taskPeriodUnit VARCHAR(10)
  taskActive     INTEGER
  instanceName   VARCHAR(50)

• taskName: Nom de la tâche. Doit être unique sur la table.
• scriptName: Nom du script à lancer
• scriptParams: Paramètres à passer au script. Peut être null ou vide. Si défini, la valeur doit être un arbre JSON.
• taskStart: Date/Heure de la prochaine exécution du script¹.
• taskPeriod: Période entre deux exécutions de la tâche² (voir chapitre "Période" ci-dessous)
• taskPeriodUnit: Unité de la période. Les unités reconnues sont les mêmes que celles utilisées dans les fonctions de calcul de dates/heures (librairie $cal du langage de script), à savoir
  • y ou year
  • m ou month
  • d ou day
  • h ou hour
  • min ou minute
  • sec ou second
  • ms ou millisecond

• taskActive: Valeur 0, 1 ou 2 indiquant si le niveau d'activité de la tâche.

  • Niveau 0 : la tâche est inactive et ne sera pas démarrée par le scheduler
  • Niveau 1 : la tâche est active et sera démarrée par le scheduler
  • Niveau 2 : la tâche est active et en cours d'exécution

  Si la valeur n'est pas spécifiée, elle est considérée comme un 0. - instanceName: Nom de l'instance sur laquelle la tâche doit s'exécuter. Si la valeur est vide, la tâche est lancée sur toutes les instances.

  Le nom d'instance doit être déclaré au niveau de l'application via l'entrée admin.instanceName du fichier de configuration.

Période

La table des tâches est relue toutes les 60 secondes. Cela signifie que les modifications apportées à la table sont prises en considération au plus tard dans la minute suivante.

Attention, il faut bien distinguer la période de lecture de la table scheduler et la période d'exécution d'une tâche. Ces deux périodes ne sont pas liées.

En effet, la période d'exécution des tâches (définie à l'aide de taskPeriod et taskPeriodUnit) peut très bien être inférieure à la période de relecture de la table scheduler. Il est donc parfaitement possible de spécifier une période inférieure à 60 secondes pour une tâche.

En réalité, chaque minute le moteur recherche les tâches qui sont susceptibles de devoir démarrer durant la minute à venir. Il planifie alors l'exécution de ces tâches. Par exemple si une tâche est configurée avec une période de 10 secondes, alors le moteur planifiera automatiquement des exécutions à T+0, T+10, T+20, T+30, T+40 et T+50.

Par contre, les changements apportés sur la table scheduler ne prendront effet qu'à la prochaine lecture de la table, soit après au plus 60 secondes.

Les tâches sont toutes démarrées dans un thread séparé.

Démarrage automatique

Pour que le scheduler d'une application démarre immédiatement après démarrage du serveur d'application, il faut que l'application soit référencée dans la liste des auto-load-applications au niveau du fichier de propriétés d'Ewt. Celui-ci se trouve dans le répertoire de base des applications Ewt (/opt/ewt par défaut).

L'entrée admin.enableScheduler du config permet d'indiquer si une application utilise ou non le scheduler

Notifications

Chevauchement de tâches (task-overlap)

Lorsque le scheduler détecte qu'une tâche doit être démarrée alors que la dernière exécution de cette même tâche n'est pas terminée, le traitement est abandonné et reporté au prochain scan de tâches (soit 1 minute plus tard dans la configuration par défaut).

De plus, le moteur envoie la notification task-overlap. Il est donc possible de spécifier le script de traitement à appeler lorsque cette notification est envoyée. En plus des infos relatives à la notification elle-même, le script en question recevra les paramètres suivants:

• taskName: nom de la tâche
• taskStart: date/heure d'exécution planifiée, c'est-à-dire la date/heure à laquelle la tâche aurait dû démarrer
• taskPeriod: période entre deux exécutions, telle que définie dans la table
• taskPeriodUnit: unité de la période, sous forme de libellé long
• instanceName: nom de l'instance
• scriptName: nom du script qui aurait dû être exécuté
• scriptParams: paramètres du script
• taskStartLast: date/heure à laquelle le moteur a cherché à démarrer la tâche
• taskStartNext: date/heure de prochaine exécution de la tâche

Erreur d'exécution (task-error)

Lorsqu'un script démarré par le scheduler génère une erreur et que celle-ci interrompt le traitement du script, le scheduler déclenche une notification de type task-error.

Cette notification est accompagnée des mêmes paramètres que dans le cas de la notification task-overlap, avec en plus le paramètre suivant:

• errors: Tableau contenant toutes les erreurs déclenchées par la tâche. Les erreurs sont triées par ordre décroissant de déclenchement (la plus récente erreur figure en premier). Chaque erreur est un objet contenant les propriétés suivantes:
• message: Message d'erreur
• stacktrace: Stacktrace complète de l'erreur

---

1. Il n'est en fait pas tout-à-fait exact de parler de date/heure de prochaine exécution. Cette affirmation n'est pas vraie dans le cas où la période d'exécution de la tâche est inférieure à la période de lecture de la table scheduler. La date/heure inscrite dans ce champ est incrémentée de 60 secondes à chaque fois (période de lecture de la table). Elle n'est pas mise à jour à chaque exécution de tâche dans cet intervalle. Le chapitre "Période" ci-dessous revient sur le cas de figure où les tâches doivent s'exécuter à une fréquence plus haute que la minute. ↩

2. Si la période ou son unité ne sont pas définies, le moteur se base sur la période de fonctionnement du scheduler (en principe la minute). Par conséquent la tâche sera démarrée à chaque check du scheduler. ↩