Skip to main content

Step 3: Adding Custom Code Worker

Continuing the use case from the previous step, we now have a requirement to add a fraud check for all deposit transactions >= $10,000.

  1. In your current definition, add a Switch task before the deposit task.
  2. Add a switch case for checking amounts >= 10000, and add a Worker task for the case with the name fraud-check.
  3. Run workflow.

We can see that when we run this workflow for amounts >= $10,000, it runs a fraud check. If we named the task fraud-check, we'd notice that it is actually executed (in playground env), but how? That's because there is a pre-defined task that is polling and running all the tasks named fraud-check. We also have the required permissions in the playground for this task.

So how can we implement this task for ourselves? First, let's rename the task to a new unique name for ourselves - for ex: fraud-check-<replace-with-a-unique-value>. And now, let’s see how this custom fraud check can be implemented:

View our documentation on Conductor Clients & SDKs list and how to import the required dependencies in our applications. Refer to the linked repositories in the code samples below to see how to implement the worker.

Complete source file on Github: ../workers/

* Note: Using this setting, up to 5 tasks will run in parallel, with tasks being polled every 200ms
@WorkerTask(value = "fraud-check", threadCount = 5, pollingInterval = 200)
public FraudCheckResult checkForFraudTask(DepositDetail depositDetail) {
return fraudCheckService.checkForFraud(depositDetail);

Once we have cloned the repo or copied the required elements to our local machines, we can run this locally by connecting to the playground server. To do this, we must give the required permissions to our application. Refer to this video to add permission to execute the custom worker we just created above (fraud-check-<replace-with-a-unique-value>). After providing the permissions, we can change the definition to run our worker (fraud-check-<replace-with-a-unique-value>) and start the application. We can see that now our worker is picking up the task.

This is the first example of how a distributed worker is executed in Conductor; without exposing an endpoint or creating any sort of inbound connectivity, we were able to execute the task directly from our local machine pointing to the playground server.

Distributed workers in Conductor

We can run similar workflows in production, too, workers could live in any applications or even third-party services and we can connect them all together using Conductor. All of this without worrying about creating inbound connections or exposing unwanted API endpoints.