We have a business process that contains many user interactions, e.g.
Between the user interactions, there are also backend interactions, e.g.
Completion of the whole process might take several days, so it’s important to store the current process status and already populated data persistently.
At a first glance considering the facts above, the following approach seems appropriate:
However, there are certain drawbacks:
The drawbacks seem to make future maintenance and adaptations elaborate, that’s why I would rather tend to the following approach:
However I’m still not very happy with this approach…
Any opinions or experiences?
Could you add a screenshot of the process?
Attached a jpg of an example process for a flight booking, with alternating user and service tasks to illustrate the problem.
I agree this is actually a UI process, the user tasks are the UI states and services tasks the UI transitions with services calls.
A persisted process would be needed if you have some asynchronous tasks like “send a confirmation email one week before” or if the user can cancel some time later.
You must be logged in to reply to this topic.