nifi: How to update and trnaform xml file inside ExecuteScript processor
Question by sally sally 12 secs ago nifi-processorjavaapache-nifigroovy
I want to read xml file from folder and i want to update it and make new
flowfile(my code will be placed in nifi processor) which will containt this
renewated data but i can't parse xml document properly i got error like
cast object 'com.sun.org.apache.xerces.internal.dom.DeepNodeListImpl@181ae3f
1.what should i change?( except changing doc = builder.parse(inputStream)
with doc=builder.parse(file) because i need to use string data for later
Another reason why i can't fulfill my task is that i can't make flowfile in
which i would have placed all renewated xml data, for some reason i got
empty flowfile even if i use this doc=builder.parse(file) i means use config
file phisically( File file=new File('path')), what should i change to
improve this case.
if i use string content, should i use any alternative way to get xml tag
data except using NodeList( i mean is it possible to use any better use
case)? here is my groovy code:
Re: nifi: How to update and trnaform xml file inside ExecuteScript processor
Sally, there are better ways to approach this:
- First, the default for transforming XML should be to use TransformXml  with an XSLT. It kinda looks like you’re also trying to extract some elements into attributes so I’d look at EvaluateXPath  too. Your flow would then look like [_] --> [TransformXml] --> [EvaluateXPath] --> [_].
- If you must use ExecuteScript, since you’re using Groovy, you don’t have to use the native Java XML APIs. Please have a look at Groovy’s documentation on processing XML  in particular XmlSlurper, DOMBuilder and the GPath expressions if you need them. I can’t really tell what you’re doing with the file locks, but I doubt they’re necessary.
Generally speaking, I think it’d be helpful to look at ExecuteScript as a last resort Swiss army knife for those situations where an existing processor doesn’t do what you need to do. We’re always adding more processors and functionality so you’d be surprised at how many things you can cover without having to drop down to ExecuteScript.
The time and effort to pore through every processor doc is often less than writing (and debugging) the code for ExecuteScript.