Für eine Applikation zur Verwaltung, Management und Accounting von Energiedaten werden neue Funktionen entwickelt. In dieser Anwendung werden diverse Energiedaten aufbereitet. Die Rohdaten werden von externen Systemen in unterschiedlichen Formaten bezogen und anschließend einheitlich sowie revisionssicher gespeichert. Im weiteren Verlauf werden die Daten für das Controlling aufbereitet, um eine effiziente Überprüfung und Fakturierung zu ermöglichen.

Das Mehrwert des Projekts besteht darin, den bisher teilautomatisierten Excel-Import von Daten aus externen Quellen vollständig zu automatisieren. Dies wird durch die nahtlose Integration der Daten über REST-Schnittstellen erreicht. Dies ermöglicht es den Benutzern, täglich aktualisierte und präzise aufbereitete Daten zu erhalten, die bisher aufgrund manueller Schritte nur monatlich verfügbar waren.

Projektbeschreibung:
Die Deutsche Telekom entwickelt derzeit eine webbasierte Anwendung namens "TSMS" (Trusted Service Management System). TSMS dient als Plattform für Smartphone-Hersteller und Mobilfunkdienstanbieter, um die Verwaltung von hardwarebasierten Sicherheitskomponenten, wie Secure Elements, auf Mobilgeräten plattformübergreifend zu ermöglichen. Dies soll letztlich die nahtlose Integration von Sicherheitsfunktionen wie dem digitalen Personalausweis in mobilen Endgeräten ermöglichen. Ziel des Projektes war es einen IAM Provider zu evaluieren, das Rollen und Rechte-System darauf abzubilden und im Frontend mit 2 Faktor Authentifizierung zu integrieren.

M.B. entwickelte die Spezifikation für die kundenspezifische REST-API für das  User & Access Management auf Basis der OpenAPI Spezifikation Version 3 (Swagger). Dies wurde regelmäßig mit dem Projet-Owner und dem Frontend-Entwicklern abgestimmt.

Der dadurch entstehende  REST-Service, sollte durch austauschbare (Adapter) für die Anbindung unterschiedlicher Identity & Access Management (IAM) Provider konzipiert werden. Konkret entwickelte M.B. dazu zwei IAM-Adapter: Für die Anbindung an Auth0 von Okta und ICU, eine Plattform der Deutschen Telekom zur Verwaltung von Benutzerkonten von Geschäftskunden (basierend auf Key-Cloak). Des weiteren implementierte er die REST-API und das Domain-Model mit internen Schnittstellen für die Berechtigung. Eine Herausforderung war es die unterschiedlichen Interpretationen der OAuth2 Authentifizierung hinsichtlich der IAM-Provider für TSMS umzusetzen. Die Applikation wurde nach den herangehensweisen des "Domain-Driven-Design" entwickelt.

Für den Test der gesamten TSMS Anwendung mit weiteren REST-APIs entwarf und implementierte er eine Java-basierte, generative REST-API-Testsuite, die auf OpenAPI Generator-Tools und RestAssured für die Validierung von Nachrichteninhalten basiert.

Das Projekt bot M.B. auch die Möglichkeit, seine bereits profunden Kenntnisse und Fähigkeiten in den folgenden Bereichen weiter auszubauen: Entwicklung von Microservices in Go & Java, Gitlab CI/CD, Docker, Domain Driven Design, Beherrschung von API-Spezifikationen mit OpenAPI V3, Scripting mit Postman, IAM-Konzepte & -Technologie einschließlich Auth0 von Okta, IETF System for Cross-domain Identity Management 2.0 (RFC-7643 & RFC-7644).

Der Kunde produziert Fahrzeuge in verschiedenen Modellreihen mit maßgeschneiderter Ausstattung. Unabhängig von der Fahrzeugart verfügen alle Fahrzeuge über eine eigene Schnittstelle für die Diagnose Daten Aufbereitung (DDA) im Backend. Die DDA empfängt verschiedene Rohdaten von den Fahrzeugen und bereitet sie in einem standardisierten Format, für andere Anwendungen auf. Aufgrund der Vielzahl unterschiedlicher Fahrzeugtypen wurden viele verschiedene Datenformate entwickelt, die täglich von den Fahrzeugen analysiert werden.

Eine der wichtigsten Aufgaben der DDA-Architektur ist die Erweiterungsmöglichkeit im Hinblick auf neue Fahrzeugtypen, die sich in der Entwicklung befinden. Der Kunde liefert deshalb in regelmäßigen Intervallen neue Daten über alle Fahrzeugtypen. Nur mithilfe dieser modellspezifischen Stammdaten ist es möglich, Rohdaten zu interpretieren und zu analysieren. Das Ziel des Projekts war es, die Komplexität und Abhängigkeiten innerhalb der gelieferten Stammdaten zu reduzieren und einen kürzeren "Release-Zyklus" mit Unterstützung durch CI/CD zu implementieren.

Als Architekt in dem Projekt spielte M.B. eine zentrale Rolle als Ansprechpartner für Code und Architektur. Er arbeitete an der Weiterentwicklung und Wartung des nahezu gesamten DDA-Systems. Eines von M.B.s Zielen war es, die vorhandenen Datenmodelle für Stammdaten und REST-API zu analysieren, um die Komplexität zu verringern. Dazu wurde die CICD-Pipeline erweitert, um eine vorgelagerte automatisierte Optimierung außerhalb der Applikation zu ermöglichen. Auch Anpassungen der Docker-Container wurden durchgeführt, um das angepasste Datenmodell in die Applikationen zu integrieren. Letztlich war der Kunde sehr zufrieden da die Perfomance erhöht und die Komplexität verringert wurde

Neben seiner Arbeit an der Architektur hat M.B. auch als Entwickler (Java und Go-lang) gearbeitet. Er hat hauptsächlich den zentralen Service auf Basis des MicroProfile-Stacks OpenLiberty entwickelt. Er passte das Modell auch für weitere Microservices an, die über gRPC kommunizieren. Er koordinierte den Übergang zum neuen Datenmodell für alle Microservices in DDA.

Die geänderten Datenmodelle für das REST-API wurden auch in Swagger/JSON verfasst. Die Objektmodelle für Go-lang und Java wurden basierend auf den Swagger-Modellen generiert. M.B. entwickelte eine neue CICD-Pipeline für die Datenmodule. Teile der Pipeline wurden sowohl in GitlabCI als auch in Apache Maven entwickelt.

Java EE, Apache Maven, Spring Boot, Golang, JSON, JSON Web Token (JWT), XML/XSLT, OpenAPI, Postman, REST API, RESTful Web Services, Linux, Java, DevOps, Kubernetes, Docker, AWS, G-Cloud, IBM-Cloud, GitLab CI/CD, IntelliJ IDEA, Serverless Architektur, JUnit, gRPC

Die Diagnose-Daten-Analyse (DDA) analysiert Daten vom Fahrzeug. Hierfür werden Daten vom Fahrzeug an die Backend-Systeme des Herstellers gesendet. Die Daten aller verschiedenen Fahrzeugtypen werden von diesem System in ein einheitliches Format transformiert. Die Service-Landschaft für die diagnostische Datenverarbeitung besteht mehreren verschiedenen Microservices. Die Services kommunizieren über REST-API und GRPC. Die CICD-Pipeline soll die Applikationen im Kubernetes Cluster zukünftig über den Kubernetes-Paketmanager ?helm? ausrollen. Dadurch kann man die Deployments im Kubernetes-Cluster einfacher verwalten und versionieren. Dadurch ist es möglich ein komplexes Deployment sehr einfach zurückzurollen. Im Laufe dieses Projekts sollen alle Microservices des DDA-Systems über in ?helm? integriert werden. Dadurch ist ein Wechsel des Kubernetes Cluster deutlich einfacher.

[Name auf Anfrage] arbeitete eng mit dem Ops-Team zusammen, um "Helm-Charts" zu entwickeln, die als Grundlage für alle Microservices erweiterbar sind. Eine Herausforderung bestand darin, die teilweise sehr großen Konfigurationsdaten in den Containern zu integrieren. Über Helm versioniert er auch die Konfiguration der Testdaten eines Deployments. Dies hat sich als sehr hilfreich für automatisierte Tests und bei der kontinuierlichen Integration erwiesen.

Die Integration der Konfigurationsdaten für "Helm" wurde von [Name auf Anfrage] in den Java-Anwendungen mithilfe des "Eclipse MicroProfile Config"-Frameworks entwickelt. Damit konnte der Java-Code effizient und einfach angepasst werden. Anpassungen im REST-API für Anwendungsmetriken waren ebenfalls Teil von [Name auf Anfrage]s Aufgaben. Dank der erfolgreichen Migration zu "Helm-Chart" kann die gesamte Versionshistorie im Kubernetes-Cluster direkt verfolgt werden. Dies ermöglicht beispielsweise das Rollback von komplexen Kubernetes-Anwendungen. Der Kunde schätzte die neuen Möglichkeiten für das kontinuierliche Deployments (CICD) wie das einfache Wechseln des Cloud Providers von beispielsweise IBM-Cloud zu AWS.

Java, IntelliJ IDEA, Kubernetes, Docker, XML/XSLT, XML Schema Definition (XSD), Golang, GitLab CI/CD, Git, Apache Maven, Postman, REST API, OpenAPI, Serverless arkitektur, JUnit, Atlassian Jira, Atlassian Confluence, Jenkins

Der Kunde wünscht sich ein neuen Microservice, um die Aufbereitung der Diagnosedaten eines Fahrzeuges zu verbessern. Deiser soll die VIN (Vehicle Identity Number) analysieren und dadurch modle spezifische Informationen bereitstellen. Der neue Microservice ergänzt die bereits bestehenden DDA-Services. Es soll dazu ein REST-API entstehen über welche die VIN spezifische Daten abgefragt werden können.

Matthias brachte nicht nur umfangreiche Java-Kenntnisse mit, sondern integrierte auch seine Fähigkeiten in Golang, um die Performance und Skalierbarkeit der Lösung zu verbessern. Seine Erfahrung mit Apache Tomcat als Servlet-Container trug dazu bei, die zuverlässige Ausführung von Java-Servlets sicherzustellen. Um die Anforderungen an die Datenverarbeitung zu erfüllen, nutzte Matthias seine Kenntnisse in XML/XSLT und JSON. Die effiziente Verarbeitung dieser Datenformate war entscheidend für den Erfolg des Projekts.

Die Diagnosedaten eines Fahrzeuges gelten teilweise als personenbezogenen Daten. Zum Schutz dieser Daten werden diese schon im Steuergerät verschlüsselt, bevor sie auf das CAN-BUS-System des Fahrzeugs gelangen.  Diese sollen erst im Backend des Herstellers wieder entschlüsselt werden. Dazu soll im Backend ein neuer Entschlüsselung Service (FES) entwickelt werden. Dieser besteht auch aus einer Angular Applikation für das Schlüsselmanagement. Das Schlüsselmanagement stellt dann die Keys für den FES (Entschlüsselungs-Service) bereit. Ziel war es die Gesamte FES-Applikation in die Diagnosedaten Aufbereitung zu integrieren.

Zusammen mit dem Projekt-Owner definierte M.B. präzise Anforderungen und entwarf daraufhin eine umfassende Architektur, die ein Angular-Frontend, einen Key-Storage (springboot) und einen Decryption-Service (go-lang) umfasste. Der Decryption-Service war ursprünglich in Java implementiert. Um die Leistung zu steigern, entwickelte M.B.ein Prototyp in go-lang, der die Anzahl der entschlüsselten Anfragen pro Minute verdoppelte. Das Projekt wurde erfolgreich umgesetzt und nahtlos in die Produktionsumgebung integriert.

Java, Golang, RSA, Cryptography, Spring Boot, XML/XSLT, GitLab, CI/CD pipelines, Jenkins, Apache Maven, Atlassian Jira, Atlassian Confluence, Kubernetes, Docker, REST API, Swagger, JSON, JSON Web Token (JWT)

Refactoring des Stammdaten Management   für die Diagnosedaten Aufbereitung; Data Management über ?readonly? Stammdaten im Kernel.

Wird ein Auto in eine Werkstatt zum Service gebracht, werden zunächst die Diagose-Daten ausgelesen. Diese Daten werden im Backend des Herstellers analysiert. Die Diagnose endet mit einem Diagnose-Report, welcher an die Werkstatt zurückgesendet wird. Die Aufbereitung dieser Analyse Daten wird vom Hersteller ?Vehicle Data Processing? kurz VDP genannt. Da ständig neue Fahrzeugmodelle hinzukommen, muss die ?Analyse Logik? ständig auf die neuesten Baureihen erweitert werden.

[Name auf Anfrage]s Tätigkeit konzentrierte sich auf die Konzeption und Implementierung leistungsfähiger Java EE-Anwendungen. Dabei spielte die Entwicklung dynamischer Webseiten mit Java Server Pages (JSP) eine zentrale Rolle, um eine effiziente Benutzeroberfläche zu gewährleisten. Erfolgreich integrierte er IBM MQ, um einen sicheren und zuverlässigen Nachrichtentransfer zwischen verschiedenen Anwendungskomponenten sicherzustellen.

Ein bedeutender Aspekt seiner Verantwortlichkeiten umfasste die Entwicklung von SOAP Web Services, um eine effiziente Kommunikation zwischen verteilten Systemen zu ermöglichen. Matthias setzte dabei XML Schema Definition (XSD) zur Strukturierung von Daten ein und nutzte XML/XSLT zur Transformation von XML-Dokumenten. Im Bereich Datenbankzugriff verwendete er sein Know-how in JDBC, um einen effizienten Zugriff zu gewährleisten, einschließlich der Optimierung von Abfragen und der Transaktionsverarbeitung. Zusätzlich implementierte er erfolgreich Enterprise JavaBeans (EJB), um wiederverwendbare Komponenten für die Geschäftslogik zu schaffen.

Java EE, Java, JSP, IBM MQ, SOAP, XML Schema Definition (XSD), XML/XSLT, JDBC, EJB (Enterprise JavaBeans), SoapUI

Diagnosedaten Aufbereitung: JEE Application Server mit XML-Transformation (XSLT), Aufbereitung von E/E Snapshots und Fahrzeug Roh-Daten.