Systemstruktur - mehr als nur Mandanten
Die sogenannte Systemstruktur in Schleupen.CS ist in erster Näherung ein erweitertes Mandantenkonzept: Hiermit ist es möglich, organisatorische Strukturen, die über Mandanten hinausgehen, abzubilden. Damit ist es möglich, mehrere Werke in einem Schleupen.CS-System mit unterschiedlichen Konfigurationen zu betreiben. Die Systemstruktur kommt direkt beim Login des Portals zum Vorschein. In dem Login-Dialog wählt man einen Knoten - das Systemstrukturelement - aus, so dass man in dem entsprechenden Kontext arbeitet.
Die Systemstruktur ist prinzipiell sehr flexibel. So können Systemstrukturelementknoten, bestehend aus einem Typ und einem Namen definiert werden. Aber auch Systemstrukturelementtypen können selber definiert werden.
Schleupen.CS liefert folgende Standard-Systemstrukturelementtypen aus: System, Systemkatalog, Gesellschaftskatalog, Gesellschaft, Werkskatalog, Werk, Mandant. Standard-Systemstrukturelementtypen sind zu bevorzugen, da hier Konventionen angewendet werden, die das Einrichten des Systems vereinfachen.
Im Beispiel der Abbildung gibt es also u.a. folgende Systemstrukturelemente:
- System vom Typ System
- Systemkatalog vom Typ Systemkatalog
- StadtwerkMoers Huelsdonk vom Typ Gesellschaftskatalog
- LieferantMoers Huelsdonk1 vom Typ Mandant
Ein Systemstrukturelement definiert aus technischer Sicht einen Datenkontext auf dem die Services zur Laufzeit operieren.
Jeder Service erhält dazu im SOAP-Header ein sogenanntes SessionToken, das ein Systemstrukturelement adressiert. Mithilfe dieses SessionTokens ermittelt der Service die zugehörige Datenbank des Systemstrukturelements.
Die Systemstruktur und die Zuordnung der Datenbanken zu Systemstrukturelementen kann einfach administriert werden.
Wie passen der Datenkontext und die Möglichkeit, jeden Microservice in einer Datenbank zu betreiben, zusammen?
Dies sind zwei querschnittliche Aspekte. Jeder Micorservice hat sein eigenes Datenbank-Schema. In welcher Datenbank dieses deployed wird, ist dabei nicht relevant. Aus Microservices-Sicht ist relevant, dass keine Kopplung auf DB-Ebene zwischen den verschiedenen Microservices existiert. Somit ist es möglich, jedes Datenbank-Schema in einer eigenen Datenbank zu deployen. Rechnet man Systemstruktur und die Anzahl der Bausteine zusammen, entsteht schnell eine Anzahl von über 1000 Datenbanken.
Betrachten wir hierzu folgendes Beispiel:
Die Anwendung Schleupen.AS.MT.BIB_Bibliotheksverwaltung kann für den Knoten Mandant 11 ihr DB-Schema MT_BIB in der "Standard-Datenbank" DB_11 deployed haben. Diese "Standard-Datenbank" beinhaltet im Standard alle Schemata aller Länder. Es ist aber sehr einfach möglich, das System so zu konfigurieren, dass das DB-Schema MT_BIB in einer anderen Datenbank DB_11_2 separiert wird und über den Knoten Mandant 11 automatisch verwendet wird. Somit ist es prinzipiell möglich, dass jeder Microservice eine eigene Datenbank besitzt. Hierauf wird in kleinen Systemen verzichtet, da man schnell auf eine hohe Anzahl an Datenbanken kommt.
ServiceImplementationGroups und Katalog-Services
Eine ServiceImplementationGroup (oder auch kurz SIG) ist eine Menge von Services, die zusammen auf dem gleichen Systemstrukturknoten registriert werden können. Diese Menge an Service kann durch ein Land definiert sein, ist im Allgemeinen aber auch bausteinübergreifend konfiguriert. Diese Menge an Services kann wiederum per Konfiguration einem Systemstrukturknoten zugeordnet werden. Dann operieren diese Services dann quasi auf "immer" auf diesen Knoten, haben also immer denselben Datenkontext.
Das nachfolgende Beispiel versucht, das Konzept genauer zu erläutern: es ist mehr als der reine Datenkontext!
Gegeben sei die in der vorstehenden Abbildung dargestellte Systemstruktur u.a. mit den Systemstrukturelementen Mandant B vom Typ Mandant sowie Gesellschaft vom Typ Gesellschaftskatalog. Bei der Anmeldung im Portal wird ein SessionToken für den Kontext Mandant B erstellt. Zum Abschluss des Dialogablaufs zur Ausleihe eines Buchs werde in unserem Beispiel ein Activity Service mit der ServiceId Schleupen.CS.MT.BIB.Benutzerkonten.BuecherAusleihenActivityService_3.2 aufgerufen. Dieser sei der Serviceimplementierungsgruppe Bibliotheksverwaltung zugeordnet. Diese Serviceimplementierungsgruppe sei wiederum dem Knoten Gesellschaft vom Typ Gesellschaftskatalog zugeordnet. Da jeder Service-Aufruf in Schleupen.CS über den Broker geht, wird das SessionToken auf den Datenkontext umgeschrieben, auf dem die Serviceimplementierungsgruppe registriert ist. In unserem Beispiel also zu einem SessionToken für den Gesellschaftsknoten. Mit diesem Knoten wird der Zielservice durch den Broker aufgerufen.
Der Broker ermittelt dabei die Serviceimplementierungsgruppe anhand der Service-Registry. Das SessionToken wird dabei im SOAP-Header gelesen und für den Ziel-Service gesetzt. Mit Hilfe eines Infrastruktur-Service ermittelt die Service-Implementierung dann anhand des SessionTokens die dem Systemstrukturelementknoten zugeordnete Datenbank (Datenkontext).
Anmerkung: Einem Systemstrukturelement können mehrere Datenbanken zugeordnet werden. Da ein Schema einem Microservice gehört, kann pro Systemstrukturelement jeder Microservice eine eigene Datenbank mit seinem Schema haben und somit kann der Microservice möglichst autonom operieren.
Der hier dargestellte Suchalgorithmus ('von unten nach oben') gilt für alle Servicekategorien außer für Event-Services. Für Event-Services erfolgt die Suchstrategie entsprechend von oben nach unten.
In SIG-Regelwerk wird u.a. das Regelwerk beschrieben, wie Services den zugehörigen Datenkontext finden!
Startbarkeit der Dialogabläufe in der Systemstruktur
Über Serviceimplementierungsgruppen kann auch gesteuert werden, an welchen Systemstrukturelementen ein Prozess in der Oberfläche über das Dialogstartmenü gestartet werden kann. Dazu muss die jeweilige Serviceimplementierungsgruppe dem Dialogablauf zugeordnet werden. Eine Zuordnung ist für Dialogabläufe im Gegensatz zu Services allerdings nicht zwingend erforderlich: Wenn ein Dialogablauf keiner Serviceimplementierungsgruppe zugeordnet ist, kann der Dialogablauf „überall gestartet werden“ - egal an welchem Systemstrukturelement ein Anwender sich anmeldet.
Wenn ein Dialogablauf einer Serviceimplementierungsgruppe zugeordnet ist, wird wie bei Aufrufen von Services „nach oben navigiert“. Wenn die SIG auch dem Systemstrukturelement zugeordnet ist, an dem der Anwender angemeldet ist, dann kann der Prozess gestartet werden. Andernfalls wird das nächst höhere Systemstrukturelement überprüft. Wenn auf dem Pfad zur Wurzel die Serviceimplementierungsgruppe nirgendwo zugeordnet ist, kann der Prozess nicht gestartet werden.
Sonderfall: Benutzerverwaltung am System
Die Benutzerverwaltung stellt derzeit einen Sonderfall dar, da diese nur auf dem Systemstrukturelement System gestartet werden soll.
Um diese Bedingung zu erfüllen, muss an einem Dialogablauf die Zuordnung zu einer Pseudo-SIG „#System“ angegeben werden.
