Transforming a legacy HTTP API into a Camunda 8 workflow

Hi team

I would like to transform an existing synchrounous HTTP API into a Camunda 8 workflow.
The HTTP request received from the client would instanciate the workflow and at the end of the workflow, we would send the relevant HTTP response to the client.

The HTTP API internally makes HTTP calls to 2 microservices.

client — HTTP request —> API service
API service – request → microservice 1
API service ← response – microservice 1
API service – request → microservice 2
API service ← response – microservice 2
client <— HTTP response — API service

Although the use case is fairly simple, I don’t succeed to easily translate it to a Camunda 8 workflow.
Firstly the built-in inbound HTTP connector doesn’t suit as it sends immediately an HTTP response.

So I assume I have to introduce a front-end API service that receives the HTTP request and calls the Zeebe gRPC API CreateProcessInstance to trigger the workflow. The HTTP handler then waits for the end of the workflow.

The workflow can invoke the 2 microservices with 2 service tasks.
And here comes the problem: how to notify the waiting HTTP handler with the workflow result?
Do you have any idea?

Thanks for your reply

Nicolas

ps: if I transform my synchronous HTTP API into an asynchronous one, I could easily use the inbound HTTP connector and add a 3rd service task that invokes the client HTTP callback but I would like to avoid that if possible

Hi Nicolas,

This sounds very familiar. How do we know when a process has ended? Two approaches:

  1. Start the process and then poll for the process status or a specific task of the process with the process id. Do this until the process is finished, then send the result. Easy to implement but there might be a lot of useless requests.

  2. Start the process then make the thread wait() and at the end of the process you add a task that notify() the thread so it can proceed.

Thanks for your reply Christian

I had a look back at the Zeebe gRPC API to find the request for getting the status of a given process. I didn’t find it. Maybe it’s a Camunda 7 thing.

Yet I fell on the CreateProcessInstanceWithResult API and imo this is what I shall use.
The sequence diagram would look like this:

client — HTTP request —> API service
API service — CreateProcessInstanceWithResultRequest —> Zeebe
here the HTTP handler waits for the Zeebe response

Job worker #1 ---- ActivateJobsRequest —> Zeebe
Job worker #1 <---- ActivateJobsResponse —> Zeebe
Job worker #1 – request → microservice 1
Job worker #1 ← response – microservice 1
Job worker #1 — CompleteJobRequest —> Zeebe
Job worker #1 <— CompleteJobResponse —> Zeebe

Job worker #2 ---- ActivateJobsRequest —> Zeebe
Job worker #2 <---- ActivateJobsResponse —> Zeebe
Job worker #2 – request → microservice 2
Job worker #2 ← response – microservice 2
Job worker #2 — CompleteJobRequest —> Zeebe
Job worker #2 <— CompleteJobResponse —> Zeebe

API service <— CreateProcessInstanceWithResultResponse — Zeebe
client <— HTTP response — API service

Am I right?

Yes, very nice. Didn’t know about the new functionality. That’s right, we had the problem in a Camunda 7 project. If you really want to you can use the tasklist API in Camunda 8 to query for tasks (and their status) of a specific process instance. Btw in Camunda 7 you could emulate the behavior of this new functionality if you could design the process without transaction boundaries (which we couldn’t becaus of external service tasks).