Impression d'étiquettes avec Kafka : le flux comme déclencheur

Le flux existe déjà

Votre ERP ou MES publie déjà les événements de commandes, les messages de préparation et les numéros de série vers Kafka. Habituellement, ce flux se termine sur un écran et un humain appuie sur imprimer.

L'onglet Data Streaming fait du flux le déclencheur : abonnez-vous à un topic, et chaque message est rendu avec un design d'étiquette et envoyé à une imprimante. Pas de middleware, pas de travail de polling, pas de serveur d'impression.

Deux déploiements :

• Cloud - la plateforme consomme le topic elle-même (Confluent Cloud, MSK, n'importe quel broker accessible par internet).
• On-prem - un broker dans votre réseau, consommé par l'agent CLI zplCloud. Les identifiants du broker ne quittent jamais votre réseau.

Ce qu'un abonnement lie

Quatre choses : un topic, un design d'étiquette, une imprimante et - en mode cloud - la configuration de connexion du broker. Pour chaque message, la plateforme :

1. analyse la valeur comme JSON et utilise les clés de l'objet comme bindings de champs,

2. rend le design avec le même moteur que le designer,

3. envoie le ZPL résultant à l'imprimante (Weblink, ou une imprimante distante sur un agent CLI via TCP 9100 / USB).

Si la valeur n'est pas du JSON, tout le texte est lié à $message - suffisant pour une étiquette à champ unique.

Configuration de connexion

La configuration est une chaîne clé=valeur;, stockée chiffrée AES au repos :

BootstrapServers=pkc-xxxxx.eu-central-1.aws.confluent.cloud:9092;
GroupId=zplCloudPrinter;
SecurityProtocol=SaslSsl;SaslMechanism=Plain;
SaslUsername=<api-key>;SaslPassword=<api-secret>

Valeurs par défaut appliquées si vous ne les définissez pas :

AutoOffsetReset=Earliest est l'option délibérée pour rejouer un topic. Ne l'activez que si vous le voulez vraiment : sur un topic avec historique, le premier démarrage imprime tout.

SCRAM (SaslMechanism=ScramSha256 / ScramSha512) et une CA personnalisée (SslCaLocation=…) sont pris en charge. Les clés inconnues sont transmises telles quelles à la configuration du consommateur.

Pour un broker on-prem, enregistrez-le sur l'agent à la place :

zplcloud proxy --agent "Lager" \
  --kafka LOKAL="BootstrapServers=10.0.0.10:9092;GroupId=zplCloudConsumer"

L'agent signale Kafka brokers: LOKAL. Quand un abonnement en a besoin, la plateforme demande à l'agent d'exécuter le consommateur - le broker reste inaccessible depuis internet.

La sémantique de livraison, précisément

C'est la partie où la plupart des intégrations de streaming deviennent vagues, alors voici exactement comment c'est implémenté :

• Le consommateur interroge avec un délai de 30 secondes.

• Sur un message : rendre, imprimer, puis Commit(msg) uniquement si l'impression a réussi.
• Si l'impression échoue, l'offset n'est pas confirmé et le consommateur s'arrête. L'abonnement passe à déconnecté et affiche Print failed: <error>. Il ne saute pas le message et ne tourne pas en boucle de réessai.
• Parce que la valeur par défaut est AutoOffsetReset=Latest, un redémarrage après un échec ne relivre pas automatiquement le message échoué. Si vous voulez que le message échoué soit réessayé au redémarrage, mettez AutoOffsetReset=Earliest dans la config - alors l'offset non confirmé est repris.

Le raisonnement : une étiquette qui n'a pas été imprimée est un fait opérationnel que quelqu'un doit voir. Avancer en silence perdrait une étiquette physique ; réessayer éternellement bloquerait la partition. S'arrêter la rend visible et laisse l'offset où il est.

ConsumeException - broker injoignable, auth rejetée, topic supprimé - est traitée différemment. Ce n'est pas un échec d'impression, donc le consommateur réessaie avec un backoff exponentiel commençant à 5 s et plafonné à 60 s, et la dernière erreur de broker est affichée sur l'abonnement.

Keepalive d'inactivité

Si aucun message n'arrive pendant 60 secondes, la plateforme envoie une commande de réveil à l'imprimante cible. Les imprimantes Link-OS passent en état de faible consommation ; sans le keepalive, le premier message après une période calme paie la latence de réveil avant d'imprimer. Le keepalive touche l'imprimante, pas le topic - aucun offset n'est consommé ni confirmé.

Créer l'abonnement

Appuyez sur Démarrer. L'abonnement affiche alors l'état en direct - connecté, heure du dernier message, dernier offset, nombre de messages - et un journal avec les valeurs récentes des messages et leur résultat d'impression.

Forme du message

{ "ean": "40063813", "qty": 2, "dest": "Ramp 4" }

Les clés correspondent aux bindings par nom. Les clés qu'aucun binding n'utilise sont ignorées ; les bindings sans clé correspondante se rendent vides. Concevez l'étiquette contre un vrai message avant de passer en production - Données de test dans le designer accepte du JSON collé.

Comportement au redémarrage

Les abonnements actifs redémarrent quand la plateforme redémarre, et les abonnements on-prem redémarrent quand l'agent CLI se reconnecte. Une fenêtre de maintenance nocturne ou une connexion coupée ne nécessitent pas que quelqu'un appuie à nouveau sur Démarrer - avec l'exception ci-dessus : un abonnement arrêté par un échec d'impression reste arrêté jusqu'à ce que vous répariez l'imprimante et le démarriez.

Plans

Le streaming de données est mesuré. Starter l'inclut pour les tests, plafonné à 100 étiquettes en streaming par mois. Pro inclut 2 endpoints de streaming (Kafka / Azure Service Bus) ; chaque endpoint supplémentaire coûte 10 € par mois. Voir la page de prix.

Liens

• CLI zplCloud - agent, brokers, installation de service
• Agent comme conteneur Docker
• Cloud Integration / Connections