Überblick
Hintergrund-Jobs ermöglichen die automatische Ausführung von Aktionen ohne manuellen Eingriff. Sie laufen im Hintergrund auf dem Server und können durch verschiedene Auslöser gestartet werden:
- Zeitgesteuert (Cron/Intervall): Aktionen werden zu festgelegten Zeitpunkten oder in regelmäßigen Abständen ausgeführt
- Datenänderung: Aktionen reagieren automatisch auf das Anlegen, Ändern oder Löschen von Datensätzen
- Manuell: Administratoren können Jobs jederzeit von Hand aus der Admin-Oberfläche starten
Typische Anwendungsfälle sind automatische Benachrichtigungen, regelmäßige Datenbereinigungen, Report-Generierung, Eskalations-Workflows und die Synchronisation mit externen Systemen.
Job-Typen
Jeder Hintergrund-Job hat einen Job-Typ, der bestimmt, wodurch die Ausführung ausgelöst wird. UDM unterscheidet drei Typen:
Zeitgesteuert (Time)
Zeitgesteuerte Jobs werden nach einem definierten Zeitplan ausgeführt. Der Server prüft alle 60 Sekunden, ob ein Job fällig ist, und startet ihn automatisch. Für die Zeitplanung stehen mehrere Varianten zur Verfügung:
| Planungsart | Beschreibung | Beispiel |
|---|---|---|
| Täglich | Jeden Tag zu einer bestimmten Uhrzeit | Täglich um 07:00 Uhr |
| Wöchentlich | An ausgewählten Wochentagen zu einer Uhrzeit | Montag bis Freitag um 08:00 Uhr |
| Monatlich | An einem bestimmten Tag im Monat zu einer Uhrzeit | Am 1. jedes Monats um 06:00 Uhr |
| Festes Intervall | In regelmäßigen Abständen (Stunden/Minuten) | Alle 4 Stunden |
| Cron-Ausdruck | Volle Flexibilität über einen Standard-Cron-Ausdruck | 0 7 * * 1-5 (Werktags 07:00) |
Ein zeitgesteuerter Job läuft jeden Morgen um 07:00 Uhr. Er ermittelt alle offenen Vorgänge und sendet eine Zusammenfassung als Push-Nachricht an den Teamleiter. So hat das Team täglich einen aktuellen Überblick — ohne manuellen Aufwand.
Datenänderung (DataChange)
Datengesteuerte Jobs reagieren automatisch auf Änderungen an Datensätzen einer bestimmten Entität. Der Trigger wird nach dem erfolgreichen Speichern in der Datenbank ausgewertet.
| Trigger-Typ | Beschreibung |
|---|---|
| Bei Neuanlage (OnInsert) | Wird ausgelöst, wenn ein neuer Datensatz angelegt wird |
| Bei Änderung (OnUpdate) | Wird ausgelöst, wenn ein bestehender Datensatz geändert wird |
| Bei Löschung (OnDelete) | Wird ausgelöst, wenn ein Datensatz gelöscht wird |
| Bei Feldänderung (OnFieldChange) | Wird ausgelöst, wenn ein bestimmtes Feld seinen Wert ändert |
Zusätzlich kann ein Filter (Trigger-Bedingung) hinterlegt werden, der den geänderten Datensatz prüft. Nur wenn der Filter zutrifft, wird der Job tatsächlich ausgeführt.
Ein DataChange-Job überwacht das Feld „Status“ der Entität „Vorgang“. Sobald der Status auf „Abgeschlossen“ wechselt, erstellt der Job automatisch einen Prüf-Task für die Qualitätssicherung.
Manuell
Jeder Hintergrund-Job kann zusätzlich manuell aus der Admin-Oberfläche gestartet werden. Dies ist nützlich für:
- Testen eines neu konfigurierten Jobs
- Einmalige Sonderläufe (z. B. initiale Datenbereinigung)
- Sofortige Ausführung, ohne den nächsten Zeitplan abzuwarten
Schritt für Schritt: Hintergrund-Job erstellen
-
Job-Verwaltung öffnen
Navigieren Sie im Admin-Client zum Bereich „Hintergrund-Jobs“. Hier sehen Sie eine Übersicht aller vorhandenen Jobs mit ihrem Status und der nächsten geplanten Ausführung.
-
Neuen Job anlegen
Klicken Sie auf „Hinzufügen“, um einen neuen Job zu erstellen. Vergeben Sie einen aussagekräftigen Namen (z. B. „Täglicher Statusbericht“) und eine optionale Beschreibung.
-
Job-Typ wählen
Wählen Sie den Typ des Jobs: „Time“ für zeitgesteuerte Ausführung oder „DataChange“ für datengesteuerte Ausführung. Der Typ bestimmt, welche Konfigurationsoptionen im nächsten Schritt angezeigt werden.
-
Entität zuordnen
Wählen Sie die Entität, auf die sich der Job bezieht. Bei DataChange-Jobs ist dies die überwachte Entität. Bei Time-Jobs gibt die Entität den Datenkontext für die Aktion vor (z. B. welche Datensätze verarbeitet werden).
-
Zeitplan oder Trigger konfigurieren
Konfigurieren Sie den Auslöser im Bereich „Zeitplan“ (bei Time-Jobs) oder „Trigger“ (bei DataChange-Jobs). Details zu den Konfigurationsmöglichkeiten finden Sie in den folgenden Abschnitten.
-
Aktion festlegen
Wählen Sie unter „Aktion“, was der Job ausführen soll (z. B. Task erstellen, Nachricht senden, Daten schreiben). Konfigurieren Sie die Aktionsparameter entsprechend.
-
Ausführungseinstellungen prüfen
Legen Sie fest, ob der Job aktiv ist, wie viele Wiederholungsversuche bei Fehler erfolgen sollen und ob ein Timeout gelten soll. Speichern Sie den Job.
Cron-Ausdrücke konfigurieren
Für maximale Flexibilität bei zeitgesteuerten Jobs können Sie einen Cron-Ausdruck verwenden. Ein Cron-Ausdruck besteht aus fünf Feldern, die durch Leerzeichen getrennt sind:
| Feld | Erlaubte Werte | Beschreibung |
|---|---|---|
| Minute | 0–59 | Minute der Stunde |
| Stunde | 0–23 | Stunde des Tages |
| Tag (Monat) | 1–31 | Tag im Monat |
| Monat | 1–12 | Monat im Jahr |
| Wochentag | 0–6 (0=Sonntag) | Tag der Woche |
Sonderzeichen
| Zeichen | Bedeutung | Beispiel |
|---|---|---|
* |
Jeder Wert | * * * * * = jede Minute |
, |
Aufzählung | 0 8,12,18 * * * = um 8, 12 und 18 Uhr |
- |
Bereich | 0 9 * * 1-5 = Montag bis Freitag um 9 Uhr |
/ |
Schrittweite | */15 * * * * = alle 15 Minuten |
Häufig verwendete Cron-Ausdrücke
| Ausdruck | Bedeutung |
|---|---|
0 7 * * * |
Täglich um 07:00 Uhr |
0 7 * * 1-5 |
Werktags (Mo–Fr) um 07:00 Uhr |
30 8 * * 1 |
Jeden Montag um 08:30 Uhr |
0 6 1 * * |
Am 1. jedes Monats um 06:00 Uhr |
0 */4 * * * |
Alle 4 Stunden (00:00, 04:00, 08:00 …) |
0 2 * * 0 |
Jeden Sonntag um 02:00 Uhr |
0 9,13 * * 1-5 |
Werktags um 09:00 und 13:00 Uhr |
*/30 * * * * |
Alle 30 Minuten |
Aktionen im Job — Was soll passieren?
Die Aktion eines Jobs bestimmt, was bei der Ausführung geschieht. Im Hintergrund stehen folgende Aktionstypen zur Verfügung:
| Aktion | Beschreibung | Typischer Einsatz |
|---|---|---|
| Task erstellen | Legt automatisch einen neuen Task (Aufgabe) an | Prüfaufgaben, Erinnerungen, Eskalationen |
| Genehmigung erstellen | Erzeugt eine Genehmigungsanfrage mit Benachrichtigung | Automatische Freigabe-Workflows |
| Nachricht senden | Sendet eine Server-Nachricht und/oder Push-Benachrichtigung | Statusberichte, Warnungen, Erinnerungen |
| Daten schreiben | Erstellt oder aktualisiert Datensätze in der Datenbank | Kaskaden-Erstellung, Audit-Einträge |
| Code ausführen | Führt DynamicCode auf dem Server aus (ohne UI-Zugriff) | Komplexe Logik, Berechnungen, externe APIs |
| Daten kopieren | Kopiert Datensätze über mehrere Tabellen mit ID-Remapping | Vorlagenbasierte Erstellung, Datenreplikation |
| Bericht erstellen | Generiert einen Report und speichert ihn als Anhang | Regelmäßige Berichte, Dokumentenarchivierung |
| External Table Polling | Überwacht eine ReadOnly-Datenquelle und kopiert neue/geänderte Datensätze automatisch in eine UDM-Ziel-Tabelle | SCADA-Alarme, externe Sensordaten, Fremdsystem-Synchronisation |
Aktion „Code ausführen“ im Hintergrund
Wenn Sie die Aktion „Code ausführen“ wählen, wird ein spezieller serverseitiger DynamicCode-Container verwendet. Im Unterschied zu interaktiven Code-Aktionen steht kein UI-Zugriff zur Verfügung (kein FormApi, kein DialogApi). Stattdessen bietet der Hintergrund-Container:
- DataApi: Lesen und Schreiben von Datensätzen
- MessageApi: Nachrichten und Benachrichtigungen versenden
- EntityApi: Zugriff auf Entitäts-Metadaten
Job-Ausführungsprotokoll
Jede Ausführung eines Hintergrund-Jobs wird automatisch protokolliert. Das Ausführungsprotokoll finden Sie im Detail-Bereich des jeweiligen Jobs sowie in der zentralen Monitoring-Ansicht.
| Feld | Beschreibung |
|---|---|
| Gestartet | Zeitpunkt, zu dem die Ausführung begonnen hat |
| Abgeschlossen | Zeitpunkt, zu dem die Ausführung beendet wurde (leer bei laufenden Jobs) |
| Status | Farbcodierter Status: Erfolgreich (grün), Laufend (gelb), Fehlgeschlagen (rot), Abgebrochen (grau) |
| Auslöser | Wie der Job gestartet wurde: „Zeitgesteuert“, „Datenänderung“ oder „Manuell“ |
| Dauer | Laufzeit der Ausführung in Millisekunden |
| Ergebnis | Erfolgsmeldung oder Fehlerinformation mit Details |
| Wiederholungen | Anzahl der bisherigen Wiederholungsversuche (bei Fehler) |
Zentrale Monitoring-Ansicht
Neben dem Protokoll im Job-Detail gibt es eine zentrale Monitoring-Seite, die alle Ausführungen über alle Jobs hinweg anzeigt. Diese Ansicht bietet:
- Chronologische Übersicht aller Ausführungen (neueste zuerst)
- Filter nach Job-Name, Status und Zeitraum
- Farbcodierte Status-Anzeige für schnelle Problemerkennung
- Direkter Zugriff auf Fehlerdetails und Stack-Traces
- Übersicht aktiver Jobs mit nächster geplanter Ausführung
| Gestartet ▼ | Job | Auslöser | Dauer | Status |
|---|---|---|---|---|
| 2026-05-04 07:00:01 | Täglicher Statusbericht | Zeitgesteuert | 842 ms | Erfolgreich |
| 2026-05-04 06:42:18 | Vorgang → QS-Prüfung | Datenänderung | 312 ms | Erfolgreich |
| 2026-05-04 06:00:00 | SCADA-Polling | Zeitgesteuert | 30.0 s | Fehlgeschlagen |
| 2026-05-04 04:00:00 | Eskalation überfällig | Zeitgesteuert | 1.2 s | Erfolgreich |
| 2026-05-04 02:00:03 | Wöchentliche Bereinigung | Zeitgesteuert | 14.8 s | Erfolgreich |
Fehlerbehandlung und Wiederholung
Wenn ein Hintergrund-Job fehlschlägt, greift die automatische Fehlerbehandlung:
- Der Fehler wird vollständig protokolliert (Fehlermeldung, StackTrace, Zeitpunkt)
- Wenn Wiederholungsversuche konfiguriert sind (
MaxRetries > 0), wird der Job nach der eingestellten Wartezeit erneut ausgeführt - Die Wartezeit zwischen Versuchen ist konfigurierbar (Standard: 5 Minuten)
- Bei anhaltendem Fehler wird der Status auf „Fehlgeschlagen“ gesetzt — der Job bleibt jedoch aktiv und wird beim nächsten regulären Auslöser erneut versucht
| Einstellung | Beschreibung |
|---|---|
| Max. Wiederholungen | Wie oft der Job bei einem Fehler wiederholt werden soll (0 = keine Wiederholung) |
| Wartezeit (Sekunden) | Pause zwischen Wiederholungsversuchen (Standard: 300 = 5 Minuten) |
| Max. Ausführungszeit | Timeout in Sekunden — wird der Job nicht rechtzeitig fertig, wird er abgebrochen (leer = kein Limit) |
Praxisbeispiele
Typ: Time · Zeitplan: Jeden Sonntag um 02:00 Uhr (0 2 * * 0) · Aktion: Code ausführen
Der Job identifiziert verwaiste Datensätze (z. B. unvollständige Entwürfe älter als 90 Tage) und archiviert sie automatisch. Das Ergebnis wird im Ausführungsprotokoll dokumentiert.
Typ: DataChange · Trigger: OnUpdate auf Feld „Betrag“ mit Filterbedingung „Betrag > 10.000“ · Aktion: Nachricht senden
Sobald ein Datensatz gespeichert wird und der Betrag 10.000 überschreitet, erhält der zuständige Abteilungsleiter eine Push-Benachrichtigung.
Typ: DataChange · Trigger: OnInsert auf Entität „Bestellung“ · Aktion: Genehmigung erstellen
Jede neue Bestellung erzeugt automatisch eine Genehmigungsanfrage. Der verantwortliche Freigeber wird per Benachrichtigung informiert.
Typ: Time · Zeitplan: Am 1. jedes Monats um 06:00 Uhr (0 6 1 * *) · Aktion: Bericht erstellen
Der Job generiert einen Monatsbericht als PDF und speichert ihn automatisch als Anhang am zugehörigen Datensatz. So ist der Bericht für alle berechtigten Anwender verfügbar.
Typ: Time · Zeitplan: Alle 4 Stunden (0 */4 * * *) · Aktion: Code ausführen mit Bedingungsfunktion
Der Job prüft alle 4 Stunden, ob offene Vorgänge länger als 48 Stunden unerledigt sind. Falls ja, erstellt er eine Eskalations-Nachricht an den Vorgesetzten. Die Bedingungsfunktion sorgt dafür, dass nur bei tatsächlichem Handlungsbedarf eine Nachricht gesendet wird.
Tipps und Warnungen
FormApi oder DialogApi führen zu Fehlern. Verwenden Sie ausschließlich die serverseitigen APIs (DataApi, MessageApi, EntityApi).
Häufige Fragen
| Frage | Antwort |
|---|---|
| Was passiert, wenn der Server während einer geplanten Ausführung nicht läuft? | Verpasste Ausführungen werden nicht nachgeholt. Der Job wird erst beim nächsten regulären Fälligkeitszeitpunkt wieder ausgeführt. Nutzen Sie „RunOnStartup“ für kritische Jobs, die nach einem Neustart sofort laufen sollen. |
| Kann ein Job mehrere Aktionen gleichzeitig ausführen? | Nein. Jeder Job hat genau eine Aktion. Für mehrere Aktionen legen Sie separate Jobs an oder verwenden die Aktion „Code ausführen“, um in einem Skript mehrere Schritte zu kombinieren. |
| Wie genau ist die Zeitsteuerung? | Der Scheduler prüft alle 60 Sekunden auf fällige Jobs. Die Ausführung kann daher bis zu 60 Sekunden nach dem geplanten Zeitpunkt beginnen. Für sekundengenaue Zeitsteuerung ist das System nicht ausgelegt. |
| Kann ich einen DataChange-Job auf mehrere Felder gleichzeitig reagieren lassen? | Pro Schedule-Eintrag kann ein Trigger-Feld definiert werden. Für mehrere Felder legen Sie mehrere Schedule-Einträge innerhalb desselben Jobs an — jeweils mit einem anderen Feld als Trigger. |
| Werden DataChange-Jobs auch bei Massenänderungen (Bulk-Updates) ausgelöst? | Ja. Der Trigger wird für jeden einzelnen geänderten Datensatz ausgewertet. Bei großen Massenänderungen kann dies zu vielen parallelen Ausführungen führen. Berücksichtigen Sie dies bei der Konfiguration. |
| Wie deaktiviere ich einen Job vorübergehend? | Setzen Sie die Einstellung „Aktiv“ auf „Nein“ in den Job-Einstellungen. Der Job bleibt konfiguriert, wird aber vom Scheduler und den Triggern ignoriert, bis Sie ihn wieder aktivieren. |
| Was ist der Unterschied zwischen „Festes Intervall“ und einem Cron-Ausdruck? | Festes Intervall misst die Zeit seit der letzten Ausführung (z. B. alle 4 Stunden ab dem letzten Lauf). Ein Cron-Ausdruck definiert feste Zeitpunkte (z. B. um 00:00, 04:00, 08:00). Bei Intervallen kann sich der Zeitpunkt verschieben, bei Cron bleibt er immer gleich. |
| Kann ich die alten Ausführungsprotokolle löschen? | Alte Protokoll-Einträge werden periodisch automatisch bereinigt. Der Aufbewahrungszeitraum kann in den Systemeinstellungen konfiguriert werden. |
| Kann ein Job einen anderen Job auslösen? | Nicht direkt. Wenn die Aktion eines Jobs jedoch Daten ändert und ein DataChange-Job auf diese Entität konfiguriert ist, wird dieser automatisch ausgelöst. So entstehen indirekte Verkettungen. |
| Unter welchem Benutzer laufen Hintergrund-Jobs? | Hintergrund-Jobs laufen unter einem System-Benutzer. Berechtigungsprüfungen auf Datensatzebene gelten nicht. Die Konfiguration von Jobs ist über die Berechtigung „UdmJob“ geschützt. |
Background-Service-Architektur
Hintergrund-Jobs laufen in einem separaten Background-Service, der unabhängig vom Hauptsystem arbeitet. Diese Architektur bietet mehrere Vorteile:
- Unabhängigkeit — Hintergrund-Verarbeitungen beeinflussen nicht die Performance des Hauptsystems.
- Skalierbarkeit — Der Background-Service kann auf einem eigenen Server betrieben werden.
- Zuverlässigkeit — Bei einem Neustart des Hauptsystems laufen Hintergrund-Jobs weiter.
Der Status des Background-Service kann über den System-Monitor (Verwaltung → System-Monitor) überwacht werden.
Integrierte Dienste
- Ordnerüberwachung (FolderWatch) — Überwacht konfigurierte Verzeichnisse auf neue Dateien und verarbeitet diese automatisch.
- Zeitgesteuerte Jobs — Führt UdmJob-Aktionen nach einem definierten Zeitplan aus (Cron-basiert).
- Externes Daten-Polling — Überwacht externe Datenquellen auf Änderungen und übernimmt neue Daten automatisch.