Is that possible to send signal to a temporal workflow through REST api?

Community Support
1

Say we start the workflow in service A and at some point we’d like to block the workflow and only continue when we receive a signal from service B. Is that possible to do it through REST api instead of using client? Thanks!

3

I assume rest api is exposed from service B? It’s not uncommon to have rest api endpoints which use temporal sdk client apis to start / signal executions. If you provide more info on use case we could possibly give more details.

5

Hi @tihomir, thanks for your reply. I am still new to temporal and still evaluating the framework. I assume there should be a server hosting the workflow, and in this case it is service A. My use case is pretty generic, you start the whole workflow in one service, and call another service to do something asynchronously. Instead of polling service B for result, I’d like service B to send a signal to the workflow engine so the workflow could continue. Given I don’t want to introduce any temporal dependencies in service B so prefer to do a http call instead of using client sdk. Am I making sense here? ChatGPT advised that Temporal provides a REST API endpoint to send signals to running workflows, and you could do something like

POST /api/workflows/v1/{namespace}/{workflow-type}/{workflow-id}/signal/{signal-name}

Just to be clear, I am looking for REST APIs available out of the box. Similar to Camunda REST APIs: Camunda Platform REST API

Could you please help to confirm this is the right approach?

6

We plan to provide REST APIs out of the box. But it is not currently available. You have to write your own HTTP handler. In most cases, you don’t want to expose Temporal specific APIs, so this handler is usually application specific and doesn’t even mention Temporal abstractions like signals and workflows.

1 Like
7

The Server currently only has a gRPC API, so the 3 options are:

  1. Client SDK (which isn’t a big library—it just wraps our gRPC API and does things for you like data conversion)
  2. Call gRPC API directly (recommend #1 over this, as Client is easier to use)
  3. Develop and deploy your own HTTP API, which uses #1 or #2

For #2, you’d call the WorkflowService.SignalWorkflowExecution method with this input:

SignalWorkflowExecutionRequest

and call another service to do something asynchronously. Instead of polling service B for result

This doesn’t fit your no-dependencies need, but perhaps worth noting that this is one of the use cases we have AsyncCompletionClient for. The workflow can start an activity that calls service B, and service B completes the activity using an AsyncCompletionClient.

1 Like
8

Thanks a lot @maxim and @lorensr. This is very helpful

9

I made a generic API gateway server for doing this via REST, and it has extra routes for interacting with slack webhooks and routing them back to the workflow.

This enables not only your current use case but also provides patterns for usage when you don’t have control over a 3rd party service (other than telling it where to send an event payload) but need interactivity with external users/services from a temporal workflow

2 Likes
10

BTW in the long term, we do plan to provide use-case-specific HTTP and other APIs through Nexus gateways.

11

That’s great, I’m super excited about nexus. Hopefully I can deprecate this or at least just keep the slack encoding & forwarding route