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…)

One of the basic tasks Integration Engineers do is to compare files that we use or receive.  There are some interesting and useful tools that people can get out there to DIFF files.  But on Linux and Unix machines around the world there is a native tool that is almost always present.  Amazingly it is called DIFF.

Like some other command-line tools, its interface is not really intuitive.  Lets walk through the basics of how to get use out of this handy file comparing tool.  (If you are working with and comparing EDI files, you might want to look at the post on how to unwrap your EDI file so that our line by line comparison is more meaningful.)

(more…)

If you have just a few Trading Partners, having a unique and separate map for each of them might be a good option.  However, if you have plans to scale your integration to 10s, 20s, or 100s and 1000s of trading partners, having a one map to one trading partner strategy is a recipe for a difficult to maintain and support integration solution.  And it doesn’t have to be this way.  There are a few strategies that will help you create an integration that will scale and be easy to support.

(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…)