Skip to content

Extending Conductor


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

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

//Store for workflow and task definitions
//Store for workflow executions
//Index for workflow executions
//Queue provider for tasks

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
  • 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 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: true

Event Handling

Provide the implementation of EventQueueProvider.

E.g. SQS Queue Provider: