Häufig gestellte Fragen

Allgemein

Wie unterscheiden sich INUBIT und IGUASU voneinander?

Während wir mit INUBIT ein Integrations-Werkzeug mit einem Schwerpunkt im On-Premise Bereich anbieten, liegt der Fokus mit IGUASU in der Cloud. Da IGUASU als Service zur Verfügung steht, kann es sehr schnell und einfach für kleine Projekte verwendet werden, ohne dass ein eigenes System installiert und gewartet werden muss.

Des Weiteren bietet es den Vorteil, dass die Skalierung in der Cloud auch dank der konsequenten Nutzung modernster Technologien wie Kubernetes einfach umsetzbar ist, wenn die Anforderungen ebenfalls steigen sollten. Die Nutzungspläne für IGUASU sind entsprechend flexibel und ermöglichen die Anpassung an unterschiedliche Szenarien.

Während INUBIT viele Konnektoren und Möglichkeiten im Bereich der Legacy-Systeme anbietet, besteht bei IGUASU zudem die Möglichkeit, viele Services und Systeme vereinfacht anzubinden und abzudecken, die in der Cloud verfügbar sind. Durch die Möglichkeit einer hybriden Verwendung von INUBIT, IGUASU und BPC lassen sich zusätzlich vielfältige Aufgabenbereiche abdecken.

Umgebungsvariablen

Die Umgebungsvariablen enthalten relevante Verzeichnispfade für IGUASU:

IGUASU_PATH
Der Pfad, in dem IGUASU installiert ist
IGUASU_DRIVER_PATH
Der Pfad, in dem Datenbanktreiber im JAR(Java Archive) Format abgelegt werden können
IGUASU_KEYSTORES_PATH
Der Pfad, in dem Zertifikatsdateien im JKS/PKCS12 Format gespeichert werden können
IGUASU_PERSISTENCE_PATH
Der Pfad, in dem Daten persistent gespeichert werden können (insbesondere im Kubernetes Umfeld wichtig)

Diese Umgebungsvariablen können bei On-Premise Installationen in der Datei iguasu-env.sh im Pfad iguasu/bin/ angepasst werden

Prozessoren

Was tue ich, wenn sich ein Prozessor nicht starten/stoppen lässt?

Wird ein Prozessor gestoppt, wird die aktuell laufende Task nicht unterbrochen. Stattdessen wird versucht, diese zu beenden. Angezeigt wird dies dadurch, dass der Prozessor den Status "STOPPED" erhält und in der linken unteren Ecke die Anzahl der laufenden Tasks steht.

Unter Umständen kann es notwendig sein, diese noch laufende Task abzubrechen. Im Kontextmenü des Prozessors erscheint nun der Menüpunkt "Terminate". Wird er ausgewählt, dann wird der laufende Task abgebrochen und das dazugehörende FlowFile in die Queue zur erneuten Verarbeitung wieder eingereiht.

Welche Daten werden bei einer isolierten Testausführung eines Prozessors verwendet?

Grundsätzlich werden für die isolierte Testausführung eines Prozessors immer die Daten verwendet, die im Data Panel in den Bereichen Attributes, sowie Input Data stehen.

Es existieren verschiedene Möglichkeiten, Daten in diese Felder einzufügen:

Man lässt sich zu einem Prozessor die Tabelle der Events vorhergehender Ausführungen anzeigen. Wird nun eines der angezeigten Events ausgewählt, werden die dort geflossenen Daten in das Data Panel geladen. Diese werden dann bei der Testausführung dieses Prozessors verwendet.
Daten werden über Copy/Paste eingefügt. Diese Daten können entweder
- aus den Ausführungen eines anderen Prozessors (siehe 1.),
- aus den Daten in einer Queue oder
- aus dem Ergebnis einer Testausführung (eines anderen Prozessors) kommen.
Die Daten und Attribute werden von Hand manuell eingetragen.

Ab IGUASU Version 2.2.1 ist es möglich, das serverbasierte Copy von Daten aus dem Output Panel zu verwenden.

Wieso funktionieren die Filesystem-Prozessoren nicht?

Die Nutzung von Filesystem-basierten Prozessoren wie beispielsweise der GetFile-Prozessor ist insbesondere auf dem geteilten Playground nicht vorgesehen. Besteht eine eigene IGUASU-Instanz, können die Rechte hier anders vergeben werden.

Für die Nutzung von JKS Dateien und weiteren "Files" ist eine Unterstützung durch IGUASU vorgesehen, sodass man diese von der Oberfläche aus verwalten kann. Für JDBC-Treiber besteht bereits die Möglichkeit, diese über die Oberfläche hochzuladen. Im Playground ist dies aktuell der Admin-Rolle vorbehalten.

Was ist die "Metro"?

Die Metro-Prozessoren bieten eine Möglichkeit, FlowFiles zu verwenden (GetMetro, ExitMetro), die vor einem anderen Prozessor (PutMetro) in der Queue warten. Hierbei ist es nicht relevant, an welcher Stelle des Flows diese Prozessoren sich befinden, da diese mit den entsprechenden Services verknüpft werden.

Damit hat man eine Möglichkeit, Daten zu Routen, die neben den im Diagramm gezogenen Verbindungen besteht. Neben den sichtbaren Datenflüssen oder “Bahnen”, existiert also ein nicht sichtbarer Datenfluss bzw. eine “Untergrundbahn”. Dadurch ergibt sich die Namensgebung als Metro, die von der Pariser Untergrundbahn hergeleitet ist.

Services

Warum werden Services auf Prozessgruppen-Ebene angelegt und nicht für einzelne Prozessoren?

Services hängen an Prozessgruppen und können von allen Prozessoren bzw. Services in dieser und tieferen Prozessgruppen verwendet werden. Damit können die entsprechende Logik oder Systemverbindungen für multiple Prozessoren und Services bereitgestellt werden und es wird eine vorteilhafte Wiederverwertbarkeit erreicht.

Ein sehr gutes Beispiel für die Nützlichkeit dieses Prinzips sind Datenbankverbindungen. Sowohl die Konfiguration der Verbindung als auch der Pool der Connections kann dadurch durch viele Prozessoren genutzt werden, ohne dass diese wiederholt konfiguriert werden müssen.

Des Weiteren gibt es Services (z.B. HybridRESTServerController), die eine Schnittstelle nach außen bereitstellen und damit einen Port belegen. Ein Port kann nicht von mehreren Services verwendet werden, weshalb bei mehrfacher Benutzung der selbe Sevice verwendet werden muss.

FlowFiles

Was bedeuten DROP-Events für FlowFiles in der Event-Tabelle

Das DROP-Event zeigt im Allgemeinen an, dass ein FlowFile den Prozessor verlassen hat. Das ist bei einem beispielsweise der Fall, wenn die Daten mit einem InvokeHTTP-Prozessor versendet werden, da das FlowFile dann in ein anderes System geschickt wird. Dadurch werden die zugehörigen Daten intern gelöscht und es wird für die einzelnen FlowFiles, die durch die Prozessoren durchgelaufen sind, ein Drop-Event angezeigt.

REST/HTTP-Endpunkte

Wie kann ich HTTP-Endpunkte absichern?

Endpunkte werden über HandleHttpRequest/HandleHttpResponse Prozessoren abgebildet. Hier sollte immer HTTPS verwendet werden, wozu ein SSL Context Service konfiguriert wird. Wird hier der vorkonfigurierte Service für eingehende Requests verwendet, kann der Endpunkt von einem Browser sicher aufgerufen werden.

Mutual TLS (mTLS)

Für Absicherung von Endpunkte, die als Services dienen und automatisiert aufgerufen werden, empfehlen wir eine beidseitige Verwendung von Zertifikaten. Die Zertifikate können bei IGUASU im Bereich Certificates im Management-Bereich verwaltet werden.

Die eigenen Zertifikate werden dann in einem eigenen SSL Context Service konfiguriert. Dieser wird dann im Prozessor verwendet. Die aufrufende Seite muss entsprechend ebenfalls mit den Zertifikaten konfiguriert werden.

Basic Authentication

Diese Art der Authentifizierung wird nicht mehr empfohlen! Da es aber Lagacy-Systeme möglicherweise erforderlich machen sie zu verwenden, ist sie hier aufgeführt.

In diesem Beispiel wird die Basic Authentifizierung in einem RouteOnAttribute-Prozessor überprüft, wobei hier Benutzername und Passwort fest hinterlegt sind. Diese könnten ebenso vorher an anderer Stelle gelesen werden und als Attribute an den RouteOnAttribute-Prozessor übergeben werden. Trifft die Bedingung zu, wird das FlowFile an den Ausgang mit dem Namen des Properties übergeben.