Multi threading in Outsystems

Multi threading in Outsystems


I have an action that executes an external web service that is very slow. The providers of the web service told me that to improve the performance of the application I should use parallel requests to their application. The easiest way to do this would be to execute an outsystems action in several threads.

I can think of three solutions:

1 - Make my eSpace Multi-Tenant and wake the timers of several tenants. The worst part here is "tell" each tenant what he must process (this could be done with a new table).

2 - Create an extension that has an action that throws several threads that will execute the outsystems action with a parameter that indicates what should be processed.

3 - Create several timers that execute the same action. In this case the timers are harcoded. The indication of what each timer should do can be written in a new table before it is started.

Any other ideas? Which of the above do you think is best?

Thanks in advance,

Hi Daniel,

I would like to think back with you the assumption that, to improve the performance of the application, you should use paralled requests.
How will be done the interaction with the web service? By each «work do do», will you call only one action of the WS, or will you call a sequence of actions of the WS?
Have you found out why is it slow? Is it the SOAP round-trip (like a lot of data travelling arround), or is it its internal execution?
What is the trigger, for calling this WS? Is it user-driven (like pressing a button in an application), or scheduled (with a timer), or other?



I guess the best option is to create an extension for async requests over your application and not the web service.

- Create an entry point that will do the logic you want at Preparation and invoke the Web Service.
- Create a static class in the extension that will act as a queue of results with Ids (the preparation of the entry point above must receive the queue Id and will queue the Web Service result).
- Create Actions in the extension to put and get elements in the queue by Id.
- Create an Action in the extension to invoke a certain url in an asynchronous fashion (your entry point). Use an async HttpRequest or just launch a thread and do a regular sync request.
- Then create an Action in SS that will do as many requests as you want and wait for the results in the several queues. If you have timeout problems you must set the server request timeout via an Extension Action that will simply do: HttpContext.Current.Server.ScriptTimeout = SomeIntMScsTimeout;

This way you keep using the platform features (Web Services refresh, Actions in SS...) and ar eable to do multithreading.

Does it solve the problem?


Rodrigo and Olivier, thanks a lot for the reply but unfortunately the situation was so urgent that a solution had to be implemented immediately and therefore I could not use you ideas/comments on it.

I must add that this was a situation where the truly "built to change" and "adapt to new business requirements in a few hours" were made real with an astonishing success.

The concrete situation was the following. Hi have a application in which a campaign is configured where, for each client that enrolls for the campaign, an external system web service has to be invoked three times to activate the client in three different systems. This activation is done by invoking the web service in a central broker with the parameter that specifies which system is to be activated. The request for an activation is done by placing the pair client/system in an eSpace queue that is processed by a timer. One other thing is that the request for the second system activation of the client is only done after the first is fulfilled. Likewise, the request for the third system of the client is also only done after the second is fulfilled.

The problem that has arosen is the fact that requests for each of the systems were waiting in line for the requests to the other two systems. This alied to the fact that the activation is extremely time consuming and also that the number of clients was high lead to a situation where clients had to wait for several hours before they were activated in the three systems.

Answering you question, Olivier, it would definitely be rewarding to make parallel requests for each of the systems to activate (each of them leads to a specific activation queue in the broker).

The solution to the problem was in fact extremely simple. What I had in the first place was a timer Timer_Requests that executed the action ProcessRequests. To have parallel requests I made the following changes:
- In the Request table I added a new field timerPoolIdentifier that specified in which thread a certain request type is to be executed;
- Added a new parameter timerPoolIdentifier to the action ProcessRequests and changed the query in this action that gets the requests to process so that only the ones with the timerPoolIdentifier identifer equal to the timerPoolIdentifier in the input parameter would be retrieved;
- Created three timers, Timer_Requests_0, Timer_Requests_1 and Timer_Requests_2, that executed the action ProcessRequests. Each of them would passes the values 0, 1 and 2 respectively to the action ProcessRequests;
- Made small changes to the web interface so that the user would be able to specify that a certain request type is to be executed in a certain timer.

In one hour the the new business requirement was implemented and in a few hours deployed in production. The performance gains were the expected.