Scheduler

Le Scheduler est une planification d'exécution récurrente que l'on enregistre dans un Space. En associant un Script à une heure de déclenchement, le serveur exécute ce Script chaque fois que cette heure arrive. Par exemple, pour exécuter une fois par jour un Script qui, dans une boutique de vêtements en ligne, repère les produits dont le stock est à 0 et appelle le guichet de commande du fournisseur, créez un Scheduler qui pointe vers ce Script.

Le Scheduler est une ressource enfant du Space dans CMA, et son chemin repose sur /spaces/{spaceId}/schedulers. Il n'a pas de notion de publication (publish), ni de sys.version. Une fois créé, il entre aussitôt dans la planification, et sa modification ne requiert pas d'en-tête de version. En revanche, deux points le distinguent des autres ressources. Le Script à exécuter ne peut pas être modifié après la création, et pour le créer ou le modifier, le droit d'exécution du Script concerné est requis séparément, en plus du droit de configuration du Space. Le résultat de l'exécution est conservé sous forme de SchedulerLog : une exécution réussie disparaît au bout d'une heure, une exécution en échec au bout de trois jours.

Structure de la ressource

Voici la réponse renvoyée lors de la création d'un Scheduler. sys contient les identifiants et les références ; le corps contient le nom, l'heure de déclenchement et l'état d'activation.

{
  "sys": {
    "id": "7kQm2ZbTn4Rc9WvXpL3dHsY6fJ",
    "type": "Scheduler",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "script": { "sys": { "id": "3trmXRMKq7bd0Prbef1NcZ", "type": "Refer", "targetType": "Script" } },
    "createdBy": { "sys": { "id": "9dLmQ2pVnRb8sTfWcXd3LhJ7gK", "type": "Refer", "targetType": "User" } },
    "createdAt": "2026-08-26T01:20:07.442Z",
    "updatedBy": { "sys": { "id": "9dLmQ2pVnRb8sTfWcXd3LhJ7gK", "type": "Refer", "targetType": "User" } },
    "updatedAt": "2026-08-26T01:20:07.442Z"
  },
  "name": "Commande de stock",
  "cronExpression": "0 0 * * *",
  "activated": true
}

Clés principales :

• sys.id : identifiant unique du Scheduler. Il s'insère dans le {schedulerId} des chemins de consultation unitaire, de modification et de suppression.
• sys.script : le Script que cette planification exécutera. Il se définit uniquement à la création et ne peut plus être modifié ensuite. Pour exécuter un autre Script, créez un nouveau Scheduler.
• name : libellé affiché dans la console. Non utilisé pour l'exécution.
• cronExpression : l'heure de déclenchement. Elle comporte cinq champs (minute, heure, jour, mois, jour de la semaine) et est interprétée en UTC. Voir Définir l'heure de déclenchement ci-dessous.
• activated : l'état d'activation. Si false, l'enregistrement est conservé mais l'exécution seule n'a pas lieu.

Il n'y a pas de sys.version. N'envoyez pas d'en-tête X-Weegloo-Version dans une requête de modification.

Propriétés système (sys)

space, script, createdBy et updatedBy se présentent sous la forme Refer ({ "sys": { "id", "type": "Refer", "targetType" } }).

Propriétés du corps :

Définir l'heure de déclenchement

Écrivez les cinq champs, de gauche à droite, dans l'ordre minute, heure, jour, mois, jour de la semaine. Il n'y a pas de champ pour les secondes.

Vous pouvez utiliser * (tout), , (liste), - (plage) et / (intervalle) ; le jour de la semaine s'écrit avec un chiffre (07, où 0 et 7 correspondent au dimanche) ou avec un nom (SUNSAT).

Toutes les valeurs sont interprétées en UTC. Vous devez calculer et intégrer le décalage avec l'heure locale ; pour une heure liée à une date ou à un jour de la semaine, ce décalage peut faire changer de jour.

Une valeur qui ne se déclenche jamais n'est pas enregistrée. Si l'expression est correcte sur la forme mais désigne un jour qui n'arrive jamais, comme 0 0 30 2 * (30 février), elle est rejetée.

Statut et contraintes

Règles de fonctionnement et de permissions :

• Deux permissions sont requises simultanément. Le rôle (SpaceRole) doit inclure SETTING_SCHEDULER dans ses settings et, indépendamment, vous devez disposer du droit Execute sur le Script ciblé. Cette vérification a lieu non seulement à la création, mais aussi lors de la modification et de la modification partielle. En effet, changer l'heure de déclenchement revient à décider quand ce Script s'exécute, et réactiver une planification désactivée revient à en lancer l'exécution. S'il en manque ne serait-ce qu'une des deux, la requête est refusée.
• L'exécution s'effectue avec les droits de sys.createdBy. Le filtre :self à l'intérieur du Script est lui aussi résolu vers cet utilisateur. Même si l'auteur d'une modification est différent, l'identité qui exécute ne change pas.
• Si l'auteur perd son droit d'exécution, la planification se désactive automatiquement. À la prochaine heure d'exécution, le serveur effectue une vérification, n'exécute pas et fait passer activated à false. Même si le droit est rétabli, la réactivation n'est pas automatique.
• Le nombre est limité. Le nombre de Scheduler qu'une Organization peut détenir dépend du forfait (Free : 1, Basic : 5, Pro : 30, Enterprise : illimité). Au-delà de cette limite, la création est refusée.
• Le quota d'exécutions est partagé avec le Script. Chaque exécution consomme une unité du quota d'exécutions de Script du forfait. Il n'existe pas de limite d'exécution propre au Scheduler. Si ce quota est dépassé et que l'exécution des Script de l'Organization est suspendue, les Scheduler dont l'échéance survient ensuite ne s'exécutent pas et activated passe à false. Dans ce cas, un SchedulerLog est conservé et le motif figure dans son sys.error. Une fois désactivé, ce Scheduler n'est plus replanifié.
• Les exécutions manquées ne sont pas rattrapées. Même si certaines occurrences n'ont pas pu s'exécuter, elles ne sont pas relancées en bloc par la suite ; le cycle reprend à l'heure suivante.
• Un Script en cours d'utilisation ne peut pas être supprimé. Toute tentative de suppression d'un Script référencé par un Scheduler est refusée (voir les Erreurs de Script).
• Il n'y a pas de publication. Sans valeur de statut ni étape de publication, la création place immédiatement la planification en service ; de même, la suppression est immédiate, sans étape préalable.

SchedulerLog

Chaque fois qu'un Scheduler s'exécute, un enregistrement d'exécution est conservé. Il est en lecture seule et ne dispose d'aucun endpoint de création, de modification ou de suppression. Son chemin est /spaces/{spaceId}/schedulers/{schedulerId}/logs.

{
  "sys": {
    "id": "5nRt8YcVm2Qb7WxZpK4dGhJ9sL",
    "type": "SchedulerLog",
    "space": { "sys": { "id": "HnQ32YiH", "type": "Refer", "targetType": "Space" } },
    "requestId": "3trmXRM8dNvQ2LbYpK7fHsJ3gWc4Rt",
    "success": true,
    "createdBy": { "sys": { "id": "7kQm2ZbTn4Rc9WvXpL3dHsY6fJ", "type": "Refer", "targetType": "Scheduler" } },
    "createdAt": "2026-09-03T00:00:02.503Z",
    "updatedBy": { "sys": { "id": "7kQm2ZbTn4Rc9WvXpL3dHsY6fJ", "type": "Refer", "targetType": "Scheduler" } },
    "updatedAt": "2026-09-03T00:00:02.503Z"
  }
}

Toutes les valeurs se trouvent dans sys et il n'y a pas de propriété au niveau du corps. Les clés sans valeur sont absentes de la réponse (dans l'exemple ci-dessus, error n'est pas présent).

Il n'y a pas de champ scheduler. C'est sys.createdBy qui indique quel Scheduler a laissé l'enregistrement, et son targetType vaut "Scheduler". sys.updatedBy désigne le même Scheduler.

Il n'y a pas non plus de startedAt, de endedAt, de result ni de champ de durée. Le temps qu'a pris une occurrence et la valeur renvoyée par le Script se trouvent dans le ScriptLog portant le même requestId (sys.durationMs, sys.value, sys.statusCode). La composition des champs est traitée dans Ressource Script et endpoints.

Une occurrence laisse deux journaux. L'un est ce SchedulerLog minimal, l'autre est le ScriptLog qui porte l'exécution elle-même (le sys.trigger du ScriptLog pointe vers ce Scheduler). Les deux sont reliés par le même requestId.

L'enregistrement est écrit une seule fois, une fois l'exécution terminée, puis n'est plus modifié. Une exécution réussie disparaît au bout d'une heure, une exécution en échec au bout de trois jours. Aucun champ de la réponse ne porte la date d'expiration : le moment venu, l'enregistrement disparaît. Pour conserver une valeur plus longtemps, enregistrez-la sous forme de Content depuis le Script.

Erreurs

Ce sont les codes que l'on rencontre lorsque l'on manipule un Scheduler. Pour les codes communs à toutes les ressources, consultez Erreurs communes.

API

L'URL de référence de tous les endpoints ci-dessous est https://cma.weegloo.com/v1, et un jeton Bearer authentifiant auprès de CMA est requis dans l'en-tête Authorization. Comme le Scheduler n'a pas de sys.version, n'envoyez pas d'en-tête X-Weegloo-Version lors d'une modification.

Documents liés

• Script : la ressource qu'exécute un Scheduler. Traite de la structure de définition et des types de statement.
• Webhook : la ressource qui exécute un Script sur un événement plutôt qu'à une heure donnée.
• SpaceRole : le rôle qui contient la permission de configuration SETTING_SCHEDULER et le droit Execute sur le Script.
• Notions de Scheduler : à quoi sert cette fonctionnalité et comment l'utiliser dans la console.