Some time ago, I recall reading a Blog about Printing as a Service (PAAS) by my colleague Brent Black. At the time, I never expected to be involved in a project revolving around PAAS, but a recent customer example changed all that. The benefits the company sought were the flexibility to adapt to new requirements and the simplification of their printing infrastructure.
This retail company approached us because they were developing a new Java application that creates documents using the typical Java libraries for composing documents like iText or Crystal Reports. These libraries produce documents in PDF format, which is not always the best format for printing. The document types ranged from invoices to sales tickets and contained different paper formats (A4, A5, A6) with different fonts and styles. All of these documents must be able to print on thousands of different print devices from multiple vendors and support various printing languages used in laser printers, thermal printers, and more.
This complex scenario would require a lot of development effort. Apart from creating a proper Java application to manage the information, the application would have to control where to print the document and how to generate the appropriate document formats for each device type. This involves selecting the correct printer language as well as the appropriate printer commands for each printer brand or model. For example, producing documents for different paper formats would entail embedding a set of printer commands to select the suitable printer tray. The risk is that this would make the application more and more complex and difficult to maintain when new printer devices are added or new document formats are created.
Like many other retail companies, this customer uses print to enhance the customer experience at the point of purchase. When a sales ticket is generated, a series of discount coupons and marketing messages are also printed as a part of the sales transaction. These tickets are designed to be printed and cut individually at POS (point of sale) thermal printers. Unlike other output devices, such printers do not use standard printing languages but rather a special page description language (PDL) used primarily for labeling applications.
Further complicating matters, this retailer has employed innovations like providing customer-facing staff with PDA devices to assist sales. This allows them to move around with the customer as they look for products and add these items to the customer’s order on the fly. When the customer has finished shopping, the salesperson brings the PDA near the printer where all the tickets are supposed to print. Using NFC technology, the printer is identified and the Java application is directed to send all tickets to the selected printer.
Without a doubt, all of these requirements make the application harder and more expensive to develop and maintain over time.
But what if we relegated all of these functions to a specific infrastructure layer designed to relieve the rest of the system of these print-related tasks? In recent years, we’ve heard and read about many such services — often delivered over the Internet rather than hosted locally or on-site — in which software is licensed on a subscription basis.
Now apply this concept to printing. One can easily imagine a service running as single middleware architecture that communicates with various applications. These applications may run on Windows, UNIX, Linux, or other platforms and deliver any kind of document to a variety of printer devices. The middleware needs to convert the native format created by the application into a printer-ready form suitable for the target device. Such a solution dramatically simplifies the applications, making them easier to maintain in the long term.
Back to the customer example… using LRS output management software, the applications that produce documents in different formats and PDLs are relieved of the burden of printing. They only need to pass the document data and the ID of the destination printer. No worrying about which languages are supported by the printer, no need to add special device-dependent commands to specify which input tray contains the appropriate paper size, no more need to check whether the document has been printed correctly. All these tasks can be handled by the LRS software using one of the many APIs distributed with the service. These APIs can not only be used to send the document, but also to verify that the proper output is delivered in time and suitably to complete the business process. Moreover, when new printer models are added to the fleet, they become available for printing as soon as they are added to the LRS software.
For the sales tickets that roaming employees print from their PDAs, LRS software converts the information to a PDL that the POS thermal printer can handle. It also bundles together the sales ticket and related coupons or advertising into a single document. This way, the application doesn’t need to keep track of which tickets have been released for each transaction. Just send each ticket to the LRS solution (along with the associated transaction ID), and let the LRS software bundle them all together when the final piece of data is received. The LRS software can also add the special commands that are needed to force the printer to cut the paper after each individual ticket. So now, when the salesperson walks over to the printer with their PDA, the bundle of tickets is ready to be delivered to the printer without delay and combined in a single bunch. This ensures that each salesperson gets only the tickets that they are expecting.
This example shows how the use of LRS software as a service for printing can simplify application development by reducing the number of tasks and providing better control of document flow. The advantages extend to other systems as well, since all LRS-defined printers are also available for other applications running on different platforms. The LRS solution also establishes a central driver repository and a mechanism to track who prints what as well as which workers are adhering to printing policies designed to reduce paper waste. In short, this Printing as a Service approach establishes a new way of printing that provides a central point of control for all of an organization’s documents.
It doesn’t end there. We’ve all experienced companies that prefer to send tickets and other documents by email instead of print — it’s cheaper for the vendor, simpler for the customer, and better for the environment. Shifting existing applications to electronic document delivery can be complicated if print functions are hard-coded in the application. But if you have already adopted the Printing as a Service methodology, it’s a simple matter of making a few changes in the configuration.
Imagine the advantages for your organization of adopting this service-oriented approach to printing. Now stop imagining and start doing. It is time to make it happen, and LRS can help you in this mission.