Basic information about communication paths, data sources & data sinks
Beyond the data formats used in EDI (and EAI), we are also interested in how data come into a system, and how they leave it again afterwards. In other words, how do your partners’ and customers’ data get into your EDI system, how does that system communicate with your internal systems, and how do your partners get their data back?
It is difficult to draw any clear dividing lines here – whether between the communication itself and data sources or sinks, or between public and internal communication. After all, emails, FTP transfers and HTTP requests could just as easily be used on your own intranet in the same way as they are sent throughout the world over the web. Likewise, it is perfectly possible for databases or ERP systems to be connected over long distances (e.g. via VPNs).
Every data source and sink naturally comes with one or more modes of communication. For example, a database might be accessed via JDBC or ODBC; inventory management systems can import and export text files or we can also directly access the tables in the underlying database; and systems like SAP often have their own specialised access methods, which in this case would be called ALE and RFC.
Nonetheless, over the following pages we shall draw a distinction between “public” and “internal” – though you should keep in mind that the boundary between these two concepts is fluid. In much the same way as the boundary between EDI and EAI tends to be fluid in practice, since many systems and communication paths need to be accessed for both.
Example showing the options within a specific system
For example, here you can see the options offered by the EDI software Lobster_data for receiving data or obtaining them yourself for processing purposes:
As you can see, the FTP protocol appears twice, both in “Event-based” and as an option that can be selected under “Scheduled”. The same goes for a few other modes of communication. This is because this product comes with a dedicated, fully functional FTP server as an integral component. As a result, a data transfer can be initiated in one of two different ways.
Under option one, your partner can decide that they want to send a file to you. In that case, they open an FTP connection to your EDI server (provided that you have set up a suitable user account for them) and send you the data. That means your system simply waits for an external party to send it something to process.
Alternatively, you can agree with your partner that they should make their data available on their own FTP server, where you can retrieve the files yourself. Of course, this process should be fully automated, so you will need to configure a scheduler to manage the retrieval of the files.
If any of you have noticed that there isn’t actually a download command in OFTP equivalent to the “get” (or RETR) used in the standard FTP protocol then you can take a look at the OFTP chapter to learn how to get around that and create a similar query.
Once the EDI system has completed its work (whether this is format conversion, enrichment, reconciliation, etc.), it needs to send the result of its activity off again:
When inputting and outputting data, you will encounter a wide assortment of methods that we have divided up below into either “public paths” or “internal paths”. This shouldn’t really make any difference to an EDI system, since its sole purpose is to connect the internal systems to the outside world. However, if you can also connect internal systems on both sides then you will have already met one of the most important requirements placed on EAI software. Once again, we should note here that any strict divide between EDI and EAI is a purely theoretical construct, and in practice it is largely unfeasible to handle them both separately using two independent systems.