@Shrink   What do you mean by "by storing flow file temporally to save RAM or backpressure"? FlowFiles held in NiFi connections will consume NiFi heap memory (unless queue has gotten very large resulting some of those queued FlowFiles being swapped to disk).  But this behavior is no different if you use process groups or not. Process groups do allow you to configure: "Process Group FlowFile Concurrency" "Process Group Outbound Policy" I assume you are using the above to control the FlowFile going in and out of your process groups as those FlowFiles move from one process group to the next?  Using these allows you to insure processing in one PG completes before the outbound FlowFiles are released to the next downstream process group.  This also allows you to leave all your processor in a running state for more efficient /performant dataflow. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@Alf015  The  "merge-param-context" cli.sh NiFi command does the following when merging one parameter context into another: Adds any parameters that exist in the exported context that don't exist in the existing context.  So your observations align with the documented behavior of this command.  It will not modify value of any already existing parameter in the destination parameter context. It sounds like what you want to be using in the "set-param" command instead: Creates or updates a parameter in the given parameter context. Above will allow you to modify an existing parameter within the target parameter context. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@Alf015  The merge-param-context command will merge an exported parameter context's parameters into another existing parameter context. As simple exported parameter context with three parameters defined in it looks like this: { "name" : "test-param", "description" : "", "parameters" : [ { "parameter" : { "name" : "test1", "description" : "", "sensitive" : false, "value" : "test1", "provided" : false, "inherited" : false } }, { "parameter" : { "name" : "test2", "description" : "", "sensitive" : false, "value" : "test2", "provided" : false, "inherited" : false } }, { "parameter" : { "name" : "test3", "description" : "", "sensitive" : false, "value" : "test3", "provided" : false, "inherited" : false } } ], "inheritedParameterContexts" : [ ] } You can then use the merge-param-context command to merge the exported parameter context with another parameter context that already exists in the target NiFi: ./cli.sh nifi merge-param-context -i /tmp/test-param.json -p /opt/nifi-toolkit/conf/mytarget.properties -pcid b47a13ab-0195-1000-cc06-dc7779729310 --verbose "test-param.json" contains above shared json "mytarget.properties" contains the connection info for target NiFi. "b47a13ab-0195-1000-cc06-dc7779729310" is the id for the destination parameter context in which I am merging the input parameters There is a sample .properties file (../conf/cli.properties.example) in the toolkit conf directory. Contents of mine looks like this: baseUrl=https://nifihostname:8443 keystore=/opt/nifi/conf/keystore.p12 keystoreType=PKCS12 keystorePasswd=<password> keyPasswd=<password> truststore=/opt/nifi/conf/truststore.p12 truststoreType=PKCS12 truststorePasswd=<password> proxiedEntity=<nifiadmin> You can get the values for above from your nifi.properties file of the target/destination NiFi.  The proxiedEntity is my NiFi user identity that has permissions to edit the destination parameter context I am importing the new parameters into.  NOTE:  Your NiFi node must be authorized to /proxy user requests with Access Policies in destination NiFi.  If you choose not to use a proxiedEntity, your NiFi node will need to be directly authorized to edit the target parameter context. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@0tto  Using child process groups is a matter of your own personal preference.   Using child Process Groups allows you create a more manageable NiFi canvas by placing unique dataflows in different Process Groups.   When it comes to one continuous dataflow, you may choose to put portions of it in to child process groups.   For example, you might do this if portions of the dataflow can be reusable.  You can right click on a process group and download a flow definition or you can choose to version control a process group  to NiFi-Registry.  These becomes snippets of your overall end-to-end dataflow.  So let's your "transform" sub dataflow is reusable with just a few modifications, others could easily reuse it by importing from NIFi-Registry or deploying a shared flow definition. Typically users of NiFi will create a process group per unique end-to-end datflow or will create a unique process group per team to separate dataflows and control access per process group so team 1 can't mess with team 2's process group. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@Shrink  Once your certificate has expired, you'll need to generate a new certificate. Form your image, it appears you are using the NiFi auto-generated out-of-the-box self signed certificate? There are multiple options: (Recommended) The auto-generated certificate is intended to be used for product evaluation.   For extended use and specially for production use, you should be using certificates signed by an internal company Certificate Authority (CA) or an external CA. You can manually create new self signed keystore and truststore as well. https://nifi.apache.org/nifi-docs/walkthroughs.html#manual-keystore To make life easier, I'd use the existing keystore.p12 and trustore.p12 filename instead of the nifi1.p12 and trust.p12 used in above documentation.  I would also use the same password used already for the expired keystore.p12 and truststore.p12 files set in your nifi.properties file.  That way if you are using these keystore and truststoe file in any NiFi dataflow controller services, you will not need to edit them. You could delete or rename the existing expired keystore.p12 and truststore.p12 files.  Then edit the nifi.properies file to clear the keystore and truststore password values: nifi.security.keystorePasswd= nifi.security.keyPasswd= nifi.security.truststorePasswd=​ With the passwords cleared and the keystore.p12 file and truststore.p12 files removed/renamed, NiFi will generate a new keystore.p12 and truststore.p12 using new randomly generated passwords.  Down side here is if you use the keystore and truststore anywher in your dataflow, you'll need to update the password. Or you can use the javak keytool command to change the passwords to the password used previously.  If you do this, you'll need to restart NiFi afterwards for NiFi to start using the new passwords you update in the nifi.properties file. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more