Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision 		Previous revision
Next revision Both sides next revision
devel:documentation:application_configuration:dev:scheduled_tasks:task-scheduler [2019/11/20 12:27]
tomiskar [DeleteNotificationTaskExecutor] 		devel:documentation:application_configuration:dev:scheduled_tasks:task-scheduler [2020/05/25 05:59]
husniko
Line 1: Line 1:
 ====== Tasks scheduler ====== ====== Tasks scheduler ======
  
-{{tag> scheduler}}+{{tag> scheduler final lrt long running task description triggers cron scheduled }}
  
 The task can be scheduled in three different ways - types of ''triggers'': The task can be scheduled in three different ways - types of ''triggers'':
Line 36: Line 36:
 ==== Example ==== ==== Example ====
  
-Example of an implementing task - you will find everything that has been mentioned [[https://github.com/bcvsolutions/CzechIdMng/blob/develop/Realization/backend/core/core-impl/src/test/java/eu/bcvsolutions/idm/core/scheduler/TestSchedulableTask.java|here]].+Example of an implementing task - you will find everything that has been mentioned [[https://github.com/bcvsolutions/CzechIdMng/blob/develop/Realization/backend/core/core-impl/src/test/java/eu/bcvsolutions/idm/core/scheduler/service/impl/TestSchedulableTask.java|here]].
  
 ===== Stateful task executors ===== ===== Stateful task executors =====
Line 59: Line 59:
   * ''requireNewTransaction'' ''false'' by default. Each item will be processed in new transaction - ensures successfully processed item will be commited after other item or LRT task fails. Use this property everywhere, when LRT can be executed synchronously (e.g. for synchronization dependent task, which are executed synchronously and wrapped which one parent transaction).   * ''requireNewTransaction'' ''false'' by default. Each item will be processed in new transaction - ensures successfully processed item will be commited after other item or LRT task fails. Use this property everywhere, when LRT can be executed synchronously (e.g. for synchronization dependent task, which are executed synchronously and wrapped which one parent transaction).
   * ''supportsQueue'' - ''true'' by default. If is ''false'', then each item (candidate) will be processed without checking already processed items (queue is ignored). Usable, when processed items should be logged, but queue has to be ignored.   * ''supportsQueue'' - ''true'' by default. If is ''false'', then each item (candidate) will be processed without checking already processed items (queue is ignored). Usable, when processed items should be logged, but queue has to be ignored.
 +  * ''isRecoverable'' - ''false'' by default. See recoverable task introduction below.
  
 <note warning>Look out: when scheduled task is removed, then all item will be processed again! Processed items are linked to scheduled task instance. Prevent to remove tasks, which sends notifications etc. (e.g. passwor exrire warning) - notifications will be send again.</note> <note warning>Look out: when scheduled task is removed, then all item will be processed again! Processed items are linked to scheduled task instance. Prevent to remove tasks, which sends notifications etc. (e.g. passwor exrire warning) - notifications will be send again.</note>
 +
 +===== Recoverable tasks =====
 +
 +@since 10.2.0
 +
 +Task can be executed repetitively without reschedule is needed. When task is canceled (e.g. by server is restarted), then task can be executed again (~recovered) directly from long running task agenda. New task will be created and executed with the same configuration as original task. **When task** is stateful and **supports queue**, then **already processed items will not be processed again**.
 +
 +
 +<note>To enable this feature, task method ''isRecoverable'' has to be overiden and return ''true''.</note>
 +
 +<note important>Only tasks created and **running** in the version **10.2.0** and higher can be run again!</note>
 +
 +{{ :devel:documentation:application_configuration:dev:scheduled_tasks:lrt-sync-recreation.png |}}
 +
 +
  
 ===== Implemented task types ===== ===== Implemented task types =====
Line 69: Line 85:
  
 Sends warning notification before password expires. Notification is **not send to disabled identities**. Days before has to be given as task's parameter (number greater than zero). More task could be configured e.g. for sending warning notification 14,7,3 days before password expires. Default notification topic is configured to email sender. Sends warning notification before password expires. Notification is **not send to disabled identities**. Days before has to be given as task's parameter (number greater than zero). More task could be configured e.g. for sending warning notification 14,7,3 days before password expires. Default notification topic is configured to email sender.
 +
 +<note tip>It's good to schedule ''PasswordExpiredTaskExecutor'' and ''PasswordExpirationWarningTaskExecutor'' on the start of day - e.g. ** 0 5 0 ? * * ** => passwords which expired yesterday will be processed and proper notifications will be send.</note>
  
 ==== PasswordExpiredTaskExecutor ==== ==== PasswordExpiredTaskExecutor ====
 Sends warning notification after password expires. Notification is **not send to disabled identities**. Default notification topic is configured to email sender. Sends warning notification after password expires. Notification is **not send to disabled identities**. Default notification topic is configured to email sender.
 +
 +<note tip>Task is scheduled by default on the start of day: ** 0 5 0 ? * * ** - passwords which expired yesterday will be processed and proper notification will be send.</note>
  
 ==== AccountProtectionExpirationTaskExecutor ==== ==== AccountProtectionExpirationTaskExecutor ====
Line 193: Line 213:
   * ``System`` - Delete operations with given system only.   * ``System`` - Delete operations with given system only.
   * ``Empty provisioning`` - Delete provisioning operations only without attributes. Operation with DELETE type is not considered as empty (even haven't attributes).   * ``Empty provisioning`` - Delete provisioning operations only without attributes. Operation with DELETE type is not considered as empty (even haven't attributes).
 +
 +<code sql>
 +-- PostgreSql
 +-- Delete archives
 +DELETE FROM sys_provisioning_archive WHERE created < now() - INTERVAL '90 day';
 +-- Delete attributes
 +DELETE FROM sys_provisioning_attribute attr WHERE NOT EXISTS (SELECT FROM sys_provisioning_archive arch where attr.provisioning_id = arch.id) AND NOT EXISTS (SELECT FROM sys_provisioning_operation oper where attr.provisioning_id = oper.id);
 +</code>
  
 ==== DeleteExecutedEventTaskExecutor ==== ==== DeleteExecutedEventTaskExecutor ====
Line 202: Line 230:
 === Parameters === === Parameters ===
   * ``Number of days`` - Delete events older than given number of days.   * ``Number of days`` - Delete events older than given number of days.
 +
 +<code sql>
 +-- PostgreSql
 +-- Delete events older then 3 days
 +delete from idm_entity_event where result_state='EXECUTED' AND created <= NOW() - INTERVAL '72 HOURS';
 +vacuum full idm_entity_event;
 +</code>
  
 ==== DeleteLongRunningTaskExecutor==== ==== DeleteLongRunningTaskExecutor====
Line 247: Line 282:
 -- Delete recipients -- Delete recipients
 DELETE FROM idm_notification_recipient WHERE notification_id NOT IN (SELECT id FROM idm_notification); DELETE FROM idm_notification_recipient WHERE notification_id NOT IN (SELECT id FROM idm_notification);
 +</code>
 +
 +==== DeleteSynchronizationLogTaskExecutor ====
 +
 +@since 9.7.12
 +
 +Delete synchronization logs.
 +
 +=== Parameters ===
 +  * ``Number of days`` - Delete synchronization logsolder than given number of days.
 +  * ``System`` - Delete logs on the given system only.
 +
 +<code sql>
 +-- PostgreSql
 +-- Delete logs
 +DELETE FROM sys_sync_log WHERE created < now() - INTERVAL '180 day';
 +-- Delete actions
 +DELETE FROM sys_sync_action_log WHERE sync_log_id NOT IN (SELECT id FROM sys_sync_log);
 +-- Delete items
 +DELETE FROM sys_sync_item_log WHERE sync_action_log_id NOT IN (SELECT id FROM sys_sync_action_log);
 </code> </code>
  
Line 259: Line 314:
   * ``Workflow definition`` - Delete historic workflow processes with this definition only.   * ``Workflow definition`` - Delete historic workflow processes with this definition only.
  
 +==== VsSystemGeneratorTaskExecutor ====
 +
 +@since 10.4.0
 +
 +Task generates given number of virtual systems, roles and identities. All generated entities are evenly distributed among themselves. I.e. Roles assigned to users and connected to generated systems. Task serves for generating required scenario and following performance test.
 +
 +=== Parameters ===
 +  * ``Item prefix`` - A name prefix of all generated entities. Serves for easier searching of entities in IdM.
 +  * ``System count`` - Number of generated virtual systems.
 +  * ``Role count`` - Number of generated roles.
 +  * ``User count`` - Number of generated identities.
  
 ===== Testing tips ===== ===== Testing tips =====
Line 274: Line 340:
  
   * Support for the check of the competition of the running tasks. Now it is on the task implementation to check if it should be run or not. This could be extracted to the general.   * Support for the check of the competition of the running tasks. Now it is on the task implementation to check if it should be run or not. This could be extracted to the general.
-  * Immediate task running is carried out through the scheduler - a simple trigger - it could be carried out directly through the service [[https://github.com/bcvsolutions/CzechIdMng/blob/develop/Realization/backend/core/core-api/src/main/java/eu/bcvsolutions/idm/core/scheduler/api/service/LongRunningTaskManager.java|LongRunningTaskManager]] +  * Display of the scheduled triggers in the detail of the scheduled job. 
-  * Display of the scheduled triggers in the detail of the scheduled job+  * Recover canceled task by server is restarted automatically.
  • by apeterova