BizTalk Server - Preventing loss of input file in case of Biztalk failures

This is Interesting: Free IT Magazines  
Home > Archive > BizTalk Server > March 2005 > Preventing loss of input file in case of Biztalk failures





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Preventing loss of input file in case of Biztalk failures
vikramswami

2004-12-23, 5:51 pm

I have a biztalk project which reads from a location for a flat file(comma
sepeated) and loads the info in a database table. The input file is
received from another application which creates this file at it's End of
Day. Someimes what happens is that the Biztalk project reads the file and
removes it from the receive location but then meets with some error while
processing the file(lets supposes for any reason). In such cases, my input
file is lost and I have to request the sending application to re process
and send the file which could be embarassing. Is there some way by which
the Biztalk can be stopped from removing the file from the receive
location.
Any help would be appreciated

regards
Vikram

Jon Flanders

2004-12-23, 5:51 pm

You need to add a registry DWORD value named RenameReceivedFiles to the Host
registry hive (HKLM\SYSTEM\CurrentControlSet\Services\
BTSSvs{GUID}) - set
the value to 1 to have the file adatper rename the files instead of deleting
them.

--
Jon Flanders
http://staff.develop.com/jfland/
"vikramswami" <vikramswami@rediffmail.com> wrote in message
news:7a4df50d3c377e09fb5ab4dfd78e92f5@lo
calhost.talkaboutsoftware.com...
> I have a biztalk project which reads from a location for a flat file(comma
> sepeated) and loads the info in a database table. The input file is
> received from another application which creates this file at it's End of
> Day. Someimes what happens is that the Biztalk project reads the file and
> removes it from the receive location but then meets with some error while
> processing the file(lets supposes for any reason). In such cases, my input
> file is lost and I have to request the sending application to re process
> and send the file which could be embarassing. Is there some way by which
> the Biztalk can be stopped from removing the file from the receive
> location.
> Any help would be appreciated
>
> regards
> Vikram
>



Matt Milner

2004-12-27, 8:46 pm

I believe that option only renames them temporarily and is meant to keep you
from getting files resubmitted. According to the docs, after the file is
renamed, if it can be submitted to the message box or suspended in the
message box, the renamed file is still deleted. The processing is
different, but the end result is the same in that your file gets deleted
when you are done. THis just adds some fail safe features.

if the message gets suspended, then you can save the message contents from
the Health and Activity Tracking (HAT) tool by right clicking and choose
Save Message. You can also use WMI to get suspended message instances and
write them out to file. Even though your message is suspended, BizTalk
still was able to persist it to the message box (albeit in a suspended
state) so you can get the contents back.

If for some reason you are having problems where the file is not being
persisted via suspension, but still getting deleted, then you'll want to
follow Jon's suggestion below to take care of that.

matt
http://www.m3technologypartners.com/blogs/



"Jon Flanders" <jfland@develop.com> wrote in message
news:O9fAp4Q6EHA.2876@TK2MSFTNGP12.phx.gbl...
> You need to add a registry DWORD value named RenameReceivedFiles to the
> Host
> registry hive (HKLM\SYSTEM\CurrentControlSet\Services\
BTSSvs{GUID}) - set
> the value to 1 to have the file adatper rename the files instead of
> deleting
> them.
>
> --
> Jon Flanders
> http://staff.develop.com/jfland/
> "vikramswami" <vikramswami@rediffmail.com> wrote in message
> news:7a4df50d3c377e09fb5ab4dfd78e92f5@lo
calhost.talkaboutsoftware.com...
>
>



Jon Flanders

2004-12-28, 2:46 am

I assumed it was a suspended message situation If it isn't - what I
usually recommend is creating a send port that also subscribes to the
receive port and essentially becomes a backup queue. The only thing you
have to be careful of is that you don't get "filled up" (like the disk
getting filled if used the File send adapter).

--
Jon Flanders
http://staff.develop.com/jfland/
"Matt Milner" <matt.milner@m3technologypartners dot com> wrote in message
news:uuJji$G7EHA.1396@tk2msftngp13.phx.gbl...
> I believe that option only renames them temporarily and is meant to keep

you
> from getting files resubmitted. According to the docs, after the file is
> renamed, if it can be submitted to the message box or suspended in the
> message box, the renamed file is still deleted. The processing is
> different, but the end result is the same in that your file gets deleted
> when you are done. THis just adds some fail safe features.
>
> if the message gets suspended, then you can save the message contents from
> the Health and Activity Tracking (HAT) tool by right clicking and choose
> Save Message. You can also use WMI to get suspended message instances and
> write them out to file. Even though your message is suspended, BizTalk
> still was able to persist it to the message box (albeit in a suspended
> state) so you can get the contents back.
>
> If for some reason you are having problems where the file is not being
> persisted via suspension, but still getting deleted, then you'll want to
> follow Jon's suggestion below to take care of that.
>
> matt
> http://www.m3technologypartners.com/blogs/
>
>
>
> "Jon Flanders" <jfland@develop.com> wrote in message
> news:O9fAp4Q6EHA.2876@TK2MSFTNGP12.phx.gbl...
set[vbcol=seagreen]
of[vbcol=seagreen]
and[vbcol=seagreen]
while[vbcol=seagreen]
process[vbcol=seagreen]
which[vbcol=seagreen]
>
>



kartikp@online.microsoft.com

2005-03-04, 5:49 pm

The document can be suspended by the biztalk messaging engine for some
receive pipeline and all routing failures after receive pipeline.

When a message gets suspended you can retrieve the message again using HAT.

You cannot have send ports to directly subscribe to failed messages in
Biztalk 2004. You can however have send port to subscribe to what are called
"NACKS" which get generated when a message is suspended. You probably don't
want to subscribe for NACKS, but for other people reading this. You can
search for a a blog by kevinsmi on msdn for more info.

"Jon Flanders" wrote:

> I assumed it was a suspended message situation If it isn't - what I
> usually recommend is creating a send port that also subscribes to the
> receive port and essentially becomes a backup queue. The only thing you
> have to be careful of is that you don't get "filled up" (like the disk
> getting filled if used the File send adapter).
>
> --
> Jon Flanders
> http://staff.develop.com/jfland/
> "Matt Milner" <matt.milner@m3technologypartners dot com> wrote in message
> news:uuJji$G7EHA.1396@tk2msftngp13.phx.gbl...
> you
> set
> of
> and
> while
> process
> which
>
>
>

Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com