Fair enough and I'm sure we all appreciate that. I do not read "screen scraper" as "simple" or "small", I think we are really referring to the intrinsic overheads of this implementation here, in fact we even emphasize the complexity of it. And of course, while exposing this functionality in a much more controlled fashion than any other approach has clear good sides, the more fiddly low-level approaches do offer extra flexibility and speed. Which squarely brings us back to the original interface requirements: whether it's something big or something small would dictate what approaches are available to you in the end. And selecting a wrong approach would make your path so much longer and more painful...
In my opinion, far too often, the approach selection boils down to available skillsets, the comfort level of the developers with any given approach, or even the quality of available documentation. Which are all fair reasons, but neglect to mention the compatibility of the adopted approach to the issue at hand and fails to take into account all pro's and con's. And if the original developer was intimately familiar with all available approaches and had no technology bias, the selection may have gone differently and been quicker or produced a better result in the end.
And specifically addressing the requirements that you have quoted, JDE has sample XML "programs" to do this (and/or similar) stuff. Have you looked into that? Just curious. - it may have potentially proved to be quicker to develop, would have likely offered the same integrity and very probably resulted in a faster interface, not to mention no additional licensing requirements...
