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.
Abbildung: Menüpunkt 'Timer' in der Administrationskonsole
Einmalige Ausführung
Mit derselben Zeitangabe in "Von" und "Bis" sowie "alle 1 Minuten" erfolgt der Start der Timer-Aktion genau einmal.
Abbildung: Beispiel einer Konfiguration für eine einmalige Ausführung
Caches optimieren | An dieser Stelle konfigurieren Sie, wie oft veraltete Einträge aus dem Systemcache entfernt werden sollen. Empfehlenswert ist, den Cache ein Mal täglich zu optimieren. Es erfolgt kein Leeren des Caches, aktuelle Einträge bleiben hierbei erhalten. |
|---|---|
Systemtabellen bereinigen | Startet die Datenbereinigung von Prozessen. |
Abgelaufene Anmeldungen bereinigen | An dieser Stelle definieren Sie, wie oft ein Client eine Rückmeldung an den Server liefern soll, ob er noch im System angemeldet ist. 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 | Es kann ein Zeitplan hinterlegt werden (über den Schalter Taskliste), der bestimmt, wann eine Aktion (z.B Datenexporte, Lucene-Index-Erstellung, Prozesse, Skript-Test) starten soll. |
Initialisieren | Der Server-Cache wird nach dem Neustart vorgefüllt. |
Timer zur Abarbeitung von Hintergrund-Jobs | Der Timer ist für die Benachrichtigung fertiger Jobs in der Auftragswarteschlange zuständig. |
Suchindex erneuern | Hier können Sie einstellen, wie oft die Änderungen im System an den Lucene-Index übergeben und somit für die Suchen sichtbar werden sollen. Beachten Sie, dass sehr häufige Indexierung die Performance des Systems beeinflussen kann. |
Endgültiger Löschlauf nach DS-GVO | 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 muss 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 | 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. Details siehe Unterkapitel Kopieren von Dokumenten über Timer. |
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. |
Wartung prüfen | 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. |
Metriken aktualisieren | Aktualisiert Tabellen-Metriken für 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. |
Kopieren von Dokumenten über Timer
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
Eintrag mit Status A wird eingefügt.
CURSOR-CRM setzt B und beginnt anschließend mit dem Kopieren.
War das Kopieren erfolgreich, wird Status C gesetzt, andernfalls F.
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.
Wurde das Dokument erfolgreich verarbeitet, wird der Status auf E gesetzt, andernfalls auf F.
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, OfflineData, WFInstanceId,
RightPk, CreateUser, UpdateUser, CreateDate, UpdateDate)
VALUES ('SYSTEM.CopyDocumentsAction.copyDocumentsDir'
,'/de/cursor/jevi/server/document/CopyDocumentsAction$!!$CopyDocumentsAction.copyDocumentsDir'
, 'SYSTEM', '', '', '<my-dir>', 'CN', 1, 0, 0, null, 'RIGHTTEMPLATE', 'TECH_USER', 'TECH_USER', GETDATE(), GETDATE())Die Tabelle befüllen
Folgende Felder können befüllt werden:
Tabellenblatt CopyDocuments
Pk | Der Primärschlüssel des Satzes, kann frei, aber eindeutig gewählt werden. Pflichtfeld. |
|---|---|
TransferStatus | Legt fest was mit dem Dokument gemacht werden soll (siehe Extratabelle). Pflichtfeld. |
DocumentPk | Der Primärschlüssel des Dokumentensatzes, dessen Dokument kopiert (oder dessen Kopie gelöscht) werden soll. Pflichtfeld. |
DocumentName | Der Name unter dem die Kopie des Dokuments angelegt werden soll. Pflichtfeld. |
ErrorMessage | Sowohl von Seiten des CURSOR-CRM, als auch von Seiten der Fremdanwendung kann hier eine Fehlermeldung hinterlegt werden. |
Tabellenblatt TransferStatus
A | Dokument soll in das Transferverzeichnis kopiert werden. |
B | Der Kopiervorgang ist gestartet. CURSOR-CRM bearbeitet das Dokument. |
C | Der Kopiervorgang ist abgeschlossen. Das Fremdsystem darf das Dokument bearbeiten. |
D | Status, dass das Dokument von einem Fremdsystem in Arbeit ist. |
E | Status, dass ein Fremdprozess seine Arbeit abgeschlossen hat. Das Dokument wird daraufhin vom CURSOR-CRM aufgeräumt. |
F | Fehlerstatus. In diesem Fall sollte in ErrorMessage eine entsprechende Fehlermeldung hinterlegt werden. |
G | Die Kopie dieses Dokuments wurde vom CURSOR-CRM gelöscht. |
Beispiel
Statement:
INSERT INTO CopyDocuments (Pk, TransferStatus, DocumentPk, DocumentName, ErrorMessage, Active, MassData, OfflineData, WFInstanceId,
RightPk, CreateUser, UpdateUser, CreateDate, UpdateDate)
VALUES ('<pk>', '<transfer-status>', '<document-pk>', '<document-name>', '<error-message>',
1, 0, 0, null, 'RIGHTTEMPLATE', 'TECH_USER', 'TECH_USER', GETDATE(), GETDATE())Index-Neuaufbau
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.
Abbildung: Selektion der zu indizierenden Entitäten
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
Abbildung: Eine Liste von gleichnamigen Aktionen
Abbildung: Konfigurationsdialog
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)