Include Assyncronous Message Queuing Connector Capabilitiies

Install Processes
On our radar
Due the desired movement of Outsystems into the Enterprise IT world, from my experience, sooner or later, it will be needed a way to easily connect to MQ based ESB's or EAI. It should be a native feature of the Agile platform to have a way to subscribe to a message queue (MSMQ or JMS) and fire an Action or a BPT process whenever a message with certain characteristics arrives to that queue.
It should be analyzed the fact that an ESB or EAI processes thousands of messages per second, so I believe that a tie to the RDBMS might not be a good technical solution.

It should also be possible to write to queues (the idiom should be the same as Webservices).
At least the standard: Point-to-Point, Publish/Subscribe and Broadcast message transmission/reception models should be supported.
Created on 31 Jan 2013
Comments (10)
Since this idea was created (more than 3 years now), has OS made any development towards native message queuing support?

We asked the same thing on several occasions, or as an alternative, a way to deploy C# Windows Service or Actions that would behave like Windows Services.

Until now we have no solution from Outsystems, we are subscribing to RabbitMQ with Windows Services running in another box, and when a message arrives we push them to an Outsystems web service.

Must have

I would like to point out that MSMQ is enabled on the Outsystems servers. You can access them by writing an extension.

You can write an extension to send and receive messages on MSMQ or any other Queue, but you cannot subscribe to the queue as it would require a process that never dies.

I think you are wrong.

in the extension you can create a receiver that fires an action when a message has been received by using "messagequeue.BeginReceive". When a message arrives in the method you can specify here: "messageQueue.ReceiveCompleted += methodToCallWhenReceived"

In that method you first call EndReceive to get the message and at the end you can call beginReceive again so it will keep listening for messages.

You can create a new thread to subscribe the queue, but I expect that to be killed along with the IIS thread when recycling option hit the parent thread.

If you already returned the execution back to Outsystem, how will you call something on Outsystems? Call a web service?

That is why I suggested something like a Windows Service, that we could rely not to be killed (recycled).

So reading through this thread, best practice for Rabbit MQ subscribe sounds like the customer should create a REST/SOAP API that can push/pull from the MQ, and the OutSystems service will use the API to process data from and to the MQ when necessary, correct? Seems like there is not a good, consistent way to subscribe to an MQ without using some sort of web service.



In one of our implementations, we created a Windows Service that subscribes to the MQ, and "wakes" Outsystems via REST service every time there is a new message to be processed.

The Outsystems REST method once wakened connects to MQ and retrieves and process all messages that it finds there.

The Windows Service is running on another host, completely separated from the Outsystems environment, as we cannot install anything in the Outsystems cloud. 

A bit more information about this issue.

Sending There is no problem in this department, you can easily create an Extension to send messages to MQ


  • asynchronously  - creating an extension to get MQ messages, and call it from a timer. The issue, in this case, is that the minimal schedule for the timer is 5 min.
  • realtime - As I described before, Outsystems doesn't support MQ in some manner that we could use to do this, neither provide means to create a "service" running forever where we could put the MQ listener/subscriber.
    Our solution was to create a simple Windows Service application, with a subscriber that only checks for new messages. When there is one new message, it calls a REST service in Outsystems, so that we can retrieve and process the messages there.

Regarding receiving, another issue that we found is the error handling. MQ allows you to retrieve a message without removing it from the queue, this way you are able to undo the operation if processing the message result in an error.  But that is not possible to do in an Outsystems extension, you need to close the connection and return the message to Outsystems in order to process it, then if an error occurs is already too late to tell MQ to leave the message in the queue.