Asynchronious processing?

Asynchronious processing?

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?

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.