@Amn  Where did you define the NiFi Attribute "${itemType}" (FlowFile Attribute on a source FlowFile driving execution of GetMongo processor or NiFi variable registry)? NiFi is also case sensitive, so for example "ItemType" and "itemType" would be considered different variables. If you found this helpful to yoru query, please take a moment to login and click "Accept" on this solution. Thank you, Matt ... View more

@Prajeesh10    If you are trying to split your source CSV in to two different FlowFile before converting each to a JSON, you could use the "SplitContent" [1] processor.   [1] https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.13.2/org.apache.nifi.processors.standard.SplitContent/index.html   If you found this useful, please take a moment to login and click "Accept" on this solution. Thank you, Matt   ... View more

@Rupesh_Raghani  NiFI templates are uploaded to the process group selected.  Only users who have been granted view and modify on that PG will be able to instantiate those templates on to the NiFi canvas. NiFi operates within a single JVM, so there are not separate per user canvases.  User not authorized on a specific NiFi Process Group (PG) will only see a blank representation for that component on the canvas (non-authorized users can not see name, description, configuration details, etc...). Non-authorized users can still see metrics presented on components and queue counts on connections only.   The reason NiFi still renders all components is because everything is executing within a single JVM.  - One users flows can impact another team (Some flow with huge backlog of queued data, high volume, etc can impact resource availability to other teams/users. - Stats on information bar is representative of entire canvas (all dataflows), so it is still important for all teams/users to be able to identify areas of concern even if is not their dataflows and they have no authorizations allowing them to do anything about it. But they could alert other teams/users. - Typical use case is team/user 1 has a PG and then team/user 2 has a different authorized PG.  If NiFi did not render both PG to both users, nothing prevents users from building flows on top of one another.  Then assume we have team/user 3 that is authorized for both above team/users PGs.  This becomes unreadable useable by that third user. If you found this helped with your query, please take a moment to login and click "Accept" on this solution. Thank you, Matt ... View more

@Rupesh_Raghani    Since templates reside in NiFi heap, they should only be uploaded to the NiFi for the purpose of instantiating that template to the canvas.  Once instantiate on to the canvas, the template should be deleted from the NiFi, so it is no longer holding that memory space. In addition to uploaded templates consuming heap memory space, so does everything build on the canvas (including controller services, and reporting tasks.).   Additionally the metrics for each component also reside within heap memory space.  Additionally, all FlowFiles queued (except large queues resulting in swap files) will also reside in the NiFi JVM heap memory space.  How much heap each FlowFile consumes is driven by the number and size of the FlowFile attributes on each FlowFile (FlowFile content does not reside in heap memory except when a processor needs to do so to perform its task and not all processors need to touch the content at all and other may also read it without needing to hold it in heap if it is streaming it somewhere else.). The impact on heap various based on what components are being used and how many. If your flow grow extremely large, it may be a case of breaking those flows to be managed by Multiple NiFi clusters. NiFi flow templates will become a deprecated capability in favor of NiFi-Registry.  You can version control your flows in to NiFi-Registry.  All NiFi's connected to this NiFi-Registry can then load Flows from NiFi-Registry to the canvas (one or more times). I am not sure what you are looking for with regards to "How does it manage individual processors in memory?"  All processors residing within the canvas and within templates will reside in the JVM heap memory space. If you find this helps with yoru query, please take a moment to login and click "ACCEPT" on this solution. Thank you, Matt ... View more

@SAMSAL  Sounds like you are very close... The 403 has nothing to do with authentication, but rather authorization. This eludes to the fact that the client was able to be properly trusted through the mutual TLS handshake, but when that resulting client string was checked against the endpoint policy being checked it was not present, thus resulting in a 403 response. The DN is the DistinquishedName for your certificate.  You can use the below command to get the verbose details on the certs added to a keystore: keytool -v -list -keystore <keystore.jks or truststore.jks>  You will see that each certificate has either type "PrivateKeyEntry" or "TrustedCertEntry" For each certificate you will see an "Owner" and an "Issuer" For each of those it will show the complete DN which would look something like: CN=<some string>, OU=<some string>, DC=<some string> There are numerous parts that can be part (CN, OU, O, ST, DC, etc.) of a DN and various lengths  The "Owner" DN for the PrivateKeyEntry is what is used as the client/user authenticated string after the successful mutual TLS handshake.  The nifi.properties file has optional ideNtity.mapping properties that can be configured to trim and manipulated these identity strings (for example pulling our on the string from the CN).   With nifi.remote.input.secure= set to false, FlowFiles send over S2S will not be over a TLS encrypted connection.  The fact that you say it works when you have this set to false and you can still successfully obtain S2S details from the configured https:// secured NiFi Destination URL tells me that authentication is correct for "Retrieve site-to-site details" NiFi policy.  That only leaves having incorrect policy setup for your remote input port. You should open a command prompt on each node and "tail -F /<path to>/nifi-user.log". Then enable your controller services and check the logs being tailed for the authorization exception.  It should clearly show you the "string" being checked against the "receive data via site-to-site" endpoint which in the log would look like "/data-transfer/input-ports/<uuid of remote input port>".  Also remember that you are NOT authorizing your user to any of these S2S policies, but rather the DN or identity mapped DN string. Really hope this helps you get fully secured here. Matt ... View more