Re: is edi translator software difficult to write? was: edi vendor complaining

Steve Richter wrote:

just curious to understand how shops get locked into their EDI
package. The VP at my current account explained to me that EDI
packages are built to not require a programmer to interface to them.
Typically a user or admin configs the rules within the EDI package to
map to the database from which you will be sending and receiving EDI
transactions. To replace an EDI package you have to redo all of those
mappings from/to the database. I guess none, or not all, EDI packages
allow you to export those mapping rules and import them into another
vendor's EDI application.

This is basically correct. AFAIK, there's no standardization of the mapping specifications for translators and not much of an incentive for vendors to make it easy to migrate this data either. So how much you're locked in depends largely on how much configuration (mostly maps and trading partnerships) you may have and how tightly the translator is tied into your other applications (eg. API calls)

If this is accurate, are the Innovis mapping rules stored in database
tables? The idea being to journal all the Innovis files, use the
package to config some mapping rules, then examine the journal to see
which files were written to. Next, use this new knowledge of how the
rules are stored to export them and import into a replacement EDI app.
Another approach, using the same concept, is to use EHLLAPI to
screen scrape from the Innovis config screens and capture the configs
that way.

I'm not up on the latest versions of TrustedLink (Inovis) but the version we have uses a database for the configuration. Our GIS translator stores the map source in a XML format (Gentrans). The real difference between them is in how the translators work. TrustedLink converts EDI data to and from database defined by multi-format logicals. GIS treats mapping as just a service within a larger workflow process which you write in BPML (Business Process Modeling Language). In GIS, we typically map EDI data to and from XML data which in turn is processed by the BPML with JDBC database calls.

Writing a conversion utility (which is what you're getting at) would be easier if the source and target translators shared a similar processing model. I'm not up on the products out there to make such a recommendation.

For us, the conversion effort from Inovis to GIS was not just about mapping. We also typically have to revise the back-end tables and programs to be compatible with the new database access. For inbound docs, our TrustedLink setup often used temporary files processed after a TrustedLink session (API call). With GIS, we now typically drive backend ("i") processing by the document using a series of SQL stored procedure calls.


Keith