Get the count of number of committed records in mule batch commit

Question

I am using batch processing to update the records in DB. Batch commit size is 100. My batch flow looks like below

  <batch:process-records>
           <batch:step name="Batch_Step" >
                <batch:commit doc:name="Batch Commit" size="100">
                    <db:update config-ref="DB_Configuration"bulkMode="true"  doc:name="Update" target="#[flowVars.count]">
                        <db:parameterized-query><![CDATA[update student set
                         column1=value1,
                         column2=value2 where id > 2000;] > </db:parameterized-query></db:update></batch:commit> </batch:step> </batch:process-records>

How can i get the number of records updated in each batch commit? I was expecting the flowVars.count in the target will have that count. But when i print i dont see the count. How can i get the number of records committed successfully?

Answer 1

On complete state tells you overall status of the successful, failure records.

Batch have its own batch flow Variable called <batch:record-variable-transformer doc:name="Record Variable"/> normal flowVars dont work inside Batch.

If you want to process the failure record separately use one more batch step and mark accept-policy="ONLY_FAILURES" , so whatever the record failed in batch step 'Allow only Success' will go to the `handle failure' flow

     <batch:job name="sample_projectBatch" max-failed-records="-1">
    <batch:process-records>
        <batch:step name="Allow only Success " accept-policy="NO_FAILURES">
            <batch:record-variable-transformer doc:name="Record Variable"/>
        </batch:step>
        <batch:step name="handle failure" accept-policy="ONLY_FAILURES">
            <logger level="INFO" doc:name="Logger"/>
         <!-- logic to handle the failure -->
        </batch:step>
    </batch:process-records>
</batch:job>

Answer 2

Can you explain more the "where id > 2000" condition in your query? Is "id" or "2000" coming from your payload?

If not then I don't understand how the query isn't just overwritting the same db records over and over again.