Die bestehende In-/Exkasso Projektlösung PayTraS mit Anbindung an bisher wenige Umsysteme soll zum Produkt weiterentwickelt werden. Dazu müssen die Schnittstellen für weitere Umsysteme erweitert, die einfachere Anpassbarkeit an verschiedene Kunden ermöglicht sowie immer neu benötigte Funktionen zur Verfügung gestellt werden.
Meine Aufgabe ist hierbei die Unterstützung des kompletten Entwicklungsweges angefangen vom EMF-Modelling (Persistence-Services und DB-Struktur) über die Domänen-Entitäten, Services und Prozessen bis hin zum Frontend.
Daneben bin ich zeitweise für das Deployment und das Updaten der Docker-Container zuständig. Eine weitere Hauptbeschäftigung sind auch Datenbank-SQL-Abfragen zum Herausfinden von Datenfehlern oder Optimierungsmöglichkeiten.
Zeitweise bin ich auch beim Kunden auf Kubernetes in der AWS unterwegs.

Eine Teilaufgabe war, bestehende Applikationen und Microservices durch Fehlerbeseitigung und Codeoptimierungen zu stabilisieren sowie neue Features zu implementieren.
Die Entwicklung wurde hier in Scrum-Teams mit ca. 5 bis 10 Personen geleistet, insgesamt gab es ca. 15 verschiedene Teams an verschiedenen Standorten. Jedes Team hatte seine eigenen Kompetenzen für eine Anzahl von Modulen. Stories/Tickets wurden dabei vom gesamten Team ins Jira eingestellt und fertig ausformuliert. Bei allen Arbeiten wurde zunächst ein neuer Feature-/Bugfix-Branch in Git erstellt, erst nach einem erfolgten PR und Review durfte der geänderte Code in den Master-Branch gemergt werden. Es wurde immer besonderer Wert auf vollständige Unit- und Integrationstests sowie Dokumentation gelegt.
Nachdem der neue Code im Master-Branch verfügbar war, musste ein Deployment-Ticket gestellt werden, damit die neue Version auch auf die Test-Stages gelangten. Erst nachdem die neuen Versionen erfolg-reich auf Test-, Integration- Approval und PreLife-Stages getestet wurden, erfolgte schliesslich das Deployen auf die Live-Umgebung. Automatische Unit-, Acceptance-, Regression- und Smoke-Tests (auch in Form von Gauge-Tests) prüften hierbei die korrekte Funktionsweise ab.
Es gab allerdings noch zwei grundsätzlich verschiedene ‚Welten‘: Zum einen die OnPrem-Umgebung mit eigenen Stages und Oracle-Datenbanken, auf der anderen Seite die Cloud-Umgebung mit Postgres-Datenbanken. Liquibase-Skripte erledigten die Datenbank-Befüllung.
Desweiteren war man gerade auch dabei, die bestehenden OnPrem-Systeme in die Cloud zu migrieren (zumindest für einen Teil der neueren Daten). Dafür musste der Code an neue Schnittstellen, neue Komponenten sowie für das geänderte Deployment angepasst werden. Die Cloud-Migration erfolgte dabei in mehreren Schritten: Als Zwischenschritt wurde zunächst die AWS gewählt, für neueste Entwicklungen dann aber die Azure-Cloud.

Projektaufgabe: Die monolithische OnPremise-Umgebung sollte in Microservices zerlegt und in Azure gehostet werden.

Die On-Premise-Umgebung war über viele Jahre gewachsen und ist um einen zentralen ZOS-Host aufgebaut. Zusätzlich zu den DB2-Datenbanken auf dem Host wurden auch einige Oracle-Datenbanken beigestellt. Viele verschiedene Applikationen nutzen die Daten für interne sowie externe Mitarbeiter und Kunden.

Das Projekt beinhaltete dazu alle Schritte von der Analyse des Ist-Zustandes bis hin zum produktiven System in der Azure-Cloud. Die Aufgaben wurden auf 4 Scrum-Teams verteilt, ich war ein Entwickler in einem Team. Die Sprints hatten eine Länge von 2 Wochen.

Aufgabe unseres Team war die Implementation eines Microservices, der die Daten der sogenannten Vermögensberater über eine REST-Schnittstelle abrufbar sowie änderbar machen sollte. Gearbeitet wurde mit IntelliJ, der Microservice wurde in Kotlin mit Spring-Boot implementiert. Für lokale Testzwecke wurde eine MS-SQL-Datenbank in einem Docker-Container genutzt, für manche Tests auch eine H2-Datenbank. Aufgebaut wurde die Datenbank über Flyway-Skripte, der produktive Microservice selbst nutzte dann eine Azure-Datenbank. Angesprochen haben wir die Datenbank über JPA-Repositories, der Microservice war in drei Schichten für API/Controller, Service sowie DB/Repositories aufgebaut. Ein Jenkins-Server deployte die aktuellen Änderungen auf einen Kubernetes in Azure, die Qualität wurde durch automatisch angestoßene Modul-, Integrations- sowie API-Tests und zusätzlich einem Sonar zur Kontrolle der Testabdeckung gewährleistet. Da der vorhandene Host für eine längere Übergangszeit auf jeden Fall noch erhalten bleiben sollte und damit auch weiterhin für die meisten Daten die Datenhoheit hatte, mussten die Bestandsdaten regelmäßig von der DB2-Datenbank in die Azure-Datenbank übertragen werden. Exportiert wurden die Daten auf dem Host mit entsprechenden Skripten und vom Host-Team in einen Data-Lake in Azure übertragen. Von dort aus realisierten wir den Import in die Azure-DB mittels Pipelines und Data-Flows der Azure-Data-Factory. Für den Reibungslosen Ablauf von Entwicklung, Integration, Abnahme und Produktion sorgten vier getrennte Umgebungen in Azure und Kubernetes.

Meine vorherigen Arbeiten in der Abteilung 'After-Sales' waren nun abgeschlossen, der Weiterbetrieb des Intranets soll von internen Mitarbeitern geleistet werden. Die dafür vorgesehenen Mitarbeiter sollen auf einen Wissensstand gebracht werden, damit der Betrieb gewährleistet ist. Hierfür wurde sämtliche Dokumentation überarbeitet und in einem WiKi bereitgestellt. Zusätzlich fanden wöchentliche Schulungen statt, in den wir (ein weiterer freiberuflicher Kollege und ich) systematisch unterteilt die Mitarbeiter in kleinen Gruppen geschult haben. Ergänzt wurden die Schulungsmaßnahmen durch Einzelschulungen zu bestimmten aktuellen Themen. Parallel habe ich in einzelnen Applikation kleine Verbesserungen und Fehlerkorrekturen durchgeführt.

Planung und Realisierung einer Internetseite, auf der sich Gruppen und Bewegungen vernetzen und austauschen können. Wordpress wurde dabei nur als grober Rahmen und für die Benutzerverwaltung genutzt, alle anderen Module sind PHP Eigenentwicklung

Basis für dieses Teilprojekt bilden die vielen in den vorhergenenden Prokten bereitgestellten Daten. Aufgrund der Datenfülle sind alle diese gesammelten Daten nicht nur in einem Datenbank-Schema gespeichert, sondern in einzelnen, separierten Bereichen verteilt. Damit sind die Daten jeweils in sich abgeschlossen, besser wartbar und können einfacher gesichert und im Notfall auch besser restauriert werden.
Diese Applikation 'Easy Objects' ermöglicht auf grafische Weise datenbank-übergreifend die einfache Verknüpfung aller Daten und stellt eine einfache Möglichkeit bereit, diese Daten auch grafisch als z.B. Pie- oder Bar-Chart einem anderen Nutzer im Browser zur Verfügung zu stellen.
Für diese Applikation war HTML5 notwendig, da hier mittels des Canvas-Objektes wesentlich umfangreichere grafische Möglichkeiten existieren.

Da bei General Motors Fahrzeuge in aller Welt gebaut und unterstützt werden, fallen auch ebenso vielfältige Daten in den unterschiedlichsten Formaten an. Das können Daten sein, die entweder per Fileshare, per FTP, Datenbank-Direktzugriff, per eMail oder sonst wie angeliefert werden. Die Formate sind dabei ebenso vielfältig, z.B. als Plain Text, XML, proprietäre Binärformate und andere. Dazu kommt, dass bestimmte Daten nur innerhalb eines bestimmten Zeitfensters verfügbar sind.
Da die Sammlung und Verarbeitung dieser Daten zuvor weitesgehend händisch erfolgte, musste nun zuerst der aktuelle Zustand analysiert und verschiedene Arbeitsgruppen in ihrer Arbeitsweise befragt werden. Nachdem ein grober Rahmen bekannt war, welche Daten in welcher Menge zu erwarten waren sowie Prozesse herausgearbeitet wurden, in welcher Form die Daten zu verarbeiten, bereitzustellen bzw. zu präsentieren waren, wurden eizelne Applikationen definiert. Im Laufe des Projekts wurde das Entwicklerteam bis auf 5 Mitarbeiter aufgestockt. Da ich die vorhandenen Systeme von Beginn an geplant und mit aufgebaut hatte, habe ich hier neben meiner Entwicklertätigkeit auch die Einarbeitung der neuen Projektmitarbeiter übernommen sowie in enger Abstimmung mit dem Projektleiter auf Kundenseite versucht, die anstehenden Arbeiten sinnvoll zu verteilen.

Hier soll nur kurz auf die verschiedenen Applikationen im Einzelnen eingegangen werden:

Design und Implementierung einer Web-Applikation zum Sammeln von Fahrzeug-Daten
Die Applikation 'Collet Data' sollte daher in der Lage sein, automatisiert Daten einzusammeln und in die Datenbank - entweder im Rohformat oder schon (vor-)verarbeitet – abzulegen. Dazu wurde ein System geschaffen, in dem der Nutzer 'Jobs' anlegen kann, in denen er jeweils ein Skript in einer
proprietären frei erweiterbaren Skriptsprache mit Anweisungen verfassen kann, die das Einsammeln und Verarbeiten der Daten bewerkstelligen. Diese Jobs können zum einmaligem Start oder auch für feste Wiederholungen konfiguriert werden. Die Erfolgsüberwachung der Jobs wird grafisch aufbereitet angezeigt.

Design und Implementierung einer Web-Applikation zum schnellen Bereitstellen spezieller Softwarepakete für Kunden
Es gibt Situationen, in denen der Softwarestand auf den General Motors Applikationsservern, von denen sich KFZ-Werkstätten mit Fahrzeugdaten versorgen, nicht aktuell genug ist oder auch eine Softwarevariante für ein spezielles Fahrzeug so nicht verfügbar ist. In diesen Fällen werden von der Fachabteilung für dieses Fahrzeug dedizierte Softwarepakete vorbereitet.
Diese Pakete sollen von dieser Applikation 'Special-VCI' auf den GM-Applikationsservern für die sofortige Verwendung bereitgestellt werden. Außerdem ermöglicht diese Applikation einen Überblick über alle bisher bereitgestellten Pakete inklusive aller notwendigen Funktionen wie Freigabe/Sperrung von Paketen, setzen spezieller Flags oder auch das Löschen eines nicht mehr benötigten Paketes.

Design und Implementierung einer Web-Applikation zur Modul-Pflege
Angefangen mit nur einem Motor-Steuergerät haben Fahrzeuge zunehmend immer mehr Steuergeräte. Das sind Steuergeräte für z.B. das Getriebe, Multimedia oder Servolenkung etc.. Jedes dieser Steuergeräte wird mit einer Software programmiert, die wieder aus mehreren Modulen aufgebaut ist. Diese Module werden von Zeit zu Zeit aktualisiert, entweder wegen neuen Funktionen und Vorgaben oder auch zur Fehlerbereinigung. Deshalb kommen regelmäßig Lieferungen mit neuen Modulen incl. Zuordnungen, für welche Fahrzeuge und Steuergeräte diese Module gültig sind.
Die Applikation 'PDS' verwaltet hier alle diese Module mit den Versionsständen sowie den Zuordnungen zu Fahrzeugen und Steuergeräten.

Design und Implementierung einer Web-Applikation zur Fahrzeugdaten-Pflege
Die Fülle von Herstellen, Plattformen und Fahrzeugtypen im GM-Konzern ist reichhaltig und unübersichtlich. Damit die verschiedenen Applikation wissen, welchem Fahrzeug sie verarbeitete Daten zuweisen sollen, bietet diese Applikation 'Vehicle Info' gesammelte Fahrzeugdaten für die weitere Nutzung an. Hier ist z.b. hinterlegt, dass der Opel Corsa-D von 2007 bis 2012 in Eisenach und Zaragoza gebaut wurde.

Design und Implementierung einer Web-Applikation zur Fahrzeug-Konfigurations-Pflege
Zusätzlich zu den eigentlichen Fahrzeugdaten fallen auch viele Konfigurations-Daten für ein Fahrzeug an. Hier ist z.B. hinterlegt, ob das Fahrzeug mit einer Anhängerkupplung gebaut oder auch ob diese später nachgerüstet wurde. Abhängig davon ist der aktuelle Softwarestand.
Diese Applikation 'VDMS' sammelt und verarbeitet daher alle Fahrzeugdaten, wie sie ab Werk angefallen sind - d.h. der Zustand wie gebaut - sowie alle Änderungen, die ein Fahrzeug während seiner Lebenszeit erfahren hat.

Vorgefundener Zustand in der Abteilung war, dass die Arbeitsplätze der verschiedenen Mitarbeiter (Autoren, Tester, Daten-Analysten) relativ losgelöst und alleinstehend installiert und gepflegt wurden. Als gemeinsame Datenbasis sowie Austauschmedium existierten Fileserver sowie Lotus-Notes-Datenbanken.
Eine entscheidende Anforderung für das gewünschte neue System war, dass möglichst nichts auf den Client-Systemen installiert werden sollte, die Lösung sollte im Frontend 'so schlank wie möglich' sein. Deshalb entschieden wir uns für ein Internet-Browser gestütztes Design in dem möglichst alle späteren Applikation als Web-Applikationen ausgeführt und über das Intranet verteilt werden sollten.
Das Projekt wurde komplett mit der Eclipse IDE entwickelt und mit GIT versioniert. Schwerpunkt war hier für mich die Softwarearchitektur.
Es mussten alle Schichten der Applikation geplant werden, angefangen vom Frontend auf den jeweiligen Nutzer-PCs bis hin zum Backend auf den Applikations-/Datenbankservern. Im Frontend sollte der Internet Explorer unterstützt werden, damals noch in der Version 8. Die Realisierung lässt sich dabei wie folgt aufteilen:
- Frontend Internet-Explorer: Webseiten realisiert mit HTML / Javascript / jQuery
- Frontend-Library (Eigenentwicklung) mit zentraler Komponente 'jTable' zur schnellen Visualisierung von neuen Tabellen incl. Dialoge zum Neuanlegen, Editieren und Löschen von Datensätzen.
- Middleware-Library (Eigenentwicklung) mit Methoden zum schnellen Erstellen von neuen Servlets
- Backend-Library (Eigenentwicklung) mit Datenbank-Zugriffskomponenten sowie allgemeiner Utility-Sammlung
- Java-Servlets
- Oracle JDBC-Treiber
- Oracle-Datenbank

Implementiert wurden hier neben dem grundsätzlichen Design der Hauptseite hauptsächlich der Administrationsbereich mit Strukturen für die Nutzerverwaltung, Applikationsverwaltung sowie eine Rollenverwaltung zu einfachen Zuweisung von Applikationspaketen. Bestehende Java-Applikationen können nun über die Website mittels Java-Webstart angeboten werden.

Planung und Realisierung eines Filmscanners für Bewegtfilme. Schwerpunkt liegt hier auf der digitalen Bildverarbeitung

In der Abteilung 'Aftersales' gab es bis dato außer Lotus-Notes, eMail- sowie Fileservern noch keine weiteren Server, um Daten zu speichern, zu verteilen sowie die existierenden proprietären Applikationen zu verteilen. Die Idee war daher, einen zentralen Server einzurichten, der jedem Mitarbeiter automatisch die aktuellen Versionen aller von ihm benötigten Applikationen mit allen Daten zur Verfügung stellt.
Nach einiger Abwägung und Evaluierung von verfügbaren Systemen fiel die Wahl schließlich auf ein VM-Ware-Host-System, welches grundsätzlich beliebig viele virtuelle Server zu Verfügung stellen kann.
Es wurde nun zunächst ein Datenbankserver eingerichtet, bei dem wir uns für Oracle-10g-Installation entschieden haben, als Betriebssystem kam Oracle-Linux zum Einsatz.
Dem Datenbankserver wurde ein Applikationsserver zur Seite gestellt, der zunächst auf Windows Server 2008 mit einem Tomcat 6 aufgesetzt wurde.
Um die Ausfallsicherheit zu erhöhen, wurden zusätzlich noch zwei Backupserver eingerichtet, die zweite Oracle-Instanz läuft dabei als 'Physical Standby'.

Fahrzeugdaten-Pflege

• Das 'Technische Informations System' (TIS) fasst mehrere Applikationen zu einem Gesamtpaket zusammen, alle Applikationen greifen auf eine gemeinsame Farzeug-Datenbasis, den sog. Vehicle-Context (VC), zu. In der VC-Datenbank sind alle Fahrzeugdaten gespeichert, welche der Anwender bei Start einer Applikation auswählen muss oder welche automatisch selektiertwerden. Wenn bestimmte Daten in der VC-DB nicht oder nicht korrekt eingegeben sind, so kann die Applikation nicht auf dem gewünschten Fahrzeug arbeiten. Dieser Datenbestand ist zu aktualisieren, zu warten und zu pflegen.

Entwicklung von produktunterstützenden Tools

• Die die verschiedenen Applikationen betreuenden Gruppen brauchen für z.B. Überwachung, Weiterentwicklung, Vereinfachung, Produktunterstützung oder Testläufe ständig verschiedenartigst gelagerte Tools. Es gibt dort Tools und Skripte in Perl, Java, C++, MS-Access sowie proprietären Scriptsprachen. Diese sind von mir zu warten und weiter zu entwickeln.

Weiterentwicklung und Wartung von Autorensystemen

• Da es zwischen den Daten in z.B. der VC-Datenbank relativ komplexe Beziehungen gibt, können diese Daten nicht direkt über eine Datenbank-Konsole eingegeben werden. Zu diesem Zweck existieren sogenannte Autorensysteme, mit dessen Hilfe diese Datenpflege bewerkstelligt wird.
• Da sich die Anforderungen an die Autorensysteme ständig aufgrund von neuen Funktionalitäten oder Datenformat-Änderungen ändern, müssen diese Systeme relativ oft angepasst werden.
• Diese Systeme unterstehen meiner Pflege, unterdessen wurden alle Systeme von mir redesignt und nach Java portiert, eine gemeinsame Bibliothek vereinfacht die Wartung.

Testen und erstellen von Test-Plänen

• Alle ca. 4 Monate werden Gross-Tests durchgeführt, für meinen Bereich müssen aktuelle Test- Pläne entworfen und durchgeführt werden. Dabei liegt der VC sowie Teile des Applikations- Frameworks in meiner Verantwortung. Das Framework fasstdie einzelnen Anwendungen zu einem Produkt zusammen, dort ist insbesondere das korrekte Zusammenspiel der einzelnen Komponenten zu testen.

Aktualisieren von Zentralservern

• Verschiedene Komponenten und Datenbanken werden wöchentlich in neuesten Versionen den Kunden zur Verfügung gestellt. Einige Komponenten werden mir fertig geliefert, andere müssen erst noch aus Rohdaten von mir erzeugt werden. Die vorbereiteten Komponenten müssen auf verschiedene Server verteilt und den jeweilichen Administratoren gemeldet werden. Das erfolgreiche Aktivieren der aktualisierten Komponenten muss überprüft und die Vorgänge dokumentiert werden.

• Hauptbestandteile wurden von mir redesignt und realisiert. 22000 Zeilen, und ein Security- Pflegeprogramm mit ca. 15000 Zeilen. Dazu kommen noch einige Hilfs- und Testprogramme in Delphi oder C++, die während der Projektlaufzeit notwendig oder vom Kunden angefordert wurden. Neben der Weiterentwicklung der Client-Programme unterstanden auch die notwendigen Dlls meiner Pflege (9 Online- und 4 Offline-Dlls). Hier mussten ständig neue Funktionen aufgenommen oder bestehende abgeändert werden. Die Dlls sind teils in Delphi, teils auch in C geschrieben. Ein proprietärer Broker sorgt fr die Kommunikation mit dem Server, hier waren fr mich nur Kleinigkeiten zu korrigieren. Der Kunde setzt ein ATM-Netz ein, in dem manchmal Pakete verloren gehen. Ein neues von einem Kollegen und mir entwickeltes UDPKommunikations- protokoll sorgt jetzt fr eine stabile Kommunikation. Auf dem Server werden je nach Konfiguration dynamische oder auch statische Worker fr den Workflow oder die Security gestartet, auch hier mussten ständige Funktionserweiterungen oder Korrekturen vorgenommen werden. Alle Server-Programme sind in C geschrieben, es gibt eine Schichten-Architektur, auf der untersten Ebene stehen die E-SQL-Statements, die je nach Anforderung von mir ausgearbeitet, realisiert und getestet wurden.

Realisierung von Systemkomponenten zur Migration von DB-Tabellen und Daten von Oracle nach DB2

• Konzeption und Entwicklung einer Anwendung für ein Kunststoff-Recycling-Unternehmen.
• Chargen mit ihren Messdaten müssen aufgenommen und verwaltet werden. Anschliessend werden für Auslieferungen Werks-Prüf-Zeugnisse aufgrund der Messdaten erstellt.

Konzept und Entwicklung einer Anwendung zum Erfassen von Lieferungen und Rechnungserstellung