One of the more common BizTalk connection problems to end systems is a timeout. Maybe you are dealing with an unexpected spike in data, or perhaps your connection is just a bit lethargic today.
No problem, just extend the timeout, right? Errm… which one? If you look at the port bindings, you can see there are often several timeouts. Without knowing the details of how the adapter works, it may be unclear which one you need.
Here’s how you figure it out.
So, you tried to look for the timeout to extend and were faced with something like this. You’re stumped as to which one is causing your issue.
Experimentation can give you the answer. The trick is to track what the relevant port is doing in the admin console.
Before you start, just make sure you have at least a basic level of tracking enabled on the relevant pipeline. Otherwise, you won’t be able to query on port events as described below.
First, set up a query of Tracked Messages Events with the offending Port Name. You should see the initial message as a Receive event, and the timeout as a Transmission Failure. Now you can take advantage of the gap between these times.
Did the gap in events match one of those timeouts? Great, you’ve probably identified the right one.
But what if it matched more than one? In this case, choose one of the candidate timeouts and shorten it (you still want it to fail, you’re just trying to identify the right one). Then Resume the failed message. If the gap between Receive and Transmission Failure is shorter this time, you know you found the right timeout, and can now extend it the other way as needed.
Hope that helps. It seems obvious in retrospect, but the above approach helped me solve an intermittent timeout issue that had plagued us for months, because the offending timeout simply wasn’t the one that seemed logical.