Benutzeroberflächen

Die direkte Nutzung von Schleupen.CS durch einen Endbenutzer erfolgt über ein zentrales Portal das per Browser erreicht werden kann. Dieses Portal gliedert sich dabei in die folgenden Bereiche:

Portal - der Rahmen, in das die Inhalte eingebettet sind
Start-Menü - zum Starten von Prozessen
Dialogschritt / -ablauf - geführte Navigation zum Starten und Durchführen eines Geschäftsprozesses
Benachrichtigungen - relevante Meldung für den Benutzer insbesondere aus der Hintergrundverarbeitung
Aufgaben - notwendige Benutzerinteraktion, die sich durch die im Hintergrund laufende Geschäftsprozesse ergeben, weil menschliche Interaktion (z.B. Entscheidungen) notwendig sind

Benutzeroberflächen stellen Schritte eines Geschäftsprozesses mit Benutzerinteraktion dar.

Dies ist der Grund, warum wir deren Dialogabläufe (= Wizards) mithilfe von BPMN modellieren!

Geschäftsprozesse können über das Start-Menü gestartet werden, die über einen Dialogablauf initiiert werden. Ein Dialogablauf besteht aus mehreren Seiten, den sogenannten Dialogschritten. Benachrichtigungen, sogenannte Notifications, werden ebenfalls im Portal dargestellt: Diese sind Rückmeldungen aus Dialogschritten, aber insbesondere auch aus der Hintergrundverarbeitung an den End-Benutzer. Sind Benutzer-Eingriffe erforderlich, so werden durch die Hintergrundverarbeitung Aufgaben eingestellt, die ebenfalls im Portal erscheinen.

In der folgenden Abbildung wird dargestellt, wie Dialogabläufe sich in übergreifende Geschäftsprozesse analog zu den Workflows einbetten. Zoomen wir noch tiefer in die Umsetzung, so stellt ein Dialogschritt einen Teil eines Dialogablaufs dar, der selber wiederum aus Controls und Containern besteht. Serviceaufrufe können dann auf verschiedenen Ebenen angeschlossen werden, insbesondere im Dialogschritt und Dialogablauf.

Um Installationshürden zu vermeiden und das Portal möglichst einfach nutzen zu können, kann dieses über die URL https://<somehost>/schleupen/portal und somit per Browser erreicht werden.

Ziele

Die Benutzeroberflächen von Schleupen.CS 3.0 haben einige Ziele, die sich von Bausteinen des Backends unterscheiden. Hierzu gehören unter anderem:

Benutzbarkeit
- einheitliches Look & Feel
- Orientierung der Benutzerführung an Geschäftsprozessen
- Übergreifendes Portal, aus dem Geschäftsprozesse gestartet werden
Portabilität
- Web-Browser als einzige Voraussetzung für Nutzung
- Unterstützung von mobilen Endgeräten (Tablets)
Wartbarkeit
- Wiederverwendung von Funktionalität (auch über Geschäftsprozesse hinweg)
- Testmöglichkeit des Codes
Effizienz
- Modellierung und Generierung zur Vermeidung von schablonenhaften Implementierungstätigkeiten
Konsistenz
- Nutzung des Microsoft .NET-Ökosystems bezüglich Entwicklungswerkzeugen und Basistechnologien
Erweiterbarkeit
- Bessere Reaktionsfähigkeit auf Regulierung und andere kurzfristige Änderungen im Markt
- Kunden können eigene Geschäftsprozesse definieren
- Kunden können Daten, Services und das User Interface anpassen (Beispiel: Kundennummern mit n Stellen)
- Customizing erfolgt durch Kunden oder Dienstleister (z.B. durch die Schleupen Individual-Entwicklung)
- Mit denselben Entwicklungswerkzeugen wie die Schleupen.CS-Entwicklung (Dogfooding)

Plugin-Konzept

Dialogabläufe und Dialogschritte werden in das zentrales Portal eingebettet, um ein einheitliches Look & Feel zu erhalten. Demensprechend ist das Portal ein Plugin-Konzept, in das sich insbesondere die Dialogabläufe samt Schritte einbetten. Dadurch ist es erweiterbar, was ein zentraler Aspekt von CS 3.0 ist.

Dabei werden die Metadaten von Dialogschritten und Dialogabläufen per Deployment auf das System gebracht und - falls noch nicht geschehen - die zur Laufzeit notwendigen Assemblies generiert (diese liegen dann im sogenannten ArtifactStorage). Zum Starten eines Dialogablaufs lädt ein MVC-Controller die notwendigen Metadaten, Assemblies usw. um die Benutzeroberflächen zu rendern.

Dialogabläufe

Dialogabläufe werden in der Business Process Model Notation modelliert und sind somit bzgl. der Granularität ein Schritt im Geschäftsprozess:

Sie orchestrieren Dialogschritte und werden über Schnittstellen ähnlich wie Servicebeschreibungen (OpenAPI, WSDL, o.ä.) zusammengebunden.

Dialogschritte mit MVVM

Dialogschritte werden nach dem Muster Model-View-ViewModel (MVVM) organisiert. Dieses separiert Geschäfts- von Präsentationslogik durch die Schichten View, ViewModel und Model, um eine wartbarere, testbarere und evolvierbarere Anwendung zu erhalten.

Synchrone Service-Aufrufe

Die einzelnen Dialogschritte als Teil eines Dialogabläufs nutzen synchrone Service-Aufrufe - d.h. sie liefern direkt das Resultat ohne dass eine Zwischenspeicherung oder Entkopplung zwischen Request und Response erfolgt. Der Grund hierfür ist, dass dies weniger komplex und somit weniger aufwendig in der Umsetzung ist als wenn das Ergebnis vollkommen asynchron gemeldet würde.

Das Laden der Daten ist direkter und performanter, sodass architekturelle Asynchronität hier nur hinderlich wäre. Auch für das Speichern der Daten ist dies einfacher: die Services implementieren in der Regel optimisches Sperren. Etwaige Konflikte kann der Benutzer direkt erkennen und lösen kann. Da es sich bei dem Editieren von Daten in Bentuzeroberflächten zudem nicht um Massendatenverarbeitung handelt, ist die Wahrscheinlichkeit von Client-seitigen Timeouts für einzelnen Service geringer.