2
 Followers
12
 Likes

Support for non-blocking IO operations / integrations for OutSystems platform

Backend
Not right now

Problem:

Currently, OutSystems 11 has been released with the support of the creation of Services (aka Microservices). Then you can split our application to multiple processes as Microservices. These services are communicating through the network and sometimes modern architectural designs it is important to combine results from multiple sources.

Let’s look following simple example with 12 REST calls:

In this example, we have 12 REST calls ( GetRest 1 - 12 ). All of these rest calls have same structure inputs, but and they are producing a similar result from different systems. All of these results are collected together to list and then this list is returned. 



This creates above problem, where all the remote calls are taking time and next REST call to be able to start we have to wait until earlier one has been completed.

How to solve that:

Above, the remote (REST) calls are executed as non-blocking way. Here the REST call can started without to wait that earlier call has been completed. We will block the operation only when we need to result. Example “GetRest12“ is blocked at “WAIT 12, but same time REST 11 and REST 10 are also complete so there are not need to block for “WAIT 11” or “WAIT 10”. Some of the calls can be longer, like “WAIT 9” and “WAIT 4”, but those are only extending execution time as much as they longer for earlier ones.

This feature should be available for all IO operations, like REST / SOAP / SAP  and Database queries and also OutSystems 11 ServiceActions as those are running on separate processes.  Underlying API should be also provided for also custom extensions made with Integration Studio.

Created on 28 Sep 2018
Comments (6)

Changed the category to Backend


This is something I definitely see the need for, but given OutSystems' preference for not supporting use cases that significantly complicate development (async and reflection are big ones) I would not be sure this will get done. On the other hand, mobile has async in it... and while it HAS significantly complicated development (anyone who has struggled with "what's the equivalent of 'Preparation' on mobile?" knows what I mean), that's a sign that maybe we will get it on desktop/services/etc. as a full-fledged model.

J.Ja

"given OutSystems' preference for not supporting use cases that significantly complicate development"


I do agree on this, but this approach. This change would not change actual tools of the developer interface as the the flow would look exactly like before, but he behavior of it would change more effective as the these remote operations would be basically asynchronous if the flow would be organized correctly.  Old code might also benefits for this as the only difference would be generated code. 

Basically with OutSystems 11 new Service Actions, this would design also asynchronous OS logic.

Hi Sampsa Sohlman,

To have asynchronous call would be great but it would need a great code introspection to double check if any call is dependent of a precedent one. 

You are exposing a very simple scenario where you get info from external systems and each call does not depend on the result of any of the previous calls. But imagine a scenario where this does not happen.

So although I think interesting and useful, but will bring more complexity if we add that logic and I don't think it would work automatically, because it would be highly dependent of the developer code.


Hi Fernando,

"To have asynchronous call would be great but it would need a great code introspection to double check if any call is dependent of a precedent one. " 

I was thinking that the generated code would be series of events, that will be run on order of the flow. Basically every flow action would be run as event, then you check if the next event can be executed would be measured by "action" parameters if the result is ready. 


Changed the status to
Not right now


Hi Sampsa,

I get your point, actually implementing an event driven architecture through the whole platform maybe a bit too much and there are very few use cases where the user would take some benefit. 

In most of the cases you want to run the code in a serial way and not by triggering independent events.

Thanks for the feedback

views
443
Followers
2