Adam,
Great (!) question, and one I have grappled with for many years integrating
EDI into applications here at Customs and Border Protection, and elsewhere.
I have seen applications at former positions where the use of the translator
was to simply syntax check, then lay down the raw EDI into a syntax-free fixed
format flat file. How easy that was.
We have legacy applications here that support both an X12 and EDIFACT flavor
of the same business transaction. The translation process presents the inbound
application file in a format predicated on the specific business component
object ... Manifest info, BOL info, Shipper info, commodity info, etc. This
works well. Quite well. Efficient.
However, interestingly, the effort to modernize some of the cargo related
systems found us having to create the business objects in a similar fashion,
but translating to an SAP IDOC format. The degree to which we have had to
deploy 'business logic' within the translation software has been significant.
Seems applications these days wish to program against only the 'cleanest' data
possible, with limited need for 'business' edits and validation. Though doable,
this methodology has resulted in a 'puff out' factor of close to 15x the
original inbound e-document given the tremendous inefficiencies with regard to
the SAP IDOC format. This has presented significant hardships within the down
stream processing infrastructure given the breadth of the data stream. Add in
the tremendous pressures within a high-volume, real-time process, the overhead
is significant. (XML overhead comes to mind here!) Despite the suggestion to
deploy a comma delimited post-xlate appl format, the
decision was made to simply remove the trailing 'white space'. Time will
serve as testament as to the effectiveness of the approach.
I will close in suggesting that the approach you take is in direct proportion
to the degree in which the need for efficiency plays a roll. Got cycles? If
so, the options are immeasureable.
Regards,
-Bud/Customs
Becker, Adam" <[EMAIL PROTECTED]> wrote:
Hello All,
I'm hoping to get your input on application files, does any body know of
any best practices for defining the format for these? Is delimited or
positional better? Should you use qualifiers for things like references
or just have a field for every type of reference you could possibly
expect? Should you only have one line in the file for each line in the
database? Any input/advice/past mistakes/etc. would be very much
appreciated.
Thanks,
Adam
This email message and any attachments are for the sole use of the intended
recipient(s). This email and any attachments may contain confidential,
privileged or otherwise protected information, including legal protection under
the Health Insurance Portability and Accountability Act (HIPAA). If you are not
the above named intended recipient, you are hereby notified that any use,
disclosure, printing, copying, or distribution of this email or attachments is
strictly prohibited and may subject you to criminal and/or civil penalties. If
you have received this email in error, please immediately notify the sender by
telephone or reply email and destroy this email
[Non-text portions of this message have been removed]
---------------------------------
Everyone is raving about the all-new Yahoo! Mail beta.
[Non-text portions of this message have been removed]
...
Please use the following Message Identifiers as your subject prefix: <SALES>,
<JOBS>, <LIST>, <TECH>, <MISC>, <EVENT>, <OFF-TOPIC>
Job postings are welcome, but for job postings or requests for work: <JOBS> IS
REQUIRED in the subject line as a prefix.
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/EDI-L/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/EDI-L/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:[EMAIL PROTECTED]
mailto:[EMAIL PROTECTED]
<*> To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
