Il y a quelques temps, je me rappelle avoir lu l’article sur l’impression en tant que service (PAAS) de mon collègue Brent Black. À l’époque, je ne m’attendais pas à m’occuper d'un projet qui s’articule autour de la PAAS, mais récemment, le cas d’un client a tout changé. L’entreprise désirait pouvoir s’adapter à de nouvelles exigences et simplifier son infrastructure d’impression.
Cette entreprise nous a contacté car elle développait une nouvelle application Java qui créait des documents utilisant les bibliothèques Java classiques pour produire des documents tels que iText ou Crystal Reports. Ces bibliothèques produisent des documents au format PDF, qui n’est pas toujours le format le plus adapté à l’impression. Les documents pouvaient être des factures comme des tickets de caisse, et plusieurs formats papier étaient concernés (A4, A5, A6), ainsi que plusieurs polices et styles. Il faut pouvoir imprimer tous ces documents sur des milliers de périphériques d’impression différents provenant de fournisseurs multiples, et pouvoir supporter plusieurs langages d’impression utilisés par les imprimantes laser, thermiques, et plus encore.
Ce scénario complexe nécessiterait énormément d’efforts de développement. Outre la création d’une application Java qui gère les informations, l’application contrôlerait le choix du périphérique d’impression et déterminerait le bon format pour chaque type de périphérique. Il faut aussi sélectionner le bon langage d’impression ainsi que les commandes d’impression adéquates pour chaque modèle ou marque. Par exemple, la production de documents pour différents formats papier implique d’intégrer une série de commandes d’impression afin de sélectionner le bac de papier approprié. Cela risquerait d’accroître la complexité de l’application et la rendrait difficile à maintenir lorsque de nouveaux périphériques sont ajoutés ou que de nouveaux formats de documents sont créés.
Comme beaucoup d’autres entreprises de vente au détail, ce client utilisait l’impression pour améliorer l’expérience du client dans ses achats. Quand un ticket de caisse est généré, des bons de réduction et des promotions sont imprimés lors de la transaction. Ces tickets sont conçus pour être imprimés et découpés un par un sur les imprimantes thermiques au point de vente. Contrairement aux autres périphériques d’output, ces imprimantes n’utilisent pas des langages d’impression standards mais un langage de description de page spécial utilisé essentiellement pour l’étiquetage.
Plus complexe encore, cette entreprise a innové en prévoyant du personnel doté d’assistants personnels numériques (PDA) qui sont en contact avec le client. Cela permet à ces employés de se déplacer avec le client quand il cherche des produits et à les ajouter à la commande au fur et à mesure. Une fois que le client a fini ses courses, le vendeur présente le PDA à l'imprimante, là où sortent tous les tickets. Grâce à la technologie NFC, l’imprimante est identifiée et l’application Java envoie tous les tickets à l’imprimante sélectionnée.
Il est certain que toutes ces exigences rendent le développement de l’application plus difficile et plus coûteux à maintenir au fil du temps.
Et si nous confiions toutes ces fonctions à une couche d’infrastructure spéciale conçue pour décharger le système de ces tâches relatives à l’impression ? Nous avons entendu parler de beaucoup de services similaires ces dernières années (souvent distribués sur internet plutôt que localement ou sur place) dans lesquels le logiciel est fourni sur abonnement.
Appliquons ce concept à l’impression. Il est facile d’imaginer un service qui fonctionne comme un intergiciel qui communique avec plusieurs applications. Ces applications fonctionnent sous Windows, UNIX, Linux et d’autres plateformes, et transmettent n’importe quel type de document à tout un tas de périphériques d’impression. L’intergiciel doit convertir le format natif créé par l’application en un format prêt pour l’impression adapté au périphérique cible. Une telle solution simplifie considérablement les applications et les rend plus faciles à maintenir à long terme.
Revenons à l’exemple client... Grâce au logiciel de gestion d’output de LRS, les applications qui produisent des documents sous différents formats et langages de description de page sont débarrassées du fardeau que représente l’impression. Elles n’ont qu’à transmettre les données des documents et l’identifiant de l’imprimante de destination. Vous n’aurez plus besoin de vous soucier des langages pris en charge par l’imprimante, ni d’ajouter des commandes spéciales en fonction de l’appareil afin de spécifier quel bac d’entrée contient tel format papier, ni de vérifier si le document a été imprimé correctement. Toutes ces tâches peuvent être gérées par le logiciel de LRS à l’aide d’une des API fournie avec le service. Non seulement ces API peuvent servir à envoyer le document, mais elles peuvent également vérifier que l’output qu'il faut est livré à temps et convenablement afin de terminer le processus commercial. De plus, lorsque de nouveaux modèles d’imprimantes sont ajoutés au parc, il est possible de les utiliser dès qu’ils sont ajoutés au logiciel de LRS.
Quant aux tickets de caisse que les employés mobiles impriment à partir de leurs PDA, le logiciel de LRS convertit les informations en un langage de description de page que les imprimantes thermiques du point de vente peuvent traiter. Il rassemble aussi les tickets de caisse et les bons ou promotions qui vont avec en un seul document. Ainsi, l’application n’a pas besoin de garder une trace des tickets et de la transaction qui leur correspond. Envoyez chaque ticket à la solution LRS (avec l’identifiant de la transaction) et laissez le logiciel de LRS les regrouper tous ensemble une fois les dernières données reçues. Le logiciel de LRS peut également ajouter les commandes spéciales qui obligent l’imprimante à découper le papier après chaque ticket. Désormais, quand le vendeur se rend à l’imprimante avec son PDA, les tickets sont prêts à être transmis sur-le-champ à l’imprimante et regroupés en un seul paquet. Cette méthode garantit que chaque vendeur récupère seulement les tickets qu’il attend.
Cet exemple montre comment l’utilisation du logiciel de LRS comme service d’impression simplifie le développement de l’application en réduisant le nombre de tâches et en fournissant un meilleur contrôle du flux de documents. Les avantages s’étendent à d’autres systèmes, puisque toutes les imprimantes définies par LRS sont disponibles pour d’autres applications qui s’exécutent sur des plateformes différentes. La solution de LRS met en place un repository de pilote central et un mécanisme pour vérifier qui imprime quoi ainsi que les employés qui respectent les politiques d’impression visant à réduire la consommation de papier. En bref, cette approche de l’impression en tant que service établit une nouvelle façon d’imprimer qui offre un point de contrôle central pour tous les documents de l’entreprise.
Ce n’est pas tout. Nous connaissons tous des entreprises qui préfèrent envoyer des tickets et d’autres documents par email plutôt que de les imprimer : c’est moins cher pour le fournisseur, plus simple pour le client et c'est bon pour l’environnement. Passer des applications existantes à la transmission électronique de documents peut s’avérer compliqué si les fonctions d’impression sont programmées dans l’application. Mais si vous avez déjà adopté la méthode d’impression en tant que service, il suffit simplement d’effectuer quelques changements de configuration.
Imaginez les avantages pour votre entreprise si vous optez pour cette approche d’impression axée sur le service. Maintenant, cessez de l’imaginer, et agissez. Il est temps de changer, et LRS peut vous aider à accomplir cette mission.