Comment connecter les étiquettes ESL aux articles via l’API

Le planogramme est mis à jour. Les prix sont corrects dans l’ERP, corrects dans le modèle d’étiquette de gondole, corrects dans la fiche produit. Et pourtant, trois heures plus tard, un rayon affiche encore l’ancien prix — parce que l’étiquette électronique de gondole fixée à cet emplacement est toujours liée à l’article qui s’y trouvait auparavant. Quelqu’un doit parcourir le rayon avec un terminal portable, scanner l’étiquette, scanner l’article, et répéter l’opération quelques centaines de fois.

Cette étape de liaison manuelle est le dernier maillon de l’étiquetage de gondole qui résiste à l’automatisation. Ce n’est pas une fatalité. Avec l’API ESL Binding du Next Generation Label Printing System (LPSNG), vous pouvez associer les étiquettes ESL aux articles par programmation, pousser les données d’article vers les afficheurs via une interface JSON neutre vis-à-vis des fournisseurs, et ne recourir à un scanner que lorsque quelque chose a réellement mal tourné.

Cet article détaille l’automatisation de bout en bout : la configuration initiale, le pipeline qui réalise la liaison, ce qu’il faut surveiller, et comment la maintenir fiable.

Configuration initiale : préparer votre environnement ESL

Cette opération se fait une seule fois par magasin, station de base ou unité MDE (saisie de données mobile). Tout ce qui suit est une tâche planifiée.

1. Enregistrer votre système externe

LPSNG utilise un protocole d’enregistrement OAuth2 simplifié : vous connectez un système externe — une station de base ESL, une unité MDE portable, un service middleware — avec une seule URL. LPSNG gère l’échange de jetons derrière cet enregistrement, vous n’avez donc pas à implémenter un client OAuth2 de zéro.

En pratique, cela signifie que votre configuration d’intégration contient une URL d’enregistrement et un identifiant, et non une machine à états de rafraîchissement de jetons :

# lpSng-integration.yaml
esl:
  registration_url: "https://lpsng.rsj.de/..."   # from your LPSNG registration
  client_id: "${LPSNG_CLIENT_ID}"
  client_secret: "${LPSNG_CLIENT_SECRET}"        # keep in a secret store, not in git
  store_id: "store-0417"

Stockez ces valeurs dans un gestionnaire de secrets. L’enregistrement est la seule étape dont une erreur est coûteuse à corriger.

2. S’assurer que le matériel est joignable

Vos étiquettes ESL doivent être installées et à portée de leur station de base ou passerelle avant qu’un appel API puisse aboutir. Si vous utilisez du matériel ESL CATIC, suivez les instructions d’installation CATIC — le placement des antennes et l’adressage des étiquettes sont les deux éléments qui causent le plus souvent le cas « l’API a fonctionné mais rien n’a changé en rayon ».

3. Confirmer votre canal de mise à jour des afficheurs

Le contenu des afficheurs est mis à jour via l’interface de fichiers JSON neutre vis-à-vis des fournisseurs (ESLSEND). C’est l’aspect qui compte sur le plan architectural : la charge utile est du JSON, pas un format binaire propriétaire, votre intégration n’est donc pas soudée à un seul fournisseur d’étiquettes. Nous avons couvert les implications dans What a Vendor-Neutral ESL Interface Means for Developers.

4. Pointer LPSNG vers vos données d’articles

L’étape de liaison a besoin de quelque chose à lier. LPSNG peut utiliser des fichiers Excel comme fichiers de données et de correspondance, un module complémentaire Google Sheets pour les équipes qui vivent dans les tableurs, ou votre ERP comme source amont. La logique de liaison elle-même s’en moque — il lui faut une clé stable (SKU ou EAN) et les champs que vous voulez afficher.

Si vous voulez la voie difficile, vous pouvez fabriquer à la main les fichiers JSON ESLSEND et exécuter vous-même l’échange de jetons OAuth2. Le workflow managé de LPSNG existe pour que vous n’ayez pas à le faire.

Le pipeline automatisé : lier les étiquettes aux articles

Voici le déroulé, étape par étape.

Étape 1 — Déclencher le processus de liaison

L’API ESL Binding est un service web conçu spécifiquement pour les unités MDE qui n’ont pas d’interface web : un terminal portable peut l’appeler, une tâche cron peut l’appeler, un webhook peut l’appeler. Une exécution de liaison démarre par une seule requête HTTP.

curl -X POST "$LPSNG_BASE/binding/jobs" \
  -H "Authorization: Bearer $LPSNG_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
        "store_id": "store-0417",
        "source": "erp-sync-2026-10-18",
        "mode": "reconcile"
      }'

Le chemin et les paramètres exacts figurent dans la documentation de l’interface de service web ; l’important est qu’une exécution de liaison est une tâche que vous soumettez, pas une session que vous suivez en direct.

Étape 2 — Laisser LPSNG faire correspondre les articles aux identifiants d’étiquettes

C’est l’étape qui remplace le scanner. LPSNG prend les identifiants d’articles (SKU, EAN) de votre source de données et les fait correspondre aux identifiants d’étiquettes ESL, en utilisant la relation étiquette-emplacement déjà connue du système. Votre code n’a jamais besoin de savoir quelle étiquette physique pend au-dessus de quelle étagère.

Si vous pilotez la réconciliation vous-même, la boucle est courte :

import os, requests

BASE = os.environ["LPSNG_BASE"]
HEADERS = {"Authorization": f"Bearer {os.environ['LPSNG_TOKEN']}"}

def reconcile(store_id: str, items: list[dict]):
    """items: [{"sku": "...", "ean": "...", "price": "...", "name": "..."}]"""
    resp = requests.post(
        f"{BASE}/binding/jobs",
        headers=HEADERS,
        json={"store_id": store_id, "items": items, "mode": "reconcile"},
        timeout=30,
    )
    resp.raise_for_status()
    return resp.json()["job_id"]

Étape 3 — Pousser les données d’article vers les afficheurs

Une fois une étiquette liée, LPSNG met à jour l’afficheur ESL avec les valeurs propres à l’article que vous fournissez — prix, nom, code-barres, tout ce que la mise en page utilise — via l’interface JSON ESLSEND. Une charge utile minimale ressemble à peu près à ceci (voir la documentation de l’interface ESL pour le schéma complet) :

{
  "esl_id": "TAG-0042-1188",
  "item": {
    "sku": "SKU-88213",
    "ean": "4012345678901",
    "name": "Organic Coffee 500g",
    "price": "8.49"
  }
}

Comme le format est neutre vis-à-vis des fournisseurs, changer de matériel d’étiquettes plus tard est une question de déploiement, pas une réécriture.

Étape 4 — Imprimer les étiquettes qui doivent encore l’être

Certaines choses restent physiques : les chevalets promotionnels, les bandes de gondole, les étiquettes de colis. Celles-ci peuvent être générées à partir des mêmes données d’article, car l’API de service web de LPSNG peut soumettre des tâches d’impression et générer des étiquettes individuelles en PDF ou PNG, et le Player autonome peut produire du PDF, du PNG, du JSON, des tâches d’impression ou des mises à jour ESL à partir de la même entrée package-plus-données. Une seule source de données, deux canaux de sortie.

Le tout sous forme de workflow planifié

Une réconciliation nocturne suffit généralement :

# crontab: every night at 02:15, after the ERP export lands
15 2 * * * /usr/local/bin/python /opt/esl/sync.py --store store-0417 >> /var/log/esl-sync.log 2>&1

# sync.py (sketch)
items = load_from_erp()          # or read the Excel/Sheets export
job_id = reconcile("store-0417", items)
wait_for_job(job_id)             # poll LPSNG for job status
handle_failures(job_id)          # retry or flag

Cron fait l’affaire. Un webhook depuis votre ERP est mieux — il lie les étiquettes au moment où les prix changent plutôt que des heures plus tard.

Surveillance et gestion des échecs

Une automatisation que vous ne pouvez pas voir est une automatisation en laquelle vous ne pouvez pas avoir confiance.

• Suivez les tâches dans la file de tâches. La file de tâches de LPSNG fait partie des fonctionnalités de base de chaque édition. Les exécutions de liaison et les mises à jour d’afficheurs y apparaissent, et les tâches échouées y sont journalisées pour examen.
• Réessayez, ne paniquez pas. Si une étiquette est injoignable, l’API renvoie une erreur. Configurez une logique de nouvelle tentative pour les échecs transitoires (une étiquette temporairement hors de portée) et signalez le reste à un humain.
• Surveillez l’état des étiquettes. L’état de la batterie et du signal est visible via l’interface ESL. C’est en interrogeant ces données que vous repérez l’étiquette qui va mourir la semaine prochaine plutôt que celle qui est déjà morte.
• Alertez de votre côté. Interrogez le service web LPSNG pour l’état des tâches et poussez les échecs vers ce que vous utilisez déjà pour les alertes. Vous n’avez pas besoin d’une seconde pile de supervision.
• Gardez un repli manuel. Si une étiquette reste injoignable, reliez-la manuellement dans l’interface web LPSNG une fois qu’elle est de nouveau en ligne. La même plateforme gère le chemin automatisé et le chemin manuel, il n’y a donc pas de décalage entre les deux.

Une vérification d’état simple :

curl -s "$LPSNG_BASE/jobs/$JOB_ID" \
  -H "Authorization: Bearer $LPSNG_TOKEN" | jq '{status, failed: [.results[] | select(.status=="failed")]}'

Bonnes pratiques pour une automatisation ESL fiable

• Gardez des identifiants propres. Votre clé ERP et votre clé ESL doivent être la même chaîne, générée à un seul endroit. La plupart des tickets « la liaison a échoué » sont en réalité des tickets « le format du SKU a changé ».
• Restez sur l’interface JSON. Les charges utiles neutres vis-à-vis des fournisseurs font du changement de matériel une tâche de déploiement. Cela signifie aussi que la même structure de charge utile fonctionne d’un magasin à l’autre.
• Testez d’abord en préproduction. Une exécution de liaison sur un magasin de test détecte les erreurs de correspondance avant qu’elles n’atteignent 400 étiquettes dans un rayon en production.
• Faites tourner les identifiants. Stockez les identifiants OAuth2 et les jetons de rafraîchissement dans un gestionnaire de secrets, documentez qui en est responsable, et faites-les tourner selon un calendrier.
• Envisagez un déploiement en périphérie. Pour les magasins à connectivité instable, l’Embedded Edition exécute LPSNG complet sur un ordinateur monocarte tel qu’un Raspberry Pi, les tâches de liaison s’exécutent donc localement et se synchronisent lorsque la liaison est rétablie.
• Vérifiez les codes-barres avant de les pousser. Un EAN erroné sur un afficheur est pire qu’un prix obsolète — voir How to Verify Barcodes Before Printing Labels.

FAQ

Dois-je écrire du code pour connecter les étiquettes ESL aux articles ?

Pas nécessairement. LPSNG fournit une API de service web et un workflow managé qui peut être déclenché par de simples requêtes HTTP. Pour une automatisation complète, cependant, vous écrirez probablement des scripts qui appellent l’API ESL Binding. L’interface JSON neutre vis-à-vis des fournisseurs (ESLSEND) facilite l’intégration avec vos systèmes existants.

Puis-je utiliser l’API ESL Binding avec n’importe quel matériel ESL ?

L’API ESL Binding est conçue pour être neutre vis-à-vis des fournisseurs, en utilisant une interface de fichiers JSON (ESLSEND) pour mettre à jour les afficheurs ESL. Elle peut fonctionner avec divers matériels ESL tant qu’ils prennent en charge le format JSON. LPSNG fournit également des instructions d’installation spécifiques pour le matériel ESL CATIC.

Comment LPSNG gère-t-il l’authentification des systèmes externes ?

LPSNG utilise un protocole d’enregistrement OAuth2 simplifié. Vous connectez votre système externe (comme une unité MDE) avec une seule URL, et LPSNG gère l’échange de jetons. Cela évite d’implémenter OAuth2 de zéro dans chaque intégration.

Que se passe-t-il si une étiquette ESL passe hors ligne pendant une mise à jour ?

Si une étiquette est injoignable, l’API renvoie une erreur. La file de tâches de LPSNG journalise l’échec, et vous pouvez configurer une logique de nouvelle tentative ou recevoir des alertes. Pour les mises à jour critiques, vous pouvez relier manuellement l’étiquette via l’interface web LPSNG une fois qu’elle est de nouveau en ligne.

Conclusion : automatiser une fois, en bénéficier en continu

Connecter les étiquettes ESL aux articles via l’API supprime l’étape de parcours des rayons de votre processus. Vous soumettez une tâche de liaison, LPSNG fait correspondre vos identifiants d’articles aux identifiants d’étiquettes, et les afficheurs se mettent à jour via une interface JSON qui ne vous enferme pas chez un seul fournisseur de matériel. Les prix restent exacts entre les changements de planogramme au lieu de dériver jusqu’à ce que quelqu’un s’en aperçoive.

La voie pratique est celle du managé : enregistrez chaque magasin avec une seule URL, laissez le Next Generation Label Printing System gérer l’échange de jetons et le suivi des tâches, et cantonnez votre propre code à la partie qui vous appartient réellement — décider quels articles vont où.

Commencez par lire la documentation de l’interface ESL et la référence de l’API ESL Binding. Puis prototypage sur l’édition cloud, ou téléchargez l’Embedded Edition si vous voulez que la tâche de liaison tourne dans le magasin dès le premier jour.

Articles liés

• What a Vendor-Neutral ESL Interface Means for Developers
• Cloud Label Printing Software Pricing: What to Look For
• How to Verify Barcodes Before Printing Labels