[
https://issues.apache.org/jira/browse/NIFI-8214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17618890#comment-17618890
]
ROGIER TIMMERMANS commented on NIFI-8214:
-----------------------------------------
Hello, thanks for the elaborate response!
yes, you're indeed correct - this particular use case was deciding between a
dev & prod environment based on earlier configuration/attribute pattern. While
it's relatively simple to build this deciding logic with a few additional
components the goal of this request is to be able to reduce graphical/component
duplication (and/or flow connection) clutter (which could be avoided increasing
the readability).
Potentially this is no longer a valid request as it was made quite some time
ago and there may have been some evolution and/or deprecation that overtook the
idea from back then.
Still - I feel it could be useful to allow (most/all?) components with an
URL/Username/similar type of field (remote endpoints, ports, username, paths,
etc...) to accept attributes; ex: the HTTPInvoke has the flexibility to take
VarRegs and Attribs, why not have (all?) others do the same?
I haven't checked more recent versions of Nifi for components where the field
cannot utilize attributes so there may be additional ones that could benefit;
also, i wasn't aware "PutElasticsearchHttp" is being deprecated so my initial
CR might not be very useful now if this turns out to be the only one (but i'm
positive there will be more, ex: the FTP components can also benefit from
having Remote Paths getting this treatment)
Still, to ensure we're all on the same page; Let me clarify with a more
practical example - i'm not sure if it's a common pattern so maybe i'm just
building things in a weird way.
I usually start my flow with a simple FF-generator from which I emit a small
json-file that contains configuration data (things like
users/credentials/certain eindpoints/config settings/date-time
offsets/type-of-enviroment that are to be used etc). One config flowfile can
contain several variants for a lab, a prod environment etc. This gives me a
central starting/config point which makes things simple to control/manage and i
only need to build my flow once to prevent duplicating effort during changes.
Note also that i did move to Parameters-Contexts at one point for a lot of
these things so this general pattern is becoming a bit less used but sometimes
it's just a very convenient way to just edit 1 json file and extend my
test/use-cases and not click around in things too much as this makes things
less easy to read & manage for my colleagues. I'm aware it's not the most
secure solution but this all runs in-house in a pretty isolated environment and
there's no internet so the risk is contained; it also was before the
secret-provider components were available so at the time we just had to make
due...
But going back: Effectively each flow-file will "carry" required config forward
that it needs downstream as attributes and each FF can dynamically adjust nifi
component config as needed.
So we build the logic once and apply the config (somewhat) dynamically; right
now this leads to additional RouteOnAttributes/Other dedicated groups of
components & paths since some of them are less flexible to configure via
attributes. It's not an issue but it's additional effort/testing of a path that
could go wrong and/or in case of a change there's multiple areas to touch,
etc...
i hope this clarifies the intention - if this however becomes relatively
complicated feel free to close but reach out if you need more information! Thx!
> Extend PutElasticsearchHttp / Elastic URL to take ff-Attributes
> ---------------------------------------------------------------
>
> Key: NIFI-8214
> URL: https://issues.apache.org/jira/browse/NIFI-8214
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Extensions
> Affects Versions: 1.12.1
> Reporter: ROGIER TIMMERMANS
> Priority: Minor
>
> The PutElasticsearchHttp processor's URL field only allows Variable Registry
> scope; this makes it less flexible than ea. InvokeHttp as this allows ff
> attributes as well.
> Suggesting a minor improvement/enhancement here.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
