Language Options

Zu Beginn des digitalen Zeitalters wurde von Computern erwartet, alles zu können. Allerdings waren die Verarbeitungsmöglichkeiten begrenzt, sowohl hinsichtlich der Computerleistung als auch in Bezug auf den Umfang der Probleme, die ihnen zugemutet wurden. 

Mit den Jahren wurden Computer größer und leistungsfähiger. Die Probleme, die sie lösen können sollen, leider auch.

Computer mussten einen Weg zur Arbeitsteilung finden und Rechenleistung und Speicher aufteilen, um die Bearbeitungszeit von Aufgaben so klein wie möglich zu halten. Aber Computer wurden nicht alle auf die gleiche Art und Weise gebaut. Hardware, Betriebssystem und mitunter sogar die Netzwerkinfrastruktur waren bei den meisten Rechnern verschieden. Aufgrund dieser Unterschiede benötigten Computer eine strukturierte Form einer Interprozesskommunikation (IPC). Kurz gesagt, ein Standard war nötig.

Ein solcher Standard ist beispielsweise eine API (Application Programmable Interface) – eine Anwendungsprogrammierschnittstelle. Wie bei den meisten Computerbegriffen ist allen API immer eine Standarddefinition für ihren Zweck beigefügt. „API“ kann dabei jedoch ein sehr weit gefasster Oberbegriff für verschiedene Technologien und Anwendungen sein. Alle verwenden API, aber auf ganz unterschiedliche Art und Weise.

Daraus ergibt sich als wichtigste Frage beim Gedanken an API (oder irgendeiner anderen IPC): wer definiert den Standard? Ist es die Anwendung selbst? Oder der Hardwarehersteller? Oder eine angesehene Gruppe internationaler Fachleute? In vielen Fällen lautet die Antwort „alle der Genannten“.

Doch dazu gleich mehr.

LRS baut als Softwareunternehmen ihre eigenen API. Mit diesen API werden Lösungen von Drittanbietern mit LRS-Software verbunden, was erweiterte Funktionen wie die Rückmeldung des Auftragsstatus, die Fernkonfiguration von Servern und Druckern, die detaillierte Überwachung und die Übermittlung von Druckaufträgen ermöglicht.

Die API von LRS sind also ein Standard für die Arbeit mit LRS-Software, doch entsprechen sie auch verschiedenen Software-Standards, die von anderen Organisationen stammen. Das bedeutet, dass mit ihnen ein unabhängiges Drucken über alle Druckermodelle oder Server-Infrastrukturen hinweg möglich ist. Beispielsweise liefern LRS-Druckserver (einschließlich API-Anfragen) Druckausgaben mit dem IPP-Standard.

Das Internet Printing Protocol (IPP) ist ein Kommunikationsstandard, der in den späten 1990er Jahren entwickelt wurde, weil bei vielen Unternehmen der Wunsch bestand, einen internationalen Druckerstandard zu haben. Heute wird der IPP-Standard weithin eingesetzt und ist mit 98 % aller derzeitigen Druckermodelle kompatibel. Dank des IPP-Standards muss sich LRS nicht den Kopf bezüglich der Anpassung ihrer Software an die Funktionen der jeweiligen Druckhardware zerbrechen. Stattdessen können wir den IPP-Standard nutzen, sodass er mit allen Druckern unter einem einzigen vereinfachten Protokoll funktioniert.

Aber das ist nur der Teil, der die Drucker betrifft.

Es gibt viele verschiedene Druckserverfunktionen von LRS, die alle ihre eigenen Integrationsstrategien und Rollen haben.

Denken wir also größer und beziehen die gesamte Kommunikation zwischen einem Drucker und einem Server ein. LRS hat diesbezüglich Java Print Submission und Control API  zur Unterstützung der Kommunikationsstandards mit Geräten auf Java-Basis entwickelt. Diese API unterstützt mehrere Funktionen wie Status-/Ressourcenaktualisierung, Fernkonfiguration und Fernübermittlung von Aufträgen.

Durch das Design dieser API können wir leichter eine Integration mit Geräten herstellen, die auf Java-basierten SDKs aufbauen. Allerdings erstellt LRS auch API für andere Unternehmen, damit sie den LRS-Standards entsprechen, wie beispielsweise die Nutzung von IPP bei der Druckübermittlung innerhalb der LRS Java-API.

Ein weiteres Beispiel einer API-Integration ist die zertifizierte Schnittstelle von LRS mit der SAP-Anwendungsumgebung. Die Lösungsdesigner von LRS schlossen sich kurz mit SAP-Vertretern in Deutschland, um eine Lösung zu entwickeln, die den SAP-Softwarestandards am besten gerecht wird, gleichzeitig aber auch die von LRS und anderen Unternehmen der Druckwelt etablierten Best Practices erfüllt. Unsere VPSX/OutputManager Cloud-Lösung nutzt also sowohl die IPP-Auftragsübermittlung als auch den Kommunikationsstandard RESTful.

Die VPSX/OutputManager Cloud ist also ein Beispiel der RESTful-Schnittstelle und auch die LRS Gateway-Komponente ist RESTful bei der Verwaltung von Authentifizierungs- und Authorisierungstokens.

RESTful-API wurden zur Standardisierung der Kommunikation über das Internet entwickelt. Das Protokoll unterstützt natürlich Konformität, wird aber auch weithin aufgrund seiner Schlichtheit, Skalierbarkeit und Flexibilität eingesetzt. Entsprechend schufen die LRS-Entwickler Lösungen, die mit RESTful laufen, was auch in unserer eigenen Software Schlichtheit, Skalierbarkeit und Flexibilität gewährleistet. Unsere Kunden profitieren davon und gleichzeitig ist ein sicheres Drucken über WAN und andere Netzwerke garantiert.

Ich hoffe, Sie haben durch diesen Beitrag etwas tiefer in die Welt der API und IPC vordringen können. Wenn Sie allgemeine Fragen zu API oder zu bestimmten Schnittstellen haben, nehmen Sie gern mit uns Kontakt auf.

Nachfolgend finden Sie auch noch eine Übersicht über die API von LRS und über unsere zertifizierten Integrationen für unsere offenen Systeme. Darüber hinaus stehen zahlreiche Integrationen für unser IBM Z (Mainframe)-Angebot zur Verfügung, welche im Verlauf von mehr als vierzig Jahren Branchenerfahrung entwickelt wurden.

API

Zertifizierte Integrationen

Java Print Submission und Control API

Epic

IPP-Support

Cerner

Java Print Submission und Control API

MicroFocus

LRS Python API

SAP S/4HANA & BTP

PPM Client API (Personal Print Manager)

IBM-Systeme

VPSX COM API

Dell Processing Environment

VPSCMD

ANUBEX

Printer Discovery Tool

Soarian

VPSCFG

RESTful-Solutions

LRS SOAP API

Unix/Windows/Linux

LRSQueue

 

Back to Posts