none
Safe to change send port delivery status to and from ordered delivery using import binding?

    Question

  • Import binding can change the delivery status of a send port  to and from ordered delivery without first having to unenlist the port, but is this safe?

    If you try to do the same using the UI you'll get the error:

    Failed to update binding information. (mscorlib)

    This property cannot be currently changed.  Please unelist the send port before changing this property. (Microsoft.BizTalk.ExplorerOM)

    So, is it safe to change send port delivery status to and from ordered delivery using import binding? What happens behind the scenes during an import binding?

    Let's say you have an ordered send port with messages queuing up, and you now import a binding file changing the port to unordered delivery? What happens to the messages in the queue? 

    Thursday, September 18, 2014 7:53 AM

Answers

  • If you're providing integration service using BizTalk, you should always factor in "scheduled downtime".

    If the change is to update the existing ports, for "safe" way, I would always unenlist the port and update it. There is where BizTalk's suspended resumable process, host instances all comes in to play.

     


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    Thursday, September 18, 2014 1:08 PM

All replies

  • Hi Michael,

    You're right.  You can work around this in changing the Ordered delivery settings by importing the binding but if you use UI you get the above error.

    So whenever I use any scripts (or binding) to change setting like this, I always ensure I unenlist the send port. I feel it’s safe and clean way of updating the bindings.


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    Thursday, September 18, 2014 8:24 AM
  • Hi AshwinPrabhu

    But what if you want to make sure you do not loose any messages? Unenlisting will (as you know) remove the subscription, so you will potentially loose messages using your approach.

    I've done very little testing on this and only for stopped ordered ports, but it seems changing from say ordered to unordered will send queued messages through the updated (now) unordered port. At the same time the ordered port service instance will still be present and active, with the messages of the queue still hanging on to this, but having produced this suspension error (5754):

    The instance was reactivated elsewhere and all work related to this instance should be abandoned. This could be due to a database/network failure, which caused the instance to be freed and then reactivated.

    Trying to resume such messages by mistake leads to this error (5753):

    The InboundTransportLocation is disallowed. This could be because the receive location is disabled or its service window is currently inactive. 

    But since a copy of the queued messages already went trough the updated port, terminating the messages and the service instance, should be safe right?

    Thanks

    Michael


    Thursday, September 18, 2014 9:32 AM
  • If the intension is to change the Ordered delivery. I would normally follow the update process as follows.

    • Stop the inflow message ports .
    • Ensure all the received (or inflight) messages  are processed by the send port (which has the Ordered delivered flag on/off)
    • When you have ensured no messages are to be processed by this send port. Unlist the send port, change the Order delivery flag. Enlist it.

    This will ensure no in-flight message is affected and new in came messages are to follow the updated send port config for Ordered delivery.


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    Thursday, September 18, 2014 9:48 AM
  • Hi AshwinPrabhu

    That's of course possible, and useful I guess in many situations, but what if you need the receive locations running due to SLAs or similar?

    To restate my question: Is it safe to change send port delivery status to and from ordered delivery using import binding, whilst  keeping everything running? There might be a bit of cleanup afterwards but IS IT SAFE?

    Thanks

    Michael

    Thursday, September 18, 2014 10:01 AM
  • Actually, I would take this is a different direction and point out that this is not a technical issue but rather a process issue.

    Regardless of how importing a binding file works (actually, I had always assumed the Ports were silently Unenlisted during Import), you should not rely in this for uninterrupted message flow.  That is was a scheduled downtime is for.

    On the question of "is it safe" my general answer would be, for non-emergency operations that modify the system outside of a known maintenance window, no.

    Thursday, September 18, 2014 11:41 AM
    Moderator
  • Well, until we (anyone?) know what is actually going on during an import of a binding file, we can of course handle the situation via procedures build on better-safe-than-sorry and scheduled downtimes.

    However, some organizations use BizTalk as an infrastructure component to increase availability, taking BizTalk down to flick a switch seems kind of disappointing, even old school to me.

    But I guess, if every publisher (i.e. client a net-tcp receive location) implements its own queue (maybe via binding) even unscheduled down times could be acceptable.

    Or we could pay another set of BizTalk licenses, and have two separate BizTalk installations behind a load balancer, making rolling deployments possible. Sounds expensive though...

    Thanks

    Michael

    Thursday, September 18, 2014 12:02 PM
  • If you're providing integration service using BizTalk, you should always factor in "scheduled downtime".

    If the change is to update the existing ports, for "safe" way, I would always unenlist the port and update it. There is where BizTalk's suspended resumable process, host instances all comes in to play.

     


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    Thursday, September 18, 2014 1:08 PM