I have a script task in my process model which will check whether the task is accepted in the process report. If its not accepted it will execute again.If the task is accepted it will write the task owner name to DB. Once 1000 instance is done I'm getting paused by exception error.
Discussion posts and replies are publicly visible
Hi SangeethaBabu, can you shed some light on what you are trying to accomplish and your current approach? It feels to me that you are waiting (forever if needed) for a certain task to be accepted.
Pedro Simões I want to capture who accepts the task before the task is completed. So the node will check who accepted the task. I have to save the username who accept the task to database. So if the task is not accepted then it will check again
Do you have a timer node set in between separate executions of the loop? How often are you having it re-check?
Edit: judging from your screenshot it appears you don't have a timer on the re-execution flow. You absolutely need a timer here, or else your process model will essentially do everything in its power to execute all 1,000 allowed instances all at once. If there wasn't the 1,000 execution circuit breaker in place, then your system could experience noticeable degradation in performance as any instances of this process would be essentially executing unbounded infinite loops while waiting for task acceptance.
Now, if you place a timer that waits, say, 5 minutes between executions, several days would elapse before the 1,000 execution limit is reached. I believe in almost all cases this would be sufficient, and it would be dramatically less damaging to your system performance (i.e. basically nothing).
One possible option would be to create a new rule input into the Interface that you're using for your Task, and set this to the tp!owner. When a User accepts the Task this value is now available in your interface code.
Pick a field in your interface that you know the User will interact with. Once they do you can use the saveInto: to write the task owner value directly to the database using a!writeToDataStoreEntity().
To avoid keep writing the same value again and again you can wrap this write with an if() which you can control using a local! Boolean variable which you can toggle in the same saveInto:
Of course, there's nothing forcing the User to interact with the interface after they've accepted the Task, so you'd need to assess the risk of someone not doing so.
Stewart Burchell said:Of course, there's nothing forcing the User to interact with the interface after they've accepted the Task
I've given up wishing about this, but occasionally I still think about how much easier life would be if they'd just built in a way to allow designers to configure these system-based UI controls ("accept task", "reassign", etc) to also kick off expression or process-backed functionality upon execution.