Metro-Processors
Mit den Metro-Processors wird die grundsätzliche Möglichkeit eröffnet FlowFiles direkt von einem Processor (PutMetro) an einen anderen (GetMetro/ExitMetro) zu leiten, ohne diese mit einer Connection verbinden zu müssen. Dies eröffnet in verschiedenen Szenarien ganz neue Möglichkeiten der Umsetzung. Diese verschiedenen Szenarien werden hier beschrieben:
Zugriff auf ein FlowFile aus einem früheren Schritt im Flow (GetMetro)
Man hat des Öfteren die Notwendigkeit, ein FlowFile aus einem früheren Verarbeitungsschritt später noch einmal zu benötigen. Es steht aber nur das FlowFile zur Verfügung, das aus dem letzten Verarbeitungsschritt hervorging.
Um dieses Problem zu lösen, gibt auch folgende Möglichkeiten, die hier zunächst mit ihren Nachteilen dargestellt werden, bevor wir die Metro Lösung zeigen:
Bestehende Lösungsansätze
-
Daten in Attribute schreiben, die dann bis zur Verwendung mitgeschleift werden
-
In Attributen sollten keine großen Datenmengen stehen
-
Man muss die Daten in Attribute konvertieren und dann möglicherweise wieder zurück in den Content schreiben, wenn der verwendete Prozessor das so verlangt
-
Attribute werden immer in jeden Processor mitgegeben und potenziell verarbeitet
-
-
Einen Bypass legen - z.B. mit ForkEnrichment/JoinEnrichment oder MergeContent
-
Das ist primär für eine Anreicherung von strukturierten Inhalten wie z.B. JSON gedacht
-
Die Struktur ist daher dann eine andere und man muss potenziell noch einmal transformieren
-
Das Diagramm wird aufgebläht und man muss eine Verbindung von dem ursprünglichen Vorkommen bis zur Verwendung ziehen, was viel später sein kann
-
-
Ablage in einem Dritt-System
-
Man benötigt ein Drittsystem
-
Man muss sich selbst um das Aufräumen kümmern bzw. sicher sein, dass die Daten genauso transaktional vorhanden sind, wie im Flow selbst
-
Erschwert Deployments/Staging
-
Lösung mit PutMetro/GetMetro
Das FlowFile, das man später noch benötigt, wird zusätzlich zur normalen Verarbeitung zusätzlich vor einen PutMetro Processor in die Queue geschrieben. Dieser Processor hat einen MetroLineController Service, den er mit dem späteren GetMetro Prozessor teilt – hierüber wird sozusagen die Untergrundbahn zwischen diesen Processors gelegt, die man im Diagramm nicht direkt sieht.
Kommt nun das originale FlowFile zum GetMetro Processor fragt dieser den mit dem Service verbundenen PutMetro Processor nach einem FlowFile in seiner Queue, das den gleichen Wert eines Attributes hat, wie das originale FlowFile. Dies ist die relevante Konfiguration am GetMetro – der Name des Correlations-Attributes, aus dem dieser Zusammenhang hergestellt werden kann.
Im Ausgang des GetMetro Processors kommt nun das FlowFile heraus, das vor dem PutMetro Processor liegt. Hier wird es aus der Queue genommen (und ausserdem in die success Relation des PutMetro, wenn diese eine Verbindung haben sollte).
|
Wurden die zwischengespeicherten FlowFiles bereits durch einen GetMetro-Processor abgerufen, sind diese nicht mehr verfügbar. Dadurch können Fehler bei weiteren Zugriffsversuchen entstehen. |
An den Processors können Dynamic Properties gesetzt werden, die dann als Attribute zu den FlowFiles hinzugefügt werden.
Vorteile dieser Lösung
-
Das Diagramm bleibt übersichtlich
-
Man benötigt keien externen Systeme
-
Alles wird mit Flow-Mitteln gelöst
-
Die Transaktionalität bleibt bestehen – das FlowFile vor dem PutMetro wird erst entfernt, wenn das FlowFile von dem GetMetro weitergegeben wurde
-
Die Geschwindigkeit der Verarbeitung ist hoch
-
Es können Grenzen von Process Groups überwunden werden
Nachteile der Lösung
-
Gegenüber einem Bypass sieht man hier nicht direkt den Zusammenhang, wenn man auf das Diagram guckt
-
Es können Grenzen von Process Groups überwunden werden … dies ist neben dem Vorteil eben auch ein Nachteil, wenn die Nutzung darüber zu unübersichtlichen Flows führt. Das sollte bedacht werden.
Aufruf eines anderen Flows (ExitMetro)
Wenn ich an vielen Stellen eines Flows einen anderen Flow aufrufen möchte, gibt es dafür bisher folgende Möglichkeiten mit ihren Nachteilen:
-
Modellierung über eine (versionierte) Process-Group, die an den Stellen immer direkt eingebunden wird
-
Relativ aufwändig in der Modellierung und Pflege
-
Jede Subprozessgruppe ist eine eigene Instanz und hat z.B. auch ihre eigenen Qeueus und Reihenfolgen → es wird also nicht wirklich EIN anderer Flow aufgerufen, sondern viele gleiche
-
-
Aufruf über externe Möglichkeiten wie z.B. HTTP/REST
-
Es wird über ein externes Protokoll gegangen, was potenziell langsam ist und Authentifizierungen benötigt
-
Die Übergabe von Content+Attributen muss berücksichtigt werden
-
Die Flow Engine wird verlassen
-
Die Provenance ist schwieriger zu verfolgen
-
Lösung mit PutMetro/ExitMetro
Über den PutMetro und einen über den MetroService verbundenen ExitMetro wird eine "Untergrundbahn" angelegt. Es können dabei auch viele PutMetro auf einen ExitMetro verweisen. Sobald ein FlowFile in den PutMetro geht, wird es direkt an den ExitMetro geleitet und kommt dort aus der "success" Relation.
An dem PutMetro können über Dynamic Properties noch Attribute gesetzt werden.
Ein typischer Anwendungsfall für dieses Konstrukt ist z.B. ein Prozess-Logging in ein externes System wie das Business Process Center. An diversen Stellen im Flow möchte man Daten (aus Attributen und/oder dem Content) gleichförmig in das BPC loggen, um den Staus des übergeordneten Business Prozesses festzuhalten. Hinter dem ExitMetro liegt in diesem Beispiel ein Processor, der den Status in das BPC schreibt.
How-To
Ein weiteres Anwendungsbeispiel der beschriebenen Processors befindet sich zudem im Abschnitt How-Tos unter Metro.
