Introduction
Each task is stored in the table either in the taskscheduler_task_definition table or in distributed in-memory data storage (Redis), depending on the system configuration. Each entry has various properties that define the behaviour of the task.
Properties
Property | Description |
|---|---|
| A task could have a parent task. Once the parent task has finished executing, it will trigger any child tasks. |
| What kind of task it is. The value saved here is the full path of the class in which the task is implemented, followed by the assembly name in which this class is saved. |
| The very first run date this task was executed for the first time. Usually this refers to the date when the task was added. |
| The interval in seconds when tasks are executed. Note: This does not mean the time it should wait between each task run. The interval counter starts as soon as the task is getting executed. If the task is taking longer than the configured interval, it will start immediately again. Example: Interval is set to 10 minutes. The task takes 5 minutes to complete. The next run will start in 5 Minutes. |
| The state in which the task is currently in. The most common ones are: Note: When you change a task from state 3 (running) to another state, the underlying execution of the task will not be stopped. See further information below. |
| The last completion time of the task, which means it got to state 4 (completed) or 5 (faulted/error) after running. |
| The machine name on which the task got executed last. This information is needed for running tasks on multiple machines/backends. Delete this field if you want to run the task on your current machine and you imported the task definitions from somewhere else. |
| How long it did take for the task to complete the last time it reached state 4 or 5. |
| This field gets filled once the task has completed. Normally this is just “Finished” but this could also be with more information on what the task did. This field is also used if there were any errors during the execution. |
| What kind of action should take place when the task was aborted (e.g. through a new start of the service)? 1: do nothing 2: restart the task automatically 3: delayed by 10 minutes |
| What kind of action should take place when the task encountered errors during execution? 1: do nothing 2: restart the task automatically 3: delayed by 10 minutes |
| Defines if the task is editable in the GUI. 1 = readonly 0 = editable in the GUI |
| Decides if the task should be visible in the task list on the GUI. 1 = visible 0 = hidden |
| Defines when the task definition entry was created. Useful mostly for scheduled or fast tracked tasks |
| ID of the tenant to which the task belongs to |
| The core identity id under which the task is executed under |
| This active flag defines if the task will run. 1 = active 0 = inactive |
| Here it is defined in which state the task is considered finished. Usually this is state 4 (Completed) |
| A string which identifies this task instance. Is mainly used in workflows for scheduled tasks, so it can get referenced again, for example for deleting the task |
| If this is set to 1, then the task gets deleted if it reaches the finished_state id. Fast track tasks are usually cleanup_enabled, so they get deleted if task completes. |
| Defines a time when a suspended task should run the next time |
| A serialized value of the object for further information |
| A string value for setting the name of the task. Useful for identitfying different task, for example for import tasks |
| A string value for setting a description of the task for a more detailed specification |
Fast track tasks
Various tasks will be fast tracked from within the CoreOne Application Service. This means, that the task will not be persisted to the database or the distributed in-memory data structure, but are executed directly in memory. In this case, you will not find an entry in the task table or anywhere else.