We’re implementing a process which includes some waiting stages. The example scenario:
User creates an order
System waits for the account to have enough money and deducts (may be several hours or days)
User continues according to the process.
We’re implementing a custom frontend. Basically each screen is a separate user task in the process.
When the first task is completed via the Java API the call doesn’t return until the next user task is reached.
Is that a correct behavior?
The other question is what is the best approach to implement the waiting states? For example a process is stuck somewhere between user tasks. What would you do to let the user know what is going on in the process? There may be several waiting states in one process.
First off - can you upload the model you’re talking about, it’ll be make it easier to know if the answer we’re giving you is accurate.
Yes - by default the tread that completes the task will move the process forward to the next wait state and only return when that wait state has been successfully reached. If you want to change this beheaviour you can quite easily create wait states where ever you like using the async before/after function.
There are lots of possible answers to this - it really depends on what you’d like to see happen and work backwards from there. Initially i suggest that if you’re looking to have a process wait for a specific duration, timer event will do the trick.
Thanks for your help. I’ve finally got the meaning of the wait states. Although I read about them in the documentation earlier It clicked when I read your answer.
We’ve tried the async checkboxes and it resulted in what we wanted.
For the waiting states in the process we’ve added some process variables which are returned to the frontend. That way the frontend doesn’t receive an active user task but it receives the current state and the state message which are displayed to the user. The frontend continuously polls the backend and fetches the user task when the process arrives to one.