Announcement Announcement Module
Collapse
No announcement yet.
validate flatfile Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • validate flatfile

    Hi

    I am parsing a flatfile using the flatfile item reader. as part of the process I want to validate that the data in each row is correct i.e is alphanumeric, length is 10. Does anyone know of a way to do this.

    Currently i have implemented a item processor which will do the validation but am thinking there must be a better way to do this

    thanks

  • #2
    The ItemProcess is the best place to do validation. This allows you to keep the validation separate from the reading and writing. It also lets you cleaning ignore bad records by simply returning "null" from the processor, thus saving the headaches of rolling back and reprocessing anything.

    Comment


    • #3
      Thanks for the reply. My next question is I have validated the file in the item processor and if any of the records are invalid I would like to reject the file. so currently the item processor validates one line and then it rejects the file by throwing the exception. How would I get it to validate the whole file and then reject it rather than just the 1 line which it is doing currently. Thanks

      My configuration for the processor is below

      <bean id="receiptedDeliveriesJob" class="org.springframework.batch.core.job.SimpleJo b">
      <property name="jobRepository" ref="jobRepository" />
      <property name="steps">
      <list>
      <bean id="receiptedDeliveryLoad"
      class="org.springframework.batch.core.step.item.Si mpleStepFactoryBean">
      <property name="commitInterval" value="200" />
      <!-- >property name="startLimit" value="100" /-->
      <property name="jobRepository" ref="jobRepository" />
      <property name="transactionManager" ref="transactionManager" />
      <property name="itemReader" ref="FileItemReader" />
      <property name="itemProcessor" ref="FileItemProcessor" />
      <property name="itemWriter">
      <bean
      class="uk.co.FileWriter">
      <property name="receiptedDeliveriesList" ref="receiptedDeliveriesList" />
      </bean>
      </property>
      </bean>

      <bean id="FileItemProcessor"
      class="uk.co.DeliveriesProcessor">
      <property name="validator" ref="Validator" />
      </bean>

      <bean id="Validator" class="uk.co.Validator" />
      Last edited by fez001; Feb 3rd, 2010, 07:20 AM.

      Comment


      • #4
        Have a look to the exception policy in use. This defines whether or not an exception fails the batch
        Last edited by snicoll; Feb 3rd, 2010, 08:24 AM.

        Comment


        • #5
          can you point me to where this is defined. i have not defined any specific exception policy in my contexts

          Comment


          • #6
            I have had a look at the eception handler and in the repeat template it uses the default exception handler which just rethrows the exception thus failing the job.

            i have written my own exception handler similar to the one in the football job but how do i get the framewrok to use mine. It still seems to use the defualt handler. Looking through the sample I cant see where the football exception handler is injected in or refrenced

            thanks

            Comment


            • #7
              Thanks for the pointer found this on the step config

              Comment


              • #8
                Originally posted by snicoll View Post
                Have a look to the exception policy in use. This defines whether or not an exception fails the batch
                This is almost always unnecessary. If you want a particular type of exception to fail the job, then the preferred way is to simply make that exception non-skippable. (That is, if your step allows skips at all. If it doesn't then all exceptions will fail the step.)

                As for validating all records first, the efficient way to do this is to read and validate each record, but write it to a staging table in the database instead of to its final destination. If you find a bad record, then you can wipe out the table. If all records are ok, then use the next step to dump the staging data into the real destination.

                Comment

                Working...
                X