BizTalk Flat-File Overflows – Look for 80004005

I was recently working on debugging a BizTalk flat-file schema for one of my clients. The flat-file happened to be for a PeopleSoft puchase order format. I was encountering issues where the flat-file disassembler (aka ffdasm) was not recognizing a line feed and was throwing a very ambiguous error number. I was testing with ffdasm and was using a document that included an extra line feed that the schema had not been told about and it was complaining about it. What was interesting about this situation was that the tool was throwing back an HResult with an error number that usually does not specifically represent a BizTalk problem but is actually a more general or "unspecified" problem. This number, 80004005 represents an unspecified error.

 

Doing a little research on the problem I determined this error number is sometimes used to represent an out of range error, like in a stack overflow (see http://classicasp.aspfaq.com/general/why-do-i-get-non-database-related-80004005-errors.html for some examples). Of course it would be nice to have a clearer error message. When doing flat-file debugging, its all about the size of the fields or the number of lines of a file. So to resolve this problem I simply had to change the group max number to unbounded for the schema element I was working with. This effectively enabled the schema to be aware that the number of elements in the group could be more than 1 and prevented the overflow possibility.

 

I am not going to speculate on how memory management works within BizTalk to allow schemas to have the possibility of an infinite number of elements. But it is possible to say that as a BizTalk schema developer, it is important to plan for the possibility that a schema be capable of the unexpected. Specifying many details about a schema will enable the flat-file disassembler to make the least number of assumptions about the range of data. Although min and max occurs are not required field values in a BizTalk schema (in most cases), think about providing these values so that the overflow constraints are clear. If you expect that multiple items may be provided in a message, code this in the schema, otherwise you will see overflows. I think with the complexity of BizTalk it can be very hard to think about building in security with all of the other layers of the product. Some of the conventional overflows, even unintentional ones, can be prevented through full schema design.  But also being aware of the non conventional ones, like with Xml-based overflows is important too. Search on "xml overflow" at a search engine and prepare to be amazed at the overflows documented like in the following article – http://www.securityfocus.com/bid/25301. Overflows are also a problem in maps and in adapters. See this Microsoft Security Bulletin about the HTTP adapter in previous BizTalk releases – http://www.microsoft.com/technet/security/bulletin/MS03-016.mspx. So thinking about overflows in BizTalk should be just another application of defense-in-depth – ensuring security holistically throughout the product.

 

You may be thinking that this error number could appear for many different error categories, which is true. I just wanted to mention that one of the categories for this error is the overflow or out of range category, which is particularly relevant for a BizTalk schema creator.

 

Thanks,