Accessing the name of a Processor programatically

[Richard Miskin <r....@gmail.com>]

Hi,

I’ve a use case where each instance of a custom Processor on my flow represents a different instance of a remote system. The message produced by my Processor needs to include the remote system name, and currently I’m using a PropertyDescriptor to allow this to be configured. This means that the name is effectively set twice, once to be shown in the UI and once to be used by my Processor internally. This leads to the possibility of the two values being inconsistent which is likely to confuse people in future.

Is there any way I can access the name of a Processor from within an AbstractProcessor?

Cheers,
Richard

Re: Accessing the name of a Processor programatically

[Richard Miskin <r....@gmail.com>]

For my current need providing a getName() method on Processor would do the job, but 
maybe a more flexible solution would be to provide an expression language to function
to provide the display name of the component. That function could be used in a
Processor property which would, hopefully, make it explicit that the display name
is being relied upon. Is it possible to do something like this via expression language?

Aldrin’s idea of allowing the Processor name to be set via something like expression
language seems like it could be useful, but it’d need expression language to act differently
when used for the Processor name vs properties. Might that be confusing?

Cheers,
Richard


> On 21 Feb 2016, at 23:18, Matt Burgess <ma...@gmail.com> wrote:
> 
> I think Aldrin's points about being able to use properties for the UI are
> pretty cool, but I also think there's room for the inverse (which is what I
> think the OP meant). The name of the processor is tied to its instance
> (though not guaranteed unique between instances, and definitely not unique
> between tasks within an instance). I would think any
> property/attribute/value associated with an instance of a processor should
> be available to it (so if name has been a "UI field", it would be no
> longer). The tradeoff, then, is when you have to name your processor a
> certain way to get it function correctly. I think this should not be the
> normal NiFi way, but should be available with the caveat that the
> documentation should reflect such a dependency. Sometimes when you're given
> enough rope to hang yourself, you build a bridge with it. Other times you
> just get dead :-P
> 
> Regards,
> Matt
> 
> On Sun, Feb 21, 2016 at 3:25 PM, Aldrin Piri <al...@gmail.com> wrote:
> 
>> I think the functionality is certainly useful and like the deduplication,
>> certainly a great idea to be a bit more efficient.  However, I find myself
>> a bit hesitant to drive processor configuration via the processor UI
>> fields.  At first thought, I think something along the lines of EL that
>> could make use of processor properties for UI components like name and
>> potentially notes could be helpful.  In this case, the processor UI could
>> have its name be defined as something akin to "Retrieve data from ${url}
>> every ${run.time}"
>> 
>> Obviously some caveats would be needed such as handling the case of a
>> property that is also using EL likely wouldn't work, but personally find
>> driving presentation from processor logic to be more intuitive than the
>> inverse.
>> 
>> On Sun, Feb 21, 2016 at 7:45 AM, Joe Witt <jo...@gmail.com> wrote:
>> 
>>> Richard,
>>> 
>>> I don't believe the processor name (as you see in the UI or through
>>> the REST API) is made available to the processor instance itself at
>>> this time.  There is no strong/obvious case I can think of quickly to
>>> restrict access to the logical name of a ConfigurableComponent like
>>> this.
>>> 
>>> Other opinions?
>>> 
>>> Thanks
>>> Joe
>>> 
>>> On Sun, Feb 21, 2016 at 8:32 AM, Richard Miskin <r....@gmail.com>
>>> wrote:
>>>> Hi,
>>>> 
>>>> I’ve a use case where each instance of a custom Processor on my flow
>>> represents a different instance of a remote system. The message produced
>> by
>>> my Processor needs to include the remote system name, and currently I’m
>>> using a PropertyDescriptor to allow this to be configured. This means
>> that
>>> the name is effectively set twice, once to be shown in the UI and once to
>>> be used by my Processor internally. This leads to the possibility of the
>>> two values being inconsistent which is likely to confuse people in
>> future.
>>>> 
>>>> Is there any way I can access the name of a Processor from within an
>>> AbstractProcessor?
>>>> 
>>>> Cheers,
>>>> Richard
>>>> 
>>>> 
>>> 
>> 

Re: Accessing the name of a Processor programatically

[Matt Burgess <ma...@gmail.com>]

I think Aldrin's points about being able to use properties for the UI are
pretty cool, but I also think there's room for the inverse (which is what I
think the OP meant). The name of the processor is tied to its instance
(though not guaranteed unique between instances, and definitely not unique
between tasks within an instance). I would think any
property/attribute/value associated with an instance of a processor should
be available to it (so if name has been a "UI field", it would be no
longer). The tradeoff, then, is when you have to name your processor a
certain way to get it function correctly. I think this should not be the
normal NiFi way, but should be available with the caveat that the
documentation should reflect such a dependency. Sometimes when you're given
enough rope to hang yourself, you build a bridge with it. Other times you
just get dead :-P

Regards,
Matt

On Sun, Feb 21, 2016 at 3:25 PM, Aldrin Piri <al...@gmail.com> wrote:

> I think the functionality is certainly useful and like the deduplication,
> certainly a great idea to be a bit more efficient.  However, I find myself
> a bit hesitant to drive processor configuration via the processor UI
> fields.  At first thought, I think something along the lines of EL that
> could make use of processor properties for UI components like name and
> potentially notes could be helpful.  In this case, the processor UI could
> have its name be defined as something akin to "Retrieve data from ${url}
> every ${run.time}"
>
> Obviously some caveats would be needed such as handling the case of a
> property that is also using EL likely wouldn't work, but personally find
> driving presentation from processor logic to be more intuitive than the
> inverse.
>
> On Sun, Feb 21, 2016 at 7:45 AM, Joe Witt <jo...@gmail.com> wrote:
>
> > Richard,
> >
> > I don't believe the processor name (as you see in the UI or through
> > the REST API) is made available to the processor instance itself at
> > this time.  There is no strong/obvious case I can think of quickly to
> > restrict access to the logical name of a ConfigurableComponent like
> > this.
> >
> > Other opinions?
> >
> > Thanks
> > Joe
> >
> > On Sun, Feb 21, 2016 at 8:32 AM, Richard Miskin <r....@gmail.com>
> > wrote:
> > > Hi,
> > >
> > > I’ve a use case where each instance of a custom Processor on my flow
> > represents a different instance of a remote system. The message produced
> by
> > my Processor needs to include the remote system name, and currently I’m
> > using a PropertyDescriptor to allow this to be configured. This means
> that
> > the name is effectively set twice, once to be shown in the UI and once to
> > be used by my Processor internally. This leads to the possibility of the
> > two values being inconsistent which is likely to confuse people in
> future.
> > >
> > > Is there any way I can access the name of a Processor from within an
> > AbstractProcessor?
> > >
> > > Cheers,
> > > Richard
> > >
> > >
> >
>

Re: Accessing the name of a Processor programatically

[Aldrin Piri <al...@gmail.com>]

I think the functionality is certainly useful and like the deduplication,
certainly a great idea to be a bit more efficient.  However, I find myself
a bit hesitant to drive processor configuration via the processor UI
fields.  At first thought, I think something along the lines of EL that
could make use of processor properties for UI components like name and
potentially notes could be helpful.  In this case, the processor UI could
have its name be defined as something akin to "Retrieve data from ${url}
every ${run.time}"

Obviously some caveats would be needed such as handling the case of a
property that is also using EL likely wouldn't work, but personally find
driving presentation from processor logic to be more intuitive than the
inverse.

On Sun, Feb 21, 2016 at 7:45 AM, Joe Witt <jo...@gmail.com> wrote:

> Richard,
>
> I don't believe the processor name (as you see in the UI or through
> the REST API) is made available to the processor instance itself at
> this time.  There is no strong/obvious case I can think of quickly to
> restrict access to the logical name of a ConfigurableComponent like
> this.
>
> Other opinions?
>
> Thanks
> Joe
>
> On Sun, Feb 21, 2016 at 8:32 AM, Richard Miskin <r....@gmail.com>
> wrote:
> > Hi,
> >
> > I’ve a use case where each instance of a custom Processor on my flow
> represents a different instance of a remote system. The message produced by
> my Processor needs to include the remote system name, and currently I’m
> using a PropertyDescriptor to allow this to be configured. This means that
> the name is effectively set twice, once to be shown in the UI and once to
> be used by my Processor internally. This leads to the possibility of the
> two values being inconsistent which is likely to confuse people in future.
> >
> > Is there any way I can access the name of a Processor from within an
> AbstractProcessor?
> >
> > Cheers,
> > Richard
> >
> >
>

Re: Accessing the name of a Processor programatically

[Joe Witt <jo...@gmail.com>]

Richard,

I don't believe the processor name (as you see in the UI or through
the REST API) is made available to the processor instance itself at
this time.  There is no strong/obvious case I can think of quickly to
restrict access to the logical name of a ConfigurableComponent like
this.

Other opinions?

Thanks
Joe

On Sun, Feb 21, 2016 at 8:32 AM, Richard Miskin <r....@gmail.com> wrote:
> Hi,
>
> I’ve a use case where each instance of a custom Processor on my flow represents a different instance of a remote system. The message produced by my Processor needs to include the remote system name, and currently I’m using a PropertyDescriptor to allow this to be configured. This means that the name is effectively set twice, once to be shown in the UI and once to be used by my Processor internally. This leads to the possibility of the two values being inconsistent which is likely to confuse people in future.
>
> Is there any way I can access the name of a Processor from within an AbstractProcessor?
>
> Cheers,
> Richard
>
>