LBPT sleep when error

Hi Guru's,

I have a question about the lite BPT that we are using with a lot of joy. We use it for sending a message to an external system. Only there is a limit on sending a maximum amount of messages within a specific time. In this situation a error is triggered and the LBPT will try again. Only it will do so many request all getting the message back that it's trying to many times. Would it be possible to do something that when the return is to many request we put the LBPT into sleep for say 5 minutes or what. And after that I will try it again?

Perhaps in your situation you would be better off with a timer instead of your multithreaded light BPT.

Ofcourse you can let your BPT automatic activity wait, but you can never stop all BPT processes running, unless you set a property somewhere. 

why did you choose the light BPT over the timer construction?

Hey Freek,

With lightBPT you wont be able to achieve that, at least not out of the box, maybe an idea would be to change that lightBPT into a BPT this way you can have access to the Wait like this:
Luís Almeida

We want a lite BPT so there is no delay instead of the timers, and we choose a lite BPT because of the amount of messages and to prevent the logging overhead. 

You can fire a timer as well, so there would not be any delay.

But let's stick to your choice.

- If i am correct, your problem is that you get errors when you do too many requests in a certain timeframe.

- If i translate that correct it means there should be some sort of guard/check before sending the request to that API.

This means that you have a multithreading solution that needs to go past a singlethreaded check, which is not ideal, but it is possible.

You can create some sort of logging entity, where you write the timestamp to, when your BPT calls the API.

Before calling the api, do a check on the number of calls in the timeframe you are limited to (lets say 100 / minute).

If you don't pass that check, wait ( the ugly way is to use a IF with a currdatetime() and a variable datetime and loop untill it passes a minute..

Be aware that your Automatic activity has a set Timeout of 3 minutes. If you need to wait longer, you have another problem.

This is a very complex implementation. Please reconsider the timer sloution.

Thnx for your response, on this moment I have a timer and a LBTP when the LBTP gets an error it stops and then the timer will pick it up the next time the timer runs. But I was hoping to have a solution what allows us to only us the LBTP. 

As said, the timer is imho the best solution for your problem. Using LBPT and a timer makes your process unnecessarily complex. 

you will get a lot more time out errors etc. and gain only the multithreading advantage untill you reach the maximum requests of the API.

But since you already use a timer, perhaps you can consider sending all API requests throught the timer and do everything you need done before that in the LBPT?

you can always fire the timer and let the timer check if its ok to send the requests to the API.

I only think that using the wake timer function hundred of times in a few second would not be the best way to use timers right? Now the timer runs every 15 minutes and the LBTP can do hundreds of processes at the time until a maximum of request and then will close the LBTP and the timer will process them. The only best way to use the timer is not to use the wake up function of the timer and just run it every 5 min or so only then we lose the advantage of having the messages processed quicker. Do you have any other thoughts?


LBPT does indeed allow for more parallel execution, but not hundreds of processes at the same time.

Per front end server in theory you have max 20 parallel LBPT processes that can run simultaneously, so by far not hundreds.

As written by others, LBPT does not allow for a sleep/wait event. For that you would need to use a BPT using a Wait activity.

If the retry interval  within a LBPT is fast, let's say for example every 10 seconds you can use the sleep extension from the Forge within the automatic activity of the LBPT. Just make sure that you don't exceed the LBPT timeout of 3 minutes, instead try to fail gracefully or kick of another LBPT (thru create of a record) to continue the process.

As Daniel said, even with LBPT there would only be a max of 20 parallel processes running at the same time. 

But if there are so many requests being handled, than a timer might not be sufficient. I twould really slow down your handling process. That being said: you can always check if the timer is running before calling the waketimer function.

You could implement Daniels suggestion with 

- The sleep extention 

-  Kick off another process before the LBPT reaches the 3 minutes timeout ( which in your case will lead to many new records), 

- Fail gracefully. With this i am sure Daniel doesnot mean that all your processes should try to reach the external API, because every API attempt will lead to a record in the integration log. You should still consider some sort of logic telling you to wait before attempting to send the request. Meaning that when the first rejection occurs, you set a flag with a timestamp telling you to wait sending requests untill they will be accepted again.

I have to finish by saying your solution is close to real time but therefore very costly. If those messages really need to be send real time then there is no other way, but then i would raise the question as to why the receiving end is limiting incoming messages.

Best would be to gather messages and send more messages in one API. Ofcourse your receiving party would also need to change a few things.

Community GuidelinesBe kind and respectful, give credit to the original source of content, and search for duplicates before posting.