In our company, we have a business workflow with 20+ steps(Activities). For any step, user is able to go back to previous step. Just wondering what the best practice for this cases? Taking below as example.
Step 1 - Get level one’s approval
Step 2 - Get level two’s approval
Step 3 - Get level three’s approval
Step 4 - Get level four’s approval
In Step 4, User can ask level 2 to check again and then go to Step 3, Step 4.
Can you explain what “user can ask” means in your application?
Temporal supports signals, async events that are delivered to a workflow, and usually external user input is modeled as a signal.
There is no out-of-box “goto” feature, but believe you can accomplish your goal with combination of waiting for signals (user inputs), and using programming language constructs to define your activity invocation logic based on those inputs.
“User can ask” means user is able to select one step from UI and ask workflow to go to that step.
Yes, I agree with you. It’s a kind of signal. We write some code to achieve such feature like below.
Once we got the signal from user to go to previous step, we close current workflow execution
Then we start a new execution with same workflow id with the context.
Am I on the right way? ut there are some state need to be stored and recovered. Like if user want to go to Step 3, we must restore all state for Step 1 & 2, skip them and start from step 3.
Instead of closing the current run and starting a new one, you could instead continue your current workflow exec as a new, and pick what parts of current workflow data to pass to the next execution.
You can use Workflow.continueAsNew when signal is received, or you can pre-define
your continue-as-new stubs (maybe for each of the steps), for example:
private final Step2Workflow continueAsNewStep2 =
Workflow.newContinueAsNewStub(Step2Workflow.class);
...
// when signal received for step 2
// stop execution of the current workflow and start a new execution
continueAsNewStep2.doStep(input, input2, ...);
There is no “go-to” specific feature that I am aware of, but this should be close enough hopefully.
Then update the state based on user input. Obviously, you can create a more complex design that doesn’t hardcode steps but uses some DSL to specify them.