Skip to main content

Creating Task Definitions

Task definitions register tasks in Conductor. This API is used to create task definitions in Orkes Conductor.

Input Payload​

ParameterDescription
nameA unique identifier for the task. This field is mandatory.
descriptionA brief description of the task. This field is optional.
retryCountThe number of retries to attempt when a task fails. The default value is 3.
retryDelaySecondsThe time (in seconds) to wait before each retry occurs. The default value is 60.
retryLogicThe policy that determines when to schedule each retry. Supported values: It can take the following values:
  • FIXED - Reschedules the task after the given duration=retryDelaySeconds.
  • LINEAR_BACKOFF - Reschedules occur with a delay that increases linearly based on the backoff scale factor and attempt number=retryDelaySeconds x backoffScaleFactor x attemptNumber.
  • EXPONENTIAL_BACKOFF - Reschedules the task after the given duration=retryDelaySeconds x (backoffScaleFactor ^ attemptNumber).
backOffScaleFactorThe value to be multiplied with retryDelaySeconds in order to determine the interval for retry.
rateLimitPerFrequencyThe maximum number of task executions that can be scheduled in a given duration.
rateLimitFrequencyInSecondsThe duration, in seconds, specified for the rate limit.

For example, let’s set rateLimitFrequencyInSeconds=5, and rateLimitPerFrequency=12. This means our frequency window is 5 seconds in duration, and for each frequency window, the Conductor would only give 12 tasks to workers. So, in a given minute, the Conductor would only give 12*(60/5) = 144 tasks to workers, irrespective of the number of workers polling for the task.
Unlike concurrentExecLimit, rate limiting doesn't consider the tasks already in progress or a terminal state. Even if all the previous tasks are executed within 1 sec or would take a few days, the new tasks are still given to workers at configured frequency, 144 tasks per minute in the above example.
concurrentExecLimitThe number of task executions that can be scheduled concurrently.

For example, if you have 1000 task executions waiting in the queue and 1000 workers polling this queue for tasks, but if you have set concurrentExecLimit to 10, only 10 tasks would be given to workers (which would lead to starvation). If any of the workers finish execution, a new task(s) will be removed from the queue while still keeping the current execution count to 10.
responseTimeoutSecondsTime (in seconds) to wait before rescheduling the task if its status is not updated within this period. The default value is 600.
timeOutSecondsTime (in seconds), after which the task is marked as TIMED_OUT if it has not reached a terminal state after transitioning to IN_PROGRESS status for the first time. No timeout occurs if the value is set to 0.
pollTimeoutSecondsTime (in seconds), after which the task is marked as TIMED_OUT if not polled by a worker. No timeout occurs if the value is set to 0.
timeoutPolicyThe policy for how the Conductor server should handle the timeout. Supported values:
  • RETRY - Retries the task again.
  • TIME_OUT_WF - The task is marked as TIMED_OUT and terminated, which also terminates the workflow as TIMED_OUT.
  • ALERT_ONLY - A counter is registered and an alert is sent. No further action is taken.
To create a task that never times out, set timeoutSeconds and pollTimeoutSeconds to 0.
enforceSchemaSet to true to enforce task inputs/outputs for all instances of the task. By default, the value is set to false.
inputSchemaIf enforceSchema is set to true, select a schema (and version) to be used as input schema for the task definition. Learn more about creating and using schema.
outputSchemaIf enforceSchema is set to true, select a schema (and version) to be used as output schema for the task definition. Learn more about creating and using schema.
inputTemplateInput templates are defined as part of task definitions. It acts as default input to the task while adding to the workflow. It can be overridden by values provided in workflow definitions.
Note: You cannot view the input templates in the workflow definition JSON as they are part of only task definitions. However, when clicking the task, you can view the input templates supplied from the UI.
inputKeysAn array of keys representing the expected input for the task.
outputKeysAn array of keys representing the expected output from the task.
ownerEmailThis field will be auto-populated with the user's email address.

API Endpoint​

POST /api/metadata/taskdefs

Client SDK Methods​

void OrkesMetadataClient.registerTaskDefs(List<TaskDef> taskDefs) throws ApiException