Scheduler

Ein Scheduler ist eine wiederkehrende Ausführungsplanung, die Sie in einem Space registrieren. Wenn Sie ein Script mit einem Ausführungszeitpunkt verknüpfen, führt der Server dieses Script immer dann aus, wenn dieser Zeitpunkt eintritt. Um beispielsweise in einem Bekleidungs-Onlineshop ein Script, das Produkte mit Bestand 0 sucht und die Bestellstelle des Lieferanten aufruft, einmal täglich auszuführen, legen Sie einen Scheduler an, der auf dieses Script verweist.

Ein Scheduler ist eine in der CMA verwaltete untergeordnete Ressource des Space und basiert auf dem Pfad /spaces/{spaceId}/schedulers. Er kennt kein Konzept der Veröffentlichung (publish) und besitzt auch keine sys.version. Nach der Erstellung geht er sofort in die Planung ein, und für eine Änderung ist kein Versions-Header erforderlich. Dafür unterscheidet er sich in zwei Punkten von anderen Ressourcen. Das auszuführende Script lässt sich nach der Erstellung nicht mehr ändern, und um ihn anzulegen oder zu ändern, ist neben der Einstellungsberechtigung des Space für dieses Script eine gesonderte Ausführungsberechtigung erforderlich. Das Ausführungsergebnis bleibt als SchedulerLog erhalten, wobei erfolgreiche Ausführungen nach 1 Stunde und fehlgeschlagene Ausführungen nach 3 Tagen verschwinden.

Ressourcenstruktur

Im Folgenden sehen Sie die Antwort auf die Erstellung eines Scheduler. In sys stehen Kennung und Verweise, im Body stehen Name, Ausführungszeitpunkt und Eingeschaltet-Status.

{
  "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": "Nachbestellung",
  "cronExpression": "0 0 * * *",
  "activated": true
}

Wichtige Schlüssel:

• sys.id: Eindeutige Kennung des Scheduler. Wird im Pfad für Einzelabfrage, Änderung und Löschung als {schedulerId} eingesetzt.
• sys.script: Das Script, das diese Planung ausführt. Es kann nur bei der Erstellung festgelegt und danach nicht mehr geändert werden. Um ein anderes Script auszuführen, legen Sie einen neuen Scheduler an.
• name: Das in der Konsole sichtbare Label. Wird nicht für die Ausführung verwendet.
• cronExpression: Der Ausführungszeitpunkt. Fünf Felder (Minute, Stunde, Tag, Monat, Wochentag), interpretiert in UTC. Siehe unten Ausführungszeitpunkt angeben.
• activated: Der Eingeschaltet-Status. Bei false bleibt die Speicherung erhalten, nur die Ausführung unterbleibt.

Es gibt keine sys.version. In einer Änderungsanfrage wird der Header X-Weegloo-Version nicht mitgesendet.

Systemeigenschaften (sys)

space, script, createdBy und updatedBy werden in der Refer-Form ({ "sys": { "id", "type": "Refer", "targetType" } }) angegeben.

Body-Eigenschaften:

Ausführungszeitpunkt angeben

Die fünf Felder schreiben Sie von links nach rechts in der Reihenfolge Minute, Stunde, Tag, Monat, Wochentag. Ein Feld für Sekunden gibt es nicht.

Verwendbar sind * (alle), , (Liste), - (Bereich) und / (Intervall); den Wochentag geben Sie als Zahl (07, wobei 0 und 7 Sonntag sind) oder als Name (SUNSAT) an.

Alle Werte werden in UTC interpretiert. Sie müssen den Unterschied zur lokalen Zeit selbst einrechnen, und bei einem Zeitpunkt, der ein Datum oder einen Wochentag angibt, kann sich durch diese Differenz der Tag verschieben, an dem die Ausführung tatsächlich erfolgt.

Ein Wert, der niemals auslöst, wird nicht gespeichert. Wenn er wie 0 0 30 2 * (30. Februar) zwar formal korrekt ist, aber auf einen Tag verweist, der nie eintritt, wird er abgelehnt.

Status und Einschränkungen

Regeln zu Verhalten und Berechtigungen:

• Es sind zwei Berechtigungen zugleich erforderlich. Die settings der Rolle (SpaceRole) müssen SETTING_SCHEDULER enthalten, und davon unabhängig muss die Execute-Berechtigung für das betreffende Script vorliegen. Dies wird nicht nur bei der Erstellung, sondern auch bei der Änderung und Teiländerung geprüft. Denn den Ausführungszeitpunkt zu ändern heißt festzulegen, wann dieses Script ausgeführt wird, und einen ausgeschalteten Scheduler einzuschalten heißt, die Ausführung zu starten. Fehlt auch nur eine der beiden, wird die Anfrage abgelehnt.
• Die Ausführung erfolgt mit den Berechtigungen von sys.createdBy. Auch der Filter :self innerhalb des Script wird gegen diesen Benutzer aufgelöst. Selbst wenn die ändernde Person eine andere ist, ändert sich die ausführende Identität nicht.
• Verliert der Autor die Ausführungsberechtigung, wird der Scheduler automatisch ausgeschaltet. Zum nächsten Ausführungszeitpunkt prüft der Server dies, führt nicht aus und setzt activated auf false. Wird die Berechtigung wiederhergestellt, schaltet er sich nicht automatisch wieder ein.
• Die Anzahl ist begrenzt. Wie viele Scheduler eine einzelne Organization haben kann, ist je nach Tarif festgelegt (Free 1, Basic 5, Pro 30, Enterprise unbegrenzt). Wird dieses Limit überschritten, wird die Erstellung abgelehnt.
• Die Ausführungsanzahl wird mit Script geteilt. Jede Ausführung verbraucht eine der Script-Ausführungen des Tarifs. Es gibt kein eigenes Ausführungslimit nur für Scheduler. Wird dieses Limit überschritten und die Script-Ausführung der Organization ausgesetzt, werden danach fällige Scheduler nicht ausgeführt, und activated wird auf false gesetzt. In diesem Fall bleibt ein SchedulerLog zurück, und in sys.error steht der Grund. Dieser Scheduler wird nach dem Ausschalten nicht erneut eingeplant.
• Verpasste Ausführungen werden nicht nachgeholt. Auch wenn ein Durchlauf nicht ausgeführt werden konnte, wird er nicht später gesammelt nachgeholt; die Ausführung setzt ab dem nächsten Zeitpunkt wieder ein.
• Ein in Verwendung befindliches Script kann nicht gelöscht werden. Der Versuch, ein Script zu löschen, auf das ein Scheduler verweist, wird abgelehnt (siehe Fehler bei Script).
• Es gibt keine Veröffentlichung. Ohne Statuswert und Veröffentlichungsschritt geht er nach der Erstellung sofort in die Planung ein, und auch das Löschen geschieht unmittelbar ohne vorgelagerten Schritt.

SchedulerLog

Jedes Mal, wenn ein Scheduler läuft, bleibt ein Ausführungsprotokoll zurück. Es ist nur lesend und hat keine Endpunkte zum Erstellen, Ändern oder Löschen. Der Pfad ist /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"
  }
}

Alle Werte liegen in sys, und es gibt keine Body-Eigenschaften. Schlüssel ohne Wert entfallen in der Antwort (im Beispiel oben fehlt error).

Es gibt kein Feld scheduler. Welcher Scheduler das Protokoll erzeugt hat, zeigt sys.createdBy, dessen targetType "Scheduler" ist. Auch sys.updatedBy ist derselbe Scheduler.

Auch die Felder startedAt, endedAt und result sowie ein Feld für die Dauer gibt es nicht. Wie lange ein Durchlauf gedauert hat und welchen Wert das Script zurückgegeben hat, steht im ScriptLog mit derselben requestId (sys.durationMs, sys.value, sys.statusCode). Der Feldaufbau wird unter Script-Ressource und Endpunkte behandelt.

Ein Durchlauf hinterlässt zwei Protokolle. Das eine ist dieses schlanke SchedulerLog, das andere ist das ScriptLog, das die Ausführung selbst enthält (sys.trigger des ScriptLog verweist auf diesen Scheduler). Beide sind über dieselbe requestId verknüpft.

Das Protokoll wird nach dem Ende der Ausführung einmal geschrieben und ändert sich nicht mehr. Protokolle erfolgreicher Ausführungen verschwinden nach 1 Stunde, Protokolle fehlgeschlagener Ausführungen nach 3 Tagen. Ein Feld mit dem Ablaufzeitpunkt gibt es in der Antwort nicht; ist die Zeit gekommen, verschwindet das Protokoll. Werte, die länger erhalten bleiben sollen, speichern Sie innerhalb des Script als Content.

Fehler

Dies sind die Codes, die beim Umgang mit einem Scheduler auftreten. Codes, die allen Ressourcen gemeinsam sind, finden Sie unter Gemeinsame Fehler.

API

Die Basis-URL aller Endpunkte unten ist https://cma.weegloo.com/v1, und im Authorization-Header ist ein Bearer-Token zur Authentifizierung an der CMA erforderlich. Da ein Scheduler keine sys.version besitzt, wird bei einer Änderung der Header X-Weegloo-Version nicht mitgesendet.

Verwandte Dokumente

• Script: Die Ressource, die ein Scheduler ausführt. Behandelt die Definitionsstruktur und die Statement-Arten.
• Webhook: Die Ressource, die ein Script nicht nach Zeitpunkt, sondern durch ein Ereignis ausführt.
• SpaceRole: Die Rolle, die die Einstellungsberechtigung SETTING_SCHEDULER und die Execute-Berechtigung für Script enthält.
• Scheduler-Konzept: Wofür die Funktion dient und wie man sie in der Konsole bedient.