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. > > > > > >
