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]> 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]> 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]> 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]> 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 (BG Mobile) >> +4961509729845 (DE Landline) >> Email: [email protected] >> http://cst-bg.net >> >> >> > >
