Drucken aus ERP-, CRM- oder EMR (KIS)-Systemen
In vielen Unternehmen ist das Drucken aus Backend-Systemen ein wichtiger Bestandteil der Druckumgebung und oft auch ein geschäftskritischer Prozess. Das betrifft das ERP-Drucken, z.B. aus SAP sowie Oracle, ebenso wie das EMR-Drucken aus McKesson, Cerner oder Epic im medizinischen Bereich.
ThinPrint bietet Lösungen, um Druckaufträge aus unterschiedlichen Backend-Systemen performant auszugeben. Durch sein Hochverfügbarkeits-Feature stellt der neue ThinPrint LPD Service die Geschäftskontinuität beim Drucken aus ERP-, CRM- oder EMR (KIS)-Systemen sicher. Auch die Herausforderungen, die sich in VDI/Remote-App-Szenarien ergeben, meistert ThinPrint.
Optimiertes LPR-Drucken mit ThinPrint
Backend-Systeme verschiedener Plattformen (oft Unix) senden die Druckaufträge über LPR an die ThinPrint Engine, die auf einem Windows-Server läuft. Von der ThinPrint Engine wird der Druckauftrag mit allen ThinPrint-Leistungsmerkmalen wie Komprimierung, Streaming, Bandbreitenkontrolle und optional TLS-verschlüsselt zum ThinPrint Client gesendet. Insbesondere beim Drucken über WAN führt das zu einer Steigerung der Performance und einer Entlastung der Verbindungen. Für viele Unternehmen ist das ein großer Vorteil, da die Backend-Systeme meist zentral aufgestellt sind, während die Druckausgabe oft dezentral in Außenstellen oder Filialen erfolgt.
Hochverfügbares Drucken aus Backend-Systemen
Die Hochverfügbarkeit von ERP-, CRM- oder EMR (KIS)-Drucksystemen ist in den unterschiedlichsten Branchen von entscheidender Bedeutung, denn die Backend-Systeme unterstützen kritische Geschäftsprozesse und die Patientenversorgung. Ein Ausfall in einem dieser Systeme kann zu schwerwiegenden Störungen führen. ThinPrint sorgt durch Hochverfügbarkeit und Failover für den kontinuierlichen Betrieb der Drucksysteme.
Das Problem: Serverseitige Hochverfügbarkeit beim Drucken über LPR
Eine Besonderheit beim Druck aus ERP- oder EMR-Systemen besteht oft darin, dass Druckerwarteschlangen bzw. Druckernamen fest definiert sind. So wird ein hoher Grad an Automatisierung bzw. Drucken ohne zusätzliche Interaktion eines Anwenders möglich. Allerdings führt das zu Einschränkungen, wenn es darum geht, das Druckaufkommen auf mehrere Windows Druckserver zu verteilen bzw. eine Lösung für die Hochverfügbarkeit zu implementieren. Jeder Windows Druckserver hat seinen eigenen Spooler und damit eigene Druckerwarteschlangen.
In der Vergangenheit hat Microsoft zur Adressierung dieses Problems einen Druckservercluster mit virtuellen Warteschlangen unterstützt. Der Support wurde aber bereits mit Erscheinen von Server 2012 eingestellt, sodass es aktuell dafür keine Lösung gibt. Mehr zu Hochverfügbarkeit beim Drucken »
Die Lösung: Der neue ThinPrint LPD Service sorgt für Hochverfügbarkeit
ThinPrint hat sich dieser Herausforderung angenommen und bietet auch serverseitige Hochverfügbarkeit für das Drucken über LPR. Wir schließen damit auch eine Lücke für Kunden, die nicht über ein WAN drucken wollen – also keinen ThinPrint Client benötigen.
Prinzipiell war es in dem bisher betrachteten Szenario so, dass der integrierte Windows LPD die Druckjobs aus ERP- oder EMR-Systemen übernimmt. Dieser Dienst stellt aber selbst einen Single Point of Failure dar. Läuft der Dienst oder der nachgelagerte Spooler nicht, ist kein Druck möglich.
ThinPrint löst dieses Problem, indem wir einen eigenen LPD mit erweiterten Funktionen implementieren. Wir kombinieren außerdem bewährte ThinPrint-Hochverfügbarkeits-Technologie mit einem Network Load Balancer (NLB). Dieser wird vom Backend-System an Stelle des physischen Knotens zum Adressieren der Druckerwarteschlangen genutzt. Der ThinPrint-eigene LPD übernimmt dann diese Druckjobs.
Der ThinPrint Hochverfügbarkeits-Dienst auf den Druckservern überwacht die Server, deren Spooler und alle abhängigen Dienste u.a. auch den ThinPrint LPD. Dazu werden kontinuierlich diverse Health Checks durchgeführt. Im Falle eines Fehlers sorgt ThinPrint dafür, dass der fehlerhafte Knoten in den Status offline gesetzt wird. Alle Druckaufträge werden dann von dem alternativen Knoten (Druckserver) angenommen und abgearbeitet. Für das sendende Backend-System ist dieser Vorgang transparent.
Das Thema Sicherheit in der Druckumgebung wird ebenfalls berücksichtigt. Einerseits ist es möglich, per Whitelisting die sendenden LPR-Clients einzuschränken, andererseits können auch White Lists für die adressierbaren Druckerwarteschlangen erstellt werden.
Clientseitige Hochverfügbarkeit beim Drucken über LPR
Auch ThinPrint Client kann zur Vermeidung eines „Single Point of Failure“ hochverfügbar ausgelegt werden. Das kann u.a. dadurch geschehen, dass zwei Drucker mit integriertem ThinPrint Client adressiert werden oder bei Einsatz des ThinPrint Hubs eine zweite Instanz verwendet wird. In diesem Fall ist auch ein Load Balancing möglich.
Drucken von virtuellen Desktops, Terminal Servern und veröffentlichten Anwendungen
Eine weitere Herausforderung für das Backend-Drucken stellt das Bereitstellen der Druckobjekte für die Anwender.innen in den jeweiligen Anwendungen dar. Wenn über diese Anwendungen auf Backend-Systeme zugegriffen wird, die z.B. in einer Citrix XenApp/XenDesktop- oder Microsoft VDI/Remote App-Sitzung laufen, melden sich Benutzer.innen häufig von wechselnden Standorten und Geräten aus an. Das Drucken aus Backend-Systemen ist jedoch in der Regel statisch und nur auf vordefinierte Drucker möglich.
Mit ThinPrint AutoConnect als Bestandteil der ThinPrint Engine kann auch dieses Problem gelöst werden. Die ThinPrint Engine kann entweder auf einem Windows-Druckserver (wie im obigen Szenario) oder direkt auf dem Terminal Server/RDSH laufen. AutoConnect ist zuständig für die regelbasierte Bereitstellung der Drucker für die Anwender.innen. Grundsätzlich kann man zwei Methoden der Druckerbereitstellung (Mapping) betrachten:
- Mappen lokaler Drucker in die VDI-/Terminalserver-Sitzung
- Mappen von Druckern von zentralen Druckservern
Betrachten wir die Möglichkeiten im Einzelnen:
Mappen lokaler Drucker in die VDI-/Terminal-Server-Sitzung
Der ThinPrint Client (ICA oder RDP) auf der lokalen Workstation „meldet“ die lokalen Drucker an die ThinPrint Engine auf dem Server oder virtuellen Desktop. Diese legt die Druckobjekte für die Sitzungsdauer an. ThinPrint kann dafür sorgen, dass die Druckernamen für die Anwender.innen immer gleich bleiben, unabhängig davon, auf welchem Terminal Server/virtuellen Desktop sie sich anmelden. Das funktioniert auch beim Trennen/Verbinden der Sitzung ohne Abmeldung. Eine ständige Neukonfiguration in den Backend-Systemen ist damit nicht notwendig. Zum Vergleich: mit Microsoft oder Citrix-Bordmitteln für das Verbinden der Drucker wird immer eine Sitzungs-ID in den Druckernamen eingebunden. Diese ändert sich aber mit jedem neuen Sitzungsaufbau.
Mappen von Druckern von zentralen Druckservern
Eine große Stärke von ThinPrint AutoConnect ist das Bereitstellen von Druckobjekten von Druckservern in VDI-/Terminal-Server-Sitzungen. Dafür können verschiedene Kriterien, die auch untereinander kombinierbar sind, herangezogen werden. Neben AD-Anwender.innen und AD-Gruppen kann auch eine IP-Adresse oder ein Subnetz als Kriterium für die Regeln verwendet werden. Gerade das Mapping per Subnetz ermöglicht es Anwender.innen, die häufig Standorte wechseln, Drucker standortbezogen ohne administrativen Eingriff zu erhalten. Hervorzuheben ist auch die Möglichkeit, Drucker fest für einen oder mehrere Clients (Hosts) zu mappen. D.h. unabhängig vom.von der Anwender.in, der.die sich anmeldet, wird immer derselbe Drucker verbunden. Klassische Anwendungsfälle finden sich hier insbesondere im Klinikumfeld bzw. in der Logistikbranche.
Und zu guter Letzt: ThinPrint bietet auch eine Self-Service App für das Verbinden der Drucker. Falls von administrativer Seite gewünscht, kann den Anwender.innen damit mehr Eigenständigkeit und Flexibilität gegeben werden. Anwender.innen können sich die Drucker aus dem für sie verfügbaren Pool auswählen und auch den Standarddrucker selbst definieren.
