Angel, OK, sounds like we've got a good path forward. I created a JIRA for this [1].
Is this by chance something that you would be able / interested in working on? Thanks -Mark [1] https://issues.apache.org/jira/browse/NIFI-2161 <https://issues.apache.org/jira/browse/NIFI-2161> > On Jul 1, 2016, at 9:10 AM, Angel Kafazov <[email protected]> wrote: > > Hi Mark, > > Yes, I think this option would be exactly what I am looking for. It would > make sense to add it, as there doesn't seem to be any other way around this > using any of the available processors. > > Best Regards, > Angel > > > On Fri, Jul 1, 2016 at 4:01 PM, Mark Payne <[email protected] > <mailto:[email protected]>> wrote: > Ah, I did miss that. In the cases that I have used it, an empty string would > not be a valid value in the JSON, so I > have been able to route on whether or not the value is 'null or empty' by > checking ${myAttribute:isEmpty()}. > Would it help if there were a new option in this Processor for the "Null > Value Representation" such that if the value > does not exist, no attribute is even added? Then you'd be able to simply > check for the existence of the attribute. > > Thanks > -Mark > >> On Jul 1, 2016, at 8:08 AM, Angel Kafazov <[email protected] >> <mailto:[email protected]>> wrote: >> >> Hi Mark, >> >> The EvaluateJsonPath always sets the attribute with empty string value, >> regardless if the JSON field exists or not. It is only possible to check if >> the field has a empty value or not, but not possible to check if it actually >> exists. Am I missing something? >> >> Best Regards, >> Angel >> >> >> On Thu, Jun 30, 2016 at 7:31 PM, Mark Payne <[email protected] >> <mailto:[email protected]>> wrote: >> Hi Angel, >> >> I don't know the reasoning behind only using 'unmatched' for FlowFile >> Content, but I am guessing >> it has to do with the idea that the FlowFile is not modified when routed to >> this relationship and the >> author probably wanted to avoid the ambiguity that would occur when some >> paths matched but >> others didn't. >> >> That being said, the pattern that is typically followed is to use >> EvaluateJsonPath with a destination >> of attribute and then to follow this processor with a RouteOnAttribute >> processor to check if all of the >> attributes were added. >> >> Thanks >> -Mark >> >> >>> On Jun 30, 2016, at 12:05 PM, Angel Kafazov <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> Hello, >>> >>> I am considering using EvaluateJsonPath processor to check if JSON >>> formatted FlowFile content contains a number of predefined fields. The >>> processor defines three relationships: failure, unmatched and matched as >>> follows: >>> >>> failure FlowFiles are routed to this relationship when the JsonPath >>> cannot be evaluated against the content of the FlowFile; for instance, if >>> the FlowFile is not valid JSON >>> unmatched FlowFiles are routed to this relationship when the JsonPath >>> does not match the content of the FlowFile and the Destination is set to >>> flowfile-content >>> matched FlowFiles are routed to this relationship when the JsonPath is >>> successfully evaluated and the FlowFile is modified as a result >>> >>> If the flowfile-content Destination is used, the existance only one field >>> can be checked. To validate multiple fields, flowfile-attribute destination >>> must be used, this means however that the unmatched relationship will not >>> be used. >>> >>> This actually prevents one from being able to check existance multiple JSON >>> fields in the content, if I understand correctly. What is the reason for >>> this implementation? Is there any other processor that could be used to >>> achieve the task? >>> >>> Regards, >>> Angel >>> >>> >>> Angel Kafazov >>> CST LTD >>> Bul. Bulgaria, blok 10, 6500 Svilengrad >>> Bulgaria >>> +359877336002 <tel:%2B359877336002> (BG Mobile) >>> +4961509729845 <tel:%2B4961509729845> (DE Landline) >>> Email: [email protected] <mailto:[email protected]> >>> http://cst-bg.net <http://cst-bg.net/> >> > >
