Job Life Cycle Statuses

The diagram below shows the possible statuses during the life cycle of a job. These are returned by the action executor as the workflow progresses:


JEF executors set this status to appear when the action configuration instance is processed by the action executor.


{"executionId":"624","workflowId":null,"progress":25,"message":"In Progress","status":"RUNNING"}`


When the execute method completes, it returns an instance of the ActionExecutorResponse and Dalet Flex either progresses to the next stage in the workflow, or finishes the workflow.

In the response, you can set any of the following fields:

  • result: this is a message that shows in the Recent Activity panel in the Dalet Flex user interface. You can customise the message if required.
  • executionId: This is an identifier for the job. This enables you to retrieve information about the job at later stages.
  • jobContextVariables: This contains a map of key values which are reflected under the Variables tab in the Dalet Flex user interface. These are passed to the next stage of the workflow.
  • workflowContextVariables: This is essentially the same as the jobContextVariables, however it overrides the workflow context.

When the action executor has finished processing, the status is automatically updated to “Completed”.




If an unhandled exception is thrown within the ActionExecutor.execute method, the job and/or workflow that instances the job will fail. Job and workflow failures can be seen in the Recent Activity panel in the Dalet Flex user interface.




If the request has been handled, but it has not started yet, it will be in a QUEUED state. Jobs are put in a QUEUED state from the point they are delivered from Enterprise, until the execute class starts execution.




This status is displayed if a cancellation occurs. A cancellation can occur if a job is cancelled by the job, workflow, or by the underlying services. This is internally managed by JEF, and so, no action is required by the developer.



Timed Out

Async executors can see jobs timing out. Jobs that are running in async executors are watchers for notification updates. If long running do not update, they are marked as TIMED_OUT by the watchers or upon restarting the service. This is reported to Enterprise but the job will not be in a FAILED state.

Waiting For Lock

JEF requests are processed internally (through the Job Engine service) for available locks if SHARED or EXCLUSIVE locks are required. If a lock is not available (because another job is currently using it in Enterprise or a JEF execution), the job remains in a WAITING_FOR_LOCK state until the required job is available and the execution can proceed further.