@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

@Ankit Jain When a secure NiFi is started for the first time, a users.xml and authorizations.xml file is generated. The users.xml that is created will have your users added to it using the provided DN form your authorizers.xml file: Initial Admin Identity Node Identity 1 Node Identity 2 Node Identity 3 Node Identity 4 etc... Each of those "users" are assigned a UUID which is then used to set some required policies in the authorizations.xml file in order to be able to access the NiFi UI. At a minimum, all "Node Identity" DN's UUIDs need to be assigned to the /proxy resource (Policy) and /flow (read/R )resource inside that file. You "Initial Admin" DN should have /flow (READ/R and Write/W) and /policies (R and W). If NiFi was secured and started prior to some or all of the above DNs being set in the authorizers.xml, the users.xml and authorizations.xml files will be created without any entries. Updates to these DN properties in the authorizers.xml file later will not cause updated to occur two these files. If you find this is what occurred in your case, you can stop your NiFi nodes, deleted both the users.xml and authorizations.xml files from all nodes and restart. On restart NiFi will again generate these files since they do not exist using the DNs in your authorizers.xml file on each node. Thanks, Matt ... View more

@Jobin George When you add new components (Process groups or processors), they inherit the policies from the parent component by default. This means the your process group (Group1) has inherited some policies maybe from its parent process group and your processor (getSFTP) has inherited policies from the process group it is inside. My guess is that those inherited policies are allowing user "john" view and "modify" to process group 'Group1'. When you select a component (process group or processor) and click on the key icon to modify/set its policies, you may notice the following in the "Access Policies" UI that is displayed: This line is telling you that the policies you are currently looking at are coming from a parent process group. If you modify any of these policies, what you are really doing is modifying the policies on that parent process group rather then on the actual selected component. In order to set specific policies for the select component, you must fist click on "Override". You will then see the above effective policy line go away and the specific policy you are currently looking at will be cleared of all entries. Now you can add specific users for this policy that are applied to only tis component. If the component is a process group, any processor or additional process group within will inherit this new policy. Keep in mind that every policy inherits from its parent by default, so clicking on "Override" only create a new policy accesses for that one policy. You will need to select each available policy for a component and click "Override" for each one where you want to set component specific policy accesses. Thanks, Matt ... View more