Make it possible to extent the timeout on the automatic activity


I understand why there is a default timeout in BPT for the automatic activity: Because BPT is multi threading you can create performance issues.

However, as a expert developer it should be possible to override the default timeout of 5 minutes. For example: I have created an application where there would never be more than 5 processes running at the same time. Those processes need to convert a file with more than 10.000 records. To do this i had to create a nasty workaround that would save the current position and run the automatic activity again untill its finished.

So, it would be best if default timeout remains but timeout can be altered using a server action. this means a developer knows the risk and has given it enough thoughts.

Created on 16 Aug 2019
Comments (4)

Changed the category to Backend

Hi Stefano,

I agree, almost everything is configurable, then why not BPT (now fixed on 5min)  and BPT light (fixed on 3 min).

Did you read the next article on how you can  combi a BPT with a timer? I think it is a more easy and elegant solution to implement.

Although if the timers need to run parallel in your case you would need to create 5 timers as you can not have same timer simultaniously running.

Another question why does it take more than 5 minutes to convert a file with 10.000 records? That does not sound really fast, compared to what I am just to in OutSystems.



Hi Daniel,

I did consider the timer but i just didn't want a multi threaded solution to queue up to the timer. That didn't seem right.

Your other question: So far i haven't hit the 5 minutes threshold. But i couldn't take the risk: i said 10.000 but i am pretty sure within this year we will be getting XML with over 80.000 records.

I am quite happy with my working solution but the whole thing wouldnot be necessary if i were able to configure time out time.

You description about future expectations on data growth, is exactly why I would advice to use timers. 

I would always advice to make  the timer logic 'safe', meaning in such a way that irrespective of the data growth it will process all data without running into a time out. Now you think it might grow to 80.000, but predicting the future is not easy what if it turns out to be 10 times more than expected.

Justin James wrote a very nice article regarding this subject:


It is a bit more work, but avoids future production problems and then you probably still would have to change your BPT processes to timers.

Bottom line, if you can not split the processing of large data set into small steps, then you should use timers, not BPT processes.