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: [email protected] > To: [email protected] > CC: [email protected] > > 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 <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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. >>>>> >>>> >>>
