Aug 01, 2006 05:09 PM
1413 Views
Our company was in the process of developing an EDI integration system. This system was designed to accept order form vendors through ANSI X12 EDI. Our company has expertise in dealing with XML, but not EDI. As a result of time constraints, we decided to purchase the Altova Enterprise Suite and use Mapforce to convert EDI documents into our proprietary XML, and vice versa. Pretty soon after we started using Mapforce, we began running into limitations and bugs. It was not possible to correctly map all EDI segments & loops. 1. Their transaction sets did not have some segments our clients were using, and we had to ‘hack’ into their XML configuration files to accommodate what we were looking for. (Msg). 2. If you modified the XSD to which you were mapping the EDI, all existing connections would be broken. One can imagine the pain we went through during development, when the XSD was still being refined. 3. One would expect that delimiters for fields and segments would be variable. These are variable in the UI, but not in the code generated by Mapforce. Thus if you expect EDI from a couple of clients who use different characters as separators, you would have to generate and build those many dll/exe. 4. We use C++ for development. The prime reason people use C++ is efficiency. We were appalled at the code generated by Altova for the mappings. It generated reams of code to the extent that while using VC++ 6.0, it is documented that compiler settings be altered to accommodate those many lines! 5. The code generated is such that you cannot use two mappings in the same exe. Thus they expect that every mapping will be built into an independent exe. Since we wanted to have a common EDI Service, we had to create DLL’s for each mapping. Every Dll was huge, and the applications starts up consuming over 25 MB when idle! 6. The worst nightmare was realized when we saw that the code generated by Mapforce has significant memory leaks. The memory leaks are so high, that over a week, the application consume over 256MB of RAM. We have to restart our EDI service everyday to avoid it from stalling our server. 7. Inspite of having the 1 year SMP, they have absolutely no help or support. We logged bugs, and logged more bugs, getting nothing but automated replies. We tried calling them over and over again, with no results. We are now in the process of rewriting the EDI service completely independent of Mapforce. Our first module dealing with EDI X12-850, was implemented within two weeks, and takes about 200 KB of RAM, in comparison to several MB consumed by Altova generated code. Within a couple of more weeks, we will have rooted out Mapforce from our EDI implementation. Our EDI code is configurable via XML mapping files, and thus as flexible as Mapforce itself, without the GUI. I have taken this time to write this article to express my frustration and anguish with Altova. It is downright cheating on their part to release such a product and call it ‘Enterprise Edition’, when clearly it cannot be used in enterprise class software development.
