The Integration Engineer
When it just has to work.

Starting off work on my On-line Status Repository, one of the things that I will be starting with is uploading and downloading SEF file from a data repository.  SEF stand for Standards Exchange Format.  SEF files are repositories of standards information that can then be exchanged between people and applications to define the format of EDI documents.

If you have used a standards editor, you probably know what an SEF file is, or have used it.  Some applications and EAI even use SEF files as part of their document creation and validation processes.  It becomes useful to describe briefly what SEF files look like, and what type of information they contain.

(more…)

When two trading partners agree to send each other electronic documents.  And they begin to describe what EDI documents they will exchange and how the documents will flow, they should also exchange EDI specification documents.  EDI usage or specification documents describe what fields and what segments a trading partner will send or expect to convey the information necessary to complete a transaction.  It doesn’t matter if we are ordering widgets, or invoicing, or transmitting catalog data, or checking insurance claims eligibility, the EDI needs to contain the data that the two parties need to communicate.  To explain this, and document it to that both trading partners know what is expected, we create an EDI usage specification.

(more…)

I have been studying some on the SEF format.  SEF stands for Standards Exchange Format.  This is a file that defines the EDI standard so that you can use a validation or standard and usage document editor to create nice, and clean specifications for you and your trading partners.

I have used Foresights EDISIM, but I wonder what others use.  I have found a few links to SEF software, and will list them below.

(more…)

From time to time I am asked if I know where such and such standard can be found.  This is more than idle curiosity.  People are trying to integrate, or update integrations, and the standard documentation is not available or has been lost.  From the perspective of an integration engineer, such standards are more precious than gold.  I keep a collection of the standards that I have used over the years, (something that I recommend) but what I really encourage is for companies to publish their standards in a publicly accessible location.  Booknet Canada is an example of a company that has done this.  Lets take a look and see what it says….

(more…)

After you have created your usage specification, it can be useful to use a validation tool to check to verify that new trading partners comply during your boarding process. I have used Foresight’s EDI Analyzer for this many times, and it lets be quickly see where the EDI file departs from the specification.

There is a temptation to use this same validation in the production integration. But this would be a mistake. I’m not saying, “Don’t validate.” I highly encourage validation on both standard compliance and required data validation in mapping and integration. But to use the usage specification has a side effect that I witnessed once. (Only once.) (more…)

I have sitting on my desk, a very expensive book published by the ASC that contain the guidelines for the X12 3010 EDI standard.  I have rarely used them.  The EDI standards tool that I have used the most and can highly recommend is EDISIM from Foresight.  The last version that I used was version 5.0 and they are on version 6.8 as I write this post.  But for a long time, Foresight has nailed the conceptualization of working with EDI standards.

One of the things that in invaluable is the ability to share your standard documentation both internally and externally.  EDISIM is a tool that has allowed me to do that.  They produce a very professional looking document for external consumption and the standard is exportable so that everyone using EDISIM can share the same standards file in a format called SEF.

(more…)