Hi,

I am looking at ways to implement microservice architecture in OutSystems, preferably event-based / RabbitMQ.

I have read up on all the documentation I could find, like this, but I feel like it's missing some key information.

In a traditional microservice architecture based on events, an event bus (ex RabbitMQ) would provide the communication channel between microservices, however it seems like the proposed implementation in OutSystems (see link above) would require microservices to communicate to each other via REST API calls. Is this the best-practice in OutSystems?

Better yet, does anyone here have experience implementing microservice architecture and can you share your input on the best way to go about it in OutSystems?

Thank you in advance.

DavidA wrote:

Hi,

I am looking at ways to implement microservice architecture in OutSystems, preferably event-based / RabbitMQ.

I have read up on all the documentation I could find, like this, but I feel like it's missing some key information.

In a traditional microservice architecture based on events, an event bus (ex RabbitMQ) would provide the communication channel between microservices, however it seems like the proposed implementation in OutSystems (see link above) would require microservices to communicate to each other via REST API calls. Is this the best-practice in OutSystems?

Better yet, does anyone here have experience implementing microservice architecture and can you share your input on the best way to go about it in OutSystems?

Thank you in advance.


Hi DavidA,

Check the Domains and Services Tech talk to see if it inspires you. It covers when to use Microservices and shows the strategy for exposing microservices internally inside the platform, to external systems or to consume microservices from external systems

Francisco Menezes wrote:

DavidA wrote:

Hi,

I am looking at ways to implement microservice architecture in OutSystems, preferably event-based / RabbitMQ.

I have read up on all the documentation I could find, like this, but I feel like it's missing some key information.

In a traditional microservice architecture based on events, an event bus (ex RabbitMQ) would provide the communication channel between microservices, however it seems like the proposed implementation in OutSystems (see link above) would require microservices to communicate to each other via REST API calls. Is this the best-practice in OutSystems?

Better yet, does anyone here have experience implementing microservice architecture and can you share your input on the best way to go about it in OutSystems?

Thank you in advance.


Hi DavidA,

Check the Domains and Services Tech talk to see if it inspires you. It covers when to use Microservices and shows the strategy for exposing microservices internally inside the platform, to external systems or to consume microservices from external systems

Hi Francisco,

Thanks so much for sharing this tech talk video. It was helpful in understanding how OutSystems recommends services to interact with another in the most loosely-coupled manner.

That being said, there was no mention of event-driven services and I am still looking for information on how OutSystems can implement event-driven microservice architecture. One of the advantages of using event-driven services is that new services can be created completely independent of the others (on the most part), by simply listening for the events that matter to its domain, and on a large scale implementation - services can pick up where another left off by processing the event messaging queue.

According to the video, we can use loosely-couple Service Actions and expose loosely-coupled query models to achieve decoupling, and then using an orchestrating service when multiple calls are required to several services. But in this proposed architecture, if we want to create a new service to do something new, we'd have to explicitly call the service actions of other services instead of simply "listening" to the events published that matter to that service domain. Also, I'm not sure how this will scale if we want to deploy multiple services in containers in the cloud.

I guess my question is: are there any recommendations for implementing event-driven microservice architecture in OutSystems with or without a messaging queue like RabbitMQ? Or is event-driven architecture simply not something OutSystems currently recommends its developers to use. Any information will be hugely appreciated!

Thank you,

David


Hi David,

I'm also looking for methods to add event based input via a servicebus natively in OutSystems but haven't been able to create such a thing. The main problem is that the only method to trigger an OutSystems application from the outside is via a REST, SOAP or Screen call. 

For example I have made a module with Integration Studio that is triggered when a message is received from the servicebus. This works but since you can't trigger an event with Integration Studio Actions then that's where the magic ends.

I found conformation about this inability of OutSystems in a Forge component that OutSystems created themselves. The OutSystems Workato Connector clearly states that Real-Time triggers are not available for OutSystems and then you need to poll the Workato environment yourself to see if there are new tasks available. 

We do however have "solved" this issue by using some extra components outside of OutSystems. We have created Azure Functions and Azure Logic Apps that are triggered by a message on a Service Bus. This Function/Logic App then calls a REST that I expose with my application. Not the most pretty solution but it works nicely and gives me the event-driven power I need. Posting on a service bus is no problem at all from OutSystems, it's just the incoming part that is problematic.

Hi David and Vicent.

If you want to create an event mechanism in OutSystems, you should consider creating a queue entity exposing process events in some foundation component.

This component will expose that entity (with all relevant data you want in your event representation) and a service action to enqueue an event (and/or a Rest API to be called by external systems).

Whoever wants to generate an event simply call that action passing any relevant event data.

Whoever wants to react to an event consumes the queue entity and add a light process to react to it. Check Design Scalable Database Queueing Using Light Processes

Hi Francisco,

You are solving the servicebus issue with only OutSystems building blocks (entities and a bpt-light proces). That is nice in an OutSystems-only world but that is not the case, at least in my situation (but nice suggestion nonetheless :)). 

In my company we use an external service bus to trigger all sorts of actions within applications. This happens near-realtime. The moment a message is place on the bus the subscribers get an notification and things start happening. This is currently not possible with native OutSystems as I previously described. You can't connect to a servicebus in a subscriber fashion and expect things to work as they would in a "regular" application. We solved this by using external components like Azure Functions and Azure Logic Apps.

Hi Francisco and Vincent,

Thank you both for your very valuable insight and recommendations.

In summary, I see 3 possible options:

  1. Just use weak references - As per the tech talk video, OS11 allows for weaker references between services, which is great. But this is not event-driven design.
  2. Use some middleware to allow the service bus to speak to OutSystems - As per Vicent's implementation. However another component makes me nervous since it's another potential point of failure in an already complex system.
  3. Create your own service bus in OutSystems, leveraging light processes - Sounds fine but really restricts you to the OutSystems ecosystem, and likely not as quick/responsive as a native service bus. 

That being said, I am sending a huge recommendation to OutSystems to enable native support for popular event buses, like RabbitMQ. This would dramatically improve the type of applications and services that can be built using OutSystems, and allow us to implement native event-driven services that can work hand in hand with non-OutSystems services as well. 

Thanks again for all of your input!
David


Vincent Koning wrote:

Hi Francisco,

You are solving the servicebus issue with only OutSystems building blocks (entities and a bpt-light proces). That is nice in an OutSystems-only world but that is not the case, at least in my situation (but nice suggestion nonetheless :)). 

In my company we use an external service bus to trigger all sorts of actions within applications. This happens near-realtime. The moment a message is place on the bus the subscribers get an notification and things start happening. This is currently not possible with native OutSystems as I previously described. You can't connect to a servicebus in a subscriber fashion and expect things to work as they would in a "regular" application. We solved this by using external components like Azure Functions and Azure Logic Apps.


Hi Vincet. My suggestion of also/alternatively exposing a Rest API in your event generation module, is exactly to provide an entry point for any external producer, namely a Service Bus, register events. I.e. the OutSystems event module would subscribe to the external Service Bus, and any OutSystems consumer would subscribe to the event via entity/Light BPT.