Dan, I'd like to know of the following methods, which one do you (the list) do and why? 1) application (some DB) <-> flat-file <-> EDI mapper/translator <-> trading partner 2) application (some DB) <-> EDI mapper/translator <-> trading partner thanks, Dan Kazzaz wrote: > Andrew, > > In very general terms, neither your data to be sent, nor your data to be > received is "clean". In either event the data must be staged or scrubbed in > some manner. > > There are three primary methods for this process: > > 1. Put all the logic inside the mapper, using its rules (methods) > capabilities. > 2. Create new tables (inside) the database to hold the data just prior to > submission or just after receipt. > 3. Use Views and/or stored procedures inside the database for this process. > > All of these methods are easier and more efficient than flat files. > > Dan Kazzaz > PaperFree Systems, Inc. > > -----Original Message----- > From: Andrew Clifford [mailto:[EMAIL PROTECTED]] > Sent: Thursday, March 02, 2000 6:27 PM > To: [EMAIL PROTECTED] > Subject: Re: Mapping to/from Access and/or Excel > > << File: Card for Andrew Clifford >> 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.
begin:vcard n:Clifford;Andy tel;work:603-672-9304 x-mozilla-html:FALSE url:www.edisciences.com org:EDI Sciences, Inc.;www.edisciences.com adr:;;2 Pine Acres Road;Amherst;New Hampshire;03031; version:2.1 email;internet:[EMAIL PROTECTED] title:President fn:Andy Clifford end:vcard
