Part 3 | The „API“, the unknown entity

In today’s business world, digital systems provide valuable services in almost all companies and it is hard to imagine life without them. These systems can be simple databases for managing the customer base, software for order processing, production data management tools or even a ticket system for customer support. It is not uncommon for the associated software to have been in use for several decades. It is even possible that underneath the surface ‘custom-made products’ by programmers who are no longer available or by former students are still doing a good job. In such cases, even small change requests can turn into a nightmare and result in disproportionately high investments, especially if several systems are interlinked and based on one another. Even if the source code is available, it is usually not practicable to have a programmer work on it after many years, because at the time of its creation, the intention was usually not to make the code as comprehensible as possible, nor are the programming techniques used at the time of its creation still up-to-date – not to mention the lack of comprehensive documentation. These days, it is considered good manners for a software application to include a documented programming interface (in short API, for Application Programming Interface). This interface allows other programs and programmers to access and use the software in a defined way, without having to deal with another programmer’s code first. This is particularly important, if not a prerequisite, for the interaction with other components in web applications. STW’s MACHINES.cloud is based on such a detailed documented API. Both the TCG telemetry modules in the field and the users‘ browser applications all access this one API, on which all functions are depicted.

What exactly are the advantages of an IoT platform with an API? First of all, application programmers can work with the programming language of their choice and are not restricted to the programming language of the platform software or a specific end device on which they wish to base their work. They can use the documented functions of the API and integrate them into their code in a programming language of their choice. The programmer’s software application accesses the API, the user accesses the IoT platform or cloud using the software application written by the programmer.

And how exactly does the MACHINES.cloud work? The MACHINES.cloud consists of a so-called backend and a user interface. The backend is the entirety of all services that a server makes available to the outside world. This server is accessed by the user via a URL (simply said an internet address). This address is used to establish an encrypted connection to the server’s API service. To make sure that not just anyone can send commands to the API via the Internet, authentication is required. So for each API request, a username and password is requested, otherwise it will not work. Currently there are about 120 commands and functions, which can be executed via the API. These are, for example, requests for measurement values, creating users or update requests for devices in the field. Since all functions, including the deletion of all data, are executed via the API, it makes sense to have an authorization management in place and, depending on the authorizations the requesting users have received from the platform administrator, they are allowed to execute more or less commands.

In contrast to programmers, users probably consider such an API less exciting. They may simply be interested in receiving the required information at the push of a button or in executing functions via their browser. To avoid having to deal with such abstract things as an API, the MACHINES.cloud offers several web applications for different user groups as a standard feature: The cockpit for users, the device management for fleet managers and an application for administrators. These standard applications can be configured and adapted at the push of a button via the browser. If, however, very specific functions or applications are required, a web programmer can create additional applications, which in turn send commands to the API. The finished App can then be seamlessly integrated into MACHINES.cloud. A style guide for programmers is available for the MACHINES.cloud, which shows exactly how the individual graphical elements are structured. This also allows the "look and feel" to be seamlessly integrated. The MACHINES.access application by STW, a VPN service with a simple configuration surface, is an example of such seamless integration.

But there is still one more very special user who has not been mentioned yet: The device user. After all, without the data from the TCG telemetry modules of the machines in the field, the whole beautiful cloud is useless. And – this will not come as a surprise – these data are also transmitted via the API. For this purpose, each individual machine in the field is given its own login data and only very limited authorization when logging in. For example, the devices are only allowed to send measurement data or to receive commands, but not to create additional users or change other important parameters of the cloud. This standardization also makes it possible that, in addition to the TCG hardware by STW, other devices can also be used in the field, as the registration process is also precisely defined and documented. A number of other hardware components are also available for connection to the MACHINES.cloud in addition to the TCG series of STW, but then usually with a correspondingly smaller range of functions, for example for pure tracker applications.

However, not only real people can use the API via a browser application or devices in the field, but also servers or services, provided they have the necessary permissions. And this is where it gets really exciting, as there are almost no limits to the possibilities. Just one example: An oil sensor on the motor of a machine in the field reports that the oil level is too low. There is a risk of the machine’s motor running dry. For some reason, the operator who has rented the machine does not notice that the oil needs to be refilled. However, the built-in TCG telemetry module registers the error and sends an alarm to MACHINES.cloud. A new case is then triggered via an API connection in the machine rental company’s ticket system. Automatically, the customer’s current data from the rental database (API) is emailed (API) together with a description of the problem with the highest priority to a service employee, who immediately takes care of the problem. This way, major motor damage can be prevented. This is just one example of how different systems can engage with each other usefully. If all of these systems have a documented API, and most current systems do, such functions can be implemented without the otherwise often enormous programming effort.

This is how the API technology, which is also available for MACHINES.cloud, can help implement new business ideas quickly and inexpensively.

Link: https://cumulocity.com/…