Hyperion – Section 3 – Workflow Definitions and Instances

Workflow definitions and workflow instances are similar concepts. Workflow definition is the design-time concept of an workflow, which is represented as a class. A workflow instance is a run-time concept, which is an object of the workflow definition class.

A class tagged with “Workflow” annotation is recognized as a workflow definition, which contains all transitions related to this workflow. The “Workflow” annotation contains the following attributes:

  • id – A unique GUID. Workflow definitions must have different GUIDs. This is verified by the Hyperion workflow engine on startup.
  • name – The name of workflow. If set to null, the name will be by default set to the short name of the workflow definition class. It is strongly recommended that every workflow definition should have an explict name. Workflow definition names do not need to be unique but having the same name will add ambiguity.
  • initialState – A workflow state class which will be set as the initial state of the workflow instance.
  • contextType – The class of the workflow context that will be used for this workflow definition
  • Workflow definitions can inherit from its base class, to derive all transitions defined in its parent. While the workflow definition will not derive the definition metadata of its parent. i.e. the derived workflow needs to have its own “Workflow” annotation tagged.

    @Workflow(id = "db70d05e-05d3-411a-8fda-f21306ae5608", initialState = Start.class, name = "BaseWorkflow")
    public class BaseWorkflow {
    }
    
    @Workflow(id = "f3ed3707-1a50-481c-9527-a4af5601ee4f", initialState = Start.class, name = "DerivedWorkflow")
    public class DerivedWorkflow {
    }
    

    Hyperion is designed as a state workflow engine, and therefore needs to persist workflow instances, as a workflow instance may take a number of transitions to go through the entire lifecycle from the initial state to the completed state, and the time span could be days, months or even longer. There are two things that need to be persisted in the workflow instance:

  • The workflow states
  • As Hyperion supports multiple workflow states on a single workflow instance at any given time, the workflow state of a workflow instance is in fact a workflow state set, which contains multiple workflow states. The workflow state set will be persisted to database when the workflow instance is persisted.

  • The workflow context
  • The workflow context is used to store custom information of the workflow instance. At design-time, a workflow context is a class the derives “WorkflowContext” class; at run-time, the workflow context is an instance of the workflow context class. Each workflow definition can specify its own workflow context class in the “contextType” attribute in “Workflow” annotation. The default workflow context type is “WorkflowContext”, which contains a string to object map. If the workflow does not require intensive data during the whole lifecycle, it can simply use the map to store the information. Workflow context will be persisted to database by serialization. There are two types of serializer supported in Hyperion, the binary serializer and the XML serializer. Binary serializer has better performance, but require all objects in the workflow context instance are binary serializable. XML serializer is using XStream library to do the serialization, it provides better readibility if directly viewed in database.

    Leave a Reply

    Your email address will not be published. Required fields are marked *