Support Center

Building a Client Server solution with FaxMan

Last Updated: Jun 20, 2013 05:10PM EDT


The most common pre-sales question we get at Data Techniques regards how to build a server-based faxing solution.  Q:  Can you build a fax server system with all the modems on one machine and no UI or no modem at the client? A:  Yes!  Q:  How? A:  You need to build a client-server based system.  The client app simply supplies the fax information to the server through some shared mechanism.  FaxMan itself does not currently support being distributed and accessed remotely.  There are several very simple approaches to this.  

Shared text files 
One of the crudest, yet simplest methods is to have the client app build a little ASCII text file that contains all the necessary information that the server app needs to schedule a fax on behalf of the client.  This file would be placed in a shared network directory that both the client and server apps both have access to. For example, line 1 of the text file could contain the fax number to send to and line 2 could hold the name of the sender and line 3 would have the actual fax file name.  Of course, the faxable file would need to be put in this shared directory so the server app has access to it.  The server simply needs to periodically (based on some timer or other event) poll this shared directory and check for the existence of a file it hasn’t processed.  In this scenario, however, there is not much of a mechanism for the client to get any feedback on the status of the fax. 

Data base table 
You would simply put the information and the file somewhere where the actual server app has access to the information. The server app would simply have a timer that would fire occasionally and check the table for any unscheduled faxes and schedule its own fax on behalf of the client. Also, the server app could put a status back in the table so the client can periodically check on the fax.  Since this table is the client’s “connection” to the FaxMan server app, the columns in this table can be an exact one
-to-one match for each of FaxMan’s scheduling properties.  Of course, the client’s probably want to know the final status of the fax.  One of the columns in this table can represent the status that the client can periodically check on. Now, how does the server app know what record in the table represents the fax?  There are two ways to solve this.  One, when the fax 
is initially scheduled, the server app needs to store the scheduled fax’s FaxId in another column in the table and then it co
uld search the logs to find where the fax is at any particular moment.  Two, make use of FaxMan’s FaxUserData property to store the record id of the table entry for whom the fax was scheduled.  The second option makes updating the ultimate status of a fax (complete or failed) easy.  This is because when the FaxLogAdd event is fired for a given fax, the server app can simply reference the record id found in the LogUserData(LogIndex) property.  The server app can simply query the table for that specific record since it already has the id. 

MAPI/Send an email 
The client app could also generate a specially formatted email which is sent to the server app’s email address.  The server a
pp would occasionally check this inbox to see if it has new messages.  The faxable file would be sent as an attachment.  Status of the fax could optionally be sent back to requesting client as a reply.  The nice thing about this approach is any client on the net (or has access to send to the server’s email address) using your client application which knows how to format these emails could fax from anywhere at all so long as they have the necessary connection.  Just like the data base table approach the server would put the return email address in the FaxUserData field so it would know who to optionally email statuses back to from FaxLogAdd. 

Winsock / Named Pipes 
Your server app could be written as an app that listens on a predetermined socket port.  Your client app would simply attach to that port and communicate the fax request information to the server through a protocol that you would define.  One nice thing about using sockets is that sockets isolate your application from the network you are running under.  This could be TCP/IP, XNS, DecNet, Novell packets, IPX/SPX or any other network that implements sockets. 
See the MSDN article “Windows Sockets:  Background” for more details on socket programming.

Certainly the same idea holds for named pipes.  The idea is very similar in that an app opens some sort of logical streaming connection on one end and “talks” to some other app at the other end.  However, named pipes are only available to you as an option when the server app is running under NT.  Sockets can be on anything that supports them  Win 95/ 98/ME and WinNT/Win2k.  In fact, your client app could be running under any OS so long as it implemented sockets and could connect to your server app.  Just keep in mind in this case the client app could only provide that the server app is capable of printing to its own copy of the print driver or a file that could be rasterized using ImportFiles (OCX) or FaxCreate (DLL)

Who Builds the Faxable File? 
To offload the work from the server app, you are better off having the client generate the faxable files.  The biggest reason for this is that most fax files are generated by the print driver.  Since you may not necessarily know what applications clients are using to generate faxes, it’s better to let the clients apps print to the print driver generating the fax file and then pass that file
 on to the server app.  You would not want to load your server with every possible application that all the clients might be using just so it can launch and force the application to print the server’s print driver.

What Files Go Where? 

The client
:  If the client will be generating the fax files using the printer then all the client needs is the OCX (if you are using that interface), the DLL, the print driver files and IM12XFAX.DEL (only for non-NT clients).  If the client will be using ImportFiles (OCX) or FaxCreate (DLL), then it needs the necessary DIL import modules.  In either case, the client side install does NOT require the main FaxMan server exe.  

The server
:  If your clients are going to be generating the faxable files 100% of the time, then all the server app install needs is the OCX (if you are using it), the DLL, *.DIL/*.DEL files and the FaxMan server exe.  If the server may also generate the fax files as the client described above does, then it will need all the same supporting components as well.

Contact Us