Timer
Basics
This menu item allows you to configure which actions are to be automatically executed in what time intervals. An action must be activated to be included in an execution. The intervals are set in seconds.
Column Start time: after restarting the JBoss, the timers restart at this time if the period is greater than the duration from the start of the Jboss to the start time. This is especially relevant for timers that run only once a day or week. After that, the timers continue with their period.
Figure: The menu item 'Timer' in the administration console
Run once
If the same time is entered in "From" and "To" and "every 1 minute", the timer action will be started exactly one time.
Figure: Example configuration for a one time execution
Optimize caches | At this point you specify, how often obsolete entries should be removed from the system cache. It is recommended to optimize the cache once a day. The cache is not automatically emptied and current entries remain intact. |
|---|---|
Adjust system tables | Starts the data cleansing for processes. |
Adjust old sessions | At this point you define how often a client should deliver a response to the server to signify that it is still logged into the system. If there is no response within (in this case) 6 hours, then it can be assumed that the client is no longer reachable (crash, no LAN connection, etc.). In such a case the client will be "force logged off". |
Execute actions | A timetable can be stored (via the Task list button), which determines when an action (e.g. data exports, Lucene index creation, processes, script test) should start. |
Initialize | The server cache is filled after a restart. |
Timer for processing background jobs | The timer is responsible for the notification of completed jobs in the job queue. |
Refresh search index | Here you can specify, how often the changes in the system should be forwarded to the Lucene index and therefore become visible for searches. Please note that very frequent indexing will impact on system performance. |
Final deletion run according to GDPR | Several GDPR data categories with corresponding deletion offsets can be defined for each processing activity. The start time for deletion results from a specific action (click on action box entry, BPM process, etc.), which is why we refer to this as "action-controlled deletion". It is also possible to create GDPR data categories that are subject to a purely time-controlled deletion logic ("time-controlled deletion"). For these "time-controlled" data categories, it is possible to specify a reference field (date). In this case, the deletion offset is calculated on the reference field. Once the deletion time has been reached, the deletion takes place physically on the database via the "Final deletion run according to GDPR" timer, which must be activated for this purpose. |
Copy documents | There is a timer action, which reads from the table (CopyDocuments), whether or not documents should be copied or deleted. This action is limited to documents available in the system. The timer works on a directory specified via the PropertyMapper. For details see subchapter Copy documents via timer. |
System notifications | The "System notifications" timer must be active for the system notifications to be displayed. These are system notifications that are sent by mail once a day via the email configuration configured in the system preferences (sender of system-side mail notifications). Only the expiration of the server's SSL certificate is currently checked here. |
Automatic mail import of email configurations | This timer imports all emails for email configurations in which the "Import automatically" flag is set. The timer starts automatically every 10 minutes by default. If necessary, a different timer period can be set in the Admin Console in the "Time period" column. The mentioned flag "Import automatically" is located in the email configuration mask. If the flag is active, you also have the option to store the user to whom the activities arising during the import should be delegated in the "Person responsible for imported mails" field. If the import logic cannot determine a delegate to/from employee, the fields are filled with the employee who executes the timer.  |
Automatic Groupware synchronization for employees | The timer takes over the automatic Groupware synchronization. The timer is executed every 10 minutes. The timer is deactivated in the delivery standard. During the update, the timer is automatically activated if a corresponding timer action was configured for the customer. |
Check maintenance | When maintenance becomes active, all user sessions are closed and the users are automatically logged off. Before maintenance becomes active, all other users receive messages about the upcoming maintenance via the task list. In addition, 5 minutes before maintenance, the warning is updated every minute. Warnings for maintenance are generated every 60 seconds by the "Check maintenance" timer. This can not be changed. |
Update metrics | Updates table metrics for monitoring the application server (size, space consumption, last update of statistics) |
Check escalation date | Ticket Management: By default, the system checks every minute whether a ticket or request date (due date and reminder date) has been exceeded and then sends a notification in the notification system. |
Copy documents via timer
There is a timer action, which reads from the table (CopyDocuments), whether or not documents should be copied or deleted. This action is limited to documents available in the system. The timer works on a directory specified via the PropertyMapper.
Procedure
An entry with status A is inserted.
CURSOR-CRM sets B and then begins copying.
Status C is set when the copy process was successful, otherwise F.
The third-party system can now search for entries with the status C and set them to D. It can then begin processing the file.
The status is set to E when the document was successfully processed, otherwise F.
CURSOR-CRM checks for documents with status E (before it looks for status A). These are then deleted from the transfer folder and set to G. If there are any problems with the deletion, then they are set to F.
PropertyMapper entry
The following statement (for MS SQL) must be executed. Replace <my-dir> with the directory in which the work is to be done.
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())Populating the table
The following parameters can be filled:
Worksheet CopyDocuments
Pk | The primary key of th dataset can be selected freely, but must be unique. Required field. |
|---|---|
TransferStatus | Specifies what is to be done with the document (see additional table). Required field. |
DocumentPk | The primary key of the document dataset, for which the document is to be copied (or the copy of which is to be deleted). Required field. |
DocumentName | The name under which the copy is to be created. Required field. |
ErrorMessage | An error message can be saved here on the part of CURSOR-CRM and also on the part of the third-party application. |
Worksheet TransferStatus
A | The document is to be copied to the transfer directory. |
B | The copy process has started. CURSOR-CRM is working on the document. |
C | The copy process is completed. The third-party system is permitted to edit the document. |
D | The document is currently being processed by a third-party system. |
E | The third-party process is completed. The document will then be cleaned up by CURSOR-CRM. |
F | Error status. A meaningful error message should be saved to the field ErrorMessage for this status. |
G | The copy of this document was deleted by CURSOR-CRM. |
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 reconstruction
The Lucene index can be reconstructed outside regular business hours to save application server resources and to keep the index up to date.
A new timer action of type LUCENE_INDEX can be configured in the administration console via Timer/Execute Action/Task List
The execution time can be defined just like for the other timer actions
Additionally, a number of entities can be selected for indexing at runtime.
Figure: Selecting entities for indexing
Maintenance of timers independent of the process name
You can maintain the name of the timer independently from the process name. Thus, multiple timers with different parameters passed to the same BPM process can be created and called with independent timetable. Instead of creating a separate process for each timer, only exactly one BPM process exists, which in turn calls the required script library method.
The ID is used
ID is maintained on new creation of the action
Field is writable on new creation of the action
it is a unique required field, no spaces allowed
In different layers the corresponding prefix is considered
Figure: A list of actions with the same name
Figure: Configuration dialog
Timer for the unit tests
Numerous script tests are delivered with the EVU modules to ensure that the CRM system is configured correctly and that all functions and processes are working properly. These are started periodically by the Execute tests action, which in turn is called by a timer. The timer is delivered with the EVI delivery version.
Timers of type 'SCRIPT_TEST' are disabled by default during customizing transport of timers, so they are disabled in a production system. The system administrator can explicitly activate them again in the production system. This leaves open the possibility of continuing to run the script tests on a production system, if you want to (and are sure that all test data will be removed again).
Logics:
Timer was already active in the production system and timer is active in the source system: Remains active during transport.
Timer was inactive in the production system and timer is active in the source system: Timer remains inactive.
Timer was already active in the production system and timer is inactive in the source system: Timer is deactivated during transport.
Delivery of timers with modules
Timers for modules are bound to a module in the C1 layer and delivered when a module is imported. On the one hand, this prevents customers from finding timers in their systems that they do not need at all, and on the other hand, when a module is imported, it reduces the manual rework to setting the timer delivered with the module.
Specification of timers:
Timers can be bound to modules in the C1 layer
Timers are only visible in the system if the module they belong to is present in the system
Timers are displayed strikethrough for existing but inactive modules and are never executed
Timers are only shown as available if the module they belong to is present and licensed in the system
For the timer, the partner ID is prefixed to the selected timer name in the ID when it is saved for the first time
In the C1 layer, only timers with the own partner ID can be edited
The timetable is read-only in the C1 layer unless it is an action with its own partner ID
In the C2 layer the timetable is not read-only
Integration of processes and the script library
see also:
→ Processes (time-controlled actions)