Sending Signals to Workflows in Orkes Conductor

Conductor is a powerful platform that lets you build event-driven distributed applications. These applications often have long-running processes that must be managed through external signals during their life cycle. For example, an e-commerce backend could not clear payments due to issues with the payment system. However, Conductor workflows are self-healing; they will do automated retries until they exhaust all the retries. So how do you retry those failed workflows after the payment system has been restored after a long outage?

Another example is a subscription system that runs a loop {wait for 30 days and then charge the credit card}. This is a long-running workflow that keeps running in the loop until the duration of the subscription. How do you “cancel” the workflow if the user decides to cancel the subscription?

Conductor lets you interact with the running workflow processes by sending “signals” - these signals effectively interact with the running workflow and change its state.

This blog delves into the various scenarios where signals are sent to a running workflow execution and how you can utilize a platform like Orkes Conductor for controlling workflow executions in real time. Orkes Conductor is an orchestration platform that simplifies workflows, microservices, and events, built over the battle-tested Netflix Conductor. Whether it's handling unpredictable scenarios, orchestrating microservices efficiently, or responding to external events, Orkes Conductor is your reliable ally in conquering the challenges of modern workflow orchestration.

Executing Workflows

To understand the concept of sending signals to a workflow, let’s assume you are running an e-commerce application and want to send signals to control its executions.

You may want to send signals to temporarily halt or restart processes, attempt retries in case of failures, or ultimately end specific procedures. This adaptability empowers you to smoothly align your app with changing business demands.

Initially, let's look at how to run an application using Conductor. The app/workflow can be executed in different ways, such as using API, SDKs, or from Conductor UI.

Let’s see a sample workflow for an e-commerce app:

In Orkes Conductor, you can execute this workflow using the following API, utilizing tools like Swagger:

POST /api/workflow/{name}

On making this API call, you receive a string representing the ID of the workflow execution as the response. You can monitor the workflow execution from the Workflow Executions page from your Conductor UI.

Let’s see how you can run the same workflow in different languages. Whether your preference is Java, Python, or Golang, we’ve got you covered.

Here’s how to implement in different SDKs:

String startWorkflow(StartWorkflowRequest startWorkflowRequest)

Alternatively, for the testing, you can also start a workflow from the Conductor UI.

From your Conductor console, navigate to the Run Workflow option from the left menu, and choose your workflow under the field Workflow Name. You can also select the workflow version, provide the input parameters, optionally, correlation ID, and task to domain mapping.

Run the workflow, and the workflow (execution) ID will be generated, clicking on which you can view the execution.

So, now your workflow is up and running, and you need to send signals to control the execution as per your business needs.

Pausing a Workflow for Evaluation and Resuming Later

Imagine you need to halt your e-commerce app for a manual inventory check temporarily and then proceed with the workflow after confirming that the product is available in the warehouse. The workflow will be put on hold in this scenario until the inventory check is completed.

Pausing Workflows

You can use the following API to pause your running workflow, where the workflow (execution) ID is to be supplied as the input payload.

PUT /workflow/{workflowId}/pause

You can also utilize the SDKs for pausing your workflows. Here are code samples in various languages.

BulkResponse pauseWorkflow(List<String> workflowIds) throws ApiException

Now, let’s see how you can pause your workflow execution from Conductor UI.

From your workflow execution page, click Actions > Pause.

It pauses your workflow temporarily until the inventory check is completed.

Next, you must resume the workflow once the inventory check is completed, assuming the item is available for proceeding with the workflow.

Resuming Workflows

You can leverage the following API, providing the workflow (execution) ID as the input payload:

PUT /workflow/{workflowId}/resume

And here are the SDKs for resuming your workflows in different languages.

BulkResponse resumeWorkflow(List<String> workflowIds) throws ApiException

So, let’s see how to resume the workflow execution from Conductor UI now. From the workflow execution page, click Actions > Resume.

The workflow is now resumed and moves to the next step to get completed.

Updating a Task Status in a Workflow

Let’s explore a situation where order processing is hindered by a technical glitch in your inventory system, preventing the availability update. In such scenarios, to complete the order processing, you can manually indicate that the inventory check is completed until a permanent fix is implemented.

The following API can be used to update task status manually. You must provide the workflow (execution) ID, the task reference name to be updated manually, and the task status. In this case, the status can be set to “COMPLETED”.

POST /tasks/{workflowId}/{taskRefName}/{status}

And here are the SDKs for updating task status in different languages.

String OrkesTaskClient.updateTaskByRefName(Map<String, Object> output, String workflowId, String taskRefName, String status) throws ApiException

You can also mark the task as completed from the Conductor UI. For this, navigate to the workflow execution and click on the task. Next, from the task summary, select the status as Completed under the field Update task.

This standardized approach to manually completing tasks provides a practical solution to handle temporary glitches and ensure seamless order processing.

Retrying Failed Workflows

Let’s continue with our e-commerce app scenario. After the inventory check, the workflow progresses to the payment task. Suppose the payment fails due to a network error; you can retry your workflow from failed tasks so that the end users are provided with an option to retry the payment.

You can leverage the following API to retry the workflow from the failed task. While invoking the API, provide the workflow (execution) ID of your running workflow as the input parameter.

POST /workflow/{workflowId}/retry

If you wanna try out in different languages, use the following SDKs.

BulkResponse retryWorkflow(List<String> workflowIds) throws ApiException

Now, if you are looking forward to retrying from Conductor UI, here you go:

From your execution page, go to Actions > Retry from failed task.

This action restarts the workflow from the point of failure, allowing users to retry the payment process. This standardized approach to retrying failed workflows enhances the resilience of your e-commerce app, ensuring a smoother experience for your users.

Skipping a Task from Workflow Execution

Let’s say you are gifting your customer with a digital reward card. In such cases, the shipping task is not required, as these details can be included in the notification email sent during the final step. In such situations, you can skip the shipping task from execution.

Use the following API to skip a task from workflow execution. You need to provide the workflow (execution) ID and the task reference name of the task to be skipped as the input parameters.

PUT /workflow/{workflowId}/skiptask/{taskReferenceName}

You can also utilize the following SDKs if you are implementing your application in different languages:

void skipTaskFromWorkflow(String workflowId, String taskReferenceName)

In the Conductor UI, a skipped task looks like this:

With the shipping task skipped, the workflow will be completed once users are notified through email, aligning with the modified workflow logic.

Terminating a Running Workflow

Imagine a scenario where a clearance sale unexpectedly attracts a massive surge of users and traffic, depleting the inventory to the point where no stock is left for sale. In such a situation, when the primary goal of the clearance sale has been achieved, it becomes essential to terminate the ongoing workflow temporarily.

Using the generated workflow (execution) ID, you can terminate the currently running workflow using the following API.

DELETE /workflow/{workflowId}

You also have the option to utilize the SDKs for terminating workflows in different programming languages.

void terminateWorkflow(String workflowId, String reason)

If you prefer to terminate a workflow via UI, navigate to Actions > Terminate.

This instantly terminates your workflow.

These methods allow you to exert control over your workflow execution within an e-commerce application, ensuring that you can adapt and manage your processes effectively, even in unexpected circumstances.

Here’s a video guide summarizing the topic:

In a nutshell, you can send signals to control your live workflow executions similarly.

Orkes Conductor, from the creators of the Netflix Conductor, is the cloud version of the Netflix Conductor, now accessible on major cloud platforms such as Azure, AWS & GCP.

If you’re an enterprise seeking an ideal orchestration platform, you've arrived at the right place! Check out the full set of features, try it yourself using our Developer Edition sandbox, or get a demo of Orkes Cloud, a fully managed and hosted Conductor service.

For any queries or assistance, feel free to reach out to our Slack Community!