zplCloud Blog
Weblink vs. CLI-Proxy vs. CloudToBrowserPrint: Welche Verbindung brauchst du wirklich?
Drei Transportwege, drei verschiedene Aufgaben. Alle rein ausgehend - der Unterschied liegt darin, wer die Verbindung hält und was er unterwegs konvertieren kann.
Gleiches Prinzip, andere Mechanik
Es gibt drei Wege, ein Etikett aus zplCloud auf einen physischen Drucker zu bekommen. Sie werden regelmäßig verwechselt, und die falsche Wahl kostet einen Tag Fehlersuche.
Alle drei teilen eine Eigenschaft: Die Verbindung wird immer von innen nach außen aufgebaut. Kein eingehender Port, keine Portweiterleitung, kein VPN, kein Drucker im Internet. Unterschiedlich ist, welche Komponente diese Verbindung hält - und was sie mit einem Druckauftrag machen kann, bevor er den Drucker erreicht.
Cloud Connect / Weblink - der Drucker wählt sich ein
Weblink ist Zebras eigener Mechanismus, provisioniert über zplCloud. Eine Relay-Komponente in deinem Netz hält einen ausgehenden WebSocket zur Plattform; der Drucker authentifiziert sich per mTLS mit drei Zertifikatsdateien, die in seinen Flash geschrieben werden (WEBLINK2_CA.NRD, WEBLINK2_CERT.NRD, WEBLINK2_KEY.NRD).
irm "https://zplcloud.com/weblink-deploy.ps1?hostname=printer01&apikey=sk_zplcloud_XXXX" | iex
curl -fsSL "https://zplcloud.com/weblink-deploy.sh?hostname=printer01&apikey=sk_zplcloud_XXXX" | bash
Das Skript lädt die Zertifikate des Druckers, überträgt sie per TCP 9100 (~DY), setzt die SGD-Variablen für Weblink-URL und NTP und startet den Drucker neu. Wird der Hostname im Netz nicht aufgelöst, hängst du &ip=10.0.0.5 an - der Hostname wählt weiterhin das Zertifikat, die IP ist nur das TCP-Ziel.
Wann: Der Drucker ist ein dauerhaftes Produktionsgerät und soll von überall in der Plattform erreichbar sein - Designer, Print Views, Batch-Jobs, Webhooks, API. Für einen Link-OS-Drucker an einem festen Platz ist das der Standardweg.
Voraussetzung: ein Link-OS-Drucker. Ein GK420 oder ein anderes Gerät vor Link-OS kann Weblink überhaupt nicht.
zplCloud-Proxy - ein Agent, den du betreibst
Der Proxy gehört zur zplCloud-CLI. Er läuft auf einer beliebigen Maschine im LAN - Windows, macOS, Linux, Raspberry Pi oder als Container - und registriert Drucker über eine ausgehende SignalR-Verbindung in deinem Workspace.
curl -fsSL https://zplcloud.com/install-cli.sh | sh
zplcloud proxy --agent "Lager Berlin" --service-install --api-key sk_zplcloud_XXXX
Er erreicht Drucker über TCP 9100 oder USB - und das ist der entscheidende Unterschied: Ein reiner USB-Desktopdrucker hat keinen Netzwerkstack, mit dem er sich einwählen könnte, der Agent ist also der einzige Weg, ihn in die Cloud zu holen. Der Agent wendet außerdem Druckerprofile an (Schwärzung, Geschwindigkeit, Medien, SGD-Variablen), sendet rohes ZPL, überwacht Ordner auf .zpl/.prn-Dateien und kann SQL-Server-, MongoDB- und Kafka-Verbindungen für den Datenhub tragen.
--service-install schreibt unter Linux und auf dem Pi eine systemd-Unit (zplcloud-agent.service, Restart=always), unter macOS einen launchd-Job, unter Windows eine geplante Aufgabe.
Wann: Du verwaltest eine Flotte, hast USB- oder ältere Drucker, brauchst einheitliche Profile über Standorte hinweg, oder willst denselben Agent für deine Datenquellen nutzen.
CloudToBrowserPrint - ein lokaler Dienst für Webseiten
CloudToBrowserPrint ist ein lokaler HTTP-Dienst auf dem Rechner der Bedienung:
http://127.0.0.1:9100 (https://127.0.0.1:9101 - nötig für Safari und jede https-Seite)
Eine Webseite im LAN spricht direkt mit ihm, unter anderem über einen SignalR-Hub unter /hubs/print. Er findet Drucker (Netzwerkdrucker aus printers.json, USB, Bluetooth), konvertiert Formate, dekodiert Barcodes und sendet Rohdaten. Die Cloud liegt nicht im Pfad - eine Seite kann drucken, ohne dass ein zplCloud-Roundtrip stattfindet.
irm https://zplcloud.com/install-cloudtobrowserprint-pshell | iex
Weil der Dienst auf einem bekannten Port lauscht, vor dem Rollout auf Konflikte prüfen - 9100 ist bei anderer Software beliebt, und der Dienst sagt dir, wenn er belegt ist.
Wann: Deine eigene Webanwendung soll auf den Drucker drucken, der neben dem Benutzer steht, oder du willst browsergetriebenen Druck ohne Cloud-Abhängigkeit im Druckpfad.
Gegenüberstellung
| Weblink | CLI-Proxy | CloudToBrowserPrint | |
|---|---|---|---|
| Läuft wo | Relay im LAN + Zertifikate im Drucker | Agent auf einer LAN-Maschine / Container | lokaler Dienst beim Benutzer |
| Erreicht den Drucker über | Zebra Weblink (mTLS) | TCP 9100, USB | TCP 9100, USB, Bluetooth |
| Cloud zum Drucken nötig | ja | ja | nein |
| Funktioniert ohne Link-OS | nein | ja | ja |
| Formate | ZPL aus der Plattform | rohes ZPL | ZPL, PDF, Office, Bilder, Barcodes |
| Extras | Zertifikats-Deploy, Fernverwaltung | Profile, Watch-Folder, Datenhub | Discovery, Konvertierung, Barcode-Dekodierung |
| Typischer Einsatz | feste Produktionsdrucker | verwaltete Flotten, USB, Außenstandorte | Web-Apps, Ad-hoc-Druck am Arbeitsplatz |
Auswahl
- Link-OS-Drucker, steht fest, druckt aus der Plattform → Weblink.
- USB-Drucker, alter Drucker oder eine Flotte, die du verwaltest → CLI-Proxy. (Ein alter USB-Desktopdrucker plus Raspberry Pi ist ein vollständiges Setup; dazu gibt es einen eigenen Beitrag.)
- Eigene Web-App, die auf den Drucker neben dem Benutzer druckt → CloudToBrowserPrint.
- Ein echter Standort betreibt meist zwei davon: Weblink an den Produktionsdruckern, den Agent für Flotte und Datenquellen.