Hello there,

A couple of web services I have built that process through BizTalk are
typical query type requests. If for some reason the database server is down
or it's taking a long time to respond to the request, the client will time
out. Meanwhile, BizTalk is still processing the request internally. Once it
finally completes the request the message is basically set to suspended as
it has no where to send the response back. Recently a backup of the database
caused all incoming requests to time-out (this is in a test environment) and
we ended up with a multitude of suspended messages and over 350,000 records
in the BizTalkServerIsolatedHostQ table.

What is the best way to handle timeouts on web service requests within
BizTalk? I don't want to have to delete all those messages when the request
times out. I'm working towards resolving the time-out issues with the
database server, but even so, it shouldn't cause all these issues within
BizTalk.

Thanks in advance.

[ Post a follow-up to this message ]

Ok, I've done further research and determined how to properly handle this.
BizTalk thankfully provides this capability quite easily. My transaction is
flagged as long-running. Simply set the timeout value for the long-running
transaction and you should be good to go!

Here is a great article that helped me understand this... even though I'm
not implementing these as asynchronously.

http://msdn.microsoft.com/library/d...>
iwithbts.asp

Cheers,
Andrew

"Andrew" <andrew.bryson@no-reply.com> wrote in message
news:bV0Jd.156629$8l.26963@pd7tw1no...
> Hello there,
>
> A couple of web services I have built that process through BizTalk are
> typical query type requests. If for some reason the database server is
> down or it's taking a long time to respond to the request, the client will
> time out. Meanwhile, BizTalk is still processing the request internally.
> Once it finally completes the request the message is basically set to
> suspended as it has no where to send the response back. Recently a backup
> of the database caused all incoming requests to time-out (this is in a
> test environment) and we ended up with a multitude of suspended messages
> and over 350,000 records in the BizTalkServerIsolatedHostQ table.
>
> What is the best way to handle timeouts on web service requests within
> BizTalk? I don't want to have to delete all those messages when the
> request times out. I'm working towards resolving the time-out issues with
> the database server, but even so, it shouldn't cause all these issues
> within BizTalk.
>
> Thanks in advance.
>

[ Post a follow-up to this message ]

Andrew,

If you don't want to put it all in a long running transaction and handle the
timeout, simply put a parallel branch in place with a custom timeout in
place.  This will force the execution continuation when the timeout occurs
and you can handle it nicely programatically.  Using a long running or atomi
c
scope to do this, like you say works well too, not sure if either is better
performance wise.
Ben

"Andrew" wrote:

> Ok, I've done further research and determined how to properly handle this.
> BizTalk thankfully provides this capability quite easily. My transaction i
s
> flagged as long-running. Simply set the timeout value for the long-running
> transaction and you should be good to go!
>
> Here is a great article that helped me understand this... even though I'm
> not implementing these as asynchronously.
>
> http://msdn.microsoft.com/library/d...
soiwithbts.asp
>
> Cheers,
> Andrew
>
> "Andrew" <andrew.bryson@no-reply.com> wrote in message
> news:bV0Jd.156629$8l.26963@pd7tw1no... 
>
>
>

[ Post a follow-up to this message ]

Thanks for the tip, Ben!

Andrew

"Ben Cuttriss" <BenCuttriss@discussions.microsoft.com> wrote in message
news:4AA16904-EF46-4DE6-83E5-FEFA479E337D@microsoft.com...[vbcol=seagreen]
> Andrew,
>
> If you don't want to put it all in a long running transaction and handle
> the
> timeout, simply put a parallel branch in place with a custom timeout in
> place.  This will force the execution continuation when the timeout occurs
> and you can handle it nicely programatically.  Using a long running or
> atomic
> scope to do this, like you say works well too, not sure if either is
> better
> performance wise.
> Ben
>
> "Andrew" wrote:
> 

[ Post a follow-up to this message ]