rebus-org / Rebus

:bus: Simple and lean service bus implementation for .NET
https://mookid.dk/category/rebus
Other
2.26k stars 353 forks source link

Spoof Rebus from Java, C++ etc. #1153

Closed KennethJakobsen closed 3 months ago

KennethJakobsen commented 3 months ago

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,

mookid8000 commented 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.

KennethJakobsen commented 3 months ago

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)

mookid8000 commented 3 months ago

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. 🙂

KennethJakobsen commented 3 weeks ago

@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?

KennethJakobsen commented 3 weeks ago

It was not, I registered the handler wrong. everything is working now