Hybrid Cloud Tutorial

Einführung

Sowohl im eigenen Haus bzw. Rechenzentrum als auch in der Cloud besteht der Bedarf der Integration verschiedener Systeme und Services.

Um Systeme im eigenen Haus zu integrieren, bietet Virtimo das Produkt INUBIT an. Zur Anbindung diverser Systeme und Services aus der Cloud bzw. dem Internet steht IGUASU zur Verfügung.

Es bietet sich nun an, diese beiden Welten miteinander zu verbinden. Genau zu diesem Zweck gibt es die Hybrid-Cloud-Verbindung. Hierüber werden INUBIT und IGUASU auf eine innovative, sichere und einfach zu verwendende Weise verbunden.

Hierzu gibt es den IGUASU Connector in INUBIT und INUBIT-Processors in IGUASU.

Client-to-Cloud initiierte Duplex-Verbindung

Um eine möglichst hohe Sicherheit zu gewährleisten und gleichzeitig den Konfigurationsaufwand des heimischen Netzes in Bezug auf Firewalls und Port-Freischaltungen zu minimieren, wird die Verbindung zwischen On-Prem und Cloud immer von dem On-Prem System - also INUBIT - hergestellt.

Die Verbindung in Form eines Secure Web Sockets wird dann ständig aufrechterhalten. Sollte sie einmal abbrechen, wird sie sofort von der On-Prem Seite (INUBIT) wiederhergestellt.

Über diese Verbindung können sowohl von der On-Prem Seite (INUBIT) als auch aus der Cloud (IGUASU) Workflows/Flows auf dem jeweils anderen System gestartet werden.

Maximale Sicherheit durch die Verwendung von mTLS

Die Verbindung ist notwendigerweise immer durch mTLS/SSL gesichert. Das bedeutet, dass beide Seiten (IGUASU und INUBIT) über Zertifikate ihre Identität beweisen und die Verbindung über SSL gesichert ist.

Die notwendigen Zertifikate werden dabei von IGUASU generiert. Für INUBIT müssen sie heruntergeladen und an der Verbindung eingestellt werden. In IGUASU werden sie nach ihrer Erzeugung lediglich noch in den entsprechenden Services konfiguriert.

Beispielhafte Anwendungsfälle

Wie oben beschrieben, können nach der Verbindung der Systeme von beiden Seiten aus Prozesse des anderen Systems gestartet werden. Mögliche Szenarien, die damit abbildbar wären, sind:

INUBIT → IGUASU

Aus einem lokalen Workflow in INUBIT soll ein spezifisches System in der Cloud aufgerufen werden, für welches IGUASU eine einfache Anbindung bereitstellt
- Das Schreiben einer Nachricht in ein AWS-System wie S3 oder Kinesis
- Kommunikation mit einem Kafka-System - also beispielsweise das Schreiben auf ein Kafka-Topic und das Empfangen der Nachrichten eines anderen Topics, welche dann zu Aufrufen von INUBIT Workflows führen
Teile der Prozesse, die bisher mit INUBIT umgesetzt sind, sollen dynamisiert werden, sodass sie hohe Lastspitzen über skalierende Flows in der Cloud abbilden
- Das könnte für Teile gelten, die grundsätzlich besonders hohe Last erzeugen
- Aber auch für Bereiche, die nur zu bestimmten Zeiten eine hohe Anforderung an die Last stellen - wie z.B. Shops an Weihnachten oder das Versenden von Benachrichtigungen zu bestimmten Zeiten

IGUASU → INUBIT

Aus einem Flow in der Cloud soll für einen Kunden die Adresse erfragt werden, wobei die Kundendaten On-Prem gehalten werden
- Es kann ganz gezielt der einzelne Datensatz erfragt werden. Die Datenbank selbst muss dafür nicht im Internet stehen, sondern es wird über den Weg der beiden sicher verbundenen Integrations-Produkte nur das eine Datum übertragen
Ein interner Service, der keinesfalls allgemein im Internet stehen soll, wird in einem Cloud-Flow benötigt
Es soll auf das interne SAP oder eine AS/400 zugegriffen werden

Inhalt dieses Tutorials

Um das Zusammenspiel einer lokalen INUBIT Installation und IGUASU in der Cloud zu veranschaulichen, wird Ihnen in diesem Tutorial gezeigt, wie die Verbindung zwischen beiden Komponenten hergestellt werden kann.

Mit diesem Tutorial werden Sie lernen, wie Sie die benötigten Zertifikate in IGUASU erstellen können und wie diese für die sichere Kommunikation der Anwendungen genutzt werden. Zudem wird Ihnen veranschaulicht, wie die INUBIT-spezifischen Processors in IGUASU eingestellt werden können, sodass sowohl Nachrichten vom INUBIT empfangen als auch Daten zurück an die On-premises Installation gesendet werden können.

Das folgende Tutorial wurde mit IGUASU 4.3.0 und Inubit Process Engine und workbench 8.1.14 unter Windows 11 erstellt. Der finale Flow der beiden Kommunikationsmöglichkeiten ist in der folgenden Abbildung ersichtlich:

Teil 1: Konfiguration des Endpunkts

Bevor Sie mit der Erstellung der Zertifikate beginnen, muss der richtige Endpunkt in IGUASU konfiguriert sein. Dieser Endpunkt wird vom IGUASU Connector in INUBIT verwendet, um die Verbindung zu Ihrer IGUASU-Instanz herzustellen. Navigieren Sie in IGUASU zum Endpunkt-Konfigurationsfenster, dazu muss das globale Menü geöffnet und zum Punkt Management im Menü navigiert werden.

Zur Einsicht des Endpunkt-Konfigurationsfensters werden die entsprechenden Berechtigungen in IGUASU benötigt. Sollten Sie das Konfigurationsfenster in den Einstellungen nicht sehen können, wenden Sie sich an Ihren Administrator.

Wählen Sie die Option Add URL aus, und konfigurieren Sie eine URL, die folgende Eigenschaften aufweist:

SSL terminated at backend: Der Endpunkt wird von Ihrem INUBIT-System aus mit einer TLS-terminierten Verbindung erreichbar sein.
Hostname: Wählen Sie einen passenden SSL pass-through hostname. Dies wird der URL beigefügt, die der IGUASU Connector in INUBIT verwenden wird.

Wählen Sie die URL anschließend aus und fügen Sie einen Port als Endpunkt hinzu. Im Rahmen dieses Tutorials wird der Port 9003 genutzt.

Teil 2: Erstellung der benötigten Zertifikate und Schlüssel

Um eine sichere Verbindung zwischen beiden Komponenten zu ermöglichen, müssen zunächst die entsprechenden Zertifikate und Schlüssel generiert werden. IGUASU bietet im Parameter Context die Möglichkeit, Keystores zu generieren, die die benötigten Elemente enthalten.

Zum Aufruf muss das globale Menü geöffnet und nacheinander zu den Punkten Management und Parameter Context navigiert werden. Im Rahmen dieses Tutorials wird durch den Button add Parameter Context ein neuer Parameter Context erzeugt, worin danach die beiden benötigten Keystores erzeugt werden. Hierfür wird im Folgenden der Button Add Asset Parameter verwendet, durch diesen die Option Generate Private Key/Certificate ausgewählt werden kann.

Zur Einsicht der Parameter Kontexte werden die entsprechenden Berechtigungen in IGUASU benötigt. Sollten Sie diese nicht einsehen können, wenden Sie sich an Ihren Administrator.

Im Zertifikatsmanager können nun alle bereits vorhandenen Keystores in einer tabellarischen Auflistung gesehen werden. Für dieses Tutorial werden zwei neue Keystores (Private Key & Certificate) benötigt, die beide im IGUASU generiert werden können. D.h. es werden zwei Paare aus Private Key & Certificate generiert. Das ist nötig, damit beide Seiten ihre Identität beweisen können. Somit haben IGUASU und INUBIT jeweils ein Private Key & Certificate - Paar, um sich bei der Kommunikation mittels mTLS gegenseitig zu authentifizieren. Nach erfolgreicher Konfiguration soll das zu IGUASU gehörende Zertifikat auf INUBIT Seite verlinkt/hochgeladen sein, und das zu INUBIT gehörige Zertifikat auf IGUASU Seite verlinkt sein.

Austausch der Certificates zwischen INUBIT und IGUASU

Im folgenden Bild wird gezeigt, wie die Option Generate Private Key/Certificate verwendet wird für dieses Tutorial, um einen neuen Key und ein Zertifikat zu generieren.

Für Inubit Workbench Versionen vor 8.1.10 wird kein Private Key Password unterstützt, deswegen sollte bei der Erstellung das Feld dafür freigelassen werden. Ab der INUBIT Workbench Version 8.1.14 wird empfohlen ein Private Key Password zu setzen. Bewahren Sie alle Passwörter sicher auf, da Sie die Keystores im Rahmen dieses Tutorials erneut öffnen werden.

Keystore für IGUASU erstellen Keystore für INUBIT erstellen

Danach ist der neu erstellte Keystore sichtbar, über dessen Parameterdialog die entsprechenden Schlüssel heruntergeladen werden können. Zum Download des gesamten Keystores kann die Download funktion genutzt werden, die direkt im Parameterdialog erscheint.

Eine Ebene tiefer befindet sich die Editierfunktion, über die nach erfolgreicher Eingabe des richtigen Keystore Passwortes Private Key und Zertifikat getrennt heruntergeladen werden können. Zum Download des Private Keys und des Public Keys/Zertifikats kann der Schlüssel-Button verwendet werden.

Sowohl die Zertifikate als auch die Private Keys werden bei der Konfiguration der Services in IGUASU und der Konnektoren in INUBIT benötigt, was in den folgenden Abschnitten des Tutorials genauer beschrieben wird.

Teil 3: Konfiguration der Websockets und SSL Services

Nachdem die Keystores erstellt wurden, können die Services konfiguriert werden, die für die Verwendung der INUBIT-Processors benötigt werden. Im Rahmen dieses Tutorials wird hierfür eine neue Prozessgruppe in IGUASU erstellt. Zunächst wird der StandardSSLContextService benötigt, in dem die Keystore Informationen abgerufen werden, um eine sichere Kommunikation zwischen den Komponenten zu ermöglichen.

Im StandardSSLContextService muss zur Konfiguration des Keystores der Pfad angegeben werden, in dem dieser gespeichert ist. Dazu muss der Parameter Context der erstellten Prozessgruppe zugewiesen werden. Durch Klicken auf das freie Feld innerhalb der Prozessgruppe gelangen Sie zu den Einstellungen, wo Sie den richtigen Parameter Context zuweisen können.

Danach muss im StandardSSLContextService der Keystore Filename und der Truststore Filename gesetzt werden. Hierfür kann die Expression Language genutzt werden, um nicht den ganzen Pfad angeben zu müssen. Durch den Aufruf #{<Name des Keystores> wird der hinterlegte Keystore Pfad aufgerufen.

Zudem wird das definierte Keystore Passwort, welches zuvor im Fenster des Keystores definiert wurde, benötigt, um die entsprechenden Keys aufzurufen. Falls zuvor zudem ein Key Passwort, also das optionale Passwort welches am Anfang der Erstellung eines Keystores erfragt wird, hinterlegt wurde, müsste dieses ebenfalls in dem Service hinterlegt werden. Da die Keystores in IGUASU erstellt wurde, kann der Standard-Typ PKCS12 unverändert bleiben. Für den Truststore wird hier kein Zertifikat benötigt, sondern es kann einfach der INUBIT Keystore verlinkt werden.

Nach der Erstellung des SSL-Context-Services wird zudem der Service HybridWebSocketServerController benötigt, um die Websocket-Verbindung zwischen den beiden Systemen zu realisieren. Für die Konfiguration muss lediglich der Listening Port und ein SSL Context Service gesetzt werden. Als SSL Context Service kann der zuvor erstellte Service im Dropdown-Menü ausgewählt werden. Als Listening Port wird hingegen der Port benötigt, der zuvor vom Administrator für die Kommunikation von IGUASU mit dem INUBIT-System freigegeben wurde. Im Rahmen dieses Tutorials ist das Port 9003, dieser kann allerdings bei Ihnen ein anderer sein.

Mit diesen Angaben sollte der konfigurierte Service wie folgt aussehen:

Es ist nur für IGUASU notwendig, einen Port freizugeben. Für das INUBIT System ist dieser Schritt nicht erforderlich.

Mit der Erstellung beider Services können im Anschluss die benötigten Processors abschließend konfiguriert werden, die für die Kommunikation mit INUBIT benötigt werden.

Teil 4: Kommunikation INUBIT → IGUASU

In diesem Abschnitt wird erläutert, wie Nachrichten vom INUBIT an das IGUASU in der Cloud versendet werden können.

4.1 Empfangen der Daten mit dem ListenInubit-Processor

Um eine Kommunikation zwischen den beiden Systemen zu ermöglichen, müssen zunächst die entsprechenden Elemente in IGUASU erstellt werden, um die Daten empfangen und antworten zu können. Das Empfangen der Daten von einem INUBIT-System läuft hierbei über den ListenInubit-Processor, der als Startpunkt des Flows in IGUASU dienen wird.

Zur Konfiguration des Processors stehen vier Properties zur Verfügung. Als erste Einstellungsmöglichkeit muss hierbei der Listener Identifier definiert werden, der zum Differenzieren und Identifizieren der Listener genutzt werden kann.

Zusätzlich muss ein Server Controller festgelegt werden. Für diese Einstellungsmöglichkeit wird der zuvor erstellte HybridWebsocketServerController-Service verwendet, über den unter anderem die Port-Konfiguration erfolgt ist.

Des Weiteren muss ein Name für den Processor angegeben werden, der ebenfalls für die Identifizierung des Flows genutzt wird. Der Eintrag, der an dieser Stelle definiert wird, ist im späteren Verlauf bei der Konfiguration des IGUASU-Konnektors in INUBIT sichtbar und ermöglicht es dadurch, den richtigen Einstiegspunkt in der Cloud zu finden.

Zusätzlich muss eine Beschreibung hinterlegt werden, die ebenfalls in INUBIT sichtbar ist und dadurch zusätzlich das Finden des richtigen Listeners im anderen System vereinfacht.

Mit der abgeschlossenen Konfiguration sollte der Processor wie folgt aussehen:

4.2 Verarbeitung der Daten und der RespondInubit-Processor

Nachdem die Daten durch den ListenInubit-Processor in IGUASU empfangen werden können, kann die Verarbeitung erfolgen. An dieser Stelle wäre es möglich, einen komplexen Flow zu erstellen, externe Services vereinfacht zu integrieren und verschiedene Zweige der Verarbeitung zu erstellen. Um es im Rahmen dieses Tutorials allerdings simpel zu halten und den Fokus auf die Kommunikation der beiden Systeme zu legen, soll nur ein einfacher Verarbeitungsschritt erfolgen.

Für diesen Zweck wird der ReplaceText-Processor verwendet, mit dem der FlowFile Inhalt geändert werden soll. Hierbei soll der Inhalt vollständig geändert werden, weswegen die Replacement Strategy Always Replace genutzt werden soll. Als Replacement Value kann ein beliebiger Text verwendet werden, da er an dieser Stelle nur dazu dient, in INUBIT die Veränderung durch IGUASU kenntlich zu machen. In diesem Beispiel wurde The IGUASU Response at mit der aktuellen Uhrzeit eingetragen. Eine mögliche Konfiguration kann der folgenden Abbildung entnommen werden.

Um am Ende der Verarbeitung die Daten erneut an INUBIT zu versenden bzw. um generell eine Response zu erzeugen, wird der RespondInubit-Processor verwendet. Zur Konfiguration muss bei diesem Processor nur ein Listener Controller gesetzt werden. Ähnlich wie beim ListenInubit-Processor wird hierfür der HybridWebsocketServerController-Service verwendet.

Damit ist der Flow in IGUASU zum Empfangen und Verarbeiten der Daten aus INUBIT bereits abgeschlossen. An dieser Stelle sollten alle neuen Services und Processors aktiviert bzw. auf Start gestellt sein.

4.3 Konfiguration der IGUASU Konnektoren in INUBIT

Um Nachrichten von einer lokalen INUBIT-Installation an IGUASU in der Cloud zu senden, muss in INUBIT zunächst ein Workflow angelegt werden. Um die Kommunikation zwischen den beiden Systemen zu vereinfachen, bietet INUBIT für diesen Zweck den IGUASU Connector an, mit dem die Verbindung über Websockets aufgebaut werden kann.

Zur Konfiguration des IGUASU Connector in INUBIT wird benötigt:

Die URL des IGUASU Endpoints (aus Teil 1) im Format: "<URL>/hybrid".
Ein Download des IGUASU seitigen Zertifikates (aus Teil 2).
Ein Download des INUBIT seitigen Keystores (aus Teil 2).

Eine umfangreiche Beschreibung der Konfiguration dieser Elemente finden Sie in der INUBIT Dokumentation im Abschnitt IGUASU-Konnektoren.

4.4 Workflow starten und testen

Nachdem nun auch die Konfigurationen in INUBIT abgeschlossen sind, sollte der Workflow in INUBIT aktiviert, am IGUASU-Connector ein Startpunkt gesetzt und schließlich mit „Start test without file” gestartet werden. Danach sollten Informationen in IGUASU durch den ListenInubit-Processor empfangen werden, die im Anschluss als FlowFile sichtbar sind.

Nach der Veränderung des Inhalts durch den ReplaceText-Processor gelangen die Daten im Anschluss erneut zurück an INUBIT, wo diese mit dem neuen Text und den zusätzlichen Metadaten, die in Form von Attributen in IGUASU hinzugefügt wurden, dargestellt werden.

Am Ende des angelegten Flows in IGUASU sollten die Daten im Flowfile wie in der folgenden Abbildung aussehen:

Am Ende des Workflows in INUBIT sollten die Daten im Watchpoint wie in der folgenden Abbildung aussehen:

Teil 5: Kommunikation IGUASU → INUBIT

Während es in Teil 1-4 dieses Tutorials um die Kommunikation ging, die durch INUBIT gestartet wird und bei der eine Antwort durch IGUASU zurückgesendet wurde, ist es ebenfalls möglich, einen Workflow durch IGUASU zu initiieren.

5.1 IGUASU-Konnektor als Listener

Um Prozesse abzubilden, in denen das IGUASU einen INUBIT Workflow aufruft, bietet das System ebenfalls einen individuellen Processor an. Um diese Daten aus IGUASU allerdings zu empfangen, muss zunächst ein IGUASU Konnektor in INUBIT erstellt werden, an den die in IGUASU generierten Daten gesendet werden können. Dieser wird genauso konfiguriert wie in Teil 4.3 dieses Tutorials, mit dem Unterschied, dass der Connector Type auf Input Connector gestellt werden soll, da Daten aus IGUASU empfangen werden sollen. Ähnlich wie zuvor finden Sie umfangreiche Informationen zur Konfiguration im Abschnitt IGUASU-Konnektoren.

5.2 Daten übertragen mit dem InvokeInubit-Processor

Nachdem die Konfiguration in INUBIT abgeschlossen ist und ein Listener zur Verfügung steht, an den Daten übertragen werden können, kann die Konfiguration in IGUASU erfolgen. Zum Senden von Anfragen vom IGUASU und INUBIT kann der InvokeInubit-Processor genutzt werden. Um das im Rahmen dieses Tutorials zu demonstrieren, müssen zunächst Daten in IGUASU generiert werden, die an das INUBIT System übertragen werden können.

Zur Erstellung eines einfachen FlowFiles kann wie in anderen Tutorials der GenerateFlowFile-Processor verwendet werden. Um die Übertragung der Daten im vollen Umfang abzubilden, sollen hierbei ein eindeutiger Inhalt und ein Attribut für das entsprechende FlowFile erstellt werden.

Daher wird zum einen die Option Custom Text konfiguriert, für die hier der folgende Text eingefügt wird: This is the text from IGUASU at ${now()}.

Zudem kann ein Attribut festgelegt werden, das als Metadata ebenfalls an INUBIT übertragen wird und im System im Anschluss als Variable zur Verfügung steht. Für diesen Zweck kann eine dynamische Property verwendet werden, um ein Attribut zu erstellen. Als Attribut eignet sich beispielsweise die eindeutige ID des FlowFiles, sodass Value with UUID: ${UUID()} eingetragen werden kann.

Die vollständige Konfiguration des GenerateFlowFile-Processors sieht im Anschluss wie folgt aus:

Anschließend wird der InvokeInubit-Processor erstellt, mit dem diese generierten Daten an INUBIT übertragen werden können. Zur Konfiguration muss zunächst erneut ein Listener Controller definiert werden, für den erneut der zuvor erstellte HybridWebSocketServerController genutzt wird.

Als Nächstes muss die Choose Listener-Option konfiguriert werden, wobei zwei unterschiedliche Optionen zur Verfügung stehen: Zum einen kann die Möglichkeit Use 'Listener Identifier' field verwendet werden, um die ID des Listeners in INUBIT festzulegen, an die das FlowFile übertragen werden soll.
Wenn allerdings bereits eine Verbindung zwischen den beiden Systemen besteht, sollten alle verfügbaren Listener im DropDown-Menü zur Auswahl stehen. Hier z.B. der "IGUASU Listener 1" welcher den Namen des zugehörigen IGUASU Connectors in INUBIT trägt.

Falls Ihnen diese Listener-Auswahl nicht zur Verfügung steht, empfiehlt es sich, zunächst Teil 4 dieses Tutorials abzuschließen, da dort eine Verbindung zwischen beiden Systemen aufgebaut wird. Außerdem sollte der Workflow in INUBIT publiziert und aktiviert sein, um bei bestehender Verbindung die Listener-Auswahl angezeigt zu bekommen.

Zudem können Sie optional die Einstellung Target unavailable konfigurieren, wodurch das Verhalten bei Verbindungsproblemen definiert werden kann. Hierbei bietet sich die Option Route in "unavailable" Relation an, durch die ein Zweig mit weiteren Verarbeitungsschritten definiert werden kann. Im Rahmen dieses Tutorials soll an dieser Stelle ein Trichter eingefügt werden, der als Endpunkt dienen soll.

Der finale Workflow sieht im Anschluss wie folgt aus:

Wenn der GenerateFlowFile-Processor nun mit Run Once ausgeführt wird, werden die definierten Daten generiert und im Anschluss an den erstellten Listener in INUBIT versandt.