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

[Keith Carpenter <entropypool@xxxxxxxxx>]

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