Another strange behaviour....
An FTP sender adapter picks up a file.
When trying to archive it, the system detects that a file with the same name already exits in the archive directory.
So processing is interrupted which is shown in the comm.channel monitoring.
Learning: The FTP adapter is not able to overwrite the file in the archive directory.
We deleted the file in the archive directory to solve this.
With the next polling the adapter picks up the same file from the source location, tries to process it, and...
returns now a message
"Archiving file "/Backup/EXTOUT20120425172603.txt failed. Cannot create a file when that file already exists. Message Id 5fbe2514-b9c0-439e-03cc-b70ca53143b0(OUTBOUND) already exists in duplicate check table". !!!!!!!!!!!!!!!!!!!!!!!!!!
But this is now not about the archive directory as the file doesn´t exist any more there.
It is about the file name of the file picked up in the source directory!
Processing is again interrupted.
We could solve this by renaming the file in the source directory so that the adapter does not recognize the file as the one from the duplicate check table
which already got a message ID!
But this is strange behaviour that the system stores a message ID with this file name and rejects the next processing because of the duplicate that it detects.
Remember: The system didn t process the file!
Now your answer could be add the "time stamp" flag in the module to avoid the first issue not to move into the second one.
But as you can see there is already a time stamp in the file name and adding another time stamp makes it only confusing readig the file name in the archive
director for the support guys.
Is this "duplicate" processing really standard?
Or is there any idea how to avoid such system behaviour?