Challenge

Da der Kunde keine Möglichkeit hat, die Transaktionsdaten seiner Kunden statistisch aufzubereiten, gestaltet sich das Auswerten dieser als mühsam und zeitaufwendig.

Lösung

Ziel war es, ein Portal aufzubauen, das der sicheren statistischen Aufbereitung von Transaktionen eines Kunden dient und zusätzlich einfache Transaktionsveränderungen ermöglicht. Dabei war die Programmierung eines Frontends, Backends, asynchron arbeitende Worker und einer API unsererseits notwendig.

1. Potentialanalyse

Nach intensivem Austausch mit dem Kunden haben wir einen Überblick über dessen Vorstellungen und Wünsche erhalten. Anhand dieser konnten wir Empfehlungen für Werkzeuge, Technologien und Architekturen aussprechen, wie zum Beispiel Flask und MongoDB. Zusammen mit dem Kunden wurde in nachfolgenden Gesprächen das bestmögliche Potenzial aus dem Geschäftsprozess erarbeitet.

2. Use Case Definition

Anhand der Prozessanalyse definierten wir den Use Case des gewünschten Portals. Ein solcher Use Case enthält alle möglichen Szenarien, die mithilfe des Systems zu leisten sind.

Szenario 1:

Vorbedingung:

Die API des Kunden ist ansprechbar und der Benutzer hat sich am Portal authentifiziert.

Nachbedingung:

Alle Transaktionen sind erfolgreich statistisch aufbereitet worden.

Ablauf – Normalszenario:

1.Der Benutzer gelangt auf ein leeres Dashboard.

2. In Folge dessen, dass der Benutzer auf das Dashboard gelangt, fragt das Portal Daten bei der API an.

3. Die abgefragten Daten werden von dem Portal grafisch dargestellt.

Ablauf – Alternativszenario:

3.1 Der Benutzer filtert die Daten nach vorgegebenen Kriterien.

3.1.1 Das Portal bereitet die Grafiken nach den ausgewählten Filterkriterien auf.

3.2 Der Benutzer greift auf die Seite Counter zu und sieht Bezahlstatistiken ein.

3.2.1 Der Benutzer filtert die Daten nach vorgegebenen Kriterien.

3.2.2 Das Portal bereitet die Daten statistisch nach den ausgewählten Filterkriterien auf.

Szenario 2:

Vorbedingung:

Die API des Kunden ist ansprechbar und der Benutzer hat sich am Portal authentifiziert.

Nachbedingung:

Die Daten der Transaktion sind einsehbar.

Ablauf – Normalszenario:

1. Der Benutzer gelangt zu den Transaktionen.

2. In Folge dessen, dass der Benutzer auf die Transaktionsseite gelangt, fragt das Portal Daten bei der API an.

3. Das Portal bereitet die Daten der Transaktionen der Kunden des Benutzers als Tabelle auf.

4. Der Benutzer öffnet über einen Link in der Tabelle eine spezifische Transaktion.

5. Der Benutzer greift durch eine erneute API Anfrage auf sensible Kundendaten und dessen Transaktionshistorie zu.

Szenario 3:

Vorbedingung:

Die API des Kunden ist ansprechbar. Der Benutzer hat sich am Portal authentifiziert, sieht die Transaktionen ein und hat das Recht, Transaktionen zu verändern.

Nachbedingung:

Eine bestehende Transaktion wurde erfolgreich verändert.

Ablauf – Normalszenario:

1. Der Benutzer öffnet über einen Link in der Tabelle eine spezifische Transaktion.

2. Der Benutzer klickt auf den Actionbutton.

3. Der Benutzer verändert die Transaktion durch einen Refund.

4. Die Aktion wird zur Ausführung an die Kunden API übertragen.

Ablauf – Alternativszenario:

3.1 Der Benutzer verändert die Transaktion durch einen Capture.

3.1.1 Weiter wie in Schritt 4.

3.2 Der Benutzer verändert die Transaktion durch einen Cancel.

3.2.1 Weiter wie in Schritt 4.

3. Iterative Modellerstellung

Durch die Use Case Definition konnte unser Team ein Mockup-Portal ausarbeiten. Dieses wurde mit dem Kunden besprochen und mit weiteren Wünschen ausgebaut.

Nach dem Konzeptausbau begannen wir mit der Implementierung des Portals, also der Umsetzung der festgelegten Strukturen und Prozessabläufen.

Während des gesamten Prozesses wurde höchster Wert auf den Schutz der sensiblen Kundendaten gelegt. Es musste sichergestellt werden, dass die Verbindung zu der Kunden API verschlüsselt ist. Zudem speichert das Portal an keinem Punkt kundenbezogene Daten.

Eine wichtige Implementierung war unter anderem die Einbindung einer vom Kunden zur Verfügung gestellten API (Application Programming Interface), welche eine Authentifizierung pro User vorsah. Diese API ermöglicht den Zugriff auf die Daten, die für die Transaktion relevant sind. Diese Daten werden über das Backend angefragt und von den Workern für das Frontend aufbereitet.

Im Zuge der Einbindung erstellten wir ein Frontend, welches sämtliche Daten tabellarisch aufzeigt und das Filtern unterschiedlicher Kriterien und nachträgliche Ändern von Transaktionen ermöglicht. Das Frontend wurde zudem um ein Dashboard erweitert, welches statistische Grafiken ausgibt. Auch hier ist die Möglichkeit des Filterns gegeben.

Nach der Implementierung kam es zur Vorstellung des von uns ausgearbeiteten Systems. Hier wurden unter Absprache mit dem Kunden Anpassungen im Frontend durchgeführt die seinen Vorstellungen entsprachen.

 

4. Integration und Ergebnisanalyse

Nachdem wir das Portal bei dem Kunden integriert haben, erfolgt eine Ergebnisanalyse des in Betrieb genommenen Portals. Dafür wurden verschiedene Tests im Hinblick auf User Interface-Funktionen und Sicherheit ausgeführt, um die Funktion des Portals sicherzustellen.