Re: Configuration Suggestion for NiFi HandleHTTPResponse Processor

Hello! You can get the results you are looking for by using ReplaceText to modify the body. In your case, you could completely replace the text with an empty string. There is an example of this in the Example Dataflow Templates [1] with the Hello NiFi Web Service template. The performance impac

Configuration Suggestion for NiFi HandleHTTPResponse Processor

Greetings, I cam across an issue with the HandleHTTPResponse Processor in which the processor sends the response but it also sends the body of the message along with the response code. I wanted to ask if it was possible for future development to add a configuration in the processor that allows the

Re: site-to-site configuration

I created a Jira to make sure we update that paragraph in the 1.x User Guide: https://issues.apache.org/jira/browse/NIFI-3526 -Drew > On Feb 23, 2017, at 1:48 PM, Bryan Bende wrote: > > Mark, > > I think you are correct that the paragraph in the user guide should be > updated for 1.x. > > I

Re: site-to-site configuration

Mark, I think you are correct that the paragraph in the user guide should be updated for 1.x. I know the admin guide has a section about users and policies in general, but not necessarily specific to site-to-site: https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#config-users

Re: I don't want the ENTIRE remaining flow after the split execute that many times

Hi Srini, You could make use of a RouteOnAttribute to only pass those fragments of the split that have a given 'fragment.index' of 0 (at least I believe these are zero indexed) where all the others are dropped. In this case, you would get one and only one of each "batch." On Thu, Feb 23, 2017 at

Re: site-to-site configuration

Ok. Understood. I created the policy and added the user (server.) All is working as expected now. Is this process of manipulating policies required for secure site-to-site documented anywhere? The User Guide still talked about Access Control and the NiFi Role which seems to apply only to 0.x. Tha

Re: site-to-site configuration

Mark, When you are looking at the "receive data via site-to-site" for the input port, is there a link across the top to "Create Policy"? I think you need to create a policy first then you can add users. Thanks, Bryan On Thu, Feb 23, 2017 at 1:01 PM, Mark Bean wrote: > Bryan, > > The server is

Re: How to keep the original flowfile?

Hi Srini, Depending on the typical size of the response, it is possible to store the response in an attribute. This would append the content onto the previously existing FlowFile in an attribute of your choosing. On Thu, Feb 23, 2017 at 12:55 PM, srini wrote: > Hi Pierre, > But I want the resp

Re: site-to-site configuration

Bryan, The server is listed on the global policy for "retrieve site-to-site details". However, I am not able to add users to the "receive data via site-to-site" policy for the given Input Port (the add user button is grayed out.) Under global access policies, "access all policies/modify", I am lis

Re: How to keep the original flowfile?

Hi Pierre, But I want the response from InvokeHTTP also. How can I use the response and keep the original flowfile so that SplitJson in the flow can use it. thanks Srini -- View this message in context: http://apache-nifi-developer-list.39713.n7.nabble.com/How-to-keep-the-original-flowfile-tp1

Re: site-to-site configuration

Hi Mark, There are two policies needed for secure site-to-site... In the global policies there needs to be a policy for "retrieve site-to-site details" with the user of the server added. In the policies for the port (from the palette on the left when the port is selected) there needs to be a pol

site-to-site configuration

I am attempting to setup secure site-to-site using NiFi 1.1.1. I have secured NiFi, and am able to access the UI securely via HTTPS. I have set the following security-related properties: nifi.sensitive.props.key= nifi.sensitive.props.key.protected= nifi.sensitive.props.algorithm=PBEWITHMD5AND256BI

Re: How to keep the original flowfile?

Hi Srini, You have a relationship "original" that will route the original flow file used to perform the request. Have a look here: https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi.processors.standard.InvokeHTTP/ Thanks 2017-02-23 18:20 GMT+01:00 srini : > Hello, > In the attach

How to keep the original flowfile?

Hello, In the attached flow, the InvokeHTTP replaces the original flowfile. But the SplitJSON needs the original flowfile instead of the flowfile given by the InvokeHTTP. How to do that? Thanks Srin

I don't want the ENTIRE remaining flow after the split execute that many times

Hi, Here, the number of times the process group and the LogAttribute executes is depends on the number of elements in the split. If there are 5 elements due to the split, then the Process Group and the LogAttribute executes 5 times. But I don't want the ENTIRE remaining flow after the split execut

Re: Minifi receiving flowflie through Remote process

Just to clarify it will work in the c++ version just not the java version > On Feb 23, 2017, at 9:14 AM, Bryan Rosander wrote: > > Hey Rafael Carlos, > > Unfortunately, remote process group output ports aren't currently supported > in MiNiFi [1]. There is currently a Jira case to support this

Re: Minifi receiving flowflie through Remote process

Hey Rafael Carlos, Unfortunately, remote process group output ports aren't currently supported in MiNiFi [1]. There is currently a Jira case to support this functionality [2]. Thanks, Bryan [1] https://nifi.apache.org/minifi/system-admin-guide.html#remote-process-groups [2] https://issues.apach

Re: Minifi receiving flowflie through Remote process

Hey Rafael Can you please attach the error that you are seeing? It would also be helpful to see your minifi YAML configuration file if there is nothing sensitive in there. Are you using the java or c++ minifi version? Thanks Sent from my iPhone > On Feb 22, 2017, at 11:20 PM, Rafael Carlos

Re: Closing in on a NiFi 1.2.0 release?

Slightly off topic, but your statement "we need reviews/feedback as much as we need contributions" made me think that the project could somehow benefit from the concept of Kanban Work In Progress limits. Not sure how you'd implement this with an open source project, but just a thought. On Thu, Fe

Re: Closing in on a NiFi 1.2.0 release?

As someone who has surely been guilty of optimistically setting fix versions and then not meeting them, I second Joe's point about it holding up releases. Better to get the PR out, reviewed, and merged *before* setting the fix version in my opinion. Andy LoPresto alopre...@apache.org alopresto