Case Study 3 - Publishing Real-Time Reports of Water Depth and Quality on the Sava River Watershed on the Internet and Teletext (Videotext)

Our client was a public enterprise government agency that was in charge of monitoring water depth and quality of the Sava River and its confluent rivers. To be able to do this they had to build an entire network of automatic hydro stations all over the countryside. Due to expenses and existing infrastructure it was built in phases, and unfortunately, not always by the same vendor. So they had a perfect monitoring system that contained three different applications with totally incompatible hardware, software, databases, and exports. Changing these applications traditionally would mean a lot of hardware changes, of which the cost would be measured in millions. We had to find a way of making a single and more cost-effective solution for these three systems.

This project had a budget that allowed us to make few compatible solutions, one for every task. The tasks were:

1. Read an exported, human friendly report (different for every monitoring software) and feed it to the single local database
2. Send unique data to database located on the Internet
3. Create a teletext report and upload it via FTP

The first task was the most difficult and most time-consuming. Exported reports were a plain text files written in a human readable form, which meant it was not computer friendly. Also, reports had to be exported automatically from main monitoring applications, and they had very few options, meaning we had to adapt to their system, naming conventions, and directory structure.

We decided to make an unattended application with a simple text configuration file that would enable us (and our client later) to easily add new stations, change source directory locations, and even change the file naming convention.

For the second task we made a simple, password-protected, server-side application for adding records over the HTTP protocol, and then we made a separate, unattended application that read the local database and sent new data to the server-side application.

For the third and final task we made a command-line application that read a text configuration file, then connected to the database, built a teletext configuration file, then connected to the FTP server and uploaded it.

It was decided that adding a scheduling component to our solution would burden the budget, and there was no dire need for it because Windows Scheduled tasks could fill the need.

We implemented this solution in February 2005, and although our client has changed his web site three times since then, our system is still in use.