Be Careful When Using the %SourceFileName% Macro

One of my team members ran into a interesting problem when using the %SourceFileName% macro in a send port. In this scenario the client was receiving EDI data in files and they wanted a copy of the original data sent to an archive folder using the original file name. During testing we would occassionally see the following warning messages in the event log:

"The FILE send adapter cannot open file C:\Work\BizTalk\SourceFileNameTest\Out\EDI_X12_864 - Copy.edi for writing.
Details: The file exists."

What was happening is sometimes a single EDI file (interchange) will contain multiple transactions. By default, BizTalk will split the interchange into individual transactions in the EDI pipeline. Since all the transactions came from the same source file, each transaction will contain the same value in the FILE.ReceivedFileName context property. This is the context property that the macro uses to name an output file. When BizTalk would attempt to write the transactions to the archive folder, the first transaction written would succeed and the remaining transactions would trigger the file exists warning.

To work around this behavior you can do one of the following:

1. Add some sort of unique identifier to the file name. For example instead of using just %SourceFileName% you could combine it with %MessageID% to generate a unique file name for each transaction.

2. Configure the file adapter to allow appending to an existing file.

3. Configure the EDI party agreement to preserve the interchange. This would keep all the transactions in a single message. In this case you would need to build additional functionality into your BizTalk application to manually split the interchange.