The Integration Engineer
When it just has to work.

What are Delimiters

In short, delimiters are characters that separate the elements of data so that one piece of data can be distinguished from another.  EDI files don’t have externally set delimiters.  This means in a pure sense, that an EDI parser may not know what the delimiters will be until it has begun to parse the file.  This may sound chaotic for someone familiar with strict delimited files.  But we need to remember that in and EDI file, the first segment is fixed position.  This is how EDI addresses the problem. (more…)

Beyond just compliance with the EDI standards, good form is using good practices in planing the format of your EDI.  Below are a set of rules or guidelines that will help you create EDI in good form.  Good form helps others to received your EDI and process it without encountering common exceptions.

Eliminate trailing delimiters.

When EDI was first created, modems were much slower, and high speed internet and Wi-Fi didn’t exist.  Moving large, verbose files over a network took time, and e-commerce solutions charged by the kilo-character.  This means that having unneeded characters cost money. (more…)

Why are segments Important?

The segment is what makes an EDI file an EDI file.  They are at the very heart of EDI.  There are hundreds of different types of segments and each holds a different type of data.

N1^BT^Bill Gates^01^123456789~

For instance the ‘N1′ segments holds some common data that is used in many EDI documents.  First, the ‘N1′ type.  This is the name type.  The first elements following is the qualifier for the second field.  If this is were an invoice it might be the code ‘BT’ indicating that the value in the second field is the name of the “Bill To’ party, in this case ‘Bill Gates’.  Following the name is another qualifier that determines the type of the account number in the fourth filed.  In this case we will use the DUNS Number, and so on.  We stop now with the segment terminator to indicate to the parser that the next character will start a new segment. (more…)

In the beginning we start with the data target.  This may be strange if you have not done any mapping, but the first, best thing that you can do to make a mapping project successful and fast is to start with a well defined target for your data.

I believe that Steven Covey says it this way, “Begin with the end in  mind.”  We do the same thing in data mapping, except that we begin with the end or target if you will.  The data target naturally leads us to the data sources that we need.

If one starts with the source, a lot of work goes into the project, like organizing the source data, before we know if we need any of it.  Sure, you may know that you will need the shipping addresses if you are mapping to a shipping transaction, but spending time gathering the information on the source of this data is still not effective until we know where we will be putting it.

A guide to mapping data from source to target

Spreadsheets are great for mapping.  We start with six columns.  From left to right we have source, source data type, rules, target, target data type, and notes.  We start wit the target and list the data elements that the target needs in the order that the target needs them to approximate the target form.  If this is a database table then this is really simple, and we are just listing the columns names in order.

If the target is something less list like, we will need to add some location information.  In XML we might want to include the xpath to the spreadsheet either in the cell above, or in a logical grouping.  Both approaches work and I will show you and example of each.

As we list the target we will also want to note the data type in the column to the right.  As we note the type of any data with specific formatting, like date or email addresses, we can place that definition here.

After we have the target well defined it is time to decide where this data will come from.  We probably already have some idea, so now it is time to work down the source column and fill in the data reference.  There may be more than one field that maps to a single field on the right.  And there may be one field on the left that maps to multiple fields on the right.  There may also be completely derived data that is calculated at runtime.  There can also be multiple data sources.  You will probably encounter all of these and more in your career as and integration engineer.

Upcomming Articles:

1. EDI mapping excersize.
2. XML mapping excersize.