nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Payne <>
Subject RE: Route Original Flow File Base on InvokeHTTP Response
Date Tue, 04 Aug 2015 15:47:50 GMT

I certainly agree with both Joe & Adam here. I do think that this could in fact be done
by using
the MergeContent processor. However, it would get pretty confusing and would be inefficient
and a bit 'unclean', as you would be really be using some processors to  achieve a goal very
than what they were designed for.

That being said, a member of the community, Joe Gresock, submitted a ticket a while back [1]
I think would be a great solution for this use case.

Unfortunately, it's not a processor that is in the baseline right now, but it's being worked
on. We should
be able to get it into the build pretty soon.

I hope this helps!

[1] HoldFile Processor:

> Date: Tue, 4 Aug 2015 10:45:44 -0400
> Subject: Re: Route Original Flow File Base on InvokeHTTP Response
> From:
> To:
> CC:
> Yep - i'm with Adam's interpretation here.
> Steve: For your case can you elaborate on what you'd want to do with
> the content of the web response in deciding how to handle the orig? I
> do think a custom processor would be necessary but if perhaps we can
> add something simple/consistent with the purpose of InvokeHTTP it can
> be avoided. Just need to understand the use case a bit better
> Thanks
> Joe
> On Tue, Aug 4, 2015 at 10:36 AM, Adam Taft <> wrote:
>> Right. Fundamentally, with InvokeHTTP you have two flowfiles involved.
>> The original flowfile which represents the HTTP request, and a newly
>> created "response" flowfile which captures the message body from the
>> response.
>> After invoke HTTP does its thing, you are effectively left with two
>> flowfiles. They have a common "transaction id" associated to both
>> flowfiles, so it might be possible to use this with, for example,
>> MergeContent and associate the two files back together.
>> If MergeContent can't be made to work, it might require a new custom
>> processor to take the two flowfiles coming out from InvokeHTTP and evaluate
>> them as a single unit.
>> Adam
>> On Tue, Aug 4, 2015 at 10:27 AM, Joe Witt <> wrote:
>>> Aldrin, Bryan
>>> I think the point is to route the orig flowfile based on analyzing the
>>> content of the web response. The setup would be more involved
>>> On Aug 4, 2015 8:52 AM, "Aldrin Piri" <> wrote:
>>>> Steve,
>>>> Building on the template Bryan provided you can route a successful
>>> response
>>>> to perform further inspection. Depending on content any of RouteOnContent
>>>> or EvaluateJsonPath/EvaluateXPath in conjunction with RouteOnAtrribute
>>>> could be viable options.
>>>> Let us know if this helps with the use case you are tackling or if there
>>>> are any other questions.
>>>> --
>>>> Sent from my mobile device.
>>>> On Tue, Aug 4, 2015 at 07:32 steveM <> wrote:
>>>>> Thanks for the quick response. However, my use case requires that I
>>> parse
>>>>> the
>>>>> actual response (not just make sure the response code is 200) to make
>>>>> decision on routing.
>>>>> --
>>>>> View this message in context:
>>>>> Sent from the Apache NiFi (incubating) Developer List mailing list
>>>> archive
>>>>> at
View raw message