none
Reliable Communication from On-Prem .NET services to Azure Service Bus RRS feed

  • Question

  • Hi,

    We have a number of Azure WebJobs that integrate with on-prem apps using Service Bus in a store-and-forward scenario. The overall architecture is that we receive HTTP messages that come in from the Internet through API Management, straight to Service Bus Queues, and then the WebJobs forward them to .NET Core APIs running on prem (again, going through API Management). That's great, because Azure Service Bus is reliable by its very nature; if our WebJob can't talk to the on-prem API for whatever reason, we just release the peek lock, and try again in 10 minutes until it succeeds. 

    My question is...what is the prescribed guidance for reliable messaging going the other way i.e. from on-prem to Service Bus? I'm considering things like "the network is down", or Service Bus itself is offline (yes, it can happen). And yes, I realize I could use MSMQ and then a Windows Service to call Service Bus, but is there a better way suggested way for this "first-mile" part of an on-prem to Azure integration? 

    Thanks!

    PBR

    Tuesday, June 11, 2019 8:38 PM

All replies

  • Hi,

    Wouldn't Your WebJobs fail after receiving HTTP call if ServiceBus were down?

    I mean You already rely on ServicBus on the way down to Your on premises' services...

    What we do (not because ServiceBus ever failed, but because we cannot rely on the network) in our servies is adding db entry for outgoing messages, and mark them as sent on successful push to SB. A background thread checks whether there are not sent messages in the db and retries if needed.

    Thursday, June 13, 2019 10:21 AM
  • I believe the approach that Sebastian is indeed a great way to go about this.

    The SDK has a RetryExponential policy that does this internally in-process but out-of-process approach would be more durable I suppose depending on how bad the network could get for you.

    Monday, July 15, 2019 5:25 AM
    Moderator