Je vous suggère fortement de reconsidérer la solution de la rotule Zebra à ce stade.
La meilleure solution pourrait toujours être la solution du mini serveur Web.
Mon expérience avec une solution websocket Zebra: Contexte:
J'ai d'abord essayé de créer une solution Node.js (j'avais lu à plusieurs endroits que tout serveur est faisable). Mais après quelques échecs de tentatives de connexion, même après avoir obtenu les certificats signés Zebra - et l'imprimante/serveur passant par un processus de prise de contact réussi - il échouait toujours avec une erreur cryptique, que lorsque l'on regarde est lié à l'imprimante essayant de vérifier Tomcat version/serveur est utilisé !!! ???
J'ai reçu une réponse d'un développeur Zebra qui est en train de développer une solution .Net mais qui ne parvient pas à la faire fonctionner et attend d'autres informations de la part des ingénieurs de Zebra avant de pouvoir compléter la solution. Ils ont dit qu'ils enverraient l'information quand ils l'avaient et espéraient l'obtenir dans une semaine (plus d'une semaine - pas de chance pour le moment). Donc, j'ai décidé de mettre en place un serveur Tomcat - le seul exemple de travail de Zebra ... J'ai exécuté l'exemple de servlet mais j'ai commencé à avoir de nouveaux problèmes de cert (comme j'avais changé de serveurs/domaines, etc.) Je pensais à tout le processus maladroit - et reconnaissait le briseur de 1 deal - le processus d'authentification et de signature SSL très restrictif est trop risqué.
E.g. Disons que vous avez plus de 100 clients qui comptent sur cette solution. Si vous avez JAMAIS des problèmes avec le cert (par exemple, changement de nom de domaine, changement de configuration du serveur ou invalidation/expiration de cert) - alors TOUS les 100+ clients n'ont pas leur imprimante. Mais vous ne pouvez pas le réparer vous-même - Pour réparer/générer un nouveau certificat, etc., le processus de re-signature est lent et dépend de ressources externes! (Ceci est un processus manuel Zebra btw - vous envoyez via un email et vous êtes ensuite laissé attendre un temps considérable avant qu'un employé de Zebra répond avec un cert signé). Cela signifie que les 100+ clients n'utilisent pas les services de l'imprimante depuis longtemps, mais que vous n'avez AUCUNE OPTION mais que votre certificat doit être signé par Zebra. Pour moi, il s'agit d'un risque inacceptable - (la solution websocket ne doit PAS être dépendante d'un certificat signé Zebra - une fois que vous installez VOTRE (ou vos clients) imprimante, configurez l'imprimante pour spécifier un nom de domaine/adresse EXACT pour qu'elle se connecter à). Avec votre solution de mini-serveur - si un client a un problème - cela n'affectera que ce seul client et vous ne comptez PAS sur une entreprise externe pour signer des certificats pour résoudre le problème.
Voici les problèmes identifiés et les risques associés.
PROBLÈME 1) Très mal implémenté - Je ne peux pas (et ils ne peuvent pas non plus) l'obtenir pour se connecter à un serveur standard autre qu'une configuration Tomcat très spécifique !!! NIVEAU DE RISQUE: FAIBLE - c'est-à-dire qu'il s'agit d'un coût et d'une charge de temps initiaux - mais une fois que vous travaillez, le risque continu de causer ce problème est minime. RISQUES: a) Restreint le développement à des serveurs et des technologies très spécifiques. b) Augmentation du temps et des coûts pour le développement/test initial.
PROBLÈME 2) Mal documenté - J'ai identifié (et Zebra a vérifié) plusieurs erreurs dans la documentation - la documentation est également dispersée avec des informations importantes jetées dans un fichier readme.txt difficile à trouver séparé du reste de la documentation. NIVEAU DE RISQUE: FAIBLE - c'est-à-dire qu'il s'agit d'un coût et d'une charge de temps initiaux - mais une fois que vous travaillez, le risque continu de causer ce problème est minime. RISQUES: a) Ralentit le développement initial. b) Augmentation du temps et des coûts pour la configuration/développement initial.PROBLÈME 3) La sécurité de l'imprimante/l'authentification SSL sont mal planifiées et mises en œuvre. Il implique plusieurs étapes - est extrêmement restrictif et implique un processus lent de signature zébrée qui crée un risque continu. NIVEAU DE RISQUE: ÉLEVÉ - c.-à-d. C'est la raison pour laquelle nous ne pouvons pas utiliser cette solution. RISQUES: a) Restreint le développement à des serveurs et des technologies très spécifiques. b) Ralentit le développement initial. c) Augmentation du temps et des coûts pour la configuration/développement initial. d) Crée un risque élevé de niveau élevé pour le projet comme suit: ---> L'idée est qu'une entreprise se fierait à cette solution de connexion d'imprimante - par conséquent, tout arrêt de travail potentiel causerait une DISRUPTION MAJEURE DE L'ENTREPRISE. ---> N'IMPORTE QUEL des scénarios suivants signifierait que TOUS les clients utilisant cette solution websocket seraient sans services d'imprimante pendant plusieurs jours alors que de nouveaux certificats signés Zebra sont organisés: ---> 1) Cert expire, 2) Cert est invalidé , 3) Le serveur est déplacé, 4) les détails du domaine changent, 5) La configuration du serveur Tomcat est modifiée (en raison de la façon dont l'imprimante vérifie certains paramètres Tomcat/serveur) ---> De plus, les 5 scénarios ci-dessus sont connus mes tests jusqu'ici - il pourrait y avoir d'autres restrictions possibles qui pourraient signifier des échecs de cert que je n'ai pas encore rencontrés.
Résumé: IMO Problème 3 pose un risque inacceptable et les 2 choses suivantes doivent se produire avant de reconsidérer les Webbockets Zebra. 1) Ils ont besoin d'une documentation appropriée sur la façon dont les Websockets se connectent à un serveur tel qu'il est caché et même les employés de Zebra sont actuellement dans le noir. 2) Ils ont besoin de supprimer certaines des restrictions d'authentification - de sorte que vous pouvez résoudre n'importe quel problème sans une interaction Zebra longue.
Jason !!! tu es l'homme! J'ai passé 2 heures au téléphone avec zèbre, ils n'avaient aucune idée de ce dont je parlais. Je n'ai aucun problème avec une solution qui me permet d'obtenir des informations du point A au point B sans PC. Je pense que je vais acheter un de ces ASAP. Connaissez-vous de la documentation sur les Websockets. de mes brèves recherches je vois qu'il n'a pas encore été normalisé. Je voudrais utiliser PHP sur mon serveur. Il semble que je programmerais l'application sur LinkOS pour communiquer avec mon serveur via la socket Web. Toute information supplémentaire que vous pourriez fournir est évidemment extrêmement précieuse. – Mark
Je crois que les websockets sont considérées comme incluses sous le parapluie HTML5. Avec les imprimantes Zebra, toutes les connexions websocket sont sécurisées via TLS, donc nous espérons que cela soulagera les problèmes de sécurité de votre côté. Les didacticiels Websocket ne sont pas vraiment nécessaires pour vous puisque le SDK Zebra résume toute l'installation Websocket loin de vous. Vous devez simplement configurer votre imprimante pour qu'elle pointe vers votre application Web (qui utilise le SDK Zebra). Le SDK est écrit en Java, et je ne saurais pas comment l'intégrer avec PHP. Je n'ai utilisé le SDK qu'avec Apache Tomcat et une application Web Java. –
Pour être clair - l'imprimante Zebra offre beaucoup de technologie, y compris la possibilité de programmer l'imprimante elle-même pour la communication sortante (demandez à votre revendeur à propos de ZBI). Je ne sais pas si ZBI peut communiquer sur des websockets. Dans le cas où ZBI ne supporte pas la communication websocket, votre imprimante sera effectivement une imprimante «esclave» qui ne fait que ce qui est dit. Il ne pourra pas demander au serveur quoi que ce soit; plutôt, le serveur devra forcer l'information vers le bas à l'imprimeur. Avec les websockets, c'est trivial. Mais, sans ZBI, l'imprimante ne peut pas être «programmée» pour demander des données. –