Page 1 of 1

Automating retry failed files

Posted: Mon Jun 20, 2016 4:12 pm
by MattV
Hello,

We occasionally have a problem whereby a file cannot overwrite a file already present in the outfolder with the same name.
Thus, it goes into 'Problem jobs.

So, would ideally like a method where it automatically retries to route the file, ideally with a short delay.
Or, it just routes it elsewhere, instead of the problem jobs.

But, we cannot figure out a viable method of this, don't really want to feed anything back into the workflow from problem jobs incase of a loop being created.

Any suggestions very welcome.

Thanks

Re: Automating retry failed files

Posted: Mon Jun 20, 2016 4:39 pm
by freddyp
I would like to understand why you have that situation. Switch keeps unique names for different jobs (unique ID), so this must happen on a final folder where this unique ID gets stripped. What processing step is there in front of that final folder? Are two different programs (two instances of the same program) writing the same file at the same time? Or is the first file already there for a while when the second one tries to overwrite it?

If it is the first, then put a "Hold job" and an extra folder in front of your final folder and set the "Folder constraint" property on the outgoing connection of "Hold job" to allow only 1 job in the output folder. This has the effect of serializing the feeding of files to the final output folder and hence making sure that there are no two files with the same name being written at the same time.

If it is the second, then I can only guess: do the two files come from different sources? Is the output folder on a network drive? File access right problem? Temporary loss of network? ...

Re: Automating retry failed files

Posted: Mon Jun 20, 2016 4:56 pm
by MattV
Hi,
Yeah it happens on the last folder. There's no complicated processing occurring, hierarchy path is set > automanaged folder > output folder.

The first file is already there when the second attempts to overwrite and fails. We have assumed a person, or process, has the original file open.
The second file will often overwrite the first when you retry problem jobs.