Hello,

We have an orcheatration that required to process 10 files in group. We use
correlation to get all the files. It works very smooth in our development
environment. However, when it was testing in QC environment, some receive
locations were not read and disable after BizTalk retried several times. The
Orchestration could still continue to run after manually enable the receive
locations again.

Does anyone have similar experience of it? Any hint to trouble shoot and
solve it?

[ Post a follow-up to this message ]

Hi,

Is BizTalk logging any errors to the event log? If so this may give you a
clue as to why the problem is occurring.

Regards,

Alan


"CY" wrote:

> Hello,
>
> We have an orcheatration that required to process 10 files in group. We us
e
> correlation to get all the files. It works very smooth in our development
> environment. However, when it was testing in QC environment, some receive
> locations were not read and disable after BizTalk retried several times. T
he
> Orchestration could still continue to run after manually enable the receiv
e
> locations again.
>
> Does anyone have similar experience of it? Any hint to trouble shoot and
> solve it?

[ Post a follow-up to this message ]

Here is the event log, we suspect it is a MSDTC causes that problem.


Event Type:	Information
Event Source:	MSDTC
Event Category:	CM
Event ID:	4156
Date:		21/9/2004
Time:		6:17:58 PM
User:		N/A
Computer:	QCMBCUSI01
Description:
String message: Session idle timeout over, tearing down the session.


Event Type:	Error
Event Source:	BizTalk Server 2004
Event Category:	BizTalk Server 2004
Event ID:	5649
Date:		21/9/2004
Time:		6:31:41 PM
User:		N/A
Computer:	QCMBCUSI01
Description:
The receive location
" \\qcmbcusdbmgt01\interface\CFMS\Inbound\
CFMS_booking\incoming\CFMS_booking_
*_in07_*.dat"
is shutting down. Details:"The FILE receive location
 \\qcmbcusdbmgt01\interface\CFMS\Inbound\
CFMS_booking\incoming\CFMS_booking_*
_in07_*.dat exhausted the network retry attempts. ".



"Alan Smith" wrote:
[vbcol=seagreen]
> Hi,
>
> Is BizTalk logging any errors to the event log? If so this may give you a
> clue as to why the problem is occurring.
>
> Regards,
>
> Alan
>
>
> "CY" wrote:
> 

[ Post a follow-up to this message ]

It has nothing to do with MSDTC, which tears down idle sessions on a regular
basis.

The problem is having a remote file receive location. If a network problem
causes errors connecting to the remote file share (or the other server goes
down) then Biztalk disables the receive location.
This problem will always happen with remote file locations.
You have three options:
1. move all file receive locations onto the Biztalk Server
2. write a service that listens for the ReceiveLocationDisabled WMI event
and re-enable it
3. use a different transport

Greg


"CY" <CY@discussions.microsoft.com> wrote in message
news:EDC35C35-BAE8-41B3-A054-A3FDF1C876AA@microsoft.com...
> Here is the event log, we suspect it is a MSDTC causes that problem.
>
>
> Event Type: Information
> Event Source: MSDTC
> Event Category: CM
> Event ID: 4156
> Date: 21/9/2004
> Time: 6:17:58 PM
> User: N/A
> Computer: QCMBCUSI01
> Description:
> String message: Session idle timeout over, tearing down the session.
>
>
> Event Type: Error
> Event Source: BizTalk Server 2004
> Event Category: BizTalk Server 2004
> Event ID: 5649
> Date: 21/9/2004
> Time: 6:31:41 PM
> User: N/A
> Computer: QCMBCUSI01
> Description:
> The receive location
>
" \\qcmbcusdbmgt01\interface\CFMS\Inbound\
CFMS_booking\incoming\CFMS_booking_
*_in07_*.dat"
> is shutting down. Details:"The FILE receive location
>
 \\qcmbcusdbmgt01\interface\CFMS\Inbound\
CFMS_booking\incoming\CFMS_booking_*
_in07_*.dat exhausted the network retry attempts. ".[vbcol=seagreen]
>
>
>
> "Alan Smith" wrote:
> 
a[vbcol=seagreen] 
We use[vbcol=seagreen] 
development[vbcol=seagreen] 
receive[vbcol=seagreen] 
times. The[vbcol=seagreen] 
receive[vbcol=seagreen] 
and[vbcol=seagreen] 

[ Post a follow-up to this message ]

If there is a network problem, all receive location will should be disabled.
Ping did not report any problem in network connectivity. File explorer can g
o
the the file share too.


"Greg Forsythe" wrote:

> It has nothing to do with MSDTC, which tears down idle sessions on a regul
ar
> basis.
>
> The problem is having a remote file receive location. If a network problem
> causes errors connecting to the remote file share (or the other server goe
s
> down) then Biztalk disables the receive location.
> This problem will always happen with remote file locations.
> You have three options:
> 1. move all file receive locations onto the Biztalk Server
> 2. write a service that listens for the ReceiveLocationDisabled WMI event
> and re-enable it
> 3. use a different transport
>
> Greg
>
>
> "CY" <CY@discussions.microsoft.com> wrote in message
> news:EDC35C35-BAE8-41B3-A054-A3FDF1C876AA@microsoft.com... 
> " \\qcmbcusdbmgt01\interface\CFMS\Inbound\
CFMS_booking\incoming\CFMS_bookin
g_
> *_in07_*.dat" 
>  \\qcmbcusdbmgt01\interface\CFMS\Inbound\
CFMS_booking\incoming\CFMS_booking
_*
> _in07_*.dat exhausted the network retry attempts. ". 
> a 
> We use 
> development 
> receive 
> times. The 
> receive 
> and 
>
>
>

[ Post a follow-up to this message ]

The network problem could be anywhere from the file subsystem software down,
not just at the IP layer.
The behaviour of SMB file shares can sometimes be a bit unpredictable.

Another possibility is some software on the remote server locking the file
and preventing deletion e.g backup or anti-virus software.
Although with the default retry settings this problem would have to exist
for over 20 minutes

How does the file get created  and how big is it?

p.s. ignore option 2 It would appear BTS 2004 no longer fires a WMI event on
receive location disabled.

Greg

"CY" <CY@discussions.microsoft.com> wrote in message
news:4A2AB8B6-3805-4AC4-9333-3900F2DEDCC7@microsoft.com...
>
> If there is a network problem, all receive location will should be
disabled.
> Ping did not report any problem in network connectivity. File explorer can
go[vbcol=seagreen]
> the the file share too.
>
>
> "Greg Forsythe" wrote:
> 
regular[vbcol=seagreen] 
problem[vbcol=seagreen] 
goes[vbcol=seagreen] 
event[vbcol=seagreen] 
" \\qcmbcusdbmgt01\interface\CFMS\Inbound\
 CFMS_booking\incoming\CFMS_booking_[vbco
l=seagreen]
 
 \\qcmbcusdbmgt01\interface\CFMS\Inbound\
 CFMS_booking\incoming\CFMS_booking_*[vbc
ol=seagreen]
 
you[vbcol=seagreen] 
group.[vbcol=seagreen] 
the[vbcol=seagreen] 
shoot[vbcol=seagreen] 

[ Post a follow-up to this message ]

When we see this on the SQL adapter, it is because errors have crossed the
adapter threshold level.

I would suggest looking for errors on the adapter, and it is by adapter, not
rec location.  Then the number of errors should equal the error threshold se
t
for the file adapter in your case.  Once that number has been crossed, the
adapter is disabled until it is manually enabled.

We are working on using MOM to respond to the alert in the BT management
pack and parse the rec location and re-enable it.  Anyone with similar
efforts is welcome to pass on their lessons learned.

"Greg Forsythe" wrote:

> The network problem could be anywhere from the file subsystem software dow
n,
> not just at the IP layer.
> The behaviour of SMB file shares can sometimes be a bit unpredictable.
>
> Another possibility is some software on the remote server locking the file
> and preventing deletion e.g backup or anti-virus software.
> Although with the default retry settings this problem would have to exist
> for over 20 minutes
>
> How does the file get created  and how big is it?
>
> p.s. ignore option 2 It would appear BTS 2004 no longer fires a WMI event 
on
> receive location disabled.
>
> Greg
>
> "CY" <CY@discussions.microsoft.com> wrote in message
> news:4A2AB8B6-3805-4AC4-9333-3900F2DEDCC7@microsoft.com... 
> disabled. 
> go 
> regular 
> problem 
> goes 
> event 
> " \\qcmbcusdbmgt01\interface\CFMS\Inbound\
CFMS_booking\incoming\CFMS_bookin
g_ 
>  \\qcmbcusdbmgt01\interface\CFMS\Inbound\
CFMS_booking\incoming\CFMS_booking
_* 
> you 
> group. 
> the 
> shoot 
>
>
>

[ Post a follow-up to this message ]