PutSolrContentStream SolrLocation property: parameter vs. attribute

[#1]

I moved a working flow that is populating Solr indexes from one process group to another. In the original, the SolrLocation property of the PutSolrContentStream processor is populated using two parameters:

#{solr_url}/#{solr_index_name_a}

It's done this way because a QueryRecord processor is used to split the record set into two groups, and one path uses the "a" index, and the other, the "b" index. 

However, in the new flow, I have to append a year value (i.e., "2023") to the name of the index depending on earlier processing. To accomplish this, I am holding the name of the index in an attribute instead of a parameter. At the appropriate time in the flow, I use an UpdateAttribute processor to append the correct year to the index name. Then further down, I have the PutSolrContentStream processor, and I populate the SolrLocation property like this:

#{solr_url}/${solr_index_name_a}

This fails with an "HTTP ERROR 404 NOT FOUND". It took a lot of trial an error, but I have discovered if I hard code the index name to a parameter, and set the SolrLocation name  using two parameters (as in the original flow) instead of a parameter and an attribute like this:

#{solr_url}/#{solr_index_name}

it works. I move back to the attribute, and I get 404. In testing, I inserted in the middle an UpdateAttribute where I create an attribute called coreURL and set it to the value of the parameter + attribute, and I use that attribute instead as the SolrLocation. No dice. I then copy and paste the value of coreURL into SolrLocation (i.e., a hard-coded URL), and it works.

It looks to me that, despite the documentation saying SolrLocation supports Expression Language, it doesn't, because, I've tried many variations, and any time I introduce an attribute to SolrLocation, the processor fails. with a 404 Version is 11.6.3.

[#2 · Accepted solution]

@noncitizen 
Your issue here is that the "Solr Location" property has limted NiFi Expression Language support as documented here:
https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-solr-nar/1.23.2/org.apache.ni...

You'll notice that it states:

Supports Expression Language: true (will be evaluated using variable registry only)

In order to support NiFi Expression use of FlowFile Attributes, the wording would reflect:

Supports Expression Language: true (will be evaluated using flow file attributes and variable registry

Processor Properties that limit NiFi Expression Language (NEL) usability to Variable Registry only, is usually the result of client library being used requiring that the value is available at time processor is started.  Both Parameters and Variable Registry will have values available at processor start.  NEL can be used to manipulate the Variable Registry value through NEL functions at start or processor.

If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped.

Thank you,
Matt

[#3]

Thanks, Matt! We've been pressing hard for a year now to get some migration work done from an outmoded ETL tool, and as I've moved along, there's a lot I haven't stopped to truly understand. I had seen the notice about variable registry only before, but didn't truly appreciate what that meant. Now I do! And btw, I solved the problem by calling the "udpate" API directly from an InvokeHTTP processor where there's no restriction on using attributes. Works like a charm!