Digital Signage API – Gateway to the world

The Ancient Days of Digital Signage

For a long time, digital signage represented the classic example of an isolated solution. Isolated from the outside world and not compatible with anything except itself. I was a guest at a presentation of a system for discotheques at the end of the 90s. The customer was only allowed to play prefabricated music videos and was not even offered a template engine for his own content at the beginning.

Fortunately, these times changed quickly. In the early days of the 21st century, it was natural to use your own media and generate content using templates. Nevertheless, the systems themselves still remained isolated solutions.

Data Exchange Formats

The next step in the evolution, away from the island, were data exchange formats. If a company wanted to offer a channel with daily weather data, all it had to do was book a service provider who regularly placed an XML file on a password-protected server. The CMS retrieved this and built the necessary images or videos from it.

Standardized data exchange formats such as RSS, which are frequently used for news, go one step further. This form of data exchange were, the first attempts at communication with the outside world.

However, none of this happens in real time. This is disadvantageous for controllers, as we will see below.

Advantages of a Player API based on a concrete example

Suppose you want to capture an EAN code with a scanner and then a PoS screen should interrupt the current advertising loop to display the product, the current price, and some more additional information.

The suboptimal solution

Extend the software of the Digital Signage Player with additional functionalities. That would include access to the scanner driver, evaluating EAN codes, interrupting the playlist, etc.

A few months later, another customer comes with a different scanner or wants to read QR codes. So we expand the player again with desired functionalities. The next request demands to react to gesture control or when a certain product is lifted, for example, a watch. Sensors and ideas are numerous. With each new request, more code is added to the player.

Drawbacks:

• Monolithic software development. The player software fills up with special functions for only one application/customer at a time. The more special code, the more complexity and more side effects: more bugs, more security risks.
• New staff and external service providers need the complete player source code and have to familiarize themselves with complex structures. This takes longer and increases costs.
• The analysis of the sensors or scanners must take place on the same device.

The modern solution

The player gets a web server integrated. That offers a REST interface, with a functionality called network trigger. In our case, this interrupts the currently running playlist and starts the presentation assigned to it.

The actual scanner functionality is provided by a small external app. Once the scanner has processed the code, the app sends the code to the special address of the player. That does its job and interrupts the playlist.

Advantages:

• Triggers are generic. External service providers extend software without access to the source code. This is faster and costs less money, as we avoid long familiarization periods.
• Spezialfunktionalität wird ausgelagert. Wenn ein neuer Scanner oder andere Sensor benötigt wird, tut es einfach nur eine andere App. Der softwaretechnisch weitaus komplexe Player bleibt unangetastet. Keine Seiteneffekte und Probleme mit Spezialcode in der Playersoftware.
• The sending app and the player can now even be installed on different devices. A broadcast app can also control and synchronize multiple players simultaneously.

By the way, another possible application for this type of trigger are Queue Calling Systems.

Application example for CMS-API

Requirement: You would like to create weekly special offers via your Enterprise Resource Planning and place them automatically for various locations in the Digital Signage CMS.

The suboptimal Solution

Media is created manually and added to the playlist for each one individually. This is time-consuming and error-prone.

The modern Solution

The ERP connects to the API of the CMS and automatically places the offers in the respective playlists.

The advantage: a completely digitized workflow.

Architectures for Web Apis

The best-known architectures are SOAP and REST. The simpler variant REST has gained more popularity. Here is a brief comparison for technical background knowledge.

Background SOAP

SOAP started as "Simple Object Access Protocol" based on XML standardized by the W3C as an official protocol. Unfortunately, it was so powerful and flexible that it was decided not to call it SOAP in version 1.2 because it had nothing in common with "Simple" anymore. It is still used by some legacy systems. I have had to implement it exactly once in the past 20 years. The majority uses REST.

Background REST

REST stands for "Representational State Transfer" and, unlike SOAP, does not act as a protocol. There is also no REST standard, as it is more of a guideline or recommendation. How you implement REST is up to you. In return, it is fast and lean.

When data is requested from a REST API, it is usually done via HTTP (Hypertext Transfer Protocol). The response can be in various formats such as: HTML, XML, Plain Text or JSON, with most preferring JSON (JavaScript Object Notation). Most programming languages and also humans can read JSON despite its compactness.

To address the uncontrolled proliferation of implementations, a set of guidelines has been introduced. If these are met, the application can call itself RESTful. These are::

• Client server resources architecture
• Stateless communication
• Data caching
• Unified interface
• Hierarchical multilayer system
• Code-on-Demand

External Media and Playlists

As our software specifies playlists using the freely documented multimedia language SMIL, we do not need an API for the CMS example above. In this case, an external image or video would simple add to the playlist. Alternatively, there is also the possibility to nest an external playlist into one of ours.

So the ERP doesn't need to do anything more than copy an image or video to the specific location. For playlists with multiple media, a small SMIL exporter would have to be written. Which is much less complex than an OAuth2 authentication.

Vorteile

• No additional programming work to create or control an interface.
• The content can also reside on an intranet storage location that is not accessible from the outside (CMS). Only the media player must reach this.
• The control lies with the external software/ERP management. Through SMIL, even conditional playback is possible for specific time periods.

The future with Widgets

Digital Signage Widgets are web applications that run locally on the player. This allows third parties to access any web API without us having to add extra functionality in the CMS. Whether it's Twitter, YouTube or even Microsoft BI dashboards.

I consider digital signage widgets to be the most underestimated technology in digital signage. Due to the power of HTML, CSS and Javascript, you can run the most complex applications and even 3D games directly on the players.

We expect an increased security gain in the digital signage network by moving the API from the central server to the player clients. If this gets compromised, it will only affect one or a group instead of all devices.