@D5ha   Your issue is a mutual TLS handshake issue and really has nothing specific to do with NiFi itself.  There are a lot of resources on the web for creating certificates.  There are even free services like Tinycert you can use to generate valid certificate meeting the requirements I shared in my last response.   Providing guidance on how to create certificates does not make much sense since it can be done so many ways: - Self-signed - public CA - Corporate/private CA etc. Your current shared TLS exception is telling you that the IP or Hostname (you have BLUE line through it in yoru image) was not found as a Subject Alternative Name (SAN) in the certificate created for the server side of this handshake which in yoru case happens to also be your NiFi instance.   The Site-To-Site-Bulletin-Reporting-Task is acting as the client in this Mutual TLS handshake and the NiFi server S2S destination URL is the server side of this TLS handshake. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

Thank you @Former Member  ... View more

Matt, Thanks a lot for your explain, your time and recommendation. I applied in my flow the processor MergeContent and I could resolve my problem. With this processor, the 3rd process dosent run and waits until the first boths has fineshed and it was the main idea of my question.   One more time, Thanks   Pepe ... View more

Muito obrigado pela ajuda e esclarecimento, sou novo no nifi e estou estudando como proceder com essa atualização 1.12>1.17. Acredito que seguindo suas diretrizes eu deveria ser capaz de completar esta tarefa. Obrigado Matt! Sinceramente, Ricardo. ... View more

@MrBurns  You want to take the URL that written to the FlowFile's attribute "http.request.uri" and generate a Json, correct? Where do you want to write that JSON (a new FlowFile attribute?  Content of the FlowFile?)? There are multiple ways to handle this. If you just want to write JSON to a new FlowFile Attribute, you could use the "Advanced" UI of the UpdateAttribute by setting up a rule for each url type. If you want to write to the content of a FlowFile, you could follow the above UpdateAttribute with a replaceText processor that does an "always replace" to write the json from the attribute to the content of the FlowFile. another option here is to use a RouteOnAttribute to route each url type to a unique ReplaceText to handle the specific url type.   I like first option since you can easily add new rules to the UpdateAttribute if any additional URL types are introduced without needing to modify the rest of your dataflow. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

How did anyone solve this issue? I was currently trying to solve similar issue via nifi api (Postman) ... View more

@DGaboleiro  I am a bit confused by yoru dataflow design.  In a NiFi multi-node cluster, each node is only aware of and can only execute upon FlowFiles present on that one node.   So in your Dataflow you have the QueryCasandra processor executing on "primary node" only as you should (having it execute on all nodes would result in both your nodes performing same query and returning same data).  You then Split that Json and use a DistributeLoad processor for what appears to me as means to then send some FlowFIle to node 1 and other half to node 2. This is not the best way to do this.  You are running Apache NiFi 1.17 which means that load balanced connections are possible that can accomplish the same without all these additional processors.   https://nifi.apache.org/docs/nifi-docs/html/user-guide.html#settings After your FlowFiles (this is what is being moved from processor to processor on your canvas) have been distributed I see that you are a MergeContent processor.  The MergeContent processor can only merge the FlowFiles present on the same node. It will not merge FlowFiles from multiple nodes to a single FlowFile.  So if your desire is to have one merge of all FlowFiles, distributing them across multiple nodes will not give you that desired outcome. You should never configure any processor that accepts an inbound connection for "primary node" only execution.  This is important since which node is elected as primary node can change at anytime.  Execution strategy has nothing to do with the availability of FlowFiles on each node on which to execute.  What is important to understand is that each node in yoru NiFi cluster has its own copy of the Flow, its own set of Content and FlowFile repositories contain unique data, and each nodes executes the processors in its flow with no regard of the existence of other nodes.  A node is simply aware from Zookeeper if it has been elected as the cluster coordinator and/or primary node.  If it is elected primary node, it will execute "primary node" and "all nodes" components.  If it is not the primary node, it will only execute the "all nodes" components.    If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt   ... View more

@rangareddyy  What is important to understand is that the NiFi component processors are not being executed by the user authenticated (assuming secured NiFi) into NiFi, but rather by the NiFi service user.   So let's say that your NiFi service is owned by a "nifiservice" linux account.   Whatever umask is configured for that user will be applied to directories and files create by that user.   Now if your script is using sudo, it is changing the user that executes your script resulting in different user ownership and permission from the "nifiservice" user.   Subsequent component processors will also execute as the "nifiservice" user and then not have access to those files and directories.    So you'll need to take this in to account as you built your scripts.  Make sure that your scripts are adjusting permissions on the directory tree and files as needed so your "nifiservice" user or all users can access the files needed downstream in your dataflows.  So in yoru case it sounds like your script executed by ExecuteScript processor is creating a sh file not owned by the "nifiservice" user or does not have execute permission set on it.  The ExecuteStreamCommand processor will attempt to execute the sh command on disk as the "nifiservice" user only. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more