Creating an FTP Script

In the last post I discussed using a web FTP service as an alternative EDI service, so I thourght I should also provide some help with FTP scripts. You can use a graphical tool like windows explorer for example by typing ftp://someserver.net in the address box. However to eliminate the work of the human operator as far as possible, scripts are needed.

That said the best first step to achieve this is to make sure you can do everything manually first. So drop to the command line. On a windows system click Start > Run, and type CMD. Now try and replicate something like the session below, the local machine prompts are in red, the ftp server responces are in blue, inputs in black.

C:\Documents and Settings\ACME>
C:\Documents and Settings\ACME>ftp ltoons.com
Connected to ltoons.com.
220 ready.
User: ACME
331 Password required for ACME.
Password:
230 User ACME logged in.

ftp> cd /outbox
250 CWD command successful.
ftp> put acme-bbunny-321.txt acme-bbunny-321.tmp
200 PORT command successful.
150 Opening ASCII mode data connection for put acme-bbunny-321.txt.
226 Transfer complete.
ftp> rename acme-bbunny-321.tmp acme-bbunny-321.txt
350 File exists, ready for destination name.
250 RNTO command successful.

ftp> cd /inbox
250 CWD command successful.
ftp> ls
200 PORT command successful.
150 Opening ASCII mode data connection for file list.
  bbunny-acme-123.txt
  dduck-acme-88.txt
226 Transfer complete.
ftp> get bbunny-acme-123.txt
200 PORT command successful.
150 Opening ASCII mode data connection for bbunny-acme-123.txt (999 bytes).
226 Transfer complete.
ftp> del test.tmp
250 DELE command successful.

ftp> quit
221 Goodbye.
C:\Documents and Settings\ACME>

This follows the procedure laid out in the previous post. Sending a file, listing files to be fetched and fetching them. If you can do this then you are well on your way. If not then any amount of program testing and debugging wont help you.

The next stage is some quick and dirty code just to get the job done. This example is in Python.

from ftplib import FTP

host = 'toons.com'
user = 'acme'
password = 'password'
filestosend =["acme-bbunny-321.txt"]

# Log on

ftp = FTP(host)
ftp.login(user,password)

# send

ftp.cwd('/outbox')
for filename in filestosend:
fileinput = open(filename, 'r')
ftp.storlines('STOR tempory.tmp',fileinput)
ftp.rename('tempory.tmp',filename)

# fetch

ftp.cwd('/inbox')
filestofetch = ftp.nlst()
for filename in filestofetch:
if filename[-4:] != '.tmp':
  fileoutput = open(filename, 'w').write
  ftp.retrlines('RETR ' + filename,fileoutput)
  ftp.delete(filename)

ftp.quit()

Does this work? If it does then well done, but your work isn't finished. This script has no error traps, no try statements. The 4 variable assignments at the beginning need to be parametrised in some way. (Exercise for the reader)

Embedded EDI

I have just come across the phrase Embedded EDI. I think it fits quite nicely as a label for what I have been trying to articulate.

Some highlights...

• "Are a CEO’s email or Text Messages more or less important than an X12 Shipping notice?"

• "Why is EDI not subject to universal addressing via DNS or URI name-spaces?"

• "CEO’s and children expect email to reach it’s destination, but Supply chain managers need private networks. Why?"

Good questions...

Electronic Data Interchange Needs Electronic Paper

There is probably a word for it. You know, when you are struggling to express an idea and try several times without being satisfied that you are getting your point across. Or indeed not sure what your point is. Then someone else hits the nail on the head. Then you feel the ping of recognition, the swell of confirmed pride and the annoying jealousy of "I wish I had said that".

I want EDI to be easier. Correction, I want EDI to be easy.

In a previous article I was poking fun at the format explosion and buzz word bingo that goes on in the EDI world. The idea that standards are good so we need more of them. The dis-ing of everything that has gone before as "legacy". The constant re-invention of the wheel without leaning the lessons of history.

As a throw-away remark I said in a future article I would announce a solution based on "Facsimile Technology". I knew what I was referring to but up until now I hadn't been able to express it clearly. Then I read it else where.

At The Register, Chris Mellor has an Article entitled "The latest EDI money saver? Paper invoices - Use humans, save money".

I suspect the title is being deliberately provocative. He describes a system where a Scanner is used with OCR to create "electronic copies" of invoices that are machine readable. This is not new and there are other scanner/OCR solution providers out there. If you can't get all your suppliers to send EDI invoices, it is a great way to deal with paper invoices.

The people selling this system explain their thinking...

EDI leaves IT departments perpetually recoding (changing standards, used in differing ways, new formats, different communication protocols).
No all-embracing EDI standard is going to emerge.
The number of paper invoices still being produced after all these years of EDI effort - is massive.

... so if EDI is a failure, accept it and learn to deal with the paper.


I don't want EDI to be a failure, yet I can't believe in a "paperless office". So lets study what paper has going for it.

Paper is ubiquitous, cheap and can be put to many uses.
It can be supplied by many sources and what differences exist (size, weight, color) don't cause tie in.
Organisations are already adapted to handle it.
Humans interface with it easily.


If we look at it the other way, as a sender of invoices. If we accept that some receivers will simply convert (map) the files to paper. Is there an electronic form that EDI enabled receivers can use, yet is just as good as paper for those that aren't enabled? To come close I believe the receiving user should be able to view a list of invoices in a computer folder, like any shared folder. A double click should instantly display the same image as the old paper format. Click print, and it prints. In the folder view, highlight several, Left click, select print, and several print.

HTML & PDF files do this. XML with style sheets come close. ODF & OOXML are related to XML. DOC is closed secret and proprietary.

The file types that don't do this are X12, Edifact, Eancom, Tradacom, Odette (sorry traditional EDI).

The file format is only part of the story. The delivery mechanism needs to be as universal as snail mail. Is there an electronic protocol that EDI enabled receivers can use, yet is just as good as snail mail for those that aren't enabled?

Email is close to this. However it is a bit like using post cards with no certainty of delivery.


In my view EDI needs to be so simple and fault tolerant, that it can be done with a laptop office productivity software. That may mean we have to make changes to our office productivity software. But we definitely need to make changes to our EDI.

EDI System Design - Overview

Part I - Message Control
Part II - Export Mapping
Part III - Import Mapping
Part IV - Transaction Processing

EDI Overview

Part I - Formats
Part II - Communication
Part III - Why

Overview Part II - Communication

Communicating... sending and receiving electronic messages... ummm... sounds like email!

We all understand email and are familiar and comfortable with the concept of email. Then why is EDI (Electronic Data Interchange) more complicated? Well I think part of the answer lies in its age. EDI has been in wide spread use in business longer than email. The other reason may be down to security concerns, but it is certainly technically possible to set up an EDI system using email.

Imagine we didn't have the internet (it wasn't that long ago!). To communicate with another computer I needed either a dedicated cable, or a modem, or a network. If I have 100 trading partners (there's that phrase again) that is a lot of cables or telephoning. So the obvious answer is a network all users communicated with, that forwarded all our messages onwards. Like an out-going postbox and an in-comming mailbox. Yes, this is just like internet email.

It seems so obvious to us now, but back then TCP/IP was not the dominant networking technology. So third party businesses sprung up to operate these networks (called VANs - Value Added Networks). Unfortunately, just like EDI standards, there are lots of EDI networks. So if your customer (eh... I mean trading partner) used a particular one, you were more or less forced to use it, though networks could have their own mailboxs on other networks, to provide network to network communication.

But wait a minute. You still have to communicate with the VAN. Good VANs will offer a choice of ways - modem dial up, secure FTP (File Transfer Protocol), web pages (HTTP - HyperText Transfer Protocol). These days some of these middle-men, third parties, are really just a URL and a server.

Part I, Part III