Our Community is getting an upgrade! To get everything ready for the relaunch, we’ll be placing the site in read-only mode starting September 21st.
We really appreciate your understanding while we get things set up behind the scenes. Catch up on all the exciting details about the move here.
Need help or have questions? Drop us a line at [email protected]
Created 08-25-2025 03:22 AM
In NiFi 2.4 and above, the Jython engine is no longer available in ExecuteScript.
Previously, I used scripts like this to read and update attributes:
val = flowFile.getAttribute('x')
flowFile = session.putAttribute(flowFile, 'x', str(int(val) + 10))Now I want to do the same using Python in NiFi 2.4+:
Read an attribute (e.g., x)
Compute a new value
Write it back as an attribute (or a new one)
Keep the original FlowFile content unchanged
What’s the recommended way in NiFi 2.4+?
Any official docs, samples, or best practices for this scenario would be very helpful.
Created on 09-05-2025 04:17 AM - edited 09-05-2025 04:25 AM
In NiFi 2.4 and above, the built-in Jython (Python 2 interpreter) for ExecuteScript has been removed, so the traditional approach using inline Python is no longer supported. There is, however, a modern and robust alternative using NiFi's first-class Python processor support for attribute manipulation, or using Groovy/Clojure in ExecuteScript, or simply leveraging UpdateAttribute for simple logic.
https://nifi.apache.org/nifi-docs/python-developer-guide.html
https://nifi.apache.org/components/org.apache.nifi.processors.script.ExecuteScript/
Created 09-05-2025 05:39 AM
However, I was able to resolve this by leveraging ExecuteStreamCommand (ESC). Specifically, I used the Output Destination Attribute property to push the required attributes into it, which I can then process separately.
Created 09-05-2025 05:36 AM
That approach is not feasible. Adopting a new programming language is impractical given the large number of existing Python scripts that I cannot realistically migrate. The second option is also suboptimal, since creating a dedicated NiFi processor for each script would introduce significant overhead. Furthermore, each custom processor would run in its own isolated virtual environment, leading to excessive heap consumption