Springboot with Temporal Design

Community Support
,
1

Hi Team,

I’m new to Temporal and currently working on a proof of concept (POC) with Temporal and Spring Boot. I have a couple of questions I’d appreciate clarification on:
1)The Temporal Spring Boot dependency is currently in alpha version. Is it considered production-ready, or would you recommend using the Java SDK instead?
2)In my use case, I have four microservices (all are in live already), none of which currently use Temporal. I’m developing an orchestration service using Temporal to manage a workflow that involves changes in all four microservices.
Currently, I have a single workflow with different activities for each microservice. To be specific from one workflow method implementation calling activities one by one based on previous response. Is this the recommended approach? (Actvity invokes rest api call to corresponding service)
I need to ensure the success of each activity in a microservice before proceeding to the next one.
How to achieve that using temporal ? (do I need to handle in business logic before triggering each activity)
3)Additionally, does Temporal allow for retriggering from the point of failure, or should this be handled in the business logic? For example handling rollback for previous activity if current activity response returns failure
4)Is this design recommended or do I need to consider creating different or child workflows to handle failures better.

Your guidance on these questions would be greatly appreciated.

2

  1. Yes its currently labeled as “alpha” and plan is to promote it as soon as possible. It should be stable but if you find any issues or have suggestions for new features feel free to file issues in java sdk repo.

  2. Yes approach seems fine. It’s perfectly ok to use result of activity to make business decisions in your workflow code. If you restrict activity retries via its retry policy or ScheduleToClose timeout you need to handle ActivityFailure in your code which is delivered after activity fails or times out after all retries. Default activity retry policy does not limit retries.

  3. You can handle activity failure in your workflow code and decide to invoke another activity. If you have a sequence of activities you want to retry together consider using Workflow.retry or having those activities in a child workflow that on activity failure calls continueasnew.