[
https://issues.apache.org/jira/browse/NIFI-8214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17618821#comment-17618821
]
Chris Sampson commented on NIFI-8214:
-------------------------------------
Can you elaborate on the use case as to when you'd want to specify different
Elasticsearch hosts via FlowFile attributes? I could see this possibly being a
thing for things like Dev vs. Prod environments, but would likely suggest using
Parameters for that in different NiFi environments rather than FlowFile
attributes.
One concern I'd have with host attributes would be changing sensitive values
that are also needed by the Elasticsearch processors, e.g. the Password
(assuming you've got authentication setup in your Elasticsearch
instance/cluster, which would be strongly recommended). You'd not want to have
the password as a plain text attribute on the FlowFile as there's no way of
making that sensitive (that I'm aware of).
{{PutElasticsearchHttp}} is also deprecated now, with the recommendation of
moving to the newer {{PutElasticsearchJson}} (and/or associated
{{PutElasticsearchRecord}}) processor, which uses an
{{ElasticSearchClientService}} to handle connectivity to Elasticsearch via the
Elasticsearch REST Client libraries.
The suggestion in the description here would technically be possible in the
older {{PutElasticsearhHttp}} (and associated {{PutElasticsearhHttpRecord}})
processor as the URL property evaluation simply needs to pass the FlowFile to
evaluate its attributes (as well as updating the PropertyDescriptor on the
processor, of course). However, the move to the
{{ElasticSearchClientService}}-based processors would need more thinking about
as the Controller Services are configured once then used by the processors and
can't use FlowFile attributes as part of Expression Language evaluation.
One possibility would be to introduce some sort of (cache enabled) dynamic
{{ElasticSearchClientService}} factory controller service, which can
instantiate and use {{ElasticSearchClientService}} instances dynamially using
values provided by the processor - but this feels a bit ugly and counter
intuitive, especailly when thinking about the concern highlights above.
> 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)
