ee.telekom.workflow.api

Interface WorkflowDefinition

public interface WorkflowDefinition

The workflow engine is built for running long-lived business processes. The execution logic for these business processes (or process parts) is defined via workflow definitions. You need to write and deploy a workflow definition for every business process (or multiple definitions, if you want to split the process into subprocesses/steps) that you want to run on the workflow engine.

A workflow definition is a plain Java class which implements the WorkflowDefinition interface and uses the WorkflowFactory DSL API to define the process execution logic. There is no visual drag and drop process view, there is no BPMN.

In addition to a execution logic description, a workflow definition also has a human readable name and a version number. When a new workflow instance (one execution of this business process) is created, it starts with the specified (or latest) version number. This workflow instance will live it's entire life on this version number. If you make changes into the workflow definition that don't break the backward compatibility, then you may keep the same version number and this workflow instance will start using the new definition after the next deployment. But if you make changes that break the backward compatibility, you need to increase the version number, and then the instance won't automatically migrate to the new definition. This also means that you must keep the workflow definition previous versions present for as long as there are running instances on these previous versions (when you increase the workflow definition version from 1 to 2, you must keep the old java file with version 1 and add a new java file with version 2).

The workflow definitions are meant to be kept in your implementation projects (far away from the engine implementation repository, to provide a clear distinction between the platform and the actual workflow business logic code) together with your service layer beans and plugins/event listeners. The workflow definitions must be defined as Spring beans in your implementation project's app context (@Component).

The workflow engine converts your definition into internal graph format and stores the result in the internal repository. The engine then provides you with different interfaces (web console, REST services, engine facade) to start a new workflow instance and to interact with existing instances.

Author:

Erko Hansar

See Also:

WorkflowFactory

Method Summary

Modifier and Type	Method and Description
void	configureWorkflowDefinition(WorkflowFactory factory) This method will be called once per run-time when initializing the workflow definitions for the implementing classes.
default boolean	getKeepHistory() Return keep history boolean value (default value true) for the current workflow definition.
String	getName() Return a human readable name for this workflow definition.
int	getVersion() Return a version number for the current workflow definition.

Method Detail

getName

String getName()

Return a human readable name for this workflow definition.

Returns:

a human readable name for this workflow definition

getVersion

int getVersion()

Return a version number for the current workflow definition.

Used when starting a new workflow instance. This workflow instance will live it's entire life on this version number. If you make changes that don't break the backward compatibility, then you may keep the same version number and this workflow instance will start using the new definition after the next deployment. But if you make changes that break the backward compatibility, you need to increase the version number, and then the instance won't automatically migrate to the new definition.

Returns:

a version number for the current workflow definition

configureWorkflowDefinition

void configureWorkflowDefinition(WorkflowFactory factory)

This method will be called once per run-time when initializing the workflow definitions for the implementing classes.

Use the given factory like this:

 public void configureWorkflowDefinition( WorkflowFactory factory ){
     \/* @formatter:off *\/
     factory
         .start()
         .call( 1, "helloWorldService", "sendHelloToCustomer", "${customerId}" )
         .end();
     \/* @formatter:on *\/
 }
 

Parameters:

factory - factory provides the DSL API for constructing the workflow definition and is later used by the engine to convert the

getKeepHistory

default boolean getKeepHistory()

Return keep history boolean value (default value true) for the current workflow definition.

Value false is used for extremely long running workflows when history information in workflow_instances state and history field is growing too large. When value is false then work_items with COMPLETED or CANCELLED status will be deleted. For workflow_instances state field only active token will be kept in that field. For workflow_instances history field, only last completed, abort or aborted event will be kept in that field.

Returns:

true if workflow should keep history, false if not