• Services
  • Migration Topics
  • Integration
  • Concepts
    • Automation Task Lifecycle
    • Identity and Access Management in HIRO 6
  • Best Practices
  • Api

Task States

Automation in HIRO™ is task-centric. Therefore, Automation Tasks are the central data objects to trigger the HIRO™ Engine. Automation Tasks have a lifecycle - they are created, processed and finally either succeed or fail. The following diagram illustrates the state machine of Automation Task status.

Task State Diagram
Figure 1. Task State Diagram

The black lines indicate transitions performed by the Engine, whereas:

  • some transitions will be triggered only be Engine’s internal task handling

  • some transitions can be triggered by special KI language commands

The transitions marked in red may be performed from the outside, i.e. by connectors or other applications.

NEW

New task which is ready to be processed by the HIRO™ Engine

For compatibility reasons a missing status value is interpreted as NEW

PROCESSING

Engine is currently working on this task to resolve it.

RESOLVED

Task processing has finished successfully. Technically that means: through application of KIs all ToDo variables have been deleted.

This is a final state.

WAITING

Task processing was suspended to wait for some external event (e.g. user approval). A task in that state must be set back to PROCESSING from the outside (by the controlling connector or other application).

STOPPED

Task processing has been stopped. In most cases this status means the Engine ran out of applicable knowledge.

This is a final state.

TERMINATED

Task processing has been forcefully terminated. This could be triggered internally by some error conditions (see below) or externally (e.g. Connector/CLI).

This is a final state.

Typical state transitions triggered by the HIRO™ Engine

From state To state Trigger

NEW

PROCESSING

successfully loaded task for processing

PROCESSING

RESOLVED

no remaining todo variable in task

PROCESSING

WAITING

KI command eject_issue

PROCESSING

STOPPED

KI command stop_issue

NEW / PROCESSING

TERMINATED

Processing node does not exist or is not accessible

The Engine writes the reason of a status change into the ogit/Automation/deployStatus attribute. You might want to check this attribute to understand e.g. why tasks have been terminated.

Which status changes can be triggered externally?

The transitions listed below are allowed to be triggered by connectors or other applications:

From state To state Trigger/Reason

PROCESSING

TERMINATED

External application (e.g. connector) decides then Engine should not process that task anymore.

WAITING

TERMINATED

External application (e.g. connector) decides then Engine should not process that task anymore

PROCESSING

WAITING

External application decides that Engine should (temporarily) pause processing that task (e.g. waiting for a user approval)

WAITING

PROCESSING

External application decides that a task processing can now continue

Relation to Knowledge Acquisition

When a task status is STOPPED, this means that there was not sufficient knowledge to solve it. That’s why any task being in status STOPPED is a candidate for a new knowledge acquisition session, and will be listed in the Task List in HIRO™. The responsible Subject Matter Expert should teach the system how this task can be solved the next time.