Undefined Data or the Catalyst of Chaos
When the definition for a data field or element is undefined or otherwise open to the whim of the user, we are asking for trouble. Not in the sense that this causes trouble. But how it is then used that causes trouble. And this is not to pick on the CDATA tag in XML or ZZ qualified elements in EDI. It seems that every data format of any size of adoption commits this sin of categorisation.
My general recommendation is to avoid using undefined or user defined data. Relying on a user defined field that we use to solve a problem by working around some limitation (or perceived limitation) of the file data definition, may give us a feeling of power. But over the long haul turns the implementation into a proprietary implementation that is not reusable with more than one trading partner.
And having each integration using a slightly unique implementation leads to chaos. Both in suppport, and in the applicaiton of updates.
Undefined data exists. People will use it. You will have to deal with it as some time, but whenever possible. avaid making it a critical part of the implementation, and always provide it with a healty dose of error handling.
Subscribe to "The Integration Engineer" by Email
Find out about the tools and services available at The Integration Engineer's Consulting site.
