Preventing loss of input file in case of Biztalk failures
Web Server forum
Back To The Forum Home!Search!Private Messaging System

Web Server Talk Web Server Talk > Web Servers reviews > BizTalk Server > BizTalk Server > Preventing loss of input file in case of Biztalk failures




  Last Thread   Next Thread Next
  Show Printable Version Email this Page Subscribe to this Thread      Post New Thread    Post A Reply      

    Preventing loss of input file in case of Biztalk failures  
vikramswami


View Ip Address Report This Message To A Moderator Edit/Delete Message


 
12-23-04 10: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






[ Post a follow-up to this message ]



    Re: Preventing loss of input file in case of Biztalk failures  
Jon Flanders


View Ip Address Report This Message To A Moderator Edit/Delete Message


 
12-23-04 10:51 PM

You need to add a registry DWORD value named RenameReceivedFiles to the Host
registry hive  (HKLM\SYSTEM\CurrentControlSet\Services\
BTSSvs{GUID}) - s
et
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
>







[ Post a follow-up to this message ]



    Re: Preventing loss of input file in case of Biztalk failures  
Matt Milner


View Ip Address Report This Message To A Moderator Edit/Delete Message


 
12-28-04 01:46 AM

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... 
>
>







[ Post a follow-up to this message ]



    Re: Preventing loss of input file in case of Biztalk failures  
Jon Flanders


View Ip Address Report This Message To A Moderator Edit/Delete Message


 
12-28-04 07: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] 
>
>







[ Post a follow-up to this message ]



    Re: Preventing loss of input file in case of Biztalk failures  
kartikp@online.microsoft.com


View Ip Address Report This Message To A Moderator Edit/Delete Message


 
03-04-05 10: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 calle
d
"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 
>
>
>





[ Post a follow-up to this message ]



    Sponsored Links  




 





   All times are GMT. The time now is 01:17 PM.      Post New Thread    Post A Reply      
  Last Thread   Next Thread Next


Most Popular forums 

Forum Jump:
Rate This Thread:

Forum Rules:
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
HTML code is OFF
vB code is ON
Smilies are ON
[IMG] code is OFF
 
Medical and Health forum | Computer Games Reviews | Graphics design forum

Back To The Top
Home | Usercp | Faq | Register