I need to run one (1) process async (extracting data from file). I want to this either in a Timer (preferred) or a BPT Light process. There is a high change that this process is going to longer than the maximum allowed time of either method. This is fine. We did our best and we are OK with not completing the task. I do however need to register the fact that this process reached its timeout so that the users knows that he needs to upload some data manually.
So the question is; Can I act upon the termination or a Timer of BPT Light process? Will an exception be thrown that allows me to update an entity record? Or will the process just be killed and that is the end of it?
And to answer the most obvious question "can't you restart the process?". No, we can't. The extraction of the data is one (1) server action that will only return when done. I can't add steps in that action to check for the time (nuGet package that I don't control, nor want to control).
Hi Vincent,
Timers can have long running executions more than the default 20 minutes, this is what you can configure your self. BPT have a process time out of 5 minutes. LBPT have a process time out of 3 minutes.
All 3 async methods have an auto retry mechanism. Max retries of timers is defined in service center.For LBPT that is a bit different, a retry will be reschedule multiple times, every time with a longer wait period. You don't have control over that. My advice is to ALLWAYS catch ALL exceptions in a LBPT, and fail gracefully, so you have control over the process. You can either then decide to not process the data, log the exception, or to reschedule the process.
Even thought a LBPT can take 3 minutes to complete, you should use this especially for small tasks ideally to be executed in some seconds rather than minutes, there are only 20 active LBPT instances per Front End server possible, so if you generate a lot of LBPT processes that all take 3 minutes, you are still faced with a long period for them to be all processed.
-- Daniel
Hi Daniel,
I know about when the timeout occurs. I just can't monitor it and make sure the process fails gracefully. So if it fails due to a timeout it will fail hard. Except, if I can detect this. If an exception is thrown.
But will a exception be thrown that I can catch? And how much time do I have left after the exception is thrown before the process if really terminated.
Hi Vicent, I would say it is very easy to find out, by creating a LBPT, let it wait 4 minutes with the sleep method, and having an exception handler. Sometimes you need to explore these things yourself for gaining a deeper platform knowledge.
On the other hand, you should ask yourself if LBPT is the right solution for your situation, if processing time can very much based on the file size or data you need to process, you either fall back on a timer, or you need to break down the data into bathes of equal sized (for predictable processing time) before you process it with a LBPT.
Sometimes it is better to see if someone has done this already and wants to share their experience. I know that you can get some unexpected extra knowledge by doing so ;).
But no worries, I will test this myself to see what happens and if needed involve support because one way or the other, I will need to know the process has failed.
As for splicing the data, this is simply not possible for this step. The type of file and the tool used do not support splicing so that limits my options.
Given what you share, a timer makes more sense than LBPT
True but we also have the issue that we can have concurrent jobs, something not supported by Timers. It's a nice puzzle to solve :)
You can have the same timer running simultaneously as long as it is in a different FE server.
You can also create copies of the timer with unique names, that run the same server action.
Would you care to share the results here if you have tested this Vincent?
Hi Vicent,
Although there doesn't seem to be a straightforward way of handling the scenarios, like with an Exception handler, perhaps you could implement some kind of workaround.
You could create a control Entity/set of attributes to track the success/failure of the process, e.g. inserting/updating a record and committing it at the beginning of the Timer, then updating it (marking it as complete) at the end of the Timer flow. If the Timer fails, the record wouldn't be marked as complete, which would give you a way of detecting unfinished processes. You could use some timestamp-related threshold or logic to filter out records that might still be in the middle processing. You could use that same Entity data to prevent the records from being reprocessed in case of failure. Maybe not the most elegant solution but it sounds like it should get the job done.
In a BPT/Light Process, it might require some additional considerations if the retry policy is undesired, because they tend to be tied to a specific record/ID, but it should be feasible with some adjustments.
If the processing is more granular (i.e. it has some form of large loop rather than a single node with the risk of timeout), you could go with a more traditional approach of Timeout Prevention by handling the Timeout "manually" rather than using the system's timeout. Based on your description this doesn't sound like your particular scenario but throwing it out here for reference for others who might have similar issues.
Hi,
I think u can use both BPT together with timer inside it. It makes time becomes not an issue anymore as we always able to create forever timer and parallelism is guaranteed by asynchronous feature.
Timer cannot passed with argument, but BPT can passed argument from server action. So those combination is perfectly complement.
In BPT u can have a WAIT action, and once the time elapsed, you can check whether the timer has done its job (communication thru information in a table).
I used BPT in a national banking project for loan lending approval and it works like a charm - put wait action and human action to stop the business process. For auto Action, try to use Timer if the timeout is an issue and stop to wait whether the Timer has done its job or just loop it to the same auto action.
regards
Hi all,
I had a similar issue where I wanted to set the timeout of a specific service action within a timer (since it might cause the timer to time out).
The solution I came up with was to change the service action into a consumed REST API. I could then set its timeout and catch it in the exception handler without stopping the whole timer.
Hi Pierre,
That's not a similar issue: the original post is about time-outs on (asynchronous) BPT and Timers, which is a different thing from (synchronous) server calls or REST methods.