0
votes

We have an NServiceBus endpoint that monitors an Azure Service Bus Queue (using Azure as a transport). But not all the clients that send messages to the queue are .NET-based.

Can an NServiceBus endpoint be configured to accept a simple string as input?

I've tried intercepting messages with a class that implements IMutateIncomingMessages, but at this point deserialization from the Azure transport has already failed.

I can inspect the message coming in in a class implementing IMutateIncomingTransportMessages, but I'm not sure if this is the right place.

What is the best way to configure NServiceBus to handle a message being published in the following format (keep in mind this can also come via the Java or Node SDKs, or via an Azure REST endpoint):

 var brokered = new BrokeredMessage("This plain string represents the data.");
 queueClient.Send(brokered);

Deserialization of this message will fail, because it contains a string, not a byte array as expected by the Azure transport deserializer.

PS: I know it is possible to expose the endpoint as a WCF service, but currently we only have NServiceBus.Host processes that pull from the queue and the WCF solution does not feel like the right solution to me.

1
Would custom serialization work for you ? docs.particular.net/samples/pipeline/multi-serializerSimon
It just might. I'll give it a go. Thanks!willem
I've delved a bit deeper into this now. Unfortunately the Azure Transport code insists that the message be in byte[] format. This happens before any NServiceBus serializers kick in, so this won't work.willem

1 Answers

2
votes

As mentioned on twitter earlier, but just including it here for completeness...

If you want to integrate natively, then you have to modify parts of the nsb pipeline to accomodate for your environment.

See https://github.com/yvesgoeleven/NServiceBus.AsbNativeIntegration for an example of such an integration.