I’ve just run a test on how the combination of “Allow Early Termination” and “Early Terminate Optional Fields” affects parsing positional flat files. The reason for this is that I’m currently working on a BizTalk integration system which requires accepting all kinds of not-so-nicely-formatted flat files.
In order to simplify things let us assume the following format of the positional flat file:
AAABBBCCC;
where records are delimited with “;” and each record is supposed to have 3 fields 3 characters long. Second and third fields are optional.
Here are the test results (all of the instance files included in the test are required to be accepted by the schema):
|
Allow Early Termination + Early Terminate Optional |
Yes + Yes |
Yes + No |
No + N/A |
Flat File Instance: |
|
|||
1 |
AAABBBCCC; |
PARSED |
PARSED |
PARSED |
2 |
AAABBBC; |
PARSED |
PARSED |
FAIL |
3 |
AAABBB; |
PARSED |
PARSED |
PARSED |
4 |
AAAB; |
PARSED |
FAIL |
FAIL |
5 |
AAA; |
PARSED |
PARSED |
PARSED |
6 |
AAABBBCCCDDD; |
FAIL |
PARSED |
FAIL |
Note: The value of “Early Terminate Optional Fields” is only taken into account when “Allow Early Termination” is set to “Yes”.
So, the setting of “Yes + Yes” looks the best for my requirements with the exception of case 6 when there is rubbish after the last record. In most of the real world scenarios this case need to be failed anyway because it simply does not comply with the record format. But in my case the system occasionally received otherwise valid files with a space at the end of each record (i.e. “DDD” = ” ” in my case). To solve this particular problem I have increased the Positional Length property of the last field from 3 characters to 6, effectively transforming case 6 into case 1 in my initial test.