Thanks for the quick responses.
I figured it out. ExecuteXQuery is indeed spitting out 9 separate FlowFiles, but since it flows into PutFile (and originated from a GetFile), it has a single static filename, so each one is overwriting the final output file. Doh!
Looks like a NiFi noob trick. Sorry to waste your time chasing this one.
Now I just need to figure out a way to generate a unique output filename attribute for each PutFile.
From: Joe Witt [mailto:firstname.lastname@example.org]
Sent: Saturday, August 22, 2015 12:45 AM
Subject: Re: ExecuteXQuery only returns single item when there are multiple matching items in FlowFile
Based on reading the docs for that processor I'm now with you on expected behavior...
On Sat, Aug 22, 2015 at 1:33 AM, Joe Witt <email@example.com> wrote:
Quick initial response...
I think the behavior makes sense because if it did just match all the items with desired titles you're left with blocks of valid XML but as a whole an invalid XML document.
What I believe is the expected behavior then is to use SplitXML to split out the item elements. Then you can run each of those through what you have configured here.
With this approach you end up with valid XML in every case.
I'll put together a template to verify.
On Sat, Aug 22, 2015 at 1:09 AM, Rick Braddy <firstname.lastname@example.org> wrote:
I have an XQuery processor test app configured to filter for <item> entries from an RSS feed where the <title> tag contains the word “Trump”. The XQuery is properly formed, based upon testing it outside of NiFi using XPathTester. Is this a bug in XQuery processor or am I doing something wrong?
Here’s the XQuery: //item[descendant::title[contains(text(),'Trump')]]
It properly matches only the first entry instead of matching all of the entries with “Trump” in the title.
I’m attaching a sample RSS news feed file that has numerous Trump articles in it (this file was created by a PutFile that wrote the entire file out ahead of the XQuery block)