@Rupesh_Raghani  I just want to make sure that when we are both talking about NiFi "Templates" we are talking about the same thing. https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#templates When you upload a NiFi template (xml file) to NiFi via the UI (Does not matter which node in a NiFi cluster you are accessing), that template will get uploaded and replicated to all nodes in the cluster.  So all nodes will have that template in each nodes JVM heap and written to the flow.xml.gz on disk. This statement is not clear to me: "So if I have templates on every node in cluster then will the nifi load templates on each node as per templates available on their node or a parent node will load all templates from other cluster". What do you mean by "if I have templates on every node"?  In a NiFi cluster, every node must have the same flow.xml.gz.  If the flow loaded in to heap memory does not match between nodes, the nodes no matching the elected cluster flow will be disconnected from the cluster.  Each node, while it has its own local copy of the flow, runs the exact same flow. Hope this helps, Matt ... View more

@Chakkara    The more detail you can provide, the better we may be able to assist. Are you using custom processors?  NiFi does not come with a ReplaceAttribute processor. I am assuming your flow may actually be using: GetFile (deprecated processor in favor of the listFile and FetchFile processors) --> UpdateAttribute --> ExtractText --> RouteOnAttribute --> putSQL Can you share the configuration you are currently using on the above processors, so we can see what you are doing now?  Perhaps you only need a few tweaks to your current design.   Thanks, Matt ... View more

@karthikraja @Seedy    Parameter Contexts are still relatively new.  There is an existing improvement Jira for exactly what you are looking for here that is currently in development. NIFI-8487 Unfortunately, there is not workaround or alternative to what you are trying to achieve other than recreating those common parameters in every parameter context you create currently.   If you found this query addressed your question, please take a moment to login and click accept on this solution. Thank you, Matt ... View more

@SAMSAL    NiFi Site-To-SIte (S2S) components perform to things: 1. A background process runs every 30 seconds which connects to the target URL entered (In this case https://localhost:9443/nifi ) to retrieve S2S details.  These details include details like how many nodes in target NiFi cluster, hostnames for those target NiFi nodes, load on those nodes, if those nodes support http and/or RAW transport protocols, What remote input ports exist that this source node is authorized to see, etc...  S2S details are always fetched over HTTP even if you set transport protocol to RAW. 2. Then the source NiFi uses this data to actually sent content over S2S to all the target nifi nodes in a distributed fashion. Since your target is a https, the first thing that needs to happen is a Mutual TLS handshake.  That means the keystore configured in the SSL Context service must contain a PrivateKeyEntry that support an EKU with "clientAuth".  The target NiFi which is probably returned a FQDN via those S2S details, will also send its server certificate to the client.  That means the truststore configured in your sslContextService must contain the complete trust chain for that certificate.   That server certificate which comes from the keystore in the nifi.properties file on the target NiFi must contain a single PrivateKeyEntry with a EKU that supports "serverAuth" and must also have a SAN that matches the hostname used to connect with.  The target NiFi's truststore configured in its nifi.properties file must also contain the complete trust chain for that client certificate presented from the sslContextService. So if all the above is properly in place, and I would guess it is since you are trying to S2S back to same NiFi cluster/instance and are probably using same keystore and truststore in your SSLContextService as is configured in the nifi.properties file, that those files are good.  I would however be concerned with your use of "localhost" as the target URL because I doubt the server certificate sent in that TLS handshake is going to have a SAN entry that contains "localhost".  You should instead provide the actual hostname for that target NiFi.  It is fine and common to use localhost in the "instance URL"field as that is only used to identify the host that sent the FlowFile to the target InputPort. The only other statement that stands out to me is "The user created by securing the instance has the policy "retrieve site-to-site details"."  NiFi authentication and authorization is setup to control what users are allowed to do once they access a secured NiFi UI.  The components that are added by the authorized user do not execute as that authenticated user.  All components execute as the NiFi service user.  In that case of this S2S reporting task, it is executing as the NiFi service user but authenticating to the target through that mutual LS handshake, which means the DN form that clientAuth certificate is going to be the user that needs to be authorized for both the "retrieve Site-To-Site details" and "receive data via site-to-site" NiFi authorization policies. I know there is a lot of information here and hope it is clear. If you found this addressed your query, please take a moment to login and click accept on this solution. Thank you, Matt ... View more