Backend

Conductor provides a pluggable backend. The current implementation uses Dynomite.

There are 4 interfaces that needs to be implemented for each backend:

//Store for workflow and task definitions
com.netflix.conductor.dao.MetadataDAO
//Store for workflow executions
com.netflix.conductor.dao.ExecutionDAO
//Index for workflow executions
com.netflix.conductor.dao.IndexDAO
//Queue provider for tasks
com.netflix.conductor.dao.QueueDAO

It is possible to mix and match different implementations for each of these.
For example, SQS for queueing and a relational store for others.

System Tasks

To create system tasks follow the steps below:

  • Extend com.netflix.conductor.core.execution.tasks.WorkflowSystemTask
  • Instantiate the new class as part of the startup (eager singleton)
  • Implement the TaskMapper interface
  • Add this implementation to the map identified by TaskMappers

External Payload Storage

To configure conductor to externalize the storage of large payloads:

  • Implement the ExternalPayloadStorage interface.
  • Add the storage option to the enum here.
  • Set this JVM system property workflow.external.payload.storage to the value of the enum element added above.
  • Add a binding similar to this.

Workflow Status Listener

To provide a notification mechanism upon completion/termination of workflows:

  • Implement the WorkflowStatusListener interface
  • This can be configured to plugin custom notification/eventing upon workflows reaching a terminal state.

Locking Service

By default, Conductor Server module loads Zookeeper lock module. If you'd like to provide your own locking implementation module, for eg., with Dynomite and Redlock:

  • Implement Lock interface.
  • Add a binding similar to this
  • Enable locking service: decider.locking.enabled: true