nifi-dev mailing list archives

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

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
different
than what they were designed for.

That being said, a member of the community, Joe Gresock, submitted a ticket a while back [1]
that
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!
-Mark


[1] HoldFile Processor: https://issues.apache.org/jira/browse/NIFI-190

----------------------------------------
> Date: Tue, 4 Aug 2015 10:45:44 -0400
> Subject: Re: Route Original Flow File Base on InvokeHTTP Response
> From: joe.witt@gmail.com
> To: dev@nifi.apache.org
> CC: dev@nifi.incubator.apache.org
>
> 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 <adam@adamtaft.com> 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 <joe.witt@gmail.com> 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" <aldrinpiri@gmail.com> 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 <stephen.c.metcalf@lmco.com> 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
a
>>>>> decision on routing.
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>>
>>>>
>>> http://apache-nifi-incubating-developer-list.39713.n7.nabble.com/Route-Original-Flow-File-Base-on-InvokeHTTP-Response-tp2317p2324.html
>>>>> Sent from the Apache NiFi (incubating) Developer List mailing list
>>>> archive
>>>>> at Nabble.com.
>>>>>
>>>>
>>>
 		 	   		  
Mime
View raw message