@midee Have you resolved your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future.      ... View more

@SolidSnake    Site-To-Site is not a proxy. Perhaps a diagram of what you are trying to accomplish may make it easier to follow your use case? Could you share such a diagram that shows flow of connections and what is happening now versus a diagram that shows what you want to happen.    You have a 2 node nifi cluster using invokeHTTP processor making a request to a handleHttpRequest processor on the standalone NiFi (1 node cluster) and then the FlowFile generated by the HandleHttpRequest processor is end via Site-To-Site to the NiFi cluster that then routes to a HandleHttpResponse?   Maybe i am not following very well, but I don't understand why you are doing that if I understand your flow correctly?  Why isn't the same node that receives the the request via the HandleHttpRequest processor also sending the response via a HandleHttpResponse processor? Thanks, Matt ... View more

@MattWho  Thanks for providing the solutions .   thanks! ... View more

Hi @HariAllstate, I'm glad to see you resolved your issue. Please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. ... View more

Maybe a TransformXml with this XSLT might be more future proof:   <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output omit-xml-declaration="yes" indent="yes"/> <xsl:strip-space elements="*"/> <xsl:template match="node()"> <xsl:copy> <xsl:apply-templates /> </xsl:copy> </xsl:template> </xsl:stylesheet> ... View more

@jg6  There is no direct relationship between the DistributedMapCacheServer and the DistributedMapCacheClientService.  Meaning that the client is simply configured with a hostname and a port.  This hostname and port could be a DistributedMapCacheServer running on an entirely different NiFi cluster somewhere. Additionally there is no component that registers a dependency on the DistributedMapCacheServer controller service.  They only have a dependency on the DistributedMapCacheClientService.  So when constructing a template only the interconnected and dependent pieces are included. That being said, using the DistributedMapCache is not the cache I would recommend using anyway.  IT offers no high Availability (HA).  While a DistributedMapCacheServer is being started on every node in a NiFi cluster, they do not talk to one another and the DistributedMapCacheClientService can only be configured to point at one of them.  So if you lose the NiFi node were your clients point, you lost all your cache.  There are better options for external cache services that do offer HA. Hope this is helpful, Matt ... View more

@Aiiyer  What ERROR?  All I see are a bunch of normal INFO log lines form the nifi-app.log snippet you shared. Please share the ERROR log line and stack trace if present.   Or share screenshots of what you are doing and observing. Thank you, Matt ... View more

@midee    You are using an InvokeHTTP processor to hit the rest-api endpoint of some authentication service to obtain a JWT Token, correct? The invokeHTTP processor gives you only two options for handling the response from the endpoint.  Placed it in the content of the FlowFile or in to an attribute of the FlowFile.  This means that any user who has been granted authorization to view the data of any component that this FlowFile will traverse can see the attributes and content of this FlowFile. There is no capability for the invokeHTTP to encrypt/mask the endpoint response in either options.  Even if there was, this now masked/encrypted data would no longer be usable by downstream components.  I suspect your plan is to then use this token to make additional requests to other endpoints later in your flow?  Also keep in mind that a token generally has a limited lifespan.  You should also have the ability to invalidate the token via another endpoint when you are done with it.    So your options here are: 1. Limit user's access so they can not view the data in the dataflows that utilize this token so that they can't see the token in the content or attributes.  If you are building the flow, then you know how to get the token so does not matter that you can see the token via the attributes or content. 2. Invalidate the token once done with it. Token can't be used anymore even if a user gained access to it later via looking at the content or attributes of a FlowFile.  So you may consider building yoru flow to get a token --> use that token for other actions --> invalidate token (Using NiFi login authentication as a JWT token example, you hit the logout endpoint to invalidate the token on the server side. This means the client token will no longer work even if you have it still).  Of course this means you flow needs to obtain a new token every time it runs.  Issue here is if your flow utilizes same token for multiple FlowFiles.  First FlowFile that hist logout will invalidate token other FlowFiles may try to still use.   Note that the default life of a token issued by NiFi is 12 hours.  After that the client token can't be used anymore and a new token would need to be obtained anyway (of course this age can be adjusted via the NiFi login provider configuration) If you found this answered your query, please take a moment to login and click "Accept" on the solutions that assisted you. Thank you, Matt ... View more