I am migrating one of my conductor workflow to temporal.
In this workflow there are multiple process that have to occur which are present in multiple micro-services.
Module 1 → Process 1 & 9
Module 2 → Process 2, 3, 4, 5
Module 3 → Process 6 , 7
Module 4 → Process 7, 8
What will be the best practice to create this in temporal?
My first solution was to create separate worker in all 4 modules which will implement their respective processes in their module but i want to understand if there is any other way temporal supports multiple activities in different microservices?
welcome to Temporal
do you need the activities to run in the same host as the microservice? or do the microservice expose some API you can invoke to perform each step?
If you need the activities to run in the same machine, you can schedule each activity in a different taskqueue, through activity options eg “taskqueue-module1”, “taskqueue-module2”
(note that by default activities are schedules in a taskqueue with the same name as the workflow)
and have the worker running in the microservice, listening on the taskqueue the activity was scheduled.
but i want to understand if there is any other way temporal supports multiple activities in different microservices?
- If your your microservices expose an api you can communicate with, another approach would be to write those activities in a way that they interact with the microservice, and have all activities running in the same taskqueue.
Let me know if it helps,
Thanks @antonio.perez for the quick response!
I have 2 Microservice:
- Multi-Module Microservice A
- Microservice B
Use case: orchestration between multi-module ms A as well as B service.
I have decided to take child workflow route. Basically i am creating child workflow for communicating between these multi-modules as well as service B. I just want to understand is this the best way?
There is no single “best way”. If you are calling code in another service then this code should be either a child workflow or an activity. And B service should use its own task queue name.
For modules that lives in the same service you can use child workflows, but it is not required. In many cases having a single workflow that implements multiple modules might be simpler.