Andrew...
I guess I'm spoiled working on the AS/400; EVERYTHING is a database call since
DB2 is integrated in the operating system. My usual approach is to create a
mirror image of the production data base object(s) and map to it. Then my app
interface program needs to do validation and insert the records into the
production db object.
This method makes it reasonably easy for application programmers to understand
since they are working with familiar file layouts and structures. Extracts
only
need to copy the application records out to the mirror objects, inserts have a
mirror of the production object as a source. The only potential "down side" to
this approach is that changes to the production table layouts necessitate
changes to the maps.
You can argue map changes in several ways, but IMHO, they're not necessarily a
bad thing since they force the applications people to consider the EDI
requirements in their designs and specifications. It also minimizes the number
of times that the EDI staff is surprised by application changes...
Phil Catlin
"Just my personal $.02 for a Thursday!"
-----Original Message-----
From: "Andrew Clifford"
Sent: Thursday, March 02, 2000 3:27 PM
To: "EDI-L"
Subject: RE: Mapping to/from Access and/or Excel
I�m interested to hear how people feel about these two approaches to EDI
integration: flat-file interface vs. direct database calls.
I would think that direct DB calls would be more efficient on outbound since
the data is presumed clean and is what you want to send to your trading
partner. Even if the data goes through a flat-file intermediate step first
before hitting the mapper, the source is the same.
On inbound, however, I think it�s more fraught with peril since you risk
garbage coming into your database without an adequate opportunity to review
the data. If you add edits into the mapping to- for example- kick out
questionable data or outright errors, you�ll have to constantly tweak the
maps to keep up with the inventive ways trading partners can make life
interesting. After you fix the offending data or ask for re-sends, you�ll
have to reprocess the stream and perhaps keep track of duplicates.
Should you decide to change your EDI software - no one would actually do
that, would they? ;) � you may have an entirely new API to deal with.
For flat-files, I think that overhead is higher and of course batch
processing is not in �real� time.
However, if you use a flat-file approach, you will still have to deal with
edits on inbound but you�d be changing load code that you will be able to
manage through version control and code libraries.
If you then change your EDI software, you�d need only to insure that the
mapper writes out identically formatted flat-files, preserving your load
programs.
I haven�t touched on all pros and cons and I�d like to hear what others
think on this. It�s a fundamental issue and I wonder how you arrived at
your choice.
=======================================================================
To signoff the EDI-L list, mailto:[EMAIL PROTECTED]
To subscribe, mailto:[EMAIL PROTECTED]
To contact the list owner: mailto:[EMAIL PROTECTED]
Archives at http://www.mail-archive.com/edi-l%40listserv.ucop.edu/
