Victor Fehlberg’s Tech Postings

The other day at work I needed to change the URL and proxy class of a send port that was using ordered delivery, but that was already suspended with lots of messages queued up in the instance.  So, I did what most of us would have tried, I changed the URL and proxy class, and then I resumed the send port.  Did this work?  No.  The send port kept trying to send the messages to the old URL, using the old proxy class.

So I started trying to see if there was anyway to resolve this without losing messages.  I did what most administrators would have done next: I bounced the host instance.  Did that work?  No.

Then I got creative.  I decided to change the host instance of the send port to another available host instance.  I made the change and pressed ok, but got an error indicating that I couldn’t change the host instance since ordered delivery was on.  So I put things back the way they were and tried once more to resume the instance.  At this point, you’re probably thinking this didn’t make any difference (as I did).  But guess what?  It made all the difference.   Suddenly messages began flowing with the new URL and proxy class!  I couldn’t believe it.  I guess the attempted change of the host instance triggers something in BizTalk, causing it to read in the URL and proxy class again…

I presume this problem exists if you are only trying to change the URL as well (and not the proxy), but I didn’t take the time to verify this.  Hope this information helps someone out there!