zplCloud Blog
Kafka-Topics direkt auf den Drucker: Data Streaming als Druck-Trigger
Eine Subscription = Topic + Design + Drucker. Interessant wird es bei der Frage, was der Consumer bei einem fehlgeschlagenen Druck macht.
Den Stream gibt es schon
Dein ERP oder MES veröffentlicht Auftragsereignisse, Kommissioniermeldungen und Seriennummern längst nach Kafka. Meistens endet dieser Stream auf einem Bildschirm, und ein Mensch drückt auf Drucken.
Der Tab Data Streaming macht den Stream selbst zum Auslöser: Topic abonnieren, und jede Nachricht wird mit einem Label-Design gerendert und an einen Drucker geschickt. Keine Middleware, kein Polling-Job, kein Druckserver.
Zwei Betriebsarten:
- Cloud - die Plattform konsumiert das Topic selbst (Confluent Cloud, MSK, jeder aus dem Internet erreichbare Broker).
- On-Prem - ein Broker in deinem Netz, konsumiert vom zplCloud-CLI-Agent. Broker-Zugangsdaten verlassen dein Netz nicht.
Was eine Subscription verbindet
Vier Dinge: ein Topic, ein Label-Design, einen Drucker und - im Cloud-Modus - die Broker-Konfiguration. Für jede Nachricht gilt:
1. Wert als JSON parsen, die Objekt-Keys werden zu Feld-Bindings,
2. Design mit derselben Engine rendern, die auch der Designer nutzt,
3. das erzeugte ZPL an den Drucker senden (Weblink oder ein Remote-Drucker am CLI-Agent über TCP 9100 / USB).
Ist der Wert kein JSON, wird der gesamte Text an $message gebunden - genug für ein einfeldriges Label.
Verbindungskonfiguration
Die Konfiguration ist ein key=value;-String und wird AES-verschlüsselt gespeichert:
BootstrapServers=pkc-xxxxx.eu-central-1.aws.confluent.cloud:9092;
GroupId=zplCloudPrinter;
SecurityProtocol=SaslSsl;SaslMechanism=Plain;
SaslUsername=<api-key>;SaslPassword=<api-secret>
Defaults, wenn du nichts angibst:
| Einstellung | Default | Warum das zählt |
|---|---|---|
AutoOffsetReset | Latest | eine neue Subscription startet am Kopf - sie druckt beim ersten Start nicht die gesamte Topic-Historie |
EnableAutoCommit | false | Offsets committet die Plattform, nach erfolgreichem Druck - nicht per Timer |
AutoCommitIntervalMs | 0 | ohne Auto-Commit ohne Bedeutung |
AutoOffsetReset=Earliest ist der bewusste Opt-in fürs Nachlesen eines Topics. Setz es nur, wenn du es meinst: Auf einem Topic mit Historie druckt der erste Start alles.
SCRAM (SaslMechanism=ScramSha256 / ScramSha512) und eine eigene CA (SslCaLocation=…) werden unterstützt. Unbekannte Keys reicht der Parser unverändert an die Consumer-Konfiguration durch.
Für einen On-Prem-Broker registrierst du ihn stattdessen am Agent:
zplcloud proxy --agent "Lager" \
--kafka LOKAL="BootstrapServers=10.0.0.10:9092;GroupId=zplCloudConsumer"
Der Agent meldet Kafka brokers: LOKAL. Braucht eine Subscription ihn, weist die Plattform den Agent an, den Consumer zu starten - der Broker bleibt aus dem Internet unerreichbar.
Die Zustellsemantik, genau
Genau hier bleiben die meisten Streaming-Integrationen vage, deshalb exakt wie implementiert:
- Der Consumer pollt mit 30 Sekunden Timeout.
- Bei einer Nachricht: rendern, drucken, und
Commit(msg)nur, wenn der Druck erfolgreich war. - Schlägt der Druck fehl, wird der Offset nicht committet und der Consumer stoppt. Die Subscription geht auf „nicht verbunden" und zeigt
Druck fehlgeschlagen: <Fehler>. Sie überspringt die Nachricht nicht und dreht auch keine Retry-Schleife. - Weil der Default
AutoOffsetReset=Latestist, wird die fehlgeschlagene Nachricht nach einem Neustart nicht automatisch erneut zugestellt. Wenn du genau das willst, setzAutoOffsetReset=Earliestin die Konfiguration - dann wird der nicht committete Offset wieder aufgegriffen.
Die Begründung: Ein Label, das nicht gedruckt wurde, ist ein Betriebsvorfall, den jemand sehen muss. Stilles Weiterschalten würde ein physisches Etikett verlieren, endloses Wiederholen die Partition blockieren. Anhalten macht es sichtbar und lässt den Offset stehen.
Eine ConsumeException - Broker nicht erreichbar, Auth abgelehnt, Topic weg - wird anders behandelt. Das ist kein Druckfehler, also versucht es der Consumer mit exponentiellem Backoff ab 5 s, gedeckelt bei 60 s, erneut; der letzte Broker-Fehler steht an der Subscription.
Keepalive im Leerlauf
Kommt 60 Sekunden lang keine Nachricht, schickt die Plattform ein Wake-Kommando an den Zieldrucker. Link-OS-Drucker gehen in einen Energiesparzustand; ohne Keepalive zahlt die erste Nachricht nach einer ruhigen Phase die Aufwachzeit, bevor sie druckt. Das Keepalive betrifft den Drucker, nicht das Topic - es wird kein Offset konsumiert oder committet.
Subscription anlegen
| Feld | Wert |
|---|---|
| Name | Produktionslabels |
| Typ | Cloud (Internet) oder On-Prem (über zplCloudCli) |
| Verbindungskonfiguration | nur Cloud: BootstrapServers=…;… |
| Agent + Broker | nur On-Prem: Agent und Broker-Chip auswählen |
| Topic | production.orders |
| Label-Design | das Design, dessen Bindings zu den Message-Keys passen |
| Drucker | Weblink-Drucker oder Remote-Drucker am CLI-Agent |
Start drücken. Danach zeigt die Subscription Live-Status - verbunden, Zeit der letzten Nachricht, letzter Offset, Nachrichtenzähler - und ein Log mit den jüngsten Werten und ihrem Druckergebnis.
Aufbau der Nachricht
{ "ean": "40063813", "qty": 2, "dest": "Rampe 4" }
Keys werden über den Namen auf Bindings abgebildet. Keys ohne Binding werden ignoriert, Bindings ohne passenden Key rendern leer. Entwirf das Label gegen eine echte Nachricht, bevor du live gehst - Testdaten im Designer nimmt eingefügtes JSON entgegen.
Neustartverhalten
Aktive Subscriptions starten neu, wenn die Plattform neu startet; On-Prem-Subscriptions starten neu, wenn der CLI-Agent sich wieder verbindet. Ein nächtliches Wartungsfenster oder eine abgerissene Verbindung erfordert also kein manuelles Start - mit der Ausnahme oben: Eine durch Druckfehler gestoppte Subscription bleibt gestoppt, bis der Drucker in Ordnung ist und du sie startest.
Tarife
Data Streaming wird gemessen. Starter enthält es zum Testen, begrenzt auf 100 gestreamte Labels pro Monat. Pro enthält 2 Streaming-Endpunkte (Kafka / Azure Service Bus), jeder weitere kostet 10 € pro Monat. Siehe Preisseite.