Vorbereitend zu einer künftigen Integration von Live-Navigation während der Zustellung von Paketen wurde untersucht, inwiefern die hierfür gewählte Plattform ?Mapviewer? in die bestehende Xamarin-App integriert werden kann. Da sich im Zuge dieser Analyse erhebliche Probleme herausgestellt haben, wird infolgedessen ein nativer Prototyp für Android entwickelt.
Der Prototyp orientiert sich dabei an den gängigen Konzepten des ?Modern Android Development (MAD)? mittels Kotlin, Gradle (Kotlin-Script), MVI und Jetpack Compose. Im Prototyp enthalten sind eine vollumfängliche Anbindung der Datawedge Intent API der verwendeten Zebra Technologies Scanner Plattform sowie die Karten- und Navigationskomponente ?Mapviewer? für die Anzeige der Zustellziele und der Live-Navigation zum nächsten geplanten Zustellziel. Besondere Herausforderung war hierbei die Verbindung der Activity- und Fragment-basierten Mapviewer-Komponenten mit dem moderneren Jetpack-Compose Framework.
Der Prototyp ist nach dem Konzept der Onion Architecture konzipiert und verwendet einen reaktiven Aufbau auf Basis des MVI-Ansatzes. Ebenfalls wird ein weitestgehend deklarativer Ansatz mit Code Generation auf Basis von KSP während des Build-Vorgangs gewählt, um Boilerplate-Code zu reduzieren.
Des Weiteren enthält der Prototyp Unit Tests und Instrumentation Tests zu allen enthaltenen Komponenten sowie Previews für Jetpack-Compose basierte UI-Komponenten.
Der Prototyp ist Basis für eine künftige Neuentwicklung der bestehenden Xamarin-App zur Verbesserung der Performance und der Integration neuer Funktionen.
Zur Unterstützung der Zusteller und im Rahmen der Ablösung der bestehenden Hardware-GPS-Tracker wird eine mobile App entwickelt, welche für iOS- und Android-basierte Mobilgeräte verfügbar ist. Hierfür wurden zunächst verschiedene Frameworks untersucht (MAUI, React Native, Flutter) mit der anschließenden Entscheidung für das Flutter-Framework.
Für die App wird dabei eine zusätzliche WebAPI auf Basis des ASP.Net Core Frameworks bereitgestellt, welche die für die App relevanten Daten aus der bestehenden Datenbasis ermittelt und optimiert aufbereitet.
Die App unterstützt den Zusteller während der Zustellung durch das Aufzeichnen der aktuellen Position für eine spätere Qualitätssicherung sowie der Rückmeldung der durchgeführten Zustellung. Außerdem werden für die einzelnen Zustellziele (Briefkästen) die für den Zusteller relevanten Informationen hinsichtlich Menge und Gewicht der zuzustellenden Sendungen sowie weitere Informationen wie Zugangsinformationen angezeigt. Die Anzeige ist dabei sowohl als Liste wie auch als interaktive Karte mit vorgezeichneter Route verfügbar.
Die App verwendet einen reaktiven Aufbau auf Basis des BLoC State Management Konzepts. Sie enthält ein grundlegendes Routing zwischen den einzelnen Views. Die Views sowie die in den Views enthaltenen UI-Komponenten sind dabei ebenso wie alle weiteren Logik-Komponenten vollständig durch Unit-Tests abgedeckt.
Im Rahmen einer CI/CD-Pipeline (separat für Staging und Produktion) wird die App automatisiert getestet und anschließend für die Zielplattformen gesondert gebaut und in die jeweiligen App-Stores veröffentlicht.
In der bereits vorhandenen Plattform zur Bereitstellung von Kundendaten aus dem zentralen SAP-System gilt es, weitere Datenquellen zu integrieren für eine vollständige Sicht auf alle von konsumierenden Systemen in der angeschlossenen Systemlandschaft benötigten Kundendaten. Hierzu werden bestehende Legacy-Systeme abgelöst und auf die zentrale Plattform migriert sowie neue Systeme auf Basis von Dynamics CRM angeschlossen. Die Anbindung der Dynamics CRM Datenquellen erfolgt dabei über eine Integration mittels Azure Service Bus.
Darüber hinaus wird eine zusätzliche Plattform für die Bereitstellung von Produktdaten aus dem zentralen Informatica PIM System aufgebaut. Die Anbindung erfolgt hierbei durch eine Verbindung mit dem auf Elasticsearch basierenden Audit-Trail des Informatica PIM System und der Verwendung der öffentlichen REST-API des Informatica PIM Systems.
Für beide Plattformen wird eine Microservice-Architektur verwendet, welche ihrerseits jeweils durch einen zusätzlichen Gateway-Service veröffentlicht werden. In den Gateway-Services werden die Endpunkte als GraphQL-Endpunkte angeboten. Die einzelnen Microservices sind mittels GraphQL Federation in den Gateway-Services integriert.
Zusätzlich wird für beide Plattformen ein minimales Webfrontend bereitgestellt, welches der Dokumentation der Endpunkte dient sowie kleinere Hilfsanwendungen (Kundenbrowser, Produktbrowser, Admin-Dashboard, ...) zur Verfügung stellt.
Alle Microservices einschließlich der Gateway-Services sind umfangreich mittels Unit-Tests sowie Integration-Tests mit Snapshot-Funktionalität abgedeckt. Die Webfrontends werden zudem durch Frontend-Tests (TestCafe) abgesichert.
Jedes Frontend und jeder Microservice wird mittels Continuous Integration und Continuous Deployment innerhalb Der Azure DevOps Services als Docker-Image in einer Azure Container Registry abgelegt und von dort durch einen im Rahmen der CI/CD-Pipeline aktualisierten Managed Kubernetes Cluster in Azure veröffentlicht.
Konzeption und Entwicklung eines cloud- basierten headless CMS als öffentlichen Service
Die Applikation besteht dabei aus den Blöcken:
Während das Frontend jeweils als Single Page Application mittels Bootstrap 4.0 als Layout-Komponente sowie VueJS als Rendering- und Applikations-Komponente umgesetzt wird, sind die jeweiligen REST-APIs als Microservices auf Basis von .Net Core und CQRS/ES unter Verwendung von EventFlow umgesetzt. Zur Datenpersistenz kommt PostgreSQL zum Einsatz. Jedes Frontend und jeder REST Microservice wird mittels Continuous Integration und Continuous Deployment innerhalb der Visual Studio Teamservices als Docker-Image in einer Azure Container Registry abgelegt und von dort durch einen im Rahmen der CI/CD-Pipeline aktualisierten Managed Kubernetes Cluster in Azure veröffentlicht.
Im Rahmen einer generellen Migration auf eine komplette Microsoft Office basierende Systemlandschaft gilt es, die bestehende Lotus-Notes Anwendung, innerhalb welcher bisher eingehende Mails und Faxnachrichten klassifiziert und an die Verarbeitungskette der kundeneigenen Fachanwendung für die gesetzliche Unfallversicherung weitergeleitet wurden, zu analysieren und auf eine .NET-basierte Lösung zu portieren.
Dabei gilt es, neben dem bereits existierenden Eingangskanal in Form von Emails und Fax-Nachrichten auch weitere künftige Eingangskanäle (Nachrichten aus einem Web-Portal für Genossenschaftsmitglieder, Anbindung des Besonderen Behördlichen Postfachs (BeBPo)) zu integrieren und eine gemeinsame Bearbeitungsoberfläche in Form einer WPF-Desktopanwendung zu erstellen.
Der Import aus den einzelnen Eingangskanälen sowie die automatisierte Weitergabe an Folgesysteme soll dabei zeitgesteuert über ebenfalls zu erstellende Konsolenanwendungen erfolgen.
Die Daten werden dabei entweder
Langjährige Erfahrung in der Software-Entwicklung in den Branchen
Vorbereitend zu einer künftigen Integration von Live-Navigation während der Zustellung von Paketen wurde untersucht, inwiefern die hierfür gewählte Plattform ?Mapviewer? in die bestehende Xamarin-App integriert werden kann. Da sich im Zuge dieser Analyse erhebliche Probleme herausgestellt haben, wird infolgedessen ein nativer Prototyp für Android entwickelt.
Der Prototyp orientiert sich dabei an den gängigen Konzepten des ?Modern Android Development (MAD)? mittels Kotlin, Gradle (Kotlin-Script), MVI und Jetpack Compose. Im Prototyp enthalten sind eine vollumfängliche Anbindung der Datawedge Intent API der verwendeten Zebra Technologies Scanner Plattform sowie die Karten- und Navigationskomponente ?Mapviewer? für die Anzeige der Zustellziele und der Live-Navigation zum nächsten geplanten Zustellziel. Besondere Herausforderung war hierbei die Verbindung der Activity- und Fragment-basierten Mapviewer-Komponenten mit dem moderneren Jetpack-Compose Framework.
Der Prototyp ist nach dem Konzept der Onion Architecture konzipiert und verwendet einen reaktiven Aufbau auf Basis des MVI-Ansatzes. Ebenfalls wird ein weitestgehend deklarativer Ansatz mit Code Generation auf Basis von KSP während des Build-Vorgangs gewählt, um Boilerplate-Code zu reduzieren.
Des Weiteren enthält der Prototyp Unit Tests und Instrumentation Tests zu allen enthaltenen Komponenten sowie Previews für Jetpack-Compose basierte UI-Komponenten.
Der Prototyp ist Basis für eine künftige Neuentwicklung der bestehenden Xamarin-App zur Verbesserung der Performance und der Integration neuer Funktionen.
Zur Unterstützung der Zusteller und im Rahmen der Ablösung der bestehenden Hardware-GPS-Tracker wird eine mobile App entwickelt, welche für iOS- und Android-basierte Mobilgeräte verfügbar ist. Hierfür wurden zunächst verschiedene Frameworks untersucht (MAUI, React Native, Flutter) mit der anschließenden Entscheidung für das Flutter-Framework.
Für die App wird dabei eine zusätzliche WebAPI auf Basis des ASP.Net Core Frameworks bereitgestellt, welche die für die App relevanten Daten aus der bestehenden Datenbasis ermittelt und optimiert aufbereitet.
Die App unterstützt den Zusteller während der Zustellung durch das Aufzeichnen der aktuellen Position für eine spätere Qualitätssicherung sowie der Rückmeldung der durchgeführten Zustellung. Außerdem werden für die einzelnen Zustellziele (Briefkästen) die für den Zusteller relevanten Informationen hinsichtlich Menge und Gewicht der zuzustellenden Sendungen sowie weitere Informationen wie Zugangsinformationen angezeigt. Die Anzeige ist dabei sowohl als Liste wie auch als interaktive Karte mit vorgezeichneter Route verfügbar.
Die App verwendet einen reaktiven Aufbau auf Basis des BLoC State Management Konzepts. Sie enthält ein grundlegendes Routing zwischen den einzelnen Views. Die Views sowie die in den Views enthaltenen UI-Komponenten sind dabei ebenso wie alle weiteren Logik-Komponenten vollständig durch Unit-Tests abgedeckt.
Im Rahmen einer CI/CD-Pipeline (separat für Staging und Produktion) wird die App automatisiert getestet und anschließend für die Zielplattformen gesondert gebaut und in die jeweiligen App-Stores veröffentlicht.
In der bereits vorhandenen Plattform zur Bereitstellung von Kundendaten aus dem zentralen SAP-System gilt es, weitere Datenquellen zu integrieren für eine vollständige Sicht auf alle von konsumierenden Systemen in der angeschlossenen Systemlandschaft benötigten Kundendaten. Hierzu werden bestehende Legacy-Systeme abgelöst und auf die zentrale Plattform migriert sowie neue Systeme auf Basis von Dynamics CRM angeschlossen. Die Anbindung der Dynamics CRM Datenquellen erfolgt dabei über eine Integration mittels Azure Service Bus.
Darüber hinaus wird eine zusätzliche Plattform für die Bereitstellung von Produktdaten aus dem zentralen Informatica PIM System aufgebaut. Die Anbindung erfolgt hierbei durch eine Verbindung mit dem auf Elasticsearch basierenden Audit-Trail des Informatica PIM System und der Verwendung der öffentlichen REST-API des Informatica PIM Systems.
Für beide Plattformen wird eine Microservice-Architektur verwendet, welche ihrerseits jeweils durch einen zusätzlichen Gateway-Service veröffentlicht werden. In den Gateway-Services werden die Endpunkte als GraphQL-Endpunkte angeboten. Die einzelnen Microservices sind mittels GraphQL Federation in den Gateway-Services integriert.
Zusätzlich wird für beide Plattformen ein minimales Webfrontend bereitgestellt, welches der Dokumentation der Endpunkte dient sowie kleinere Hilfsanwendungen (Kundenbrowser, Produktbrowser, Admin-Dashboard, ...) zur Verfügung stellt.
Alle Microservices einschließlich der Gateway-Services sind umfangreich mittels Unit-Tests sowie Integration-Tests mit Snapshot-Funktionalität abgedeckt. Die Webfrontends werden zudem durch Frontend-Tests (TestCafe) abgesichert.
Jedes Frontend und jeder Microservice wird mittels Continuous Integration und Continuous Deployment innerhalb Der Azure DevOps Services als Docker-Image in einer Azure Container Registry abgelegt und von dort durch einen im Rahmen der CI/CD-Pipeline aktualisierten Managed Kubernetes Cluster in Azure veröffentlicht.
Konzeption und Entwicklung eines cloud- basierten headless CMS als öffentlichen Service
Die Applikation besteht dabei aus den Blöcken:
Während das Frontend jeweils als Single Page Application mittels Bootstrap 4.0 als Layout-Komponente sowie VueJS als Rendering- und Applikations-Komponente umgesetzt wird, sind die jeweiligen REST-APIs als Microservices auf Basis von .Net Core und CQRS/ES unter Verwendung von EventFlow umgesetzt. Zur Datenpersistenz kommt PostgreSQL zum Einsatz. Jedes Frontend und jeder REST Microservice wird mittels Continuous Integration und Continuous Deployment innerhalb der Visual Studio Teamservices als Docker-Image in einer Azure Container Registry abgelegt und von dort durch einen im Rahmen der CI/CD-Pipeline aktualisierten Managed Kubernetes Cluster in Azure veröffentlicht.
Im Rahmen einer generellen Migration auf eine komplette Microsoft Office basierende Systemlandschaft gilt es, die bestehende Lotus-Notes Anwendung, innerhalb welcher bisher eingehende Mails und Faxnachrichten klassifiziert und an die Verarbeitungskette der kundeneigenen Fachanwendung für die gesetzliche Unfallversicherung weitergeleitet wurden, zu analysieren und auf eine .NET-basierte Lösung zu portieren.
Dabei gilt es, neben dem bereits existierenden Eingangskanal in Form von Emails und Fax-Nachrichten auch weitere künftige Eingangskanäle (Nachrichten aus einem Web-Portal für Genossenschaftsmitglieder, Anbindung des Besonderen Behördlichen Postfachs (BeBPo)) zu integrieren und eine gemeinsame Bearbeitungsoberfläche in Form einer WPF-Desktopanwendung zu erstellen.
Der Import aus den einzelnen Eingangskanälen sowie die automatisierte Weitergabe an Folgesysteme soll dabei zeitgesteuert über ebenfalls zu erstellende Konsolenanwendungen erfolgen.
Die Daten werden dabei entweder
Langjährige Erfahrung in der Software-Entwicklung in den Branchen
Direktester geht's nicht! Ganz einfach Freelancer finden und direkt Kontakt aufnehmen.