Try capitalizing the first letter of the activity method name. By default Java converts “methodName” to “MethodName” activity type.
That was the problem. It works fine now. Thanks a lot. What retry value your customers set in the production ? I would like saga compensation retry count to LONG_MAX. The exponential backoff algorithm will retry at different interval but when there is cloud provider outage or customer data center outage then there is no way to decide the retry count so keeping it maximum would help.
LONG_MAX does make sense here.
I assume the saga support in Temporal is orchestration based Saga and not Choreography based Saga.
Yes, it is orchestration based. BTW look at the Saga class implementation. It is a pretty very trivial code as all the hard lifting is done by the Temporal SDK and the service.
Thank you for confirming. I did go through the entire implementation before presenting it to the architecture board.
Also, note that you can always implement your own Saga class if the existing one doesn’t exactly fit your purpose.
As complexity grows, we may have to think about it. The out of the box saga support solves a lot of use cases. One of the use case which is not documented and very popular among cloud migration architects is data synchronization between their on-premise ODS and cloud data warehouse. Temporal can help in this situation by introducing retry and compensate mechanism while sending data to cloud in real time. The change data capture ( CDC ) is always a problem in cloud migration and technologies like temporal can help with introducing check points as DBA will not keep change log for a long time.