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 [2020/02/19 12:52]
tomiskar [Future development]
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 final}}+{{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 203: Line 219:
 DELETE FROM sys_provisioning_archive WHERE created < now() - INTERVAL '90 day'; DELETE FROM sys_provisioning_archive WHERE created < now() - INTERVAL '90 day';
 -- Delete attributes -- Delete attributes
-DELETE FROM sys_provisioning_attribute WHERE provisioning_id NOT IN (SELECT id FROM sys_provisioning_archive) AND provisioning_id NOT IN (SELECT id FROM sys_provisioning_operation);+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> </code>
  
Line 214: 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 291: 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 =====
  • by apeterova