User:Rfc1394/Scenario

The following gives an example of a scenario where an application program makes more sense than a web server.

Consider a large transaction-oriented application. A medium-sized school district, having, say, 60,000 employees, 400,000 students, hundreds of vendors and lots of equipment. Now, data entry can be done in a couple of ways. Bills, invoices and purchase orders can be entered by clerks. Payroll information can be transmitted by electronic time clocks in real time over the school's intranet to a server. Either a dedicated order-entry program or a web browser-based system would work.

But when it comes to processing the issuance of employee payments, either direct deposit with printed pay stub or checks, using a web server won't give you the economies of scale you could get by running a program on each computer to generate a payment. Having each machine send a request to the server to do this wastes the capability of individual machines to do the work, simply querying the main database for the next record. Also, the workload on the server of only handling database requests is going to be much less than also running 60 web server instances. And you don't have timeout issues as you do when a web browser is waiting for a response.

Also, if you have multiple machines normally doing data entry, those same machines can be set up to compute and print payroll or accounts payable checks (or, as is probably more likely, creating a transmission record to generate a direct deposit, while printing a pay stub instead of a check.)

• Each machine that prints actual checks can be started, along with its own printer and a batch of blank checks. Given the check number when started, it will request the next personnel record that is not marked as in progress, mark the record as in progress, and send it back to the database. If it can't save because of a conflict, it means some other machine was also given this same record, it will go back and ask for another record until it gets a record that has not been marked in progress and can mark it so.
• It will do the appropriate calculations, adding up base pay, overtime, bonuses or anything else.
• From this, deductions are taken: income tax, insurance, other benefits, union dues, garnishments, 401(K), and finally credit union. If not all goes to credit union, the rest might either go to a bank account or is actually printed on a check.
• Matching amounts would also be calculated, employer's matching Social Security, possible 401(k) match, contributions for insurance paid by the employer. These create new records related to this employee, either to store in the database, or to also generate records to be sent to a credit union, the IRS and state where the state(or city) also has income tax, and the employee's bank and/or credit union account. These might either be directed to a server handling them, to a database, or both.
• For most machines, what is generated is a pay stub, either without a check or a voided check. If actual checks are not used by this machine, the program might create a printer proof similar to a PDF except a dummy field is used in place of the check number, the proof is sent to the check stock print server, either as a message or by dropping a file in a shared directory. That machine would change the dummy number to the actual number, then possibly send the final information with the actual check number back to the database.
• If this is a stub-only print, that machine can print it locally, potentially on regular or reduced-size paper. Or the images can be sent to a different server so checks or stubs only can be generated on a high-speed fold-and-stuff machine that puts checks or stubs into pay envelopes and seals them.

Done using separate machines will do work like this much faster than having everything run on a single web server.

• If individual machines have multiple cores, and each one can be running the multiple copies of the same program, one on each separate core, potentially having 4 printers each generating a pay stub. If it takes 10 seconds to create a stub or check, a quadcore machine can be generating 24 checks a minute, the real problem will be keeping the printers full of paper.
• With 50 machines each running 4 copies of the program, 960 payroll records can be processed each minute, and 60,000 records can be processed in about 90 minutes or less. Very doubtful one server could process and generate 60,000 records that quickly.

But here is where Free Pascal can make a difference. Those machines could be PCs running Windows, or Linux, or instead of 60 PCs it could be a cluster of 240 Raspberry Pis running a Linux distribution. The same program, unmodified, could be compiled for all of them' and run on any of these and work exactly the same.

Well, actually thinking about it, you could have them designed to run unattended, possibly from a master console. Instead of printing messages on screen, each machine would send a request to the master console. The master console might assign the next record to process and sends it to one of the machines, in effect making each computer a kind of web server. Then it would create a payroll record and either print locally, or send the record to be printed, mark the record as completed (instead of in progress) then ask for the next record. When a machine runs out of paper, it can send that message, and the master console can report that.