Homepage › Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › How to handle sub-component separator(&) entered by user › Reply To: How to handle sub-component separator(&) entered by user
Makes sense except just as vendors don’t abide by the standard as far as controlling proper inclusion or exclusion of separators, many vendors also abuse the standard by utilizing subcomponents where none are defined in the standard.
The HL/7 folks realized that when utlizing structured message construction, it is essential the defined separators only be used as separators and provided a mechanism to allow vendors the flexibility to accomodate inclusion of separator characters (as escaped values) where they would not interfere with parsing.
I have little patience with vendors who are very boisterous in there proclamations how they are HL/7 compliant at sales time but are strangely quite and less than cooperative when it is shown where their products fail the standard at development/implementation time.
Normally the correction is relatively easy for the sending and receiving systems from a technical perspective but because only a few clients really object but instead apply local work arounds, there is little incentive for the vendors to correct the issues.
I guess if more clients refused to accept non-standard implementations there might be fewer of these issues.
Part of the problem is typically we as Intregration Engineers are not involved in the selection process so that the really pointed questions are not asked early on and potential deficiencies discoverd. By the time we get involved, typically, the project is well on its way and we become the ‘pimple on the butt of progress’ and work arounds are the only recourse.
I had the pleasure of once working in an environment where the integration capability of products was weighed heavily in the selection process and Integration Engineers reviewed each propsective system for integration flaws. The number of ‘surprises’ were greatly reduced. Of course, there was also detailed specification generation and excruciating testing both of which contributed to pretty stable production implementations.
That said, if after a little ‘wall to wall’ counseling with the vendor fails to produce a correction, I believe the only valid work around is to identify the offending fields and attempt to correct them prior to Xlate. However, never underestimate what can be entered any where in the message and so it would not be surprising if from time to time it would be necessary to either add fields to be corrected or change the correction necessary.
My .02…
Jim Kosloskey
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.