3.e. Scenario II - Writing a new Linux module to interact with an existing application:
If you have to write your own Linux-based piece of software that has to interface with a Windows application (for example, what we've seen in Figure 2), here are some tips:
Try to use a single database engine. For example, if your Windows application uses MS SQL Server, you should write your Linux application using the same tables and access them remotely. If you use Perl, for example, you can use DBD::ODBC to connect and operate the MS SQL Server tables from your Linux application.
If your Windows application uses Oracle, try to move the Oracle
server from Windows to Linux or Unix/Solaris along with the data.
From your Windows application, change the DSN or system
configuration so it connects to the Linux box instead of to
Windows. From your Linux application use DBI::Oracle or the
provided connection tools from your preferred programming
environment.
ii. If you can't use the same database, choose a stable GPL database engine (Postgres or mySQL) and write a Perl script to synchronize data between both databases. You can use ODBC as the 'data hub' as well.
iii. If the Windows application uses a database that is not ODBC compliant, utilize the 'update' or 'import' scheme seen above, but from both sides -or two-way integration-. This is, write a Perl script that reads a text file generated from the Windows application to update the tables on the Linux side, and write a Windows applications that reads a text file generated by the Linux application and refresh the information stored in the Windows side (Figure 4). You might want to encapsulate both jobs in the same script. For instance, the Perl script could read the text file and at the same time generate the text file that the Windows application needs (same thing with the Windows program), just make sure you synchronize the automatic execution of both import programs in a sensible way. Remember to name the text files in a different way or in different directories, and to rename or delete them after they are processed
iv. One last thing, try to maintain a log file of all the import results so you will know what happened if something went wrong. Also, try to make your update programs fault-tolerant: These should be automated processes and should only need your supervision, not your intervention. For example, if one of the import jobs fails to execute or cannot open the text file your programs should know how to handle that.
Figure 4.