Netflix / conductor

Conductor is a microservices orchestration engine.
Apache License 2.0
12.82k stars 2.34k forks source link

Suggestion: Publishing conductor-spi module #1953

Open rmohta opened 4 years ago

rmohta commented 4 years ago

Extending Conductor per https://netflix.github.io/conductor/extend/ page means we have to import the Conductor code and then build on top of that. Even though Conductor is quite extensible, this approach would not be maintainable when trying to bring conductor within an Enterprise World.

I would suggest we publish a Maven Jar (conductor-spi or similar) with required interfaces to be implemented or classes to be extended. Then it becomes easier to separate out OSS code and Enterprise functionality code. Allows us to keep up with latest changes in upstream.

apanicker-nflx commented 3 years ago

@rmohta Thanks for the suggestion. We are currently working on Conductor 3.0 within which we will be introducing the SpringBoot framework to Conductor. Once we achieve full feature parity in this effort, we will look into the extensibility story and making it easier to integrate. We hope to release the early beta version of Conductor 3.0 within the next few weeks.

rmohta commented 3 years ago

@apanicker-nflx Do you have planned roadmap for Conductor 3.0? Interested in trying it out

apanicker-nflx commented 3 years ago

@rmohta The early 3.0 version is being implemented in this branch. As can be seen, it is currently a port over from the Guice based project to the SpringBoot version. This is under active development and we will continue to make changes/tweaks in this branch until it is ready to published.

flavioschuindt commented 3 years ago

As suggestion for 2.X of conductor, you actually don't need to import conductor code per say. One approach is to create a external jar that implement any interface of conductor described in the docs and inject this as a bean using Guice. Once implemented, you change the classpath to make conductor load your external jar inside its own JVM. One example for a custom listener implementation that I did that extends the WorkflowStatusListener interface describe in the docs:

package com.test.listener;

import com.netflix.conductor.common.run.Workflow;
import com.netflix.conductor.core.execution.WorkflowStatusListener;
import lombok.extern.slf4j.Slf4j;

@Slf4j
public class WorkflowCompletionListener implements WorkflowStatusListener {
    @Override
    public void onWorkflowCompleted(Workflow workflow) {
        log.info("Workflow {} is completed!", workflow.getWorkflowId());
    }

    @Override
    public void onWorkflowTerminated(Workflow workflow) {
        log.info("Workflow {} is terminated!", workflow.getWorkflowId());
    }
}
package com.test.module;

import com.test.listener.WorkflowCompletionListener;
import com.google.inject.AbstractModule;
import com.netflix.conductor.core.execution.WorkflowStatusListener;

public class WorkflowCompletionModule extends AbstractModule {
    @Override
    protected void configure() {
        bind(WorkflowStatusListener.class).to(WorkflowCompletionListener.class);
    }
}

Then you do:

Note that in the above code there are some conductor imports. They are already being published in a regular basis here. In this particular example, I am using the core.

As I said, this worked fine for the Listener interface and I would assume it would work fine as well for any other interface that the docs asks you to implement. Hope this helps.