Inbound map fails due to nulls in incoming file
I’ve bumped into this scenario today -
A file, created by a third party, is being receiving by BizTalk using the file adapter (the file is being FTP uploaded by the third party).
Turns out that the file contains nulls (hex 0x00) in some of the fields, in some of the records.
This is evident when looking at the file in a hex viewer, although – to my surprise – when we opened, and then saved, the file in notepad (without making any changes) all nulls are replaced with spaces, which mostly meant we could only test this using the files supplied by the original creator, presumably a non-windows system.
Anyway - flat file disassembler happily processes the file and spits xml (we’re actually debatching the files in the disassmebler, so we’re getting lots of small xmls) where the attributes corresponsing to the fields with the null value, now how the escaped representation of a null. so far so good – the xml accurately represents the flat file.
At the end of the pipeline, however, we’ve got an inbound map, which then fails with the error -
The Messaging Engine failed while executing the inbound map for the message coming from source URL:"D:\Projects\BizTalk\Files\IN\*.csv" with the Message Type "<some message type>". Details:"An error occurred when parsing the incoming document: "'.', hexadecimal value 0x00, is an invalid character. Line 1, position 275.". "
Looks like the value was correclty identified as null, but that the mapper is very unhappy about that fact; the map was never actualy executed (the problem is not in any of our mapping logic as far as I can tell, but in the ‘engine’ itself); I was not aware of any restriction about the use of nulls, but it seems the maps refuse to execute.
A similar error is received when trying this in VS (test map)
We’ve scratched our heads a little bit, but eventually found a work around of kind in the BizTalkGurus.com forums - http://www.biztalkgurus.com/forums/p/6535/12594.aspx where Mark answers he’s own question and suggests that configuring the fields in question with null as the padding character will instruct the disassembler to remove any nulls it finds.
Works like a charm.
Of course this can only work if the schema is not going to be used by an assembler delivering the message, as it would happily pad the very same fields with quite a few nulls on the way out, which has to be counter productive!