You get the impression that programmers use the latest gadgets, and the best services when you attend a marketing or development conference. ITs are on the top level of technology I thought in general. But then you come back to reality.

I have already written about how we hacked SAP. But that was only one of the icing on the cake we have to solve by connecting our clients' systems with other ones. There are still some ancient systems in the business-to-customers, especially in the smaller companies sector. There may not be modern systems with APIs and some of them don't have any kind of machine-readable export like XML or CSV. Mostly you have to squeeze the maximum out of the programmers of the given system so that the result is at least somewhat usable. And sometimes you get to a point where you just can't go on. For example, when the client uses a stock system running on MS-DOS.

MS-DOS in 2016?

Yes. Even today. You will come across such an outdated thing as an accounting and stock system running on an MS-DOS environment. And this is no exception. Such programs are popular, many companies still use them. And you can still buy them. The reason is probably the fact that it is difficult to switch to something more modern or to train employees on a new system.

Of course, you don't need a piece of ancient hardware. You can run the program in modern OS through DOSBox for example.

Well, what about the connection with the online e-commerce solution?

Magic

You can only dream about an API in this case. When I asked about the possibility of exporting in XML or uploading somewhere to a server, they stared at me like I am a heretic.

Burn him! At least something like CSV was possible to get from the system's guts.

But it doesn't work automatically.

The user press Shift+F8 then puts this here, then Ctrl+T, then Alt+F5, and selects the items here. No, it doesn't have to, it will already be selected. Then he does Ctrl+E, then he goes to "Export" and then he saves that file somewhere on disk. That'll be fine, we'll print her the instructions on how to proceed and she'll just do it a few times a day.

A bit of modernity

Ugh... well, it can work. And what about the upload to the server? What is that? How to upload it somewhere on the internet? It will not work!

I can deal with "uploading somewhere on the Internet" and I proposed two possible options (there could certainly be more):

1. Export the file to a folder that will be shared via DropBox or Google Drive (or another similar service) and we will download it to our server via the API.
2. Export the file and then upload it to FTP via NcFTPPut - a simple console application that can be run either manually after the export or via automatic tasks.

Using NcFTPPut is very simple:

ncftpput -u [USERNAME] -p [PASSWORD] -R -v [FTP SERVER] [TARGET FOLDER (FTP)] [SOURCE FOLDER (LOCAL PC)]

In the end, however, we did not get to implement the project. It would be necessary to organize the data and the stock itself, for which the client did not find the time and perhaps even the energy (for the same reason, apparently, he still uses the given software). But it was a good experience and I'm glad that we managed to find a fairly simple and (for the client) cheap solution.

I can already see how some programmers would suggest installing the system on a virtual server at Amazon, using some applications for virtual keystrokes, and creating an interface to download the actual file. But the resulting price would get out of the hands.