Low code platform passes the test

Eclipse OSBP passes newbie test

Holger Traupe
© Shutterstock / sugardragon

The no-code/low-code platform Eclipse OSBP facilitates application development. It makes life easier for experienced developers. But what about newbies? How much prior experience does it take to make use of the platform? Read about the test here.

Esther Euteneuer studies physics at Heidelberg University. “I want to do more than just grasp things, I want to put them into action”, she says. “You don’t get far in R&D without software. It’s better to be more than a mere user in the long run.” This is why she was looking around for vacancies in the local software industry.

As it turned out, Compex had just been waiting for a working student like her. “My initial role was to be the guinea pig. I was thrown in at the deep end. And the only help I got was a link to the platform’s online documentation, nothing else.” By now, things have changed. In fact, she has helped to give the enterprise a whole new impulse.

Compex has masterminded OSBP, a no-code/low-code platform provided by the Eclipse Foundation. The company uses it to speed up its own software engineering. Still, it is an open source software, meant to be available to any developer who takes an interest. When they announced the vacancy, Compex had decided to find out just how accessible the platform proved to be for outsiders – ideally, somebody at entry level.

IoT tool with OSBP

The challenge they put to Euteneuer was this: Build an inventory tool for the software vendor’s own devices (PCs, servers etc.). There was rudimentary legacy software that she was supposed to replace and expand. Her colleagues wanted a more comfortable tool that supported the historicization and evaluation of the collected data.

Most importantly, they wanted it to integrate truly all of the data, including sensor data from the server room. What they had in mind was a tool that would simplify the handling of their IT not just for the immediate future, but for the long term. In other words, it would make use of one of OSBP’s major strengths: that applications created with this platform can be changed and expanded at any time in their life cycle.

SEE ALSO: Failing successfully: Making mistakes takes practice

The mode of operation with OSBP is model-driven: developers do not write code, instead, they create model instances in domain-specific languages (DSL). From this, OSBP automatically generates the target objects, such as Java code, XML documents, and other artifacts that will implement the application in the target environment. OSBP persists the model instances, so designers and developers can make changes later on.

Templates as a starting point

In addition, OSBP provides templates as accelerators for ready-made applications – a good starting point to make achievements quickly. Template “AppUpIn5Minutes” drives the automation that is possible with OSBP the furthest. After a simple drag and drop, OSBP turns a CSV table into a fully functioning application, complete with an entity model, interfaces, and other elements such as authorization management.

“This template allows you to start up quickly and, after that, explore what you can do with OSBP. It’s absolutely worth investing these five minutes, even if you choose to proceed on a different path in the end”, says Euteneuer.

In the end, she did decide for another template, called “My1stApp”. This template guides the developer through component after component, allowing for pinpointed modifications in the modeling. “This one requires basic coding skills, but it isn’t hard to draw them from the examples provided”, says Euteneuer.

In the first step, she defined the entities, which have properties (variables) and can be linked by references. In the image, you can see that she defined the entity “devices” and referenced them with the entities “user”, “devicetype”, “supplier” and “manufacturer”.


Access to the organized data is managed either via data transfer objects (DTO) or, for analytical purposes, via data marts. Other components serve to design functionalities, perspectives, views, dialogues, charts and reports.

“First thing I did was to rebuild the legacy tool. This way I had an example to emulate and got a ready-to-use application at this early stage. Only after this first stage did I turn to the new requirements. It was a real help for me that I could work step-by-step with software that was actually running. I didn’t have to plan everything from beginning to end. I could try out, look at the practical results and think on from there.”

The expansion begins

At this point, the application was still unable to collect, historicize and display sensor data from the server rooms. In the two rooms, for example, the temperatures were recorded by one device each, to which two differently positioned sensors (named Kelvin1 and Kelvin2) reported their current measured values.

Euteneuer composed a short script that collected the device ID, sensor ID, time and temperature, and subsequently wrote it in two separate CSV files – one for the degrees, and one for the time. Using the Cron daemon (Linux) or Task Manager (Windows), this script would be called periodically to collect the data.

Back to the application: Here, she defined the entity “temperature” with the properties measured value, device and sensor, plus the entity “timeline” with the timestamps of the measurements. Afterward, she adapted the subsequent components, that is, data import, tables and dialogues.

For user comfort, the temperature development over time was supposed to be graphically processed by a chart. OSBP offers a number of chart types – bars, pies etc. In her case, a curve chart seemed to be the most sensible option. In OSBP, charts can be defined either directly via the entity or via a data cube. Euteneuer chose a cube because the different sensors constituted a third dimension (besides time and temperature). This classification allowed her to depict temperature profiles both for the individual devices and the individual sensors.


The last hurdle

Last but not least, she abstracted the application to make it suitable for measurements of all kinds. This meant changing the entities again. She created an additional entity named “measure”, which included type and unit of measurement, as well as device ID and sensor ID. The previous entity “temperature” was renamed as “measurement”. It still held the measured value, but references measure and timeline entities for all other properties. This arrangement made it possible to import different types of measurements into the same table and, at the same time, visualize them in separated charts.

SEE ALSO: New report shows that nearly three-quarters of ITSM professionals feel undervalued in 2019

As a result, the application could integrate all sensor data and support their evaluation. Mission accomplished.

Bottom line

“It is true that you can create an app within five minutes, provided that you have a data model to rely on. If you want to exploit the full range of OSBP’s functionality, though, it does require you to do a little learning. But it is really easy.”

The student is now going on to refine her application. Her current objective is to replace the external data collection scripts with a generalized process, using the no-code/low-code platform’s own functionalities. “It is a matter of principle. Whatever you can do with the platform should be done with the platform.”

To her employer, the experiment has resulted in an impetus to explore a new field. “We are investigating the use of OSBP in IoT environments, especially under the umbrella of the Eclipse Foundation. Our platform and some of the other developments there seem to complement each other very well”, says Christophe Loetz, Managing Director of Compex.


Holger Traupe

Holger Traupe works for Compex Systemhaus GmbH and likes to write about trends in IT and business.

Inline Feedbacks
View all comments