Mikroarchitektur Geschäftsprozess-Komponenten

Die Mikroarchitektur bezieht sich auf die Umsetzung eines Bausteins, hier einer Geschäftsprozesskomponente (= GP-Komponente). Es wird das Design beschrieben, also welche Programmiersprache, welche Frameworks, welche Tools und welche Muster eingesetzt werden. Die Beschreibung ist dabei als Template zu verstehen und gestaltet sich im Detail leicht unterschiedlich. Wichtig ist, die Anforderungen der Makroebene zu erfüllen.

GP-Komponenten bilden (nur) Abschnitte eines vollständigen End-To-End-Geschäftsprozesses ab, da hier auch einzelne Abschnitte in unterschiedlichen Geschäftsprozessen wiederverwendet werden und somit dem DRY-Prinzip genügen.

In grober Betrachtung besteht eine Geschäftsprozesskomponente aus folgenden optionalen Bestandteilen:

• Benutzeroberflächen
• Workflows
• Aufgaben
• Services
• Business Events
• ein Datenbank-Schema

Diese werden in den folgenden Abschnitten genauer beschrieben.

Wie bei Ländern auch, wird eine GP-Komponente einer Serviceimplementierungsgruppe zugeordnet. Diese wird in der Systemstruktur einem oder mehreren Systemstrukturelementen zugeordnet, so dass einfach beispielsweise Katalogservices bereitgestellt werden können (siehe Systemstruktur und Serviceimplementierungsgruppen zuordnen).

Im Standard hat eine GP-Komponente nur eine Persistenz für Workflows. Diese erhalten jeweils eine eigenes Datenbank-Schema äquivalent zu den Schemata für Länder. D.h. bei einer GP-Komponente namens Schleupen.AS.mal.bal erhält diese das Schema mal_bal. Dieses wird genauso wie bei Ländern auch indirekt über die Zuordnung von Serviceimplementierungsgruppen der Default-Datenbank eines Systemstrukturelements zugeordnet.

In erweiterten Szenarien benötigen manche GP-Komponenten weitere persistente Daten, die dann in dasselbe Schema geschrieben werden. Dieses ist für Daten erlaubt, deren Lebensdauer an die Lebensdauer einer Workflow-Instanz gebunden ist und keine Domänenlogik der Länder ist. Als Beispiel sei hier das Erstellen von Reports angeführt, bei denen die Daten zunächst gesammelt werden und als letzter Schritt ein Report erstellt wird (vgl. Länderübergreifende Abfragen).

Eine GP-Komponente kann sich insbesondere auf Business Events subscriben. Dies kann sowohl durch Workflows als auch "normale" Services erfolgen. Geschieht dies durch einen Workflow, so wird auch von einem Start-Event gesprochen.

Dementsprechend hat eine GP-Komponente auch WCF-Services, die meist zur lesenden Orchestrierung implementiert werden. Diese Query Services werden meist gemäß Interface Segregation für spezifische Benutzeroberflächen derselben GP-Komponente bereitgestellt.

Auch Benutzeroberflächen gehören zu Geschäftsprozess-Komponenten. Diese können auch z.T. fachliche Logik beinhalten, die zum Beispiel für die Bedienung relevant sind. So wird ein Button erst dann freigeschaltet, wenn alle Felder validiert sind und das ViewModel gültig ist. Primär ist allerdings das Ziel, fachliche Logik so viel wie möglich und sinnvoll in den Ländern auszuprägen.

Über Serviceimplementierungsgruppen kann gesteuert werden, an welchen Systemstrukturelementen ein Prozess in der Oberfläche des Dialogstartmenüs gestartet werden kann. Siehe hierzu Systemstruktur. 

Workflows und Benutzeroberflächen werden über Aufgaben gekoppelt. Eine Aufgabe wird dann erstellt, wenn ein Benutzereingriff erforderlich ist. Zur Bearbeitung dieser Aufgaben wird wiederum im Allgemeinen ein DialogFlow gestartet, um anschließend den Workflow fortzusetzen.