Creating an instance of nservicebus iBus with a different transport protocol within a handler. MSMQ to Azure

0
votes

We have an existing servicebus running off of MSMQ that consumes an event that needs to publish a command to a bus running on Azure.

We're exposing azure to the outside world and keeping msmq for internal messages.

I've tried to new up an instance of a send only bus to accomplish this but with no luck, some pointers/code samples would be greatly appreciated.

EDIT

I have not found an answer to this question and my workaround as of now is to set up a web api that hosts nservicebus running Azure as the transport protocol. So my MSMQ consumer will call the api and that api will send a command to to our Azure bus. Not ideal...at all, but it's what I could come up with.

EDIT2

Created slightly different, but related question regarding gateway configuration: Nservicebus msmq to azure queue using gateway

2
azurenservicebusnservicebus4
are you trying to connect on-premise bus with one on azure? – Chris Bednarski
Exactly, on-premise to Azure – Hugo Forte
I read through this document: particular.net/articles/windows-azure-transport. But it seems to want me to change the on-premise hosting to not use msmq, which I am unfortunately not in a position to change. – Hugo Forte
have you looked at the gateway support.nservicebus.com/customer/portal/articles/… ? – Chris Bednarski
Definitely. Gateway is the bridge between multiple sites. Each site can choose their own queuing technology. The only thing that needs to be common is the serializer. (although that's been logged as a bug). We're using it to bridge multiple locations that are using MSMQ and SQL queues. – Chris Bednarski

2 Answers

0
votes

I've aggregated all my comments into this answer & added more.

Try using the NServiceBus gateway to do the inter-site communication.

Gateway is the bridge between multiple sites. Each site can choose their own queuing technology. The only thing that needs to be common is the serializer. (although that's been logged as a bug).

When the article says that http/https are the only channel types supported right now, but that cloud sites such as Azure/Amazon SQS are planned for the future, it refers to the bridging technology only. Once there is an Azure (or Amazon SQS) gateway channel, there will be no need for the intermediate HTTP(S) step.

Current examples:
a) MSMQ Q on SiteA => HTTPS channel => Azure Q on SiteB
b) MSMQ Q on SiteA => HTTPS channel => SQL Q on SiteB

Future examples:
a) MSMQ Q on SiteA => Azure channel which is also an Azure Q on SiteB
b) MSMQ Q on SiteA => Azure channel => SQL Q on SiteB

The channels refer to the transport protocol used by the gateway. The queuing technology used by the endpoint is not relevant.

0
votes

There's an example Yves Goeleven put together here.