WARNUNG: Sie betrachten nicht die Live-Version, sondern eine ältere Version.

Job PreloadUserData

Zweck

Der Job preloadUserData lädt für ausgewählte Benutzer:innen häufig benötigte Daten (z. B. Workflow-Listen, Menüberechtigungen) vor, damit deren nächster Login schneller abläuft. Grundlage ist eine Stichprobe aller Personen, die am letzten Werktag innerhalb eines definierten Zeitfensters erfolgreich angemeldet waren.

Ablauf

  1. Beim Start werden Konfiguration und verfügbare UserDataPreloader-Komponenten aus dem Spring-Context eingelesen. Sie entscheiden, welche Datensätze pro Person vorgeladen werden.
  2. Der Job ermittelt alle Personen, die sich am letzten Werktag zwischen den angegebenen Zeitpunkten erfolgreich angemeldet haben (optional gefiltert nach Mandant über die Jobdefinition).
  3. Die Ergebnisliste wird auf das konfigurierte Maximum begrenzt. Anschließend laufen die ausgewählten Preloader nacheinander über jede Person und messen ihre Ausführungszeiten.
  4. Alle 100 Personen gibt der Job einen Fortschrittsstand aus. Am Ende werden Statistikzeilen pro Preloader protokolliert (Gesamtlaufzeit, Anzahl verarbeiteter Personen, Durchschnitt).

Bekannte UserDataPreloader

Name

Aufgabe

WfListItemCacheFiller

Füllt Workflow-Listen (Offene Anträge, Erledigte Anträge, To-dos) vor und lädt Detailinformationen, damit WF-Ansichten schneller öffnen.

PoActionsOfMenuPermissionsFiller

Prüft vorausschauend Menü- und Aktionsberechtigungen, löst Weiterleitungen auf und lädt Einsichtsrechte, damit Navigationsklicks ohne Verzögerung möglich sind.

TaGetJournalV2CacheFiller

Ruft für ta_getJournalV2.act die Journal-Konfiguration der Person ab und füllt den Journal-Cache (Konten, Summen, Buchungen) auf Basis der aktuellen Action-Config.

TaCorrectionClientJournalV2CacheFiller

Bereitet Journal-Daten für ta_correctionClient.act vor, inklusive Lazy-Loading-Szenarien, damit persönliche Korrekturbuchungen ohne Wartezeit geladen werden.

Weitere Preloader können projektabhängig registriert werden; sie erscheinen automatisch in der Auswahlliste.

Konfiguration

Zeitfenster für welches eingeloggte User vom letzten Werktag genommen werden

Besteht aus den Feldern von und bis. Hier legen Sie das Login-Zeitfenster fest, aus dem die Stichprobe stammt (z. B. 07:45– 09:00). Das Format ist HH:mm. Nur erfolgreiche Logins innerhalb dieses Rahmens werden berücksichtigt.

Verwende alle verfügbaren Preloader?

Ist die Option aktiv, laufen sämtliche registrierten Preloader über jede Person. Bei deaktivierter Option erscheint die Liste Auswahl Preloader, in der Sie gezielt einzelne Beans wählen können (Mehrfachauswahl über Doppelliste).

Auswahl Preloader

Wird sichtbar, sobald Sie nicht alle Preloader verwenden möchten. Die Liste enthält alle im ApplicationContext gefundenen Implementierungen des Interfaces UserDataPreloader. Verschieben Sie die gewünschten Preloader in die rechte Spalte.

Maximum Anzahl von Personen

Begrenzt, wie viele Benutzer:innen pro Lauf höchstens verarbeitet werden. Standardwert ist 2000. Das Limit dient dem Schutz vor langen Laufzeiten; reduzieren Sie es bei knappen Ressourcen oder erhöhen Sie es bei leistungsfähigen Systemen.

Bedienhinweise

  • Wählen Sie das Zeitfenster so, dass es eine repräsentative Menge aktiver Benutzer:innen abbildet (z. B. Morgen-Peak). Außerhalb dieses Fensters angemeldete Personen werden nicht vorgeladen.
  • Wenn nur bestimmte Bereiche beschleunigt werden sollen, deaktivieren Sie „alle Preloader“ und wählen Sie gezielt die relevanten Komponenten aus.
  • Beobachten Sie nach Änderungen das Log: Dort sehen Sie, wie viele Personen verarbeitet wurden und welche Preloader wie lange benötigen.
  • Der Job berücksichtigt immer den letzten Werktag. Planen Sie ihn daher täglich in den frühen Morgenstunden, damit die Daten rechtzeitig vor Arbeitsbeginn geladen sind.
  • Stellen Sie sicher, dass sämtliche Preloader idempotent arbeiten: Mehrfachläufe dürfen keine widersprüchlichen Daten erzeugen.
Kommentare (0)