@jennings0131  Here are my thoughts based on your questions: What is the best way to provide site-specific configuration for the controllers/Processors?  <--- The recommended approach is to use Parameter contexts [1].  NiFi Parameters can be used in component properties that do not support NiFi Expression Language (EL). Should we have a unique properties file for each site and we select which one to deploy per site?  <--- You would typically create a unique parameter context per each site (same parameter strings with unique values per site) Is there a way in the controllers/Processors to provide conditional values based on deployed site?  <-- I am not clear on the ask in this question. Of particular concern is our Solr "Zookeeper Host List" This is a property value on our Query and Ingest processors, and they currently aren't enabled to support the Variable Registry, so the value is explicitly provided (no variable lookup/replacement).  <--- All properties support NiFi Parameters, so you convert these property's values into parameters.   Do we need to set up and use a "Variable Registry" at each site?  <--- I would not use variable registry in your use case.  Is there a way to import a set of variables or do we have to define the variables via the UI?  <-- Anything you can do via the UI, you can do via NiFi's rest-api [2] as well. Documentation again suggests moving away from variables, and use parameters instead. Should we use Parameters instead. What is the best way to manage/deploy site-specific set of Parameters? <-- Yes, This is what i would recommend as well. What is the best way to export from one NiFi Registry, import into another NiFi Registry instance, and then trigger the associated NiFi instance to update its workflow reference?  <-- You could certainly automated this via an external custom script.  The NiFi CLI toolkit [3] offers many functions for interacting with the NiFi-Registry allowing you to export flows and import flows. Does the update need to be triggered via the UI, or can the update be automated? One of the easiest ways when getting started with the NiFi rest-api is to make use of the developer tools in your browser.  With developer tools open you can perform the actions via the UI and observe the rest-api requests that are used.  Most developer tools even allow you to copy that request as a curl command which you could simply execute from a terminal window to produce same outcome: Automation would utilize a combination of NiFi CLI toolkit and NiFi Rest-api commands.   Keep in mind that when you import a new flow version to another registry, NiFi will not know about it right away.  NiFi checks NiFi-Registry for changes via a background thread.   What makes Parameters great: 1. Any property can utilize parameters (even those that do not support NiFi Expression Language 2. Once you create a parameter context and it is associated with a Process Group, you can easily convert existing component property values into parameters using the "convert to parameter" to the right of the property, 3. On the other NiFi site, you would not need to modify the processor properties.  Simply associate a site specific parameter context to the PG that contains all the same parameters just with site specific values. 4. Even component password property values (sensitive encrypted properties) can be converted in to parameters.   [1] https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#Parameters [2] https://nifi.apache.org/docs/nifi-docs/rest-api/index.html [3] https://nifi.apache.org/docs/nifi-docs/html/toolkit-guide.html#nifi_CLI   If you found this assisted with your query, please take a moment to login and click on "Accept as Solution" found below this post.   Thank you, Matt ... View more

@Rex13  Parameters are included when you version control a PG to the NiFi-Registry.  And if you then import that version controlled PG to another NiFi, that parameter context will be imported as well. Once imported the parameter context can be changed or updated as needed in the new environment.  Later if you commit version 2 of that same PG to NiFi-Registry and then upgrade to version 2 in the second environment, the parameter context changes you made locally on second environment will remain and will not be overwritten. If you found this response addressed your query, please take a moment to login and click on "Accept as Solution" below any solution that helped. Thank you, Matt ... View more

@Justee    First thing I would do is add a new Attribute on my FlowFile that specifies the year I'd be searching for in the lines contained within the content of that FlowFile. (optional) For example adding an attribute "year" with a value of "1995". In the routeText processor, I'd then be able to use NiFi Expression Language (NEL) in my java regular expression as supported by this processor component: ^\|(.*?)\|(.*?)\|${year}\|(.*?)$ The above java regular expression will match on lines that begin with a pipe "|" followed by a non greedy wildcard match of one or more character until the very next pipe "|", then again for field 2, then for field three I used NEL which resolves to "1995", and then finally i match via wildcard the remainder of the line. Of course you could simply put "1995" in place of "${year}" in the above regex. The routeText processor component configuration would look like this: The result would be two FlowFiles.  One FlowFile would be routed to the relationship "1995" (based on property name used) which would have content only containing lines with "1995".  The second FlowFile would route to the "unmatched" relationship and would contain all the non-matching lines ( you may to choose to just auto-terminate this relationship if you don't care about these lines). If you found these responses addressed your query, please take a moment to login and click on "Accept as Solution" below each response that helped you. Thank you, Matt   ... View more

@smartraman  This can also be accomplished through a different and more complex configuration of the ReplaceText processor: Using below input content example: { "TOT_NET_AMT" : "[\"55.00\"]", "H_OBJECT" : "File", "H_GROSS_AMNT" : "[\"55.00,58.00\"]", "TOT_TAX_AMT" : "[9.55]" }   I would set up the replaceText processor as follows: Instead of just searching for those character patterns and replacing them with nothing, I break entire input line-by-line in to a series of capture groups.  That way I can omit the capture groups matching the patterns you want removed ([ or [\" or \"] or ]) and then manipulate the capture group containing a possible comma separated list, so that only the last value in that list is returned. I used below java regular expression which results in 5 capture groups: (.*?)([\Q[\E]\\\"|[\Q[\E])(.*?)(\\\"[\Q]\E]|[\Q]\E])(.*?)$ I then used the following Replacement Value in which I used NiFi expression language against the 3rd capture group.  If that capture group does not contain any commas, the entire string is returned.   With example above and this configuration, you end up with the following new content: { "TOT_NET_AMT" : "55.00", "H_OBJECT" : "File", "H_GROSS_AMNT" : "58.00", "TOT_TAX_AMT" : "9.55" }   If you found this helped with your latest query, please take a moment to login and click on "Accept as Solution" below this response. Thank you, Matt       ... View more