NServiceBus.AmazonSQS
NServiceBus.AmazonSQS copied to clipboard
Particular
Loosen the requirements for native messages
Currently, the transport does a number of things like base64 encoding and the message type header requirement that makes it hard to use native messages. Ideally, we would flip around the requirements and everything that is NServiceBus specific should be additive on top of native messages and not be a requirement.
cc @boblangley @andreasohlund
We have several non-NSB SQS queues (wired up via SNS topic subscription) and we would love to be able to directly tap into these queues via SQS Transport. Currently we have our own custom SQS polling mechanism that pulls the messages out of SQS and puts them into another queue managed by SQL Transport. It's obviously not ideal to have two queues joined like this, and would love to just be able to leverage the SQS queue and transport directly.
Same as @mikesigs for me. Being able to leverage the SQS queue and transport directly will unlock many great capabilities for us. Looking forward to seeing what updates can be made here.
Thanks for those information @mikesigs and @efleming18 We will try to look at this in the next AWS work that we will do
@mikesigs @efleming18 We have started working on this and will keep you posted once it is available
There are still some restrictions when it comes to what is required / assumed to be an a native message to make it possible to handle it properly on an endpoint. For that reason, we are keeping the issue open.
This has been further improved in https://github.com/Particular/NServiceBus.AmazonSQS/pull/2341 (on master) and will be released in 6.2.0 as soon the backport of the feature is completed in https://github.com/Particular/NServiceBus.AmazonSQS/pull/2350.
With that the transport will be capable of handling any message without restrictions on headers or format. We'll also augment documentation and samples to add details on the new feature.
