Back to Blog

How We Print on Remote Printers

When we first started with Komet we were faced with a somewhat complex task: printing on our customers local printers. Normally this is a very simple task when the application is running within your own network or infrastructure, but in our case these networks were local and Komet is a web application running on Amazon.

 

At first we tried what seemed the simplest approach: We setup a Windows based print server and installed each of our customer printers there configuring them to use IPP (Internet Printing Protocol). This proved to be a nightmare for the following reasons:

 

  1. In some cases customers needed to open specific ports on their firewall, otherwise we were unable to connect to the printer.
  2. We always ran into driver issues. Label printers are very tough to configure but once they’re up and running they work perfectly for years. Having all the printers in a single server managed by us posed a challenge when troubleshooting.
  3. Again driver issues: we’d install a Zebra printer for a customer and a couple of weeks later we’d install another Zebra printer for a different customer. Suddenly the first printer (which was working) stopped working due to a driver incompatibility. We ran the risk of damaging functioning printers when installing a new printer.
  4. Single point of failure: if this server had an issue, nobody would be able to print.

 

After many weeks of trial and errors we concluded that this was not the way to go. We want back to the drawing board and decided that the best option consisted in creating a printer component that would be locally installed on each of our customers infrastructure and that would pull the print requests from a message queue. 

Printing Architecture

Now let’s break this down and understand how this works:

 

  1. A user using Komet is using an application server since that’s where the web app resides.
  2. Once an action triggers a document to be printed (e.g.: confirming an order) the app server creates a print message and sends it to a print queue.
  3. This message is pulled by the local printing component that’s installed at the customer’s side.
  4. The local printing component then connects to the Komet API and requests the PDFs of the documents that need to be printed.
  5. The documents are sent to the printing component and then they’re printed.

This solution gave us the following advantages:

  1. Each customer would have the flexibility to configure their printer: darkness, margins, printing preferences, etc. All of this is done locally so it does not interfere with the printer nor did it require our intervention.
  2. We eliminated the single point of failure problem: the printing components are installed on each customer and we use a highly available queue (AWS SQS – Simple Queue Service) to send the print messages.
  3. We eliminated any driver issues since it’s completely transparent to the application.

In addition to this the printer component gives us a greater flexibility to address complex printing needs. Here are a couple of examples of things that we’ve had to deal with:

  • Having multiple printers in a warehouse where certain carriers print to specific printers.
  • Printing certain number of copies based on certain business rules (e.g.: for local sales we print 2 copies of the invoices at the front desk, the pick ticket and labels in the warehouse).

I normally get the “if Komet is on the web how does it print on our printers?” as well as the “why is it such a big deal? It’s only printing some labels to a printer” so I hope that this brief explanation helps me answer those questions.

 

Alex

Related Blogs