Kommunikation mit anderen Systemen

Gemäß des Grundkonzepts von Schleupen.CS 3.0 stehen alle Services und Business-Events zur Nutzung durch Externe bereit. Auch die Integration eigener CS 3.0-Bausteine (Länder und GP-Komponenten) durch Dritte ist konzeptionell vorgesehen und kann zur Verknüpfung von externen Systemen verwendet werden.

Zum Datenabgleich zwischen Schleupen.CS 3.0 und einem externen System für redundante Datenbestände kann die sogenannte Systemintegration verwendet werden. Für einen Datenabgleich muss dabei ein Mapping der unterschiedlichen Datenstrukturen beschrieben und die Systeme an die Systemintegration angebunden werden. Die besitzt bis auf spezielle Anknüpfungspunkte und Algorithmen die unter Makroarchitektur, Mikroarchitektur Geschäftsprozess-Komponenten und Mikroarchitektur Länder beschriebene Grundarchitektur.

Darüber hinaus bietet Schleupen.CS 3.0 erweiterte Mechanismen für die einfachere Nutzung von anderen Systemen an, die sogenannten privilegierten Schnittstellen. So zum Beispiel sehen wir die Marktkommunikation als eine privilegierte Schnittstelle an; sie besteht aus mehreren Bausteinen und verknüpft mehrere Marktteilnehmer (Lieferant, Netzbetreiber …) über den Austausch von Edifact-Nachrichten per automatisierter Mail-Kommunikation miteinander. Die Marktkommunikation besitzt bis auf spezielle Anknüpfungspunkte und Algorithmen die unter Makroarchitektur, Mikroarchitektur Geschäftsprozess-Komponenten und Mikroarchitektur Länder beschriebene Grundarchitektur. Die Besonderheiten von privilegierten Schnittstellen werden unten genauer beschrieben. Die meisten privilegierten Schnittstellen fußen auf synchronen REST-Schnittstellen, die unmittelbar ein Ergebnis liefern und / oder auf asynchronen REST-Schnittstellen, die synchron den auszuführenden Auftrag quittieren und bei Fertigstellung des Auftrags eine Callback-Schnittstelle zu einem späteren Zeitpunkt aufrufen und somit eine Antwort geben. 

All diese Integrationsszenarien werden im Folgenden genauer beschrieben.

Integration im Frontend

Die Dialogschritte und Dialogabläufe der durch Schleupen.CS bereitgestellten Frontends können einfach mithilfe des visuellen WebModelers angepasst werden. Diese Möglichkeit kann insbesondere zur Integration von externen Systemen verwendet werden. Hierzu gehört insbesondere:

• Web-Anwendungen können als Link oder eigene Seite eingebunden werden.
• Services können von Dialogseiten genutzt werden.

Die Umsetzung dieser Anforderungen ist in Benutzeroberflächen beschrieben.

Da für diesen Lösungsweg derzeit nur WCF-Services verwendet werden können, kann man einen auch einen anderen Weg gehen, der im folgenden beschrieben wird.

Anbindung über Adapter-Service

Eine Möglichkeit des minimal-invasiven Anbindens eines externen Service ist, diesen über einen Adapter-Service wie folgt anzuschließen: 

Der Adapter-Service implementiert die Schleupen.CS-Schnittstelle, delegiert an die Original-Implementierung und ergänzt diesen durch einen Aufruf gegen das externe System. Dieser Adapter-Service wird dann automatisch im UI durch Registrierung in der Service Registry verwendet.

Dieses Vorgehen eignet sich natürlich nicht für alle Anwendungsfälle, kann aber an beliebigen Stellen in Schleupen.CS angewendet werden!

Integration im Reporting

3rd-Party-Services und Datenquellen sind im Reporting nutzbar. Hierzu wird in einem Birt Report eine Service Operation als Datenquelle angebunden und im Report verwendet:

Integration in Prozessen

Auch Geschäftsprozesse können bezüglich der Nutzung von Web-Services dritter Anwendungen erweitert werden. Auch in diesem Fall kann dies einfach mithilfe des WebModelers  erfolgen. Details hierzu finden sich unter Workflows und werden daher hier nicht weiter ausgeführt.

Es können zudem eigene GP-Komponenten erstellt und integriert werden. Dies veranschaulicht folgende Abbildung:

Um ein Land oder eine GP-Komponente in Schleupen.CS zu installieren, muss ein sogenanntes DeploymentPackage erstellt werden. Hiervon gibt es verschiedene Typen. Ein Service-Package hat dabei folgende Grundgestalt:

<Package ...>
  <Artifact xmlns="urn://Schleupen.CS.PI.DP.Packaging_3.2">
    <Id>Schleupen.AS.MT.BIB.Services</Id> ...
  </Artifact>
  <DeploymentRoles xmlns="urn://Schleupen.CS.PI.DP.Packaging_3.2">
    <DeploymentRole>BusinessProcessServer</DeploymentRole>
  </DeploymentRoles>
  <Content>
    <ApplicationPool>...</ApplicationPool>
    ...
    <ServiceImplementationGroup>
      <Name>Bibliotheksverwaltung</Name>
    </ServiceImplementationGroup>
    ...
    <File>...</File>
    ...
    <ConfigService>...</ConfigService>
    <ServiceImplementation>
      <Interfaces><Interface>Schleupen.AS.MT.BIB.Benutzerkonten.BuecherAusleihenActivityService_3.3</Interface></Interfaces>
      <RelativeAddress>Schleupen.AS.MT.BIB.Benutzerkonten.BuecherAusleihenActivityService_3.3.BuecherAusleihenActivityService.svc</RelativeAddress>
      <Location>SystemUsages</Location>
    </ServiceImplementation>
    ...
    <ServiceInterface><Name>Schleupen.AS.MT.BIB.Benutzerkonten.BuecherAusleihenActivityService_3.3.wsdl</Name>
    ...
    </ServiceInterface>
  </Content>
</Package>

Integration in Services

Wie oben bereits beschrieben, können Services implementiert werden, die vorhandene Services zu einem neuen Service orchestrieren. Dies kann über Workflows wie im vorherigen Abschnitt erfolgen oder über implementierte Services, die synchron orchestrieren. 

Integration eigener Länder

3rd-Party-Komponenten können als „Länder“ in die Plattform integriert werden. Die konkrete Implementierung der dazu notwendigen Werkzeuge stellen wir auf Anfrage gerne zur Verfügung. Folgende Voraussetzungen sind hierfür zu erfüllen:

• Service-Package mit WCF-Webservices samt Registrierung in der Service-Registry und Informationen zur Erstellung der notwendigen Messaging-Artefakte
• DB-Patches mit den für das Produkt notwendigen Datenbank-Objekten wie Tabellen, Views, Constraints, Schema und so weiter

Plugins

An Stellen, an denen die Funktionen eines Landes austauschbar sein sollen, kommen Plugins zum Einsatz. Die bekanntesten Beispiele sind

• Archivierung
• DSGVO-Manager
• Systemintegration

Systemintegration

Die Systemintegration dient der Integration externer Systeme. Insbesondere ist hier der Abgleich der Datenbestände angedacht. Die Systemintegration ist hier detailliert beschrieben.

Privilegierte Schnittstellen

Privilegierte Schnittstellen (privilegiert bedeutet „bevorzugt“, „mit Sonderrechten versehen“) in Schleupen.CS 3.0 sind speziell ausgestaltete Schnittstellen, die insbesondere für Integrationsszenarien im Zusammenspiel mit externer Software oder Software von Drittanbietern geschaffen werden. Die Schnittstellen werden speziell für die Nutzung in definierten Anwendungskontexten maßgeschneidert (Prozess- und / oder Datenintegration). Diese Maßschneiderung erfolgt in der Regel sowohl technisch als auch fachlich.

Privilegierte Schnittstellen sind dann einfacher nutzbar, gesondert dokumentiert, mit einen Teil der Nutzer explizit erarbeitet, abgestimmt und beachten insbesondere Aspekte wie Sicherheit, Resilienz und Monitoring. Wichtig ist, dass derartige Schnittstellen eine höhere Stabilität aufweisen, d.h. länger sowohl semantisch als auch technisch kompatibel bleiben. Sie umfassen in der Regel mehrere technische Schnittstellen (z.B. mehrere Web-APIs) und bei Änderungen der Gesamt-Schnittstelle werden die Nutzer explizit informiert und eine neue Version der Schnittstellenspezifikation bereitgestellt.

Ein wichtiger Aspekt für die Erstellung von privilegierten Schnittstellen ist, dass die Nutzung durch Konsumenten dadurch deutlich vereinfacht wird, indem mehrere Serviceaufrufe zu einem gebündelt werden. Sie stellen somit eine sowohl technische als auch fachliche Fassade von Schleupen.CS 3.0 dar. Diese Fassaden sind keine Standard-Architektur-Bausteine wie Geschäftsprozesskomponenten und Länder, da sie eine andere Struktur aufweisen. Sie sind nicht Bestandteil von Schleupen.CS-Core.

Die vereinfachte Nutzung wird auch durch Kapselung technischer Details wie das Verbergen der Systemstruktur erreicht: Möchte man Services von Schleupen.CS 3.0 direkt nutzen, so benötigt man ein SessionToken zur Ausführung um einen Systemstrukturelement-Knoten zu adressieren und damit den Datenkontext für den Service zu bestimmen. Dieses SessionToken muss den Services von Schleupen.CS 3.0 durch den Aufrufer mitgegeben werden. Derartige Interna werden bei privilegierten Schnittstellen verborgen, da diese eine gewisse Komplexität in der Nutzung mit sich bringen. Um das Wissen der Systemstruktur nicht nach außen zu exponieren und diese zu kapseln, gleichzeitig aber nicht zu viel an Flexibilität zu verlieren, kann ein Mapping von Mandanten des externen Systems zur Schleupen.CS Systemstruktur konfiguriert werden. Als Nutzer der privilegierten Schnittstelle muss dann lediglich der Mandant des externen Systems in alle Schnittstellen mitgegeben werden. Die Implementierung der privilegierten Schnittstellen routet dann zum zugeordneten Systemstrukturelement.

Die von außen aufgerufene Schnittstelle operiert auf Systemebene der Systemstruktur. Hier ist das Mapping in der zugeordneten Datenbank konfiguriert. Nach der Ermittlung des Ziel-Systemstrukturelement-Knotens wird das SessionToken für die weiteren Aufrufe erzeugt und bei den Aufrufen den unterliegenden Services mitgegeben.

Für privilegierte Schnittstellen werden Sicherheitsaspekte wie Authentifizierung, Autorisierung und Verfügbarkeit wie 24/7 bei der Definition der jeweiligen Schnittstelle explizit festgelegt. Auch ist es ideal, wenn diese möglichst separat betrieben werden können, um diese von Schleupen.CS 3.0 abschotten zu können. Derzeit erfolgt der Zugriff auf die privilegierten Schnittstellen per VPN-Tunnel, die Authentifizierung per http-Basic-Authentifizierung oder per OpenID Connect.

Da privilegierte Schnittstellen auch Resilienzmechanismen wie Retries, Circuit Breaker etc. unterstützen, haben diese viel mit API-Gateways gemeinsam.

Eine privilegierte Schnittstelle setzt sich im allgemeinen aus synchronen und asynchronen Bestandteilen zusammen. Diese werden im Folgenden betrachtet.

Synchrone Fassade

Eine synchrone Fassade arbeitet für den Nutzer blockierend, d.h. dass der aufrufende Thread blockiert wird, bis eine Antwort zurückgegeben wurde. Diese Fassade ruft Services der GP-Komponenten und Länder auf, indem der Aufruf nach CS 3.0 synchron delegiert wird.

Eine synchrone Fassade wird verwendet, wenn Daten gelesen werden sollen oder Daten einfach persistiert werden, also keine lang laufenden Prozesse ausgeführt werden. Dabei muss der Nutzer resilientes Verhalten - beispielsweise Retrys bei Timeout - selber implementieren.

Die Schnittstellen sind i.A. als REST-Schnittstellen ausgeprägt (genauer: Web-APIs). In dieser wird der Mandant des externen Systems angegeben, was intern wie oben beschrieben gemappt wird.

Beispiel der Schnittstellen-Signatur: 

Die privilegierte Schnittstelle Redispatch verbindet Schleupen.CS mit Redispatch-Systemen unterschiedlicher Hersteller. Der Endpunkt zur Übergabe abrechnungsrelevanter Ausfallarbeit hat folgende Gestalt:

http://<server>:<port>/Schleupen/Schleupen.CS.RD.RDK.REST.Services/RD/RDK/RedispatchEmpfangActivityService _3.1.svc/<RedispatchMandant>

Wie hieran ersichtlich ist, wird der Mandant in der URL angegeben. Der Aufruf muss per POST erfolgen, wobei die Nutzdaten als JSON-Objekt übergeben werden. Details: siehe Redispatch-Spezifikation.

Aufbau

Jede privilegierte Schnittstelle besitzt eine eigenes Service- und Datenmodell, da sie mit dem Kern von Schleupen.CS überschneidende Begrifflichkeiten verwenden (vgl. Kanonisches Modell) die meist nicht von Schleupen definiert werden. Diese Typen finden sich in den gesonderten Schnittstellen-Dokumentationen wieder. Zudem wird mit separaten Servicemodellen der notwendigen höheren Stabilität von privilegierten Schnittstellen Rechnung getragen. Auch Services unterschiedlicher privilegierter Schnittstellen können sich in Ihrer Funktionalität überschneiden, da diese jeweils für einen Nutzungskontext ausgerichtet sind.

Das folgende Diagramm zeigt die innere Struktur des Templates einer synchronen Fassade einer privilegierten Schnittstelle. Diese ist ein separat deploybarer Baustein, der REST-Services bereitstellt und obige Schnittstellenbeschreibungen implementiert. Er beinhaltet intern das Systemstruktur-Mandant-Mapping das in einer DB auf Systemebene persistiert ist. Mithilfe des Service CreateSessionTokenActivityService des Service Bus wird ein SessionToken erzeugt und in die synchronen Aufrufe der Services von Schleupen.CS Core mitgegeben.

Asynchrone Fassade

Bei einer asynchronen Fassade wird der Client nur für die Übergabedauer blockiert und stößt die serverseitige Verarbeitung an. Die Übergabe erfolgt hierbei an die Systemintegration (Schleupen.CS.SI_Systemintegration), da diese ein geeignetes Monitoring, Skalierung und Lastverteilung bietet. Die Antwort an den Aufrufer erfolgt über Callback-REST-Schnittstellen und eine Korrelations-ID. Diese Korrelations-ID ist notwendig, damit der initiierende Aufrufer die Antwort der Anfrage zuordnen kann (siehe hierzu bspw. https://www.enterpriseintegrationpatterns.com/CorrelationIdentifier.html).

Asynchrone Fassaden kommen insbesondere zur Anwendung, wenn Schleupen.CS-Prozesse angestoßen werden, die langlaufend sind.

Ein Beispiel einer asynchronen privilegierten Schnittstelle ist in SMGWA beschrieben!

Aufbau

Das folgende Diagramm zeigt die Default-Struktur einer privilegierten Schnittstelle mit synchronen und asynchronen Bestandteilen. Diese ist ein separat deploybarer Baustein, der REST-Services bereitstellt und obige Schnittstellenbeschreibungen implementiert. Er beinhaltet für den synchronen Fassadenteil wie die synchrone Fassade intern das Systemstruktur-Mandant-Mapping. Im asynchronen Fall ruft die privilegierte Schnittstelle die Systemintegration auf, die mithilfe des SI-Adapters auf die Typen der Schnittstelle des Landes mappt, die Requests als sogenannte Demands zwischenpuffert und schlussendlich an das Land den passenden Request zustellt. Um eine Antwort an das aufrufende externe System zu geben, erfolgt die Kommunikation der Rückrichtung ebenfalls über die Systemintegration, wobei im SI-Adapter im Schritt des "Schreibens" unter Zuhilfenahme des Mappings der Callback-Service aufgerufen wird.

Der Baustein Systemintegration wird verwendet, da hierdurch automatisch Resilienzmechanismen, Monitoring etc. zur Verfügung stehen!

Datei-Schnittstellen?

Häufig werden - auch heute noch - Datei-Schnittstellen zum Austausch zwischen Systemen verwendet. Diese sind im Allgemeinen in Schleupen.CS nicht vorgesehen. Hierfür gibt es u.a. folgende Gründe:

• Generell sind Datei-Schnittstellen breiter und unsicherer. Auch Mechanismen wie OpenID Connect können nicht genutzt werden.
• Reilienz-Mechnismen müssen manuell nach-codiert werden, was Kosten-intensiv, nicht Standardisiert und fehlerträchtig ist.
• Eine Monitoring, das auf Metriken basiert ist in der Regel nicht gegeben.

Bietet beispielsweise Fremd-Software lediglich einen Export an, so werden im Rahmen der Individualisierung im Projektgeschäft mitunter Adapter erstellt, die diese Datei-Schnittstelle nutzen und die Schleupen.CS 3.0-Services bedienen.