Announcement Announcement Module
Collapse
No announcement yet.
Report generation using Spring-Batch Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Report generation using Spring-Batch

    Hello All,

    I know that there is a multilineOrderJob in the samples that kind of generate a report-like output. But I wanted to throw this out to you guys so that I can get experts input on this.

    I have a scenario in which I need to generate the header (dynamic information) followed by content (bunch of repeated records) and then finally footer. This is more like the reports, which takes text file as input and outputs text files. I also need to display the page numbers, running totals, group and break on specific criterias.

    Do you guys think it is wise to do that using Spring-Batch (its going to be a challenging one though) OR use some reporting tools and invoke that services from spring-batch?

    Any thoughts/ideas and previous experience is greatly appreciated.

    Thanks!

  • #2
    In my project we decided to generate the report in a "black-box" service that accepts the file path and the limit time interval.

    So this means not using Spring Batch for generating it.

    Then the service was integrated with Spring Batch as a tasklet. The important point is that before to actually generat-report-step another step check that the uploading operations during the time interval (startDate and endDate are JobParameters) was always successfull and this step does directly a query to the Spring Batch tables.

    Please let me know if you find a better approach using directly Spring Batch for the report genertation.


    Ciao,
    Vicio.

    Comment


    • #3
      We had to do something similar to that but generating an XML file. We used a modified version of StaxEventItemWriter that Spring Batch provides (actually we copied and pasted its code), that would allow for a couple of extension points: header and footer.

      We had to go for the copy and paste solution because Spring Batch developers encourage users not to extend readers or writers.

      Comment


      • #4
        I'm curious about the header and footer comment you just made, as I don't quite understand why that would be necessary in an XML file. Also, if you needed a header and footer, is copying and pasting the reader really necessary? Couldn't you cat the header and footer onto the file after processing?

        Comment


        • #5
          Hi Lucas,

          I know there's not such a thing as 'order' on an XML document or anything like it. It's just 'job specifications': the output document must have a set of nodes that compose its body plus another one at the beginning, which comes out of some processing and provides info on the document. And this seems to be needed quite often.

          I guess there are a number of ways to get this done but we figured that, since the step is already creating the file, setting up the header and the root node, it is worth providing the programmer a point in which he can say "hey, take this and put it at the beginning". Then the rest of the batch kicks in and does what it has to. Finally, it isn't so foolish to think one may need to add some info regarding the process itself (say, naively, the number of items processed or any other thing); that's why we included another extension point at the end.

          We're not particularly proud about this solution though because of all the issues with copying and pasting code. But wiring another whole step just to add the header to the XML document, which would have to parse the file and add the node, all within a Tasklet because it doesn't quite fit into the 'item orientation', would be way too much work and make things more difficult for programmers.

          Comment


          • #6
            @telematica: see http://jira.springframework.org/browse/BATCH-620, maybe it can be generalized to cover both FlatFileItemWriter and StaxEventItemWriter - your insights from having it implemented in-house would certainly be welcome.

            Comment


            • #7
              Well, semantically it's precisely what the issue says: being able to have a header and/or footer on an output file.

              Comment

              Working...
              X