I think you are confusing the ExtractText and the ReplaceText proessors. The ExtractText doesn't have Search Value & Replacement Value properties but the ReplaceText does. That is why I said post screenshot would be helpful because have I known that its replace Text my answer would have been different. To get the desired result in this case , you need to specify the following pattern in the Search Value Property:   ^(.{5})(.{10}).*   Basically you need to specify the full lline text that you want to replace with the matched group. When you stopped at "^(.{5})(.{10})" it meant that you only want to replace up to the 15th character of the full text with the result $1,$2 and that is why you were getting the reminder of the text. By adding ".*" at the end it will replace the whole line and not just up to the 15th character.  The final config will look like this I hope that makes sense. ... View more

Hi, My Apologies. I think I forgot to mention that in both cases you need to set the Timestamp Format in the CSVRecordWriter to the target format as follows since by default it converts the datetime to epoch time: The point from the conversion in the QueryRecord is to tell the CSVReader that this is a datetime , however without setting the format in the writer it was converting it back to epoch time as the documentation states: Setting the format there is critical to get the desired output. Hope that helps.   ... View more

Hi @xtd , I did not try this but I think what is happening is that when you call the PutDatabaseRecord using CSVReader it doesnt differentiate null and empty string value and it will assume the later is also null and that is why you get the error. Have you tried converting csv into json and then do update record to see if that makes any difference? Another option is to use PutSql so that you can write your own sql but this would be cumbersome in case you have many fields. ... View more

Hi @NagendraKumar , I think you misunderstood how the Stateful UpdateAtrribute works which is OK since a lot of people would think this way too if you have not used before which happened to me as well  :). Basically when you make an UpdateAttribute Stateful by setting the Store State Property, as the value says it will "Store state locally" meaning you only can access the previous state of a given attribute within the processor itself. As I can see,  you are trying to store the Batch Id in the Second Update Attribute and then access it from the first UpdateAttribute and that is why you are getting empty string because it doesnt exist there.  You dont need two UpdateAttributes to manage that and one should do the job. Lets assume we have the following flow which consist of the following processors: 1- GenerateFlowFile: This will simulate setting new BatchId attribute by adding dynamic property BatchID and set it to some value. 2- UpdateAttribute: This will be a stateful and it will have two attributes: One to get the last saved BatchId value and another to set the last saved batch ID to the Current. 3- RouteOnAttribute: This is basically where you compare previous to current and route accordingly. Here is how the flow looks like Here is the config for each processor: GenerateFlowFile:   UpdateAttribute: RouteOnAttribute:   Basically, if you run once for the first time you will get the flowfile routed to the unmatched relationship of the RouteOnAttribute (since no previous value was set), however if you run it again without changing anything the result will be routed to the Match relationship since the previous saved value will equal the new one. Change the value in the GenerateFlowFile and it will go to unmatched and so on. I know you probably wondering how this works since in the UpdateAttribute Im referencing the LastSavedStateBatchID while at the same time its being set to the CurrentBatchID?! which comes first ? well the answer is simple: If you refer to the stateful documentation   where its talking about you will find the following line: " If stateful properties reference other stateful properties then the value for the other stateful properties will be an iteration behind" . Which means PreviousBatchID will be set to the lastSavedStateBatchID before resetting the later to the current . if that makes any sense 🙂 There is a cleaner way of doing it which help eliminate this confusion and the circular reference  by defining Rules under the Advanced feature which you can play with but I feel this way is much shorter. Hope that helps, if it does please accept solution. Thanks   ... View more