Les API et l’impression multiplateforme : Gestion à l’échelle de l’entreprise

Au début de l'ère digitale, les ordinateurs étaient censés tout faire. Cependant, leur capacité de traitement était limitée… tant en termes de puissance de calcul que d’étendue des problèmes qu'ils étaient censés résoudre.

Toutefois, au fil des années, les ordinateurs sont devenus plus grands et plus puissants. Malheureusement, il en était de même pour les problèmes qu'ils étaient censés résoudre.

Il fallait donc trouver le moyen de répartir la charge, de partager la puissance de traitement et la mémoire, afin de réduire le temps nécessaire à l'accomplissement d'une tâche. Mais tous les ordinateurs n’étaient pas conçus de la même manière. Ils se distinguaient les uns des autres par leur matériel, leur système d'exploitation et parfois même par l'infrastructure de réseau qu'ils utilisaient. Compte tenu de ces différences, les ordinateurs nécessitaient une forme structurée de communication interprocessus (IPC). Bref, il fallait établir un standard.

Une forme de cette norme est l’API (Application Programmable Interface). Comme pour la plupart des termes informatiques, les API sont toujours définies par l’objectif qui leur est réservé. Cependant, le terme « API » couvre une large gamme de technologies et applications diverses. Et toutes les API sont généralement utilisées différemment et sous une forme différente.

L'une des principales questions que l’on se pose sur ces API (ou toutes autres IPC) est la suivante : qui définit la norme?  Est-ce l’application ? Ou le fabricant de matériel ? Ou un groupe de confiance composé de pairs internationaux ? Dans de nombreux cas, la réponse est « tout ce qui précède ».

Nous y reviendrons plus tard.

Chez LRS, nous sommes un éditeur de logiciels et nous créons donc nos propres API. Ces API permettent à des solutions tierces de s’interfacer avec le logiciel LRS et d'offrir des fonctionnalités avancées telles que le retour d’information sur l’état des travaux, la configuration à distance du serveur et de l’imprimante, le suivi détaillé et la soumission des travaux d’impression.

Si les API LRS offrent un moyen standardisé de travailler avec le logiciel LRS, elles sont également conformes à plusieurs normes logicielles définies par d’autres organisations, ce qui permet d’obtenir l’impression adaptée à tous les modèles d’imprimantes ou aux infrastructures de serveur. Par exemple, les serveurs d’impression LRS (y compris les requêtes API) délivrent des impressions à l’aide de la norme IPP.

Le protocole d’impression Internet (IPP) est une norme de communication créée à la fin des années 1990 pour répondre au souhait de plusieurs entreprises d’établir une norme internationale pour l’impression. Aujourd’hui, la norme d’impression IPP est largement adoptée et compatible avec 98 % des modèles d’imprimantes actuels. Grâce à la norme IPP, LRS n’a pas à se préoccuper de l’adaptation de son logiciel aux caractéristiques d’un périphérique d’impression spécifique. Au lieu de cela, nous pouvons exploiter la norme IPP afin de travailler avec toutes les imprimantes sous un protocole simplifié.

Mais il ne s'agit là que de l'impression.

Il existe de nombreuses fonctions différentes du serveur d’impression LRS, chacune possédant leurs propres stratégies et considérations en matière d’intégration.

Élargissons notre champ d’application à toutes les communications entre une imprimante et un serveur. LRS a également développé l'API Java Print Submission and Control pour prendre en charge les normes de communication avec les périphériques basés sur Java. Cette API prend en charge plusieurs fonctions telles que la mise à jour du statut/des ressources, la configuration à distance et la soumission de travaux             à distance.

La conception de cette API nous permet de nous intégrer plus facilement aux équipements qui s'appuient sur des kits SDK basés sur Java. Cependant, LRS conçoit également ses API pour aider d'autres organisations à se conformer aux normes LRS, comme l'utilisation d'IPP via la soumission d'impression au sein de l'API Java de LRS.

Autre exemple d’intégration API : l’interface LRS certifiée avec l’environnement d’application SAP. Les architectes de solutions LRS ont travaillé en étroite collaboration avec les représentants SAP en Allemagne pour développer une solution qui s’adapterait au mieux aux normes logicielles SAP, tout en appliquant les meilleures pratiques définies par LRS et d’autres acteurs de la communauté de l’impression. Notre solution VPSX/OutputManager Cloud utilise la soumission de tâches IPP, tout en utilisant la norme de communication RESTful.

Non seulement VPSX/OutputManager Cloud est un exemple d’interface RESTful, mais le composant LRS/Gateway est également RESTful, car il gère les jetons d’authentification et d’autorisation.

Les API RESTful sont apparues comme un moyen de standardiser la communication sur Internet. Le protocole garantit évidemment la conformité, mais il est aussi largement utilisé pour sa simplicité, son évolutivité et sa flexibilité. Les développeurs LRS ont donc créé des solutions qui fonctionnent en mode RESTful pour offrir la même simplicité, la même flexibilité et la même évolutivité à nos propres logiciels. Cela présente des avantages à nos clients et permet une impression sécurisée sur les réseaux WAN et autres.

J'espère que cet article vous a permis de mieux comprendre le monde des API et des IPC. Pour toute question générale sur les API ou des interfaces spécifiques, n'hésitez pas à nous contacter.

A titre de référence, voici une liste des API et des certifications d'intégration LRS pour nos offres de systèmes ouverts. Celles-ci s'ajoutent aux nombreuses intégrations disponibles pour nos prestations IBM Z (mainframe), développées au cours de plus de quatre décennies d'expérience dans le secteur.