Printing from ERP, CRM or EMR systems

In many organizations printing from backend systems is an important part of everyday printing, but a silo print solution, that’s treated like a “never touch a running system”. That concerns ERP printing e.g. from SAP as well as Oracle printing, or in the medical sector like printing from Mc Kesson, Cerner or Epic. In all these scenarios ThinPrint integrates backend printing into the same print system as all other print jobs. Thus ThinPrint performance, high availability and security advantages apply and ThinPrint tracking and reporting always show the complete picture of print traffic, -cost and -behavior.

In VDI/Remote App scenarios there’s an additional challenge. Roaming users login from different devices and locations and need the printout next to where they are. Backend printing however is only possible to predefined network printers. ThinPrint overcomes this challenge, too.

In this BLOG I’d like to take a look at both scenarios. The first sceanario is about integrating backend printing like CRM, EMR or ERP printing, CRM in general into the printing via a ThinPrint print server. The second scenario cares specifically at the VDI/Remote app scenario.

Backend Hub printing

Backend System prints LPR to ThinPrint Engine (on Windows Server) and TCP/IP via ThinPrint Hub to the printer.

1. Backend printing via LPR via the ThinPrint Server

In the first scenario, the backend systems from different platforms (often Unix) sends the print jobs via LPR to the ThinPrint Engine, which is running on a Windows server. From the ThinPrint Engine, the print job is sent with all ThinPrint performance features – compression, streaming, bandwidth control – and optionally TLS/SSL encrypted to guarantee low impact of printing on the network as well as fast printing and security of print data while print jobs travel to the printer. With ThinPrint clients integrated in printers, this is even possible all the way up to the printer.

ThinPrint advantages also apply to automated batch printing, for example printing of all receipts and letters at the end of each week. These print jobs can become very large. Without regulation, print jobs grab all available bandwidth which might result in a negative user experience. Therefore it is important to control and compress print data to prevent an impact on other data streams.
Even if print jobs have to travel to remote locations, e.g. to a remote warehouse, ThinPrint advantages do apply. Only the ThinPrint Client, e.g. a ThinPrint Hub is needed in the remote location. The ThinPrint Hub is a small box that can be shipped to the branch office, plugged into the network and then securely connects branch office printers to the central ThinPrint print server. No VPN is necessary to do so, the ThinPrint Secure Tunnel establishes an encrypted connection, like a VPN just for printing.

High availability of print services is another important ThinPrint advantage. Both the ThinPrint print servers as well as the ThinPrint clients – like the ThinPrint Hub or a ThinPrint client integrated into a printer – can be setup with load balancing and failover reacting to print specific issues. This is guaranteeing great performance and reliable printing at the same time. If e.g. a printer with integrated ThinPrint client stops working, ThinPrint automatically switches to the printer next to it. This can come in handy especially in the batch printing scenario, where nobody is checking the output while jobs are printed.

failover for printers

If a printer with integrated ThinPrint client stops working, ThinPrint automatically switches to the printer next to it.

2. Additional option for virtual desktop and remote application printing

If backend systems are accessed via apps that run in a Citrix XenApp/XenDesktop or Microsoft VDI/Remote App session, users are often logging in from changing locations and devices. Printing from backend systems however is usually rigid and only possible to predefined network printers. Here, another ThinPrint feature comes in very handy: The ThinPrint Host Integration Service can flexibly include the print job into the user session, enabling users to print to any printer they’re allowed to.

The ThinPrint Engine can either run on a Windows print server (like in the scenario above) or directly on the Terminal Server/RDSH. Either way, the print job is sent via the RDP or ICA/HDX protocol, which has an advantage and disadvantage at the same time (advantage: no need to configure TCP/IP, disadvantage: it’s usually best to keep printing out of the session). As always, even when print jobs are sent via RDP or ICA/HDX the ThinPrint performance advantages of compression, caching, bandwidth control and streaming make printing thin, smooth and fast.

ThinPrint assigns the fitting printers by mapping them based on different criteria, like IP address range, device that logs in and user/group name. ThinPrint Printer Self Service enables users to flexibly choose additional printers (with the according rights) by themselves at any time. The administrator no longer has to make manual changes to the backend, each time a user needs to print from another location or to another printer.

Bottom line: No matter from which device or location the users connect from, they can print to any printer that they’re allowed to, including locally connected printers and the admins no longer have to perform manual tasks each and every time.

Comments are closed.