Konfigurationsbereich

Entsprechend der Typen der Daten gibt es Auswahllisten, Checkboxen und Textfelder. Notwendige Felder sind mit einem * markiert.

Erlauben die Felder die Nutzung der Expression Language, wird dies durch ein $ angezeigt. Felder, die eine Expression Language erlauben, zeigen den Wert der Ausführung in einer gestrichelten Box unterhalb des Textfeldes an. Diese wird aber nur angezeigt, wenn der Wert von dem Eingabewert abweicht (Daten aus gewählten Ausführungen werden bei der Evaluierung berücksichtigt). Änderungen bei der Eingabe der Properties werden on-the-fly ausgewertet und das Ergebnis entsprechend angezeigt.
Ist an einem Feld kein Wert gesetzt, ist dieses hingegen leicht ausgegraut.
Zusätzlich werden Warnungen unter den Eingabefeldern angezeigt, sollten die getätigten Angaben fehlerhaft sein oder fehlen.

Einige Prozessoren unterstützen neue, Nutzer-erstellte Properties, welche durch den -Button angelegt werden. Diese dynamischen Angaben können für unterschiedliche Zwecke genutzt werden. Sie können beispielsweise eingesetzt werden, um beim QueryRecord-Prozessor neue Filteroptionen hinzuzufügen oder beim InvokeHTTP-Prozessor neue HTTP-Header zu ergänzen.
Wofür die dynamischen Properties bei einzelnen Prozessoren verwendet werden können, ist bei eingeschalteten Tooltips bei dem ausgewählten Prozessor im Konfigurationsbereich beschrieben. Sollten die dynamisch angelegten Properties Ergebnisse durch z.B. eine Query generieren, dann stehen die angelegten Properties ebenfalls als Relation zu anderen Elementen im Diagramm zur Verfügung.

Ist an der Prozessgruppe, in welcher die Prozessoren liegen, ein Parameter-Kontext gesetzt, können den Properties der Prozessoren die Parameter aus diesem Kontext zugeordnet werden. Parameter-Kontexte werden in den zentralen Settings konfiguriert und sind im Abschnitt Parameter Contexts ausführlicher beschrieben.

Für den Editor existieren ebenfalls individuelle Funktionen, die über die Toolbar aufgerufen werden können. Genau wie in der Prozessor-Properties-Sicht kann der Prozessor über den -Button isoliert ausgeführt werden. Die Ergebnisse des Tests können mit dem anliegenden Pfeil-Button ein- oder ausgeblendet werden.

Darüber hinaus stehen weitere Funktionen in einer dritten Toolbar-Leiste zur Verfügung, die in der folgenden Tabelle aufgeführt sind.

Der angezeigte Name des Prozessors. Sollte im besten Fall genutzt werden, um die Übersichtlichkeit der angelegten Flows zu verbessern.

Die Penalty Duration ist ebenfalls eine Property, die für jeden Prozessor verfügbar ist und standardmäßig auf 30 sec gesetzt ist.
Diese Wartezeit bezieht sich auf ein bestimmtes FlowFile. Es werden also 30 Sekunden gewartet, bevor ein neuer Versuch unternommen wird, genau dieses FlowFile zu verarbeiten.

Ein Beispiel wäre ein PutFile-Prozessor, der ein FlowFile nicht auf die Festplatte schreiben kann, weil eine Datei mit diesem Namen bereits existiert. Möglicherweise entfernt ein zweiter Prozess parallel diese Files, wodurch das Schreiben nach einer bestimmten Zeit erneut funktioniert.

Ein Yield kann von einem Prozessor ausgelöst werden. Yield Duration ist hierbei die Property an jedem Prozessor und ist per Default auf 1 sec eingestellt. Dies ist die Zeit, die der Prozessor nach einem internen (vom Prozessor gefangenen) Fehler nicht mehr ausgeführt werden soll.

Ein Beispiel ist ein FTP-Prozessor, der den eingestellten FTP-Server nicht erreichen kann, es allerdings abzusehen ist, dass der Server nach kurzer Zeit wieder erreichbar sein wird (z.B. instabiles Netz).

Neben dem Yield an jedem Prozessor für die Fehler, die dieser Prozessor selbst erwartet und versteht, gibt es zudem einen zentralen Yield. In einem Fall, in dem durch einen Prozessor eine Exception generiert wird, die nicht erwartet oder behandelt wurde, wird durch NiFi ein zentraler Timer von 30 Sekunden gestartet (einstellbar mit nifi.administrative.yield.duration), bis der Prozessor erneut ausführbar ist.

Diese Option ermöglicht die Konfiguration des Levels, auf dem Meldungen vom Prozessor generiert werden. Die ausgewählten Level können genutzt werden, um Warnmeldungen zu sortieren und dadurch eine verbesserte Übersicht zu ermöglichen.

Mit dieser Einstellung kann angepasst werden, wie viele Threads gleichzeitig diesen Prozessor ausführen sollen.

Zusätzlich befindet sich in den zentralen Einstellungen in den Settings der Maximum Timer Driven Thread Count. Weitere Informationen hierzu finden Sie im Abschnitt Allgemeine Einstellungen

Prozessoren haben typischerweise ein Scheduling nach Zeitintervall (Scheduling Strategy = Timer driven). Der Defaultwert ist dabei auf Run Schedule = 0 sec gesetzt.
Die Prozessoren können somit ohne Unterbrechung auf neue FlowFiles warten. Allerdings existiert zudem ein globales Property in den nifi.properties: nifi.bored.yield.duration=10ms, wodurch diese Zeit minimal eingeschränkt wird. Somit wird zwischen den Aufrufen diese festgelegte Zeit gewartet, um das System nicht zu stark auszulasten. Bei Prozessoren, die keine hohe Aktivität aufweisen (beispielsweise bei Szenarien, in denen die Latenz kein Problem ist), kann der Wert ggf. weiter erhöht werden.

Zusätzlich besteht neben dem timer driven Scheduling die Möglichkeit, die Intervalle mit einem CRON String festzulegen.

Mit dieser Option wird festgelegt, auf welchen Knoten eines Clusters der Prozessor ausgeführt werden soll. Die Möglichkeit, Cluster zu erstellen, wird in einer späteren Version von IGUASU zur Verfügung gestellt.

Die Run Duration Property wird nicht von allen Prozessoren unterstützt. Es dient dazu, dem Prozessor mitzuteilen, dass er einen Batch an FlowFiles zusammen verarbeiten soll. Dies ist insbesondere sinnvoll bei einer großen Anzahl kleiner FlowFiles, deren Einzelausführung kurz ist.
Der Thread arbeitet für die angegebene Zeit ohne Thread-Wechsel und es wird nur einmal für alle FlowFiles committed. Je nach Szenario kann das Erhöhen der Run Duration eine signifikante Verbesserung der Performance auslösen.

In den Settings der Prozessoren können für vorhandene Verbindungstypen, wie beispielsweise Success oder Failure, Retry-Optionen konfiguriert werden. Mit der Einstellung der Anzahl der Retry-Versuche, kann festgelegt werden, wie oft ein FlowFile von einem Prozessor zur Wiederverarbeitung aufgenommen werden soll. Falls die Wiederholungsversuche ebenfalls nicht erfolgreich abgeschlossen werden können, wird der FlowFile anderweitig weitergeleitet oder fallengelassen.

Die Back Off Policy ermöglicht die Konfiguration der Verarbeitung von weiteren Daten, während ein FlowFile sich im Retry befindet. Hierbei kann zwischen der Option Penalize, bei der weitere FlowFiles trotz Retry verarbeitet werden können, und Yield, mit dem keine anderen Daten verarbeitet werden bis alle Retries abgeschlossen sind, gewählt werden.

In Kombination mit der gewählten Penalty- und Yield-Duration, wird die Dauer der Ausführung fortlaufend erhöht. Um für diese Dauer ein Limit zu definieren, kann die Maximum Back Off Period Option genutzt werde, um eine Grenze für den Zeitrahmen festzulegen.

In diesem Bereich sind alle vorhandenen Beziehungstypen des Prozessors aufgelistet, die zur Verbindung mit anderen Elementen im Diagramm genutzt werden können.

Jede aufgelistete Beziehungsart muss entweder in einer ausgehenden Verbindung zu einem anderen Element oder durch eine automatisierte Terminierung adressiert werden. Zusätzlich besteht für die Beziehungsarten die Möglichkeit, Wiederholungsversuche durch die Retry-Option zu starten.