Zur Abwicklung von elektronischen Bestell- und Rechnungsvorgängen werden verschiedene auf BizTalk Server basierende Applikationen eingesetzt. Die Hauptaufgaben der Middleware sind die Anbindung vieler verschiedener Quell- und Zielsysteme (u.a. SAP und Hubwoo) sowie die erforderlichen Datentransformationen. Im Rahmen des Gesamtprojekts findet zudem eine Migration auf BizTalk Server 2016 und SQL Server 2016 statt.

Im Zuge einer technischen Modernisierung sollte das bestehende Risikoberechnungssystem basierend auf SAS Base und C/C++ in aktuellen .NET-Technologien neu implementiert werden.
Das neue System besteht im Wesentlichen aus den vier Komponenten Business Data Layer, Staging Area, Transformation Layer und Calculation Core.

Business Data Layer:
Hier werden fortan alle Nutzdaten (Geschäftsdaten und Berechnungsparameter) in einem relationalen Datenmodell verwaltet. Die Verwaltung ist so umgesetzt, dass diese mittels Kommandozeilenprogramm, Benutzeroberfläche oder vollautomatischer Dienste erfolgen kann.

Staging Area / Transformation Layer:
In der Staging Area wir für einen Rechnungslauf ein spezifisches Set an Nutzdaten gezogen, auf dem sämtliche Transformationen und Datenanreicherungen stattfinden. Das Ergebnis dieses Prozesses ist ein konsolidierte Auflistung von Berechnungsobjekten, welche dann dem Berechnungskern übergeben werden kann.

Calculation Core:
Der Berechnungskern führt die eigentliche Berechnungsarbeit durch. Dabei arbeitet er losgelöst von der bestehenden Anwendungsarchitektur und kann mittels eigener API in beliebigen Komponenten verwendet werden (automatische Job-Steuerung, manueller Aufruf per Kommando oder Oberfläche). Auch die Verwendung via Web Service ist vorgesehen. Die Sonderstellung als losgelöste Komponente rührt primär von der hohen Anforderung an Rechenleistung. Daher ist es nötig das System beliebig skalieren zu können.

Im Zuge einer technischen Modernisierung sollte das bestehende Risikoberechnungssystem basierend auf SAS Base und C/C++ in aktuellen .NET-Technologien neu implementiert werden.
Das neue System besteht im Wesentlichen aus den vier Komponenten Business Data Layer, Staging Area, Transformation Layer und Calculation Core.

Business Data Layer:
Hier werden fortan alle Nutzdaten (Geschäftsdaten und Berechnungsparameter) in einem relationalen Datenmodell verwaltet. Die Verwaltung ist so umgesetzt, dass diese mittels Kommandozeilenprogramm, Benutzeroberfläche oder vollautomatischer Dienste erfolgen kann.

Staging Area / Transformation Layer:
In der Staging Area wir für einen Rechnungslauf ein spezifisches Set an Nutzdaten gezogen, auf dem sämtliche Transformationen und Datenanreicherungen stattfinden. Das Ergebnis dieses Prozesses ist ein konsolidierte Auflistung von Berechnungsobjekten, welche dann dem Berechnungskern übergeben werden kann.

Calculation Core:
Der Berechnungskern führt die eigentliche Berechnungsarbeit durch. Dabei arbeitet er losgelöst von der bestehenden Anwendungsarchitektur und kann mittels eigener API in beliebigen Komponenten verwendet werden (automatische Job-Steuerung, manueller Aufruf per Kommando oder Oberfläche). Auch die Verwendung via Web Service ist vorgesehen. Die Sonderstellung als losgelöste Komponente rührt primär von der hohen Anforderung an Rechenleistung. Daher ist es nötig das System beliebig skalieren zu können.

Spezifikation und Entwicklung eines Katalogsystems für alle gängigen Plattformen für einen Käufer- und Verkäufermarkt

Das Backend soll auf Microservices basieren, die in Form von Docker-Containern wahlweise auf eigene Systeme oder Cloud-Dienstleister deployed werden sollen (abhängig von der Skalierung). Diese werden direkt von der WebUI genutzt, welche als Angular-Applikation entwickelt wird. Zusätzlich wird die Funktionalität für die mobilen Applikationen Apps verwenden, was jedoch nicht direkt passiert, sondern gesichert über einen API-Gateway abgebildet wird.

Weiter soll die Plattform über ein Benutzermanagement verfügen, wodurch jeder registrierte Nutzer die Möglichkeit hat, eigene Kataloge anzulegen.

Hauptanforderung an das gesamte System ist, dass das Backend generisch gestaltet wird, damit es für andere Zwecke als Basistechnologie eingesetzt werden kann. (ähnlich BAAS)

Komponenten:

• Datenbackend basierend auf MongoDB (teilweise SQL)
• Benutzermanagement API
• Katalogmodul (für Verwaltung und Suche)
• WebUI basierend auf Angular und Bootstrap
• Mobile-App für Android und iOS (Xamarin)
• Push-Notifications (optional)
• Nachrichten-System

Im Umfeld der Softwarelizensierung wurden viele verschiedene Schnittstellenapplikationen umgesetzt. Das Führende System ist in der Regel Microsoft Dynamics AX. Es

- diverse B2B Themen mit verschiedenen Formaten (OpenTrans, EDI...)

- Automatisierte Steuermeldung an Tax Portal Spanien (SII)

- Automatisierte Steuermeldung an Tax Portal Italien (SDICoop)

- Abfrage-Cache für Lookup-Abfragen in einer Synchronisation zwischen Dynamics AX und Dynamics CRM

Folgende Kenntnisse/Technologien fanden im Rahmen der Projekte ebenfalls anwendung:

- Digitale Signatur (XAdes/CAdes)

Module (Auszug):

• GPS-Tracking, GEO-Coding
• Plugin-Engine zum Nachladen von Modulcode zur Laufzeit
• SDK zum universellen Live-Datenaustausch zwischen mobilen Endgeräten

Apps (Auszug):

• Tankstellen-App
• Universelle, adaptierbare CMS-App mit Anbindung an diverse CMS-Backends (Wordpress, Joomla, BaasBox)

Es wurde ein Client-/Server-System entwickelt, mit dem sich nahezu jede WebService-basierte Anwendung optimieren lässt. Dies passiert mittels intelligenter bidirektionaler Replikationstechniken in Verbindung mit In-Memory-Speichern. Dazu wurde auch ein generisches Java/Android-Client-Framework zur Integration entwickelt.

Entwicklung eines Marketingsystems für mobile Apps. Dabei handelt es sich um ein mehrstufiges verteiltes System, zum Aufbau und Betrieb eines eigenen Werbenetzwerkes, womit es möglich ist, Werbefläche zu verkaufen oder für eigene Zwecke zu verwenden. Ein Statistiksystem zur Analyse ist ebenfalls Bestandteil des Systems.

Durch den Verkauf von Geschäftsbereichen an andere Unternehmen wurde eine Trennung der Stammdatenhaltung notwendig. Daraus ergab sich die neue Anforderung, dass sämtliche unternehmensweite Workflows mit mehreren SAP-Systemen arbeiten können, anstatt wie bisher, eines als führendes zu verwenden.

Zur Verwaltung aller Druck- und Versandaufträge existieren Workflows, die an zentraler Stelle zusammenlaufen. Die gesetzten Anforderungen werden durch das aktuelle System nicht vollständig erfüllt. Speziell der Punkt, dass es sich um zeitkritische Prozesse handelt, lässt sich mit der aktuellen Architektur nicht abbilden. Dieser Workflow ist nun neuzugestalten und soll durch eine lastenverteilte Application-Server-Architektur mit einem Datenbankbackend realisiert und in die bestehende EAI-Landschaft integriert werden.

Basierend auf BizTalk Server wurde ein Workflowsystem implementiert, welches Genehmigungen für die Zugänge entsprechend verarbeiten kann. Dabei soll sich die Anwendung in die bereits existierende Systemlandschaft eingliedern und diese auch nutzen.

Auf Basis des BizTalk Servers 2009 und mit Hilfe einer MiddlewareDatenbank basierend auf SQL Server wurde eine Anwendung geschaffen, die eine vollautomatisierte und für den Endnutzer unbemerkte Synchronisation von ausgewählten Daten zwischen Microsoft Dynamics CRM und einem SAP ERP System ermöglicht.

Im Zuge dessen, dass beim Kunden die über die Jahre auseinandergelaufenen Geschäftsprozesse wieder zusammenführen möchte, ist eine komplexe Middleware-Architektur zu schaffen. Hierfür kommt ein verteiltes System mit BizTalk Server 2009/2010 als Hauptkomponente zum Einsatz.