Examples of assyst Message Bus Request Mappers

The underlying technology is ActiveMQ (Classic), so the documentation for that may answer some of your questions. 

The fields which are required are either Queue or Topic (depending on how you want delivery to work), and Body. 

The main limitation is that only text/string messages can be consumed by ETM channels. So, you could have Channel A submit a Message with a CSV format data which was then consumed by Channel B (using the CSV message format). However you could not have Channel A submit messages using XLSX/PNG etc. data for consumption by another channel. 

One scenario where using the message bus would be useful would be to support asynchronous processing on a Remote Upload channel whilst using a Response Mapper. The Remote Upload channel could submit the received Payload to the message bus, then immediately send a custom response to the caller (via a response mapper). Another channel could process the queued message in the background. 

Do you have more specific questions or uses cases?

Thank you very much, Paul!

I had not come across that article, and the specifics of Queues implemening a sort of “loadbalancer” were new to me.

However, the main limitation I’m experiencing is the lack of a direct example to work from, such as a example datamapper to add a message to the message bus.

I’ve spent a lot of time trying to get the syntax correct when adding data to the Body, Message Property, Priority, and Time To Live, and this is where the main issue arises as I keep getting different errors and not figuring out the syntax.

If there was an example of a Message Bus Request Mapper on the wiki, it would be much easier to know what format ETM is expecting as input when data mapping, or even better, a set of example channels that display some “best practices” for both adding and reading data from the message bus.

The specific use case I’m trying to get to work is the one you proposed in this thread;

but I’ve not had the opertunity to set aside time to try getting that to work. However upon trying to do so a few weeks ago led me to realize i did not know enough about the use of destinations and the message bus.

How to use the message bus seemed out of topic to bring up in that thread, and that’s why this is a sepererate question😅

The simplest mapper would have a Body with expression “Hello, World!” and a Queue expression “MyQueue”. When this mapper processes an Import Record it will post a message to the specified queue, which will remain in the queue until something reads it, or the ActiveMQ process is restarted.

A Channel to consume these messages would specify:

• Source: Assyst Destination
• Message format:  Free Text
• Queue: MyQueue

Such a channel would create a single record import for each invocation of the mappper.

From that simple example it should be possible to incrementally add complexity. 

Thank you very much for the response.
Due to a change in team priorities, I’ve been unable to work on the problem requiring this until now.
However, there might be some miscommunication or something I’m not quite grasping here.

The issue I have is that for Message Bus Response mappers, there is only a limited set of fields to choose from, and I’m not sure how to apply what you described to this.

To help clarify what I’m trying to do:

I’m trying to get ETM to post some details after a channel has run, such that these details can be picked up by a different channel for further processing. To illustrate the general idea:

The plan is to consolidate and reuse the Get latest status logic as this has to be called asynchronous from the reservation, and is similar for both start inputs. 

However, I’ve not been able to get this working correctly, given that the options in the Message Bus Response data mappers do not include anything about queue or topic, only response headers and body are available, as far as I can tell.

So what I could really use is an example of a Message Bus Response data mapper that display how to set the different properties in a Message Bus Response using the available fields, as this is not provided on the wiki. Given such an example I could then easily modify with the correct topic or queue name as needed.

Message Bus Response mappers are used for Message Bus/Destination Source channels. They send a reply back to a special queue that is created as part of the initial message submission. 

For example if an assyst Action Destination  with target “ETM_NewActions” is configured to wait for a reply then when an action is logged a new message is sent to the ETM_NewActions queue. That message includes a JMSReplyTo property with a value something like ETM_NewActionsReplies. asyst then waits for a new message to be sent to the ETM_NewActionsReplies queue (with a correlation id linking the original & reply messages).

See the wiki  for details of if, when & what message is sent to the reply queue. 

Messages created by Message Bus Request mappers don’t support replies - they are asynchronous. So they can trigger another channel - but don’t wait for that channel to respond. 

Waiting for a response would be an enhancement, as would explicit support for channel chaining.

Note that in principle you could use an HTTP Request Mapper & a Remote Upload channel to support synchronous inter-channel communication. However I would caution against this - there are risks of oddities like worker thread starvation and startup race conditions that could lead to ‘interesting’ behavior.