Timer

Grundlagen

In diesem Menüpunkt können Sie einstellen, welche Aktionen in welchen Zeitabständen automatisch ausgeführt werden sollen. Damit eine Aktion bei der Ausführung berücksichtigt werden kann, muss sie aktiviert werden. Die Zeiträume werden in Sekunden eingestellt.

Spalte Startzeit: nach dem Neustart des JBoss, starten die Timer zu diesem Zeitpunkt wieder, wenn die Periode größer ist, als die Zeitdauer vom Start des Jboss zur Startzeit. Die ist vor allem für Timer, die nur einmal am Tag oder Woche laufen, relevant. Danach laufen die Timer mit ihrer Periode weiter.

Einmalige Ausführung

Mit derselben Zeitangabe in "Von" und "Bis" sowie "alle 1 Minuten" erfolgt der Start der Timer-Aktion genau einmal.

Pflege von Timern unabhängig vom Prozessnamen

Man kann den Namen des Timers unabhängig vom Prozessnamen pflegen. Somit können mehrere Timer mit unterschiedlichen an denselben BPM-Prozess übergebenen Parametern angelegt und mit unabhängigem Zeitplan aufgerufen werden. Statt für jeden Timer einen separaten Prozess anzulegen, existiert nur noch genau ein BPM-Prozess, der wiederum die benötigte Skriptbibliotheksmethode aufruft.

• Es wird die ID genutzt

  • ID wird bei Neuanlage der Aktion gepflegt

  • Feld ist bei Neuanlage der Aktion schreibbar

  • es ist ein eindeutiges Pflichtfeld, keine Leerzeichen erlaubt

    • In verschiedenen Schichten wird das entsprechende Präfix berücksichtigt

Timer für die Unit-Tests

Mit den EVU-Modulen werden zahlreiche Skripttests ausgeliefert, die sicherstellen sollen, dass das CRM-System korrekt konfiguriert ist und alle Funktionen und Prozesse ordnungsgemäß funktionieren. Diese werden durch die Aktion Tests ausführen, die wiederum von einen Timer aufgerufen wird, regelmäßig gestartet. Der Timer wird mit der EVI-Auslieferungsversion ausgeliefert.

Timer vom Typ 'SCRIPT_TEST' werden standardmäßig beim Customizing-Transport von Timern deaktiviert, sodass sie in einem Produktivsystem deaktiviert sind. Der Systemadministrator kann sie im Produktivsystem wieder explizit aktivieren. So hält man sich die Möglichkeit offen, die Skripttests weiterhin auf einem Produktivsystem ausführen zu können, sofern man das möchte (und sich sicher ist, dass alle Testdaten wieder entfernt werden).

Logiken:

• Timer war im Produktivsystem bereits aktiv und Timer ist im Quellsystem aktiv: Bleibt beim Transport aktiv.

• Timer war im Produktivsystem inaktiv und Timer ist im Quellsystem aktiv: Timer bleibt inaktiv.

• Timer war im Produktivsystem bereits aktiv und Timer ist im Quellsystem inaktiv: Timer wird beim Transport deaktiviert.

Auslieferung von Timern mit Modulen

Timer für Module werden in der C1-Schicht an ein Modul gebunden und mit Einspielen eines Moduls ausgeliefert. Dies verhindert zum einen, dass Kunden Timer in ihren Systemen vorfinden, die sie gar nicht brauchen und andererseits beim Einspielen eines Moduls die manuellen Nacharbeiten auf das Einstellen des mit dem Modul ausgelieferten Timers verringern.

Spezifikation der Timer:

• Timer können in der C1-Schicht an Module gebunden werden

• Timer sind nur dann im System sichtbar, wenn das Modul, zu dem sie gehören, im System vorhanden ist

• Timer werden bei vorhandenen, aber inaktiven Modulen durchgestrichen dargestellt und nie ausgeführt

• Timer werden nur dann als verfügbar dargestellt, wenn das Modul, zu dem sie gehören im System vorhanden und lizensiert ist

• Beim Timer wird beim erstmaligen Speichern die Partner-ID dem gewählten Timer-Namen in der ID vorangestellt

• In der C1-Schicht können lediglich Timer mit der eigenen Partner-ID bearbeitet werden

• Der Zeitplan ist in der C1-Schicht schreibgeschützt, außer es handelt sich um eine Aktion mit der eigenen Partner-ID

• In der C2-Schicht ist der Zeitplan nicht schreibgeschützt

Einbindung von Prozessen und der Skriptbibliothek

siehe auch:

→ Prozesse (Zeitgesteuerte Aktionen)

→ Skriptbibliothek

Beschreibung der Timer-Jobs

Caches optimieren

Dieser Job entfernt veraltete Einträge aus dem Systemcache und unterstützt damit die technische Stabilität und Performance des Systems.

Empfehlenswert ist, den Cache ein Mal täglich zu optimieren. Es erfolgt kein Leeren des Caches, aktuelle Einträge bleiben hierbei erhalten.

Systemtabellen bereinigen

Dieser Job bereinigt technische Prozess- und Systemdaten, die sich im laufenden Betrieb ansammeln. Dies ist insbesondere in Test- und Projektphasen hilfreich.

Abgelaufene Anmeldungen bereinigen

Dieser Job erkennt veraltete oder technisch abgebrochene Sitzungen und meldet diese automatisch ab.

Erfolgt innerhalb (hier) 6 Stunden keine Rückmeldung, ist davon auszugehen, dass der Client nicht mehr erreichbar ist (Absturz, es kann keine LAN-Verbindung aufgebaut werden etc.).

In solchem Fall wird der Client "zwangsabgemeldet".

Aktionen ausführen

Dieser Timer dient als allgemeiner Scheduler für zeitgesteuerte Aktionen im System. Er prüft in regelmäßigen Abständen, ob für hinterlegte Zeitpläne Aktionen gestartet werden sollen, zum Beispiel geplante Exporte, Importe, Skripte, technische Folgeprozesse oder Batch-Läufe.
Er ist nur relevant, wenn im Projekt oder im späteren Betrieb tatsächlich zeitgesteuerte Aktionen über Taskliste und Zeitplan genutzt werden. Werden Prozesse ausschließlich ereignisgesteuert oder manuell ausgelöst, ist dieser Timer nicht erforderlich.

Timer zur Abarbeitung von Hintergrund-Jobs

Der Timer ist für die Benachrichtigung fertiger Jobs in der Auftragswarteschlange zuständig.

Suchindex erneuern

Dieser Job übergibt Änderungen im System an den Suchindex, sodass neue oder geänderte Daten in der Suche sichtbar werden.

Index-Neuaufbau als konfigurierte Aktion

Der Lucene-Index kann außerhalb der normalen Geschäftszeit neu aufgebaut werden, damit Ressourcen des Applikationsservers geschont werden und der Index aktuell bleibt.

• In der Adminkonsole kann über Timer /Aktion ausführen /Taskliste eine neue Timeraktion vom Typ LUCENE_INDEX konfiguriert werden

• Analog zu den anderen Timeraktionen kann der Zeitplan zur Ausführung definiert werden

• Zusätzlich kann eine Reihe von Entitäten selektiert werden, die bei der Ausführung indiziert werden sollen.

Endgültiger Löschlauf nach DS-GVO

Dieser Timer führt die physische Löschung von Daten durch, sobald für DSGVO-Datenkategorien definierte Löschzeitpunkte erreicht wurden. Er ist insbesondere für zeitgesteuerte Löschlogiken relevant und wird nur benötigt, wenn im System ein aktives DSGVO-Löschkonzept mit entsprechenden Datenkategorien und Fristen umgesetzt ist.

Pro Verarbeitungstätigkeit können mehrere DSGVO-Datenkategorien mit entsprechendem Löschversatz definiert werden. Der Startzeitpunkt für das Löschen ergibt sich aus einer bestimmten Aktion (Klick auf Aktionsboxeintrag, BPM-Prozess, etc.), daher sprechen wir hier vom "aktionsgesteuerten Löschen". Zusätzlich ist es möglich, DSGVO-Datenkategorien anzulegen, die einer rein zeitgesteuerten Löschlogik unterliegen ("zeitgesteuertes Löschen"). Bei diesen "zeitgesteuerten" Datenkategorien ist es möglich, ein Bezugsfeld (Datum) anzugeben. Der Löschversatz berechnet sich in diesem Fall auf das Bezugsfeld. Ist der Löschzeitpunkt erreicht, findet die Löschung physikalisch auf der Datenbank statt, dies erfolgt über den Timer "Endgültiger Löschlauf nach DS-GVO", der hierfür aktiviert werden muss.

Dokumente kopieren

Dieser Timer ist relevant, wenn Dokumente automatisiert verarbeitet, kopiert oder gelöscht werden sollen. Er kommt insbesondere dann zum Einsatz, wenn Dokumente Bestandteil der Integration oder technischer Folgeprozesse sind, zum Beispiel im Zusammenhang mit Preisanpassungen oder dokumentenbasierten Abläufen.

Es gibt eine Timer-Aktion, die aus der Tabelle (CopyDocuments) ausliest, ob Dokumente kopiert oder gelöscht werden sollen. Diese beschränkt sich auf im System vorhandene Dokumente. Der Timer arbeitet auf einem über den PropertyMapper festgelegten Verzeichnis.

Ablauf

1. Eintrag mit Status A wird eingefügt.

2. CURSOR-CRM setzt B und beginnt anschließend mit dem Kopieren.

3. War das Kopieren erfolgreich, wird Status C gesetzt, andernfalls F.

4. Das Fremdsystem kann nun nach Einträgen mit dem Status C suchen und sie auf D setzen. Anschließend kann es beginnen, die Datei zu verarbeiten.

5. Wurde das Dokument erfolgreich verarbeitet, wird der Status auf E gesetzt, andernfalls auf F.

6. Das CURSOR-CRM prüft (bevor es nach Status A sucht), ob Dokumente mit Status E existieren. Diese werden dann aus dem Transferordner gelöscht und anschließend auf G gesetzt. Gibt es beim Löschen Probleme, werden sie auf F gesetzt.

PropertyMapper Eintrag

Das folgende Statement (für MS SQL) muss zunächst abgesetzt werden. Dabei ist <my-dir> durch das Verzeichnis zu ersetzen, in dem gearbeitet werden soll.

INSERT INTO PropertyMapper (Pk, id, propertytype, property, principal, propertyvalue, CustLayer, Active, MassData, 
RightPk, CreateUser, UpdateUser, CreateDate, UpdateDate)
VALUES ('SYSTEM.CopyDocumentsAction.copyDocumentsDir'
,'/de/cursor/jevi/server/document/CopyDocumentsAction$!!$CopyDocumentsAction.copyDocumentsDir'
, 'SYSTEM', '', '', '<my-dir>', 'CN', 1, 0, 'RIGHTTEMPLATE', 'TECH_USER', 'TECH_USER', GETDATE(), GETDATE())

Die Tabelle befüllen

Folgende Felder können befüllt werden:

Tabellenblatt CopyDocuments

Tabellenblatt TransferStatus

INSERT INTO CopyDocuments (Pk, TransferStatus, DocumentPk, DocumentName, ErrorMessage, Active, MassData, 
RightPk, CreateUser, UpdateUser, CreateDate, UpdateDate)
VALUES ('<pk>', '<transfer-status>', '<document-pk>', '<document-name>', '<error-message>',
1, 0, 'RIGHTTEMPLATE', 'TECH_USER', 'TECH_USER', GETDATE(), GETDATE())

Systembenachrichtigungen

Damit die Systembenachrichtigungen anzeigt werden, muss der Timer "Systembenachrichtigungen" aktiv sein. Es handelt sich um Systembenachrichtigungen, die per Mail über die in den Systemeinstellungen konfigurierte E-Mail-Konfiguration (Sender von systemseitigen Mailbenachrichtigungen) einmal täglich gesendet werden. Hier wird derzeit nur der Ablauf des SSL-Zertifikats des Servers geprüft.

Automatischer Mailimport von E-Mail-Konfigurationen

Dieser Timer importiert alle E-Mails für E-Mail-Konfigurationen, in denen das Flag "Automatisch importieren" gesetzt ist. Der Timer startet automatisch standardmäßig alle 10 Minuten. Falls notwendig, kann eine abweichende Timerperiode in der Admin-Konsole in der Spalte "Zeitraum" eingestellt werden.

Das genannte Flag "Automatisch importieren" befindet sich in der Maske E-Mail-Konfiguration. Ist das Flag aktiv, haben Sie außerdem die Möglichkeit, im Feld "Zuständiger für importierte Mails" den Benutzer, an den die beim Import entstehenden Aktivitäten delegiert werden sollen, zu hinterlegen. Sofern die Import-Logik keinen Delegiert an/von Mitarbeiter ermitteln kann, werden die Felder mit dem Mitarbeiter gefüllt, der den Timer ausführt.

Automatischer Groupwareabgleich für die Mitarbeiter

Der Timer übernimmt den automatischen Groupware-Abgleich. Der Timer wird alle 10 Minuten ausgeführt. Im Auslieferungsstandard ist der Timer deaktiviert. Beim Update wird der Timer automatisch aktiviert, wenn beim Kunden eine entsprechende Timer-Aktion konfiguriert war.

Schlüssel abgleichen

Dieser Job unterstützt den Abgleich technischer Schlüssel und Zuordnungen im System.

Globale Variablen abgleichen

Dieser Job sorgt dafür, dass systemweit genutzte Variablen und Konfigurationswerte aktuell gehalten werden.

Wartung prüfen

Dieser Job erzeugt Hinweise auf bevorstehende Wartungen und unterstützt die automatische Benutzerabmeldung im Wartungsfall.

Wenn eine Wartung aktiv wird, werden alle Benutzer-Sessions geschlossen und die Benutzer automatisch abgemeldet. Bevor eine Wartung aktiv wird, erhalten alle anderen Benutzer über die Taskliste Nachrichten über die bevorstehende Wartung. Darüber hinaus wird 5 Minuten vor der Wartung jede Minute die Warnung aktualisiert. Warnungen für die Wartung werden über den Timer "Wartung prüfen" alle 60 Sekunden generiert. Dieser ist nicht  änderbar.

Customizing-Pakete und Module importieren

Dieser Timer dient dem automatisierten Import von Customizing-Paketen und Modulen. Er ist nur relevant, wenn technische Einspielungen bewusst über diesen Mechanismus erfolgen sollen.

Nachrichten der Auftragswarteschlange aktualisieren

Dieser Job ist für die Benachrichtigung und Abarbeitung fertiger Hintergrundjobs in der Auftragswarteschlange zuständig.

Metriken aktualisieren

Dieser Job aktualisiert technische Kennzahlen des Applikationsservers und unterstützt damit das Monitoring des Applikationsservers (Größe, Platzverbrauch, letzte Aktualisierung der Statistiken).

Eskalationsdatum prüfen

Vorgangsmanagement: Im Standard wird jede Minute prüft, ob ein Vorgang oder Anliegen Datum (Fälligkeits- und Erinnerungsdatum) überschritten wurde und versendet anschließend eine Benachrichtigung im Benachrichtigungssystem.