Salesware, the Siriusware Point-Of-Sale (POS) application, requires four types of hardware: a database server, a middleware server, a SysManager management station and a salespoint. The database server is used to store the master database and software that is required by all the components of Salesware. The middleware server functions as a middleman, taking the load off the salespoints so sales can be made quickly without time- and resource-consuming database tasks. In addition, the middleware server serves to solve many problems of system vulnerability usually associated with network database systems. A SysManager station is where Salesware as a whole is managed. A salespoint is where sales are performed.

With Salesware module, there are many options for your hardware installation. The ideal setup is to have one server dedicated as the database and middleware server, at least two SysManager stations and as many salespoints as are necessary for your operation. However, if you have twenty or more salespoints, you need to use separate computers for the database server and middleware. On the other hand, a small operation may run Salesware on one computer, which acts simultaneously as the database server, middleware server, SysManager station and salespoint. Also, it is possible to use separate computers for the database server and the middleware server or to combine a SysManager station and the middleware server. In this section of the installation guide you obtain an understanding of how the components of Salesware work together so that you understand why the “ideal setup” just mentioned is ideal, what other options exist, and what the strengths and weaknesses of each option are.

Siriusware Inc. ® examined the worst problems that database-dependent networked operations experience and created the middleware server solution to address them. With a middleware server, the problems of faulty network cables, bad power, user error, slow or broken connections, unplugging, etc., are minimized to the greatest extent possible, which translates into less down time for your system and quicker processing where you need it – when making sales.

When making sales, the salespoint takes the data from a transaction and stores it locally. The salespoint then directs the middleware to update the master database on the database server with the new data and to download any new information from the master database on the database server to the salespoint’s local data files (e.g., pricing changes, new accounts, etc.).

If all of the functional components are running on the same computer, then it is merely a question of various software programs talking to one other, with no phone calls or network connections. If your operation is small and only one salespoint is required, this could be optimal for you.

However, once two computers are networked together, connections of some sort are introduced, which requires data to pass through those connections to open database files on the database server. This leaves your data and your network vulnerable because interruption of those connections while files are open can result in corrupted data. Similarly, database operations performed over network connections consume time and network resources. The greater the number of computers networked together and the farther the computers are from the database server, the more of this type of vulnerability and resource-consumption are introduced into your operation.

This is where the middleware server comes into play. Instead of the salespoints talking over a network connection or phone line to an open database file on the database server, the salespoints direct the middleware to do the “dirty work” for them. The middleware server receives the data as a rapid stream of characters and commands, opens data files on the database server and does the time-consuming database operations of opening, searching through and updating files without delaying the salespoints in their POS activities. Therefore, the salespoints are never connected to the master database; the possibility for corruption and system crashes is greatly reduced and the speed of sales operations is greatly enhanced.

In addition, the middleware lets the salespoint know when it has completed its request. If the middleware server does not respond to the salespoint in thirty seconds (or whatever interval that you specify using the ServerTimeout .INI setting in the Sales32c.INI file) informing the salespoint of its successful operation, the salespoint automatically switches to standalone mode, operating independently of the network and saving its data locally. Once the middleware server and database server are available again, the locally saved data is automatically forwarded to the primary database on the database server for update.

Middleware also performs another important function. It not only transfers updated information from a salespoint to the database server, it also downloads updated and required information from the database server to the salespoints.

 

If a new account has been created on a given salespoint, the middleware updates the database server with that information, and then updates the other salespoints as well. If a new product is defined or a price is changed, that information is also transferred to all salespoints, on a continuous basis.

 

With a network of two or more computers, middleware can be installed on a dedicated server of its own, on the database server or even on a salespoint. If you are using less than twenty salespoints, Siriusware Inc. recommends that you run middleware on the same computer where you have SQL Server installed. If you have twenty or more salespoints, it should be installed on a separate computer. When installed on the same computer as SQL Server, there are no open data files being shared by the salespoints over network connections, which translates into less data vulnerability and more speed. However, you have to worry about the possibility of poor performance because you can “peg” the CPU on high-volume days. While a separate server can be used as the middleware server, installing middleware on the database server eliminates the network connection between the middleware and the files – a potential source of trouble. But for more than twenty salespoints, this is not a feasible configuration. When installed on a separate server, Salesware middleware includes functionality that monitors the connection to the database server, ensuring maximum uptime.

Another possible, but much less than optimal setup, is to have the middleware installed on a salespoint. The obvious advantage to this is that a single computer is used for two functions, reducing the number of computers to be purchased. However, this cancels out the purpose of the middleware, which is to prevent the salespoint computer from having open database files on the database server over a network connection. In this case, Sales would not be opening files from this computer, but middleware now would be, leaving your system vulnerable once again to data corruption and valuable use of network resources by performing time- and resource-consuming database operations over a network connection.

For more information on Salesware architecture, see the Salesware System Architecture and Specifications document. For more information on Salesware configuration, see the Salesware .INI Settings Reference document. Both of these documents are available from http://www.siriusware.com/docs.