Good day! I am new to temporal and I am working on solution that will interact with frontend.
My simplified workflow should be as follows:
User make some input (I can process it via Signal or Update events)
I am calling some internal service with user data in activity and present result to user
User enters additional data.
I am making another calls
What is the proper way to make this workflow to show previous user screen and not repeat all over again. This workflow can include 10 steps or more and lots of internal calls. I want to be able to make something like ‘back’ action for customer and continue from the previous user screen with all the data that he had before, but without calling all the services.
Thank you very much for response and suggestion. The main question is the ‘back’ functionality. I was thinking about reseting workflow to a previous ‘user screen’, this will give me ability to repeat all the steps between user actions and keep all the data in a proper sequence without necessity to code undo functionality for each users step. Can it be done this way, or resetting workflow will lead to some other problems?
I wouldn’t use reset for business-level logic. It is for dealing with operational issues.
I think modeling your workflow using OO abstractions is the way to go. For example, going back doesn’t mean that you want to lose all the information that was entered in the next screen.,
So your suggestion means that I can not use any temporal engine features for process navigation and that I will have to code everything manually? I`ve been using other BPMN solution and main profit of using it was the ability to go to any part of the process on condition. I thought that behaviour like this could be achieved with Temporal engine also, but it seems like by default it could support linear processes only.
You can use reset to go back to any part of the process in Temporal. However, regardless of the technology used, it is frequently not a good idea. Business processes execute actions in the external world, and using “goto” to jump back without running any compensations and taking care of the workflow data doesn’t work in many situations. We are considering adding the ability to execute compensations on reset, but this is not currently supported.
I personally think that the workflow logic itself should account for the majority of business-level outcomes, which might include human intervention.
Yes, completely agree with you. Goto is a bad thing and compensation will give some possibilities to solve the problem, but it is also will be a kind of hack for my situation. Thank you very much for your answers.