@mayki wogno Every Processor has a well defined job to do. When that job is executed, there are 1 to many possible outcomes. Those outcomes are represented in the form of relationships. As a FlowFile traverses through your dataflow it will be routed to these various relationships. Eventually you will reach the end of you dataflow and the auto-terminate relationship capability gives the user the ability to tell NiFi I am not done with the FlowFile you may get rid of it. A processor is never coded to ever delete FlowFiles by default. For example, lets assume the last processor in my dataflow is a putSFTP. What this processor actually does when it receives a FlowFile is send a copy of that FlowFiles content to the SFTP destination. Upon confirmed delivery it routes the FlowFile to the "success" relationship. You may choose to send that FlowFile via that "success" relationship on for further processing in additional processors or "auto-terminate" it within the putSFTP thus ending its life as FlowFile. In NiFi it is the dataflow designers job to determine when a FlowFile has reached the end of the dataflow and that is exactly what "auto-terminate relationships" is used for. Thanks, Matt ... View more

@Sanaz Janbakhsh Re-installing from scratch is not necessary. Shutdown your NiFi instance, create the user on your system that you want to run NiFi as and change ownership of all the files and directories used by NiFi to that user. This includes all 4 NiFi repositories (Database, Provenance, Content, and FlowFile). The "NiFi user" must be able to read and write to the repos, nifi logs, and state directories. If you are unsure where to find these directories your user needs access to, look in the various config files found in NiFi's conf directory. NiFi will be able to continue working on FlowFiles that were still active in the flow as long as ownership of those files was successfully changed. After that you can either start NiFi while logged in as that new user or set the "run.as=" property in the NiFI bootstrap.conf file. After starting NiFi as the user, tail the nifi-app.log and watch for any permission denied errors. If you encounter any, adjusted permissions on the reported file/dir and you should be good to go. There is no such thing as NiFi version 2.4.2.0? Are you running an Apache Nifi release (0.x or 1.x) or a HDF release (1.x or 2.0)? You can see your NiFi version by clicking on "about" in the upper right corner of the NiFi UI. Thanks, Matt ... View more

@milind pandit Is this a flow.xml.gz you copied from another instance of NiFi? All the sensitive properties inside the flow.xml.gz file are encrypted using the sensitive property defined in the nifi.properties file (If blank NiFi uses and internal default). If you move your flow.xml.gz file to another NiFi, the sensitive property value used must be the same or NiFi will fail to start because it cannot decrypt the sensitive properties in the file. Matt ... View more

@Harry You should be able to simply use two ReplaceText processors in series to create the XML structure you are looking for: First replace text configured to prepend text to the binary content as follows: and the second to append text to the resulting content from the above: *** Note: if you hold shift key while hitting enter, you will create a new line in the text editor as shown in the above examples. An example of the output from the above would look like this: There you have the binary content between <flowfile-content> and </flowfile-content> Now all you need to do is adjust the specific prepend and append values you need. Thanks, Matt ... View more

@boyer It may be helpful to see your dataflow to completely understand what you are doing. When you say you "call 2 other apis at the same time", does that mean you are forking the success relationship from the HandleHttpRequest to two downstream processors? Then you are taking the successes from those processors and merging them back together into a single FlowFile before sending to the HandleHttpResponse processor? Assuming the above is true, how do you have your mergeContent processor configured? 1. I would suggest you use the "http.context.identifier" as the "correlation Attribute Identifier" so that only FlowFiles originating form the same handleHttpRequest are merged together. 2. I also suggest setting "attribute strategy" to "Keep all unique attributes". (if 'Keep All Unique Attributes' is selected, any attribute on any FlowFile that gets bundled will be kept unless its value conflicts with the value from another FlowFile. ) This will be useful if your two intermediate processors set any unique attributes you want to keep on the resulting merged FlowFile. You also want to make sure that your FlowFile makes it from the Request to Response before the configured expiration in your "StandardHttpContextMap" controller service. Thanks, Matt ... View more