Closed KennethJakobsen closed 3 months ago
There's a few bits of information here: https://github.com/rebus-org/Rebus/wiki/Wire-level-format-of-messages – and then I recomment you check out the relevant transport for details that cannot lie 😁 e.g. for Azure Service Bus in its DefaultMessageConverter
Generally, I recommend that people treat their integrations with other platforms as exactly that: Integrations 🙂 which usually implies building channel adapters when interfacing with non-Rebus systems. But this advice is mostly for when people try to consume messages whose formats are already laid out, and so it would be pure, steep, up-hill fighting to try to make Rebus consume these messages.
But if you're in control of the message format, it's definitely possible to make other platforms send messages that Rebus will happily consume.
Sorry for the late reply @mookid8000 We are in complete control of the message format - so it would not be too problemetic to enforce the rebus model. regarding topics is it the receiving end that configures the forwarding or would it be the sender (a manual step in this case)
regarding topics is it the receiving end that configures the forwarding or would it be the sender (a manual step in this case)
I would say that it's the receiving end's responsibility to carry out whatever it takes to start listening to events. With all the official Rebus transports, a subscriber will call e.g.
await bus.Subscribe<SomeEvent>();
which will ensure that a topic for SomeEvent
exists (usually named something like SomeAssembly.SomeNamespace.SomeEvent, SomeAssembly
, possibly with invalid characters replaced by underscores or something similar) and that the subscriber's input queue is then bound to the topic (whatever that means in the context of the given broker).
This way, publishers can stay oblivious of whether there are 0..n subscribers listening. 🙂
@mookid8000 The solution I'm trying to do is: IoT Device -> Azure IoT Hub -> Azure Service Bus Queue -> Rebus Worker service.
I'm currently having trouble getting rebus to route the message, i'm suspecting that it is because i'm having issues getting the ASB converter in IOT hub to set the Subject property. Am i on the right track?
It was not, I registered the handler wrong. everything is working now
Hi I use Rebus alot, and is faced with external systems not built on dotnet needing to send messages to our message broker. These messages are then consumed by dotnet systems that uses rebus. Is there any documentation on what rebus does to the messages in order to deserialize correctly on receive.
Since there is no C++ version of rebus, I would prefer to just manually set the properties (and envelope) needed to make this possible,