Hi Joe and others,

I see a high-level problem with searchable documentation for Processors in two areas.

1.  The current new-processor-dialog shown during Add Processor has a search (filter) capability, but it only searches through the Tags and Type, not Property Names, PropertyDescriptor, or even AllowableValue's description text.  That's a shame, because doing a search for "line" brings up nothing.

Solution:  I think a more comprehensive Search/Filter that also searches PropertyDescriptor and AllowableValue's would be much better.  Showing a more expanded Add Processor dialog that also shows the description text for the Properties and AllowableValues descriptions as well.

Wanted Position: Make the dialog show more complete info for a Processor when a user clicks on a processor.

2. AllowableValue descriptions are not ideally displayed on the docs page, but instead are hidden in a small blue ? circle next to each value title, such as https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi.processors.standard.RouteText/index.html has Matching Strategy with AllowableValue of Satisfies Expression, but key information about it having variables Line and LineNo are hidden completely and should not be. Its part of the full documentation, and all documentation should be shown to a user visiting the docs pages.

Solution:  Sub table the Allowable Values column on nifi-docs and add a column for "Allowable Values description" next to each AllowableValue (just as the source code does).

I have added these comments to JIRA issue for enhanced filter on Add Processor here:


On Mon, Jun 6, 2016 at 10:47 AM, Joe Percivall <joepercivall@yahoo.com> wrote:
For number one, you can also use RouteText[1] with the matching strategy "Satisfies Expression". Then as a dynamic property use this expression "${lineNo:le(10)}". This will route first 10 lines to the "matched" relationship (assuming "Route to each matching Property Name" is not selected). This option also allows you to route those unmatched lines elsewhere if you need (if not just auto-terminate the "unmatched" relationship).

The for number two, instead of ReplaceText, you could also use RouteText. Set the matching strategy to "Matches Regular Expression". Then set the dynamic property to match everything and end with "unambiguously" (an example being "((\w|\W)*unambiguously)"). This will route all the text that matches the Regex apart from the end of the file and gives you the option to route the ending text differently if needed.

[1] https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi.processors.standard.RouteText/index.html

Joe- - - - - -
Joseph Percivall
e: joepercivall@yahoo.com

On Sunday, June 5, 2016 4:41 AM, Leslie Hartman <lphartm@nsa.gov> wrote:


    The modifyBytes processor would be the best if it would allow
   one to
specify the bytes to keep. I could calculate the number of bytes to
but when I try and place a variable in the End Offset it says it is
   not in the
<Data Size> <Data Unit> format.

    As for SegmentContent and SplitText I have tried both of these.
   The problem
is that it just takes the original file a splits it in to a bunch of
   little files. So if I wanted
say 256 Bytes of a 30 meg file, after running out of memory it would
   give me
125 Million 829 Thousand 119 Files to get rid of.

    For the 2nd case ReplaceText should work, I'm just having
   problems getting
the correct syntax. If someone could provide an example of the
   correct syntax
I would appreciate it.

    Thank You.

    Leslie Hartman

Matthew Clarke wrote:

You may also want to look at using the modifyBytes processor for number 1.
>On Jun 4, 2016 1:49 PM, "Thad Guidry" <thadguidry@gmail.com> wrote:
>For your 1st case, you can use either SegmentContent by your 256 bytes (or perhaps you can even use SplitText)
>>For your 2nd case, you can use ReplaceText