I understand, The InvokeHttp processor has a lot of properties and there is a lot of dependencies  on what value triggers what property. In this case I would recommend writing your own custom processor to simplify and you can use some of the code from the original if you want to use same relatioships\same write & read attributes. Another option is to use Parameter Context. I know this is still a lot for them to populate but this way you can instruct them which parameter they need to use on which properties and which properties they need to set themselves. You can even populate those pre configured properties as well in an invokehttp processor and create a template from it and ask them to use the template one instead of creating new one each time. This way you dont have to write any custom code and save your self the effort of coding, troubleshooting and deployment. ... View more

Hi , Have you tried using the InvokeHttp processor for this instead of writing a script ? The thing is if you have nifi secured you have to pass the SSL Context to make an authorized call . I know when I try to call the nifi api to start\stop a processor using the invokehttp I have to pass the SSL Context Service, otherwise I will get the 401 error.   If you find this is helpful please accept solution. Thanks ... View more

Hi , Can you post screenshot for the PutDatabaseRecord configuration and the associated Database Connection Pooling Service configuration to help us troubleshoot what is going on? Are both tables located under the same DB?   ... View more

Hi @vijay_loyalty , I have never tried what you are doing so I might be wrong here but my understanding is when you override the OnTrigger method in your custom invokehttp processor and use the following statement: FlowFile requestFlowFile = session.get(); Its like you are emptying the queue from the flowfile and the  flowfile no longer exists in the session, therefore when you pass the call to the parent class and the parent class try to do the same thing using the same statement there wont be a flowfile hence the error you are getting. I actually tried the following script in an ExecuteGroovyScrip where I called the session.get() twice and it failed: flowFile = session.get() if(!flowFile) return flowFile = session.get() // Processing occurs here session.transfer(flowFile, REL_SUCCESS)  The error message was different but I think both error are related to the same issue. Not sure what you can do about though, I was thinking you have two options: 1- Dont Inherit , instead copy the whole code from the original and create your custom invokehttp processor using the original code plus whatever you need to add. 2- I did not test this so Im not sure if its going to work, but before calling the super.OnTrigger(...) method  try to write the flowfile back to the session after adding the attributes using session.write(...)   If you find this is helpful please accept solution.   ... View more

Hi, The processor sure changed in 2.0 from before , so few things I will check : - Make sure the Request Bondy Enabled is set to true - Make sure the Request Content-Type is set to : multipart/form-data - Make sure to set the Request Multipart Form-Data Name to: file - Once you set the property above, the property Request Multipart Form-Data Filename Enabled becomes visible , make sure it sets to true and it will use the filename attribute in the Content-Disposition header. - Make sure to set the  Response Generation Required property to: true (default false) - Finally, I dont think you need the Content-Disposition dynamic property since its already been set through the above properties. I honestly dont like how in 2.0 there is a lot of visibility dependency with some of the properties where their visibility depends on setting the value of others. It makes it confusing specially when you read the documentation and struggle to find all the mentioned properties until you set the right values. I would rather if its all showing  or at least less visibility dependency on some of them.  Let me know if that works for you or not. If it does, please accept solution. Thanks         ... View more

Hi @jkkk , Can you please post screenshots  of the configurations of the  the InvokeHttp processor and upstream processor\s that creates the json? Also since you mentioned that you are using the evaluateJsonPath  processor make sure that the Destination property is set to flowfile-attribute and not flowfile-content.   ... View more

Hi, Have you looked into the EnforceOrder processor : https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.23.2/org.apache.nifi.processors.standard.EnforceOrder/index.html Based on your description it should do the job. One thing to keep in mind if you want this to work is what is stating in the description : "... [IMPORTANT] In order to take effect of EnforceOrder, FirstInFirstOutPrioritizer should be used at EVERY downstream relationship UNTIL the order of FlowFiles physically get FIXED by operation such as MergeContent or being stored to the final destination. " The group identifier will be in this case the value of the fragment.identifier: ${fragment.identifie} The Order Attribute will be the name of the fragment.index: fragment.index If you find this helpful please accept the solution. Thanks ... View more

Hi @iriszhuhao , The wait processor is supposed to be used with the Notify processor to work correctly and its more suited for when  you have a data that will be split downstream  where each split flowfile will have a common identifier and split count that the Wait-Notify processors can go by  as explained in this article: https://pierrevillard.com/2018/06/27/nifi-workflow-monitoring-wait-notify-pattern-with-split-and-merge/ When you get the data from SQL do you get it all in one flowfile or its already split where each record in one flowfile. If you are not getting a lot of data then I would recommend to get it all in one flowfile and then split it so that you can use this pattern and to run the final SP once. So the design will look something like this:     In this case the Wait-Notify Signal identifier will be the value of the fragment.identifier and the Wait Target Signal Count will be the value of the fragment.count which both written by the Split processor. If you find this helpful please accept solution. Thanks   ... View more