Tasks scheduler scheduler

Tasks started by CRON in maven profile DEV was started only once for 3600000ms. This configuration is set by property: scheduler.task.queue.process in application-dev.properties. Server restart is needed! This property can not be overloaded by FE configuration agenda.

Configuration of QUARTZ (scheduler) it is using application properties by individual profiles. In every profile application properties is necessary set path for queart's settings (his own application properties) - scheduler.properties.location. Change property scheduler.task.queue.process needed server restart! This property can not be overloaded by FE configuration agenda.

Example of an implementing task - you will find everything that has been mentioned here.

Stateful task executors are an extension of standard long running task executor, which hold a state and processed items log. Such functionality is suitable for tasks, which has to keep historical records of processed items.

The key concepts of stateful executors are queue and log. The queue is a set of records that have been processed, but the information about them is required for next run of the task. Take contract enable task as an example. Once a contract is valid, the task should process it. But it must be processed only once, not every time the task is run and the contract is valid. Therefore until the contract is valid, it is kept in the queue and will not be processed again. The log is a mechanism to keep track of what kind of items were processed by the task and what was the processing result.

Stateful tasks are tightly coupled with Quartz' scheduled tasks, that is the tasks that are run multiple times. Running a stateful task from code as a simple LongRunningExecutor is pointless, because there is no reason to keep neither history nor processed items queue. The relation to Quartz is realized through IdmScheduledTask entity, which holds Quartz job's unique job key. The task queue then references the IdmScheduledTask. Original IdmLongRunningTask entity is the owner of the log items. Log items are related to each task run, which is done by the mentioned entity.

All stateful tasks shall implement the SchedulableStatefulExecutor. Its abstract implementation AbstractSchedulableStatefulExecutor, which can be viewed as a template method for task execution, hold most of the common logic. The intent is to always extend the AbstractSchedulableStatefulExecutor and define the getItemsToProcess and processItem method by concrete task. Therefore the developer should mostly focus only on retrieving items and the business logic, which does the processing.

The item processing result is represented by OperationResult. Successful operations are inserted both into the queue and log, all results go to the log.

After the item processing finishes, the queue is refreshed. The algorithm is simple, as it only removes all items from queue, which were not processed in current run.

Implemented long running task are listed bellow. Non schedulable long running tasks are included.

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 after password expires. Notification is not send to disabled identities. Default notification topic is configured to email sender.

Removes accounts with expired protection interval. Account has to have inProtection flag setted to true.

Retry failed provisioning operation periodically. When provisioning operation fails, then is logged into provisioning queue with result (state, exception, result code etc.) and new attempt time. Number of attempts is 6 and time between attempts grown exponentially (configuration comming soon).

Long running task for execute script by code. Script can increment and initialize counter.

Long running task for remove old logging event, logging event exception and logging event property. Parameter remove old logs than (days).

• days - removes logs older than given days count.

Process provisioning operations in queue periodically. This LRT executes prepared (created) requests for provisioning, when target system is switched do use asynchronous provisioning.

• virtualSystem, values:
  • true - processes created operations from queue for virtual system only,
  • false - processes created operations from queue for non virtual system only,
  • null - if virtualSystem parameters is not configured, then processes created operations from queue for all systems.

Schedule synchronization.

• Synchronization uuid - synchronization configuration to schedule.

Long running task for add newly added automatic role to users. Can be executed repetitively to assign role to unprocessed identities, after process was stopped or interrupted (e.g. by server restart).

• roleTreeNode - automatic role identifier.

Long running task for remove automatic roles from identities.

• roleTreeNode - automatic role identifier.

@since 9.0.0

Long running task for add newly added role composition to users. Sub roles defined by this composition will be assigned to identities having superior role. Can be executed repetitively to assign unprocessed roles to identities, after process was stopped or interrupted (e.g. by server restart).

• role-composition-id - role composition identifier.

@since 9.0.0

Long running task for remove assigned roles by given composition from identities.

• role-composition-id - role composition identifier.

Remove roles by expired identity contracts (⇒ removes assigned roles).

Long running task for expired identity roles removal. Expected usage is in cooperation with CronTaskTrigger, running once a day after midnight.

When role was created with validity in future, then this executor publish even, when role starts to be valid. This is needed specially for account management, when new account for roles that was newly valid has to be created.

@since 7.5.1

HR process - enable identity's contract process. The processes is started for contracts that are both valid (meaning validFrom and validTill) and enabled. This LRT should be configured even event processors for HR processes are enabled - this process depends on current date ⇒ event processors cannot work this way. Event processors checks active changes on given contract.

@since 7.5.1

HR process - identity's contract exclusion. The processes is started for contracts that are both valid (meaning validFrom and validTill) and excluded. This LRT is optional with event processors for HR processes. One of LRT or processors should be enabled / scheduled. If LRT is scheduled and processors are enabled, then this LRT just checks, if everything is done (contract is already excluded by processor).

@since 7.5.1

HR process - end of identity's contract process. The processes is started for contracts that are not valid (meaning validFrom and validTill). This LRT is optional with event processors for HR processes and IdentityContractExpirationTaskExecutor. One of this LRT or processors with IdentityContractExpirationTaskExecutor should be enabled / scheduled. If this LRT is scheduled and processors with IdentityContractExpirationTaskExecutor are enabled / scheduled, then this LRT just checks, if everything is done (contract is already expired by processor or IdentityContractExpirationTaskExecutor).

@since 8.1.0

Recalculate current using slices as contract. Find all slices which should be for actual date using as contract and copy their values to parent contracts.

@since 8.2.0

Change key for crypt confidential storage. Taks can be started after you change key in application properties/file to newer. As parameter will be given old key.

Integration tests are the preferred way of testing stateful executors in combination with stubbing the returned set of items to process by Mockito, using a 'spy' on the executor. This way the developer has full control over the task and can test both processing and items retrieval independently. List through the existing test cases for details.

Module core has default implementation of AbstractScheduledTaskInitializer - InitCoreScheduledTask. This class is responsible for initializing default scheduled task. See IdmCoreScheduledTasks.xml for xml structure.

For another module is necessary implement subclass of AbstractScheduledTaskInitializer.

• 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 LongRunningTaskManager
• Display of the scheduled triggers in the detail of the scheduled job