Configuration area

There are selection lists, checkboxes and text fields depending on the type of data. Required fields are marked with an *.

If the fields allow the use of the Expression languagethis is indicated by a $.

Fields that allow an expression language display the value of the execution in a dashed box below the text field. However, this is only displayed if the value differs from the input value (data from selected executions is taken into account during evaluation). Changes made when entering the properties are evaluated on-the-fly and the result is displayed accordingly.

If no value is set for a field, it is slightly greyed out.
In addition, warnings are displayed below the input fields if the information entered is incorrect or missing.

Some Processors support new, user-created properties, which are created using the button. These dynamic properties can be used for various purposes. They can be used, for example, to add new filter options to the QueryRecord Processor or to add new HTTP headers to the InvokeHTTP Processor.
What the dynamic properties can be used for with individual Processors is described for the selected Processor in the configuration area when the tooltips are switched on. If the dynamically created properties generate results, e.g. through a query, then the created properties are also available as a relation to other elements in the Diagram.

If a Parameter Context is set for the Process Group in which the Processors are located, the properties of the Processors can be assigned the Parameters from this context. Parameter Contexts are configured in the central settings and are described in the section Parameter Contexts section.

Within the Config Panel, you will also see detailed documentation regarding how to use the processor and each property’s function.

The first paragraph provides general information regarding the processor’s purpose and technical aspects worth knowing when deciding whether the processor is suitable for your intended use.

Some processors will even provide links to "Additional Details" and "Use Cases" where the processor’s functionality and possible uses are explained in more detail.

In the bottom of the Config Panel there is more information about the processor, including any required user rights, consumption of system resource to consider, how dynamic properties are used, state management, and which attributes are read and written by the processor.

If there are any processors that are closely related with the processor, these will also be shown under "Related Components". Processors listed here can quickly be added to the diagram by drag-and-drop.

There are also individual functions for the Editor that can be called up via the toolbar. Just as in the Processor properties view, the Processor can be executed in isolation via the button. The results of the test can be shown or hidden using the adjacent arrow button.

In addition, further functions are available in a third toolbar bar, which are listed in the following table.

The displayed name of the Processor. Should ideally be used to improve the clarity of the created flows.

The Penalty Duration is also a property that is available for each Processor and is set to 30 sec by default.
This waiting time refers to a specific FlowFile. It therefore waits 30 seconds before a new attempt is made to process exactly this FlowFile.

An example would be a PutFile Processor that cannot write a FlowFile to the hard disk because a file with this name already exists. It is possible that a second process removes these files in parallel, which means that writing works again after a certain time.

A Yield can be triggered by a Processor. Yield Duration is the property on each Processor and is set to 1 sec by default. This is the time that the Processor should no longer be executed after an internal error (caught by the Processor).

An example is an FTP Processor that cannot reach the set FTP server, but it is foreseeable that the server will be accessible again after a short time (e.g. unstable network).

In addition to the yield at each Processor for the errors that this Processor itself expects and understands, there is also a central yield. In a case in which an exception is generated by a Processor that was not expected or handled, NiFi starts a central timer of 30 seconds (can be set with nifi.administrative.yield.duration) until the Processor can be executed again.

This option allows you to configure the level at which messages are generated by the Processor. The selected levels can be used to sort warning messages and thus provide an improved overview.

This setting can be used to adjust how many threads should execute this Processor simultaneously.

In addition, the central settings in the settings of Maximum Timer Driven Thread Count. Further information on this can be found in the section General settings

Processors typically have scheduling by time interval (Scheduling Strategy = Timer driven). The default value is set to Run Schedule = 0 sec.
The Processors can therefore wait for new FlowFiles without interruption. However, there is also a global property in the nifi.properties: nifi.bored.yield.duration=10ms, which minimally limits this time. This means that this defined time is waited between calls so as not to overload the system. For Processors that do not have a high level of activity (for example in scenarios in which latency is not a problem), the value can be increased further if necessary.

In addition to timer-driven scheduling, it is also possible to define the intervals with a CRON string.

This option is used to specify the nodes of a cluster on which the Processor is to be executed. The option to create clusters will be made available in a later version of IGUASU.

The Run Duration property is not supported by all Processors. It is used to tell the Processor that it should process a batch of FlowFiles together. This is particularly useful for a large number of small FlowFiles whose individual execution is short.
The thread works for the specified time without thread switching and it is only committed once for all FlowFiles. Depending on the scenario, increasing the run duration can trigger a significant improvement in performance.

Retry options can be configured for existing connection types, such as Success or Failure, in the Processors settings. By setting the number of retry attempts, you can define how often a FlowFile should be picked up by a Processor for reprocessing. If the retry attempts cannot be completed successfully either, the FlowFile is forwarded elsewhere or dropped.

The Back Off Policy allows you to configure the processing of further data while a FlowFile is in retry. Here you can choose between the option Penalize, where further FlowFiles can be processed despite retry, and Yield, where no other data is processed until all retries have been completed.

In combination with the selected Penalty and Yield duration, the duration of the execution is continuously increased. To define a limit for this duration, the Maximum Back Off Period option can be used to set a limit for the time frame.

This area lists all existing relationship types of the Processor that can be used to connect to other elements in Diagram.

Each relationship type listed must either be addressed in an outgoing connection to another element or by automated termination. In addition, it is possible to start retries for the relationship types using the retry option.