Asynchronious processing?

Asynchronious processing?

  
Hi there,

Are there any plans in the near future to support some kind of asynchronious processing?

I'm trying to implement a web site where our clients can upload an Excel file. In this Excel file there are approximately 50.000 mobile numbers and messages. When the customer clicks 'go' he must be able to start the SMS MT broadcast. At this moment the browser times out because it takes too long. I already worked-around this by making a self-refreshing iteration-timer (like the old 'compiling, please wait...' message in service center). But still it takes a lot of time (approx. 50 minutes for the whole broadcast!).

I would like to make something to have the 50.000 SendMessage calls be processed in the background, so that the client sees a message like 'thanks, the broadcast is started now'.

I could do it with a timer I think, but that would be an ugly solution since it requires me to store the excel in the database (which I really don't want, since all broadcasts are a one-time-only thing).

When this is set-up in a multi-hubnode-environment with a proper loadbalancer, can I speed-up the process by letting multiple nodes process simultaniously? Or won't that work since it is one big loop, processed on one server?

What do you think?

Thanks,

Jurriaan
Hi Jurriaan,

We already have the basic mechanisms for asynchronous processing using timers and "wake timer" actions. Currently the communication between the timers and user interface has to be done using the database. I suggest you to place the excel file in the database along with some state information to keep track of its status and progress.

You should also have a different daily timer to clean old excel files in the database and release database space.

If you want to balance the timer execution between several hub nodes you need several timers executing the same action. You need to place information in the database to ensure each timer only handles it's own job or job part and to support monitoring user interfaces.

Also, to ensure your solution is robust and efficient, a large job like 50.000 sms should be split into several smaller jobs where each timer execution only handles a single small job. This way you can execute several smaller jobs in parallel and you also ensure that if an error occurs, it only affects a smaller job, not the entire job.

Please check the attached eSpace that implements the logic described in this post.

Why is your job taking 50 minutes? Is it database intensive?

Greetings,

Lúcio Ferrão
Hi,

Thanks for your suggestions, I think I can do something with that.

Still: wouldn't it be superb if we could have a property on an action like "Process into the background"? So the program flow can continue and the action is being done in a seperate thread.

Thanks,

Jurriaan
Hi, hi, you have to send the AsyncJobs.oml to open in version  Service Studio 8.0.1.35. Or another way to run background process?

Rodrigo,

You replied to a post that's over 11 years old! You really shouldn't do that.
Ok, sorry. Open another post