Skip to content

Extending Conductor

Backend

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
com.swiftconductor.conductor.dao.MetadataDAO

//Store for workflow executions
com.swiftconductor.conductor.dao.ExecutionDAO

//Index for workflow executions
com.swiftconductor.conductor.dao.IndexDAO

//Queue provider for tasks
com.swiftconductor.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.swiftconductor.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: conductor.app.workflowExecutionLockEnabled: true

Event Handling

Provide the implementation of EventQueueProvider.

E.g. SQS Queue Provider: SQSEventQueueProvider.java