Eine zeitgemäße Digital Signage API ermöglicht Fernsteuerungen, komfortablen Datenaustausch mit anderen Anwendungen und vieles mehr. Erfahren Sie in diesem Beitrag, was sich hinter kryptischen Begriffen wie API, SOAP und REST verbirgt, welche verschiedenen Techniken existieren und welche Vorteile die Bereitstellung und Nutzung bringt.
Was ist eine Digital Signage API?
API steht als Abkürzung für „Application Programming Interface“. Zu Deutsch: Programmierschnittstelle. Diese Schnittstelle verwendet also kein menschlicher Benutzer, sondern eine Software. Übertragen auf unsere Branche bedeutet es, dass Digital Signage Anwendungen wie Medienplayer und Content-Management Funktionalitäten so bereitstellen, dass Software von Drittherstellern diese nutzen kann.
Schnittstellen sind nichts Neues in der IT. Wenn Sie mit einer Software arbeiten, nutzen Sie deren Benutzerschnittstelle. Jeder Programmierer organisiert zwangsläufig die Funktionen seines Quelltextes in Klassenbibliotheken. Diese exportieren definierte Zugriffsfunktionen. Et voilà, wir sind schon bei der API. Nur dass es in unserem Fall in der Regel um netzwerkfähige sogenannte REST-Schnittstellen geht. Diese sorgen dafür, dass unsere Digital Signage Lösungen von ihrer Insel entkommen und an digitalisierten Arbeitsabläufe teilhaben. Aber eines nach dem anderen.
Die Digital Signage Antike
Digital Signage stellte lange Zeit das klassische Beispiel einer Insellösung dar. Abgeschottet nach außen und zu nichts kompatibel außer zu sich selbst. Ich war Ende der 90er zu Gast bei einer Präsentation eines Systems für Diskotheken. Der Kunde durfte nur vorgefertigte Musikvideos abspielen und erhielt anfangs nicht mal eine Templates-Engine für eigene Inhalte.
Zum Glück änderten sich diese Zeiten schnell. In den Anfängen des 21. Jahrhunderts war es selbstverständlich, eigene Medien zu nutzen und Inhalte mittels Templates zu generieren. Trotzdem blieben die Systeme selbst immer noch Insellösungen.
Datenaustauschformate
Die nächste Entwicklungsstufe, von der Insel weg, waren Datenaustauschformate. Wollte ein Unternehmen einen Kanal mit täglichen Wetterdaten anbieten, brauchte er nur einen Dienstleister zu buchen, der regelmäßig eine XML-Datei auf einem, kennwortgesicherten Server platzierte. Das CMS holte diese ab und baute daraus die notwendigen Bilder oder Videos.
Einen Schritt weiter gehen standardisierte Datenaustauschformate wie RSS, die häufig für Nachrichten genutzt werden. Diese Form des Datenaustausches sind gewissermaßen die ersten Kommunikationsversuche mit der Außenwelt.
Allerdings passiert das alles nicht in Echtzeit. Für Steuerungen taugen Austauschformate deshalb nicht.
Vorteile einer Player-API anhand eines konkreten Beispieles
Sie wollen mit einem Scanner einen EAN-Code erfassen. Daraufhin soll ein PoS-Bildschirm die aktuelle Werbeschleife unterbrechen und das Produkt, den aktuellen Preis sowie Zusatzinformationen anzeigen.
Die suboptimale Lösung
Erweitern der Software des Digital Signage Player um zusätzliche Funktionalitäten. Das wäre Zugriff auf den Scannertreiber, die EAN-Codes auswerten, unterbrechen der Playliste usw.
Ein paar Monate später kommen Kunden mit einem anderen Scanner oder möchten QR-Codes auslesen. Wir erweitern also wieder den Player mit den neu gewünschten Funktionalitäten. Die nächsten Anfrage wünscht auf Gestensteuerung zu reagieren oder beim Anheben eines bestimmtes Produkt etwa eine Uhr. Sensoren und Ideen gibt es viele. Bei jeder neuen Anforderung kommt also mehr Code in den Player.
Nachteile:
Monolithische Softwareentwicklung. Die Playersoftware müllt sich mit Spezialfunktionen für jeweils nur einen Anwendungszweck/Kunden voll. Je mehr Sondercode, umso mehr Komplexität und mehr Seiteneffekte: mehr Bugs, mehr Sicherheitsrisiken.
Neue Mitarbeiter und externe Dienstleister benötigen den kompletten Player-Quelltext und müssen sich in komplexe Strukturen einarbeiten. Das dauert länger und erhöht die Kosten.
Die Auswertung der Sensoren oder Scanner muss auf dem gleichen Gerät stattfinden.
Die moderne Lösung
Der Player bekommt einen Webserver integriert. Dieser bietet eine REST-Schnittstelle, mit einer Funktionalität namens Netzwerktrigger an. Trigger unterbrechen in unserem Fall die gerade laufende Playliste und starten eine zugeordnete Präsentation.
Die eigentliche Scannerfunktionalität beinhaltet eine kleine externe App. Sobald der Scanner den EAN-Strichcode ausgewertet hat, sendet die App den Code an die spezielle Webadresse des Players. Der erfüllt dann seine Aufgabe und unterbricht die Playliste.
Vorteile:
Die Trigger arbeiten generisch. Externe Dienstleister erweitern so Ihr Produkt, ohne Zugriff auf den Quelltext des Players. Das geht schneller und kostet weniger Geld, da wir lange Einarbeitungszeiten vermeiden.
Saubere Strukturierung da spezialfunktionalität ausgelagert wird. Wenn Kunden einen neuen Scanner oder Sensoren benötigen, entwickeln Sie einfach nur eine andere App. Der softwaretechnisch weitaus komplexere Player bleibt unangetastet. Keine Seiteneffekte und Probleme mit Spezialcode in der Playersoftware.
Die Sende-App und der Player können Sie jetzt sogar auf unterschiedlichen Geräten installieren. Eine Sende-App ist nun ferner in der Lage mehrere Player gleichzeitig ansteuern und synchroniseren.
Eine weitere Anwendungsmöglichkeit für diese Art Trigger sind übrigens Aufrufsysteme.
Anwendungsbeispiel CMS-API
Anforderung: Sie möchten wöchentlich Sonderangebote über Ihre Warenwirtschaft erstellen und automatisiert für verschiedene Standorte ins Digital Signage CMS platzieren.
Die suboptimale Lösung
Medien werden manuell erstellt und für jeden einzeln in die Playliste eingefügt. Das ist zeitaufwendig und fehlerträchtig.
Die moderne Lösung
Die Warenwirtschaft verbindet sich mit der API des CMS und stellt die Angebote automatisiert in die jeweiligen Playlisten.
Vorteil: ein komplett digitalisierter Arbeitsablauf.
Architekturen für Web-Apis
Die bekanntesten Architekturen sind SOAP und REST. Durchgesetzt hat sich die einfachere Variante REST. Hier ein kurzer Vergleich als technische Hintergrundwissen.
Hintergrund SOAP
SOAP startete als „Simple Object Access Protocol“ basierend auf XML standardisiert vom W3C als offizielles Protokoll. Leider war es so mächtig und flexibel, dass man sich entschloss es bei Version 1.2 nicht SOAP zu nennen, weil nichts mehr mit „Simple“ gemein hatte. Es wird noch von einige Altsystemen eingesetzt. Ich habe es in den vergangenen 20 Jahren genau einmal implementieren müssen. Die Mehrheit setzt auf REST.
Hintergrund REST
REST steht für „Representational State Transfer“ und fungiert im Gegensatz zu SOAP nicht als Protokoll. Es gibt auch keinen REST-Standard, denn es versteht sich eher als Richtlinie oder Empfehlung. Wie man REST implementiert, bleibt einem selbst überlassen. Dafür ist es schnell und schlank.
Werden Daten von einer REST-API angefordert wird, geschieht dies in der Regel über HTTP (Hypertext Transfer Protocol). Die Antwort kann in verschiedenen Formaten erfolgen, wie: HTML, XML, Plain Text oder JSON erfolgen, wobei die meisten JSON (JavaScript Object Notation) bevorzugten. Die meisten Programmiersprachen und auch Menschen können JSON trotz seiner Kompaktheit lesen.
Um dem Implementierungswildwuchs entgegenzutreten, wurde eine Reihe von Richtlinien eingeführt. Wenn diese erfüllt werden, kann sich die Anwendung als RESTful bezeichnen. Das wären:
Client-Server-Ressourcen Architektur
Zustandslose Kommunikation
Datencaching
Einheitliche Schnittstelle
Hierarchisches Mehrschichtsystem
Code-on-Demand
Welche Nachteile haben Digital Signage APIs?
Eine Digital Signage APIs stellt besonders bei im Internet zugänglichen Geräte- und Contentmanagementsystemen respektive SaaS-Lösungen ein potenzielles Sicherheitsrisiko dar. Eine API bedeutet, Funktionen maschinenlesbar zu exponieren. Ohne geeignete Sicherheitsmaßnahmen nutzen Hacker das schnell als Spielwiese.
Ein weiterer Nachteil ist, dass wenn es gelingt das CMS via API zu kompromittieren alle angeschlossenen Medienplayer Gefahr laufen manipulierte Inhalte zu erhalten. Es existieren etablierte Authentifikationsmechanismen wie SAML2 und OAuth2, aber die sind weder trivial zu implementieren noch komfortabel.
Daher haben wir uns bei SmilControl entschieden, nur eine Player-API zu entwickeln und beim CMS vorerst darauf zu verzichten. Stattdessen bieten wir zwei andere aus unserer Sicht einfachere und sicherere Möglichkeiten, um dynamische Digital Signage Inhalte zu präsentieren.
Externe Medien und Playlisten
Da unsere Software Playlisten mit der frei dokumentierten Multimediasprache SMIL beschreibt, benötigen wir keine API für das obige CMS-Beispiel. In diesem Fall würde einfach ein externes Bild oder Video in die Playliste integriert. Alternativ existiert es auch die Möglichkeit, externe Playlisten in unsere zu verschachtelt.
Die Warenwirtschaft braucht also nichts weiter zu tun, als ein Bild oder Video an den entsprechenden Speicherplatz zu kopieren. Für Playlisten mit mehreren Medien müsste ein kleiner SMIL-Exporter geschrieben werden. Was weniger aufwendig ist, als eine OAuth2-Authentifikation.
Vorteile
Keine zusätzlichen Programmierarbeiten, um eine Schnittstelle zu schreiben oder anzusteuern.
Die Inhalte können auch auf einem von außen (CMS) nicht erreichbaren Intranetspeicherplatz hinterlegt werden. Nur der interne Medienplayer darf darauf zugreifen.
Die Kontrolle liegt bei der externen Software/Warenwirtschaft. Durch SMIL sind Funktionen wie selbst bedingtes Abspielen für bestimmte Zeiträume und mehr möglich.
Die Zukunft mit Widgets
Als Digital Signage Widgets bezeichnen wir Webanwendungen, die lokal auf dem Player laufen. Das ermöglicht es Drittanbietern jedwede Web-API anzusteuern, ohne dass wir im CMS extra Funktionalitäten hinzufügen müssen. Egal, ob Twitter, YouTube oder gar Microsoft BI Dashboards.
Ich halte Digital Signage Widgets für die am meisten unterschätzte Technik im Digital Signage. Durch die Mächtigkeit von HTML, CSS und Javascript lassen sich die komplexesten Anwendungen und selbst 3D-Spiele direkt auf den Playern ausführen.
Wir versprechen uns einen erhöhten Sicherheitsgewinn im Digital Signage Netzwerk durch das Verlagern der API vom zentralen Server auf die Player-Clients. Sollte diese kompromittiert werden, betrifft das nur einen oder eine Gruppe und nicht alle Geräte.
Fazit
Eine Digital Signage API ist sinnvoll eingesetzt der weiterer Schritt in Richtung digitale Transformation. Arbeitsabläufe digital nachzubilden senkt Fehlerwahrscheinlichkeiten und spart Zeit. Insellösungen scheitern früher oder später. Nicht in jedem Fall muss es unbedingt eine API sein. Manchmal reichen offene Lösungen und freie Formate aus.
