Details

    • Type: Rice Research Item
    • Status: Closed
    • Priority: Major
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Component/s: Unknown
    • Labels:
      None
    • Rice Theme:
      Adopting Existing Code
    • Priority Score:
      3
    • Impact if not Implemented:
      Each kuali application what requires batch processing will have to develop their own solution. Implementors of multiple kuali applications will have to learn and support multiple methods of batch development and management.
    • Priority - KFS:
      Low
    • Priority - KC:
      Low
    • Priority - KS:
      No Priority
    • Priority - Rice:
      Low
    • Theme:
      Kuali Application Business Drivers
    • Application Impact:
      Medium
    • Effort Estimate:
      Low ~ 200 hrs

      Description

      KFS developed a framework for building batch jobs/steps using Quartz which can be run through the KFS OLTP or scheduled via a batch scheduler. Many enterprise applications will retain some batch processing requirement. Having a generalized and supported method will allow Kuali applications to utilize a standard framework (rather than having to roll their own) and allow implementors of multiple Kuali application to take advantage of consistency and lower their TCO.

      Low effort estimate since this exists in KFS already. Need to extract, generalize, and bundle with Rice.

        Attachments

          Issue Links

            Activity

            Hide
            coppola Chris Coppola (Inactive) added a comment -

            KFS has a set of batch capabilities that could be abstracted and made available through Rice. This issue needs more description and needs to be prioritized.

            Show
            coppola Chris Coppola (Inactive) added a comment - KFS has a set of batch capabilities that could be abstracted and made available through Rice. This issue needs more description and needs to be prioritized.
            Hide
            cfairlie Cath Fairlie (Inactive) added a comment -

            This may possibly be required in the future, but KS has no need for it right now.

            Show
            cfairlie Cath Fairlie (Inactive) added a comment - This may possibly be required in the future, but KS has no need for it right now.
            Hide
            jcoltrin Jessica Coltrin (Inactive) added a comment -

            Eric and I looked at this and thought this should be championed by someone from KFS if needed.

            Show
            jcoltrin Jessica Coltrin (Inactive) added a comment - Eric and I looked at this and thought this should be championed by someone from KFS if needed.
            Hide
            kymber Kymber Horn added a comment -

            KFS already has this - so shouldn't it be championed by one of the other projects? Or am I missing something?

            Show
            kymber Kymber Horn added a comment - KFS already has this - so shouldn't it be championed by one of the other projects? Or am I missing something?
            Hide
            ewestfal Eric Westfall added a comment -

            I think the scope of this roadmap item is fairly well-defined, but I will document my assumptions here in case someone disagrees:

            1) Extract the backend batch functionality from KFS (the concepts of steps and the step runner) into KFS
            2) Hook the step framework into the component service in a proper fashion, right now this is "hacked" in to allow batch-based system parameters to work properly for KFS.
            3) Extract the batch user interface from KFS into Rice.

            There are actually some fairly important architectural decisions that need to be made here however:

            1) Where should the batch runtime environment execute? Options: within each application that uses the framework, as part of the rice standalone server, can be deployed separately
            2) Where should the batch user interface be deployed. If the batch runtime environment exists in each application, then the user interface should probably be embeddable in each application that uses the batch framework.
            3) Does each application have it's own batch quartz scheduler? Again, this will depend on the answer to the first question.

            From my perspective, an application's batch jobs are likely very application specific. So it probably makes the most sense to have the runtime be embedded in each application or allow for it to be deployed centrally. With the user interface I could go either way, but it probably makes the most sense to have it be an application which can be deployed separately (and communicates with the embedded runtime batch servers via the service bus) and it should probably also be included by default with the Rice standalone server.

            Do any of the others who have weighed in on this jira have any thoughts on the above?

            Show
            ewestfal Eric Westfall added a comment - I think the scope of this roadmap item is fairly well-defined, but I will document my assumptions here in case someone disagrees: 1) Extract the backend batch functionality from KFS (the concepts of steps and the step runner) into KFS 2) Hook the step framework into the component service in a proper fashion, right now this is "hacked" in to allow batch-based system parameters to work properly for KFS. 3) Extract the batch user interface from KFS into Rice. There are actually some fairly important architectural decisions that need to be made here however: 1) Where should the batch runtime environment execute? Options: within each application that uses the framework, as part of the rice standalone server, can be deployed separately 2) Where should the batch user interface be deployed. If the batch runtime environment exists in each application, then the user interface should probably be embeddable in each application that uses the batch framework. 3) Does each application have it's own batch quartz scheduler? Again, this will depend on the answer to the first question. From my perspective, an application's batch jobs are likely very application specific. So it probably makes the most sense to have the runtime be embedded in each application or allow for it to be deployed centrally. With the user interface I could go either way, but it probably makes the most sense to have it be an application which can be deployed separately (and communicates with the embedded runtime batch servers via the service bus) and it should probably also be included by default with the Rice standalone server. Do any of the others who have weighed in on this jira have any thoughts on the above?
            Hide
            tdurkin Terry Durkin added a comment -

            Eric -

            Just to weigh in, I think what you're suggesting (having the runtime be in the application or deployed centrally) makes sense. Regarding the UI, I think having the UI separate that can be deployed with a central Rice instance also makes sense.

            Terry

            Show
            tdurkin Terry Durkin added a comment - Eric - Just to weigh in, I think what you're suggesting (having the runtime be in the application or deployed centrally) makes sense. Regarding the UI, I think having the UI separate that can be deployed with a central Rice instance also makes sense. Terry
            Hide
            ewestfal Eric Westfall added a comment -

            I think my original estimate was likely too low considering that we will need to deal with the user interface extraction which I suspect may be a little bit hairy. We actually had a false start on this once long ago and I'm pretty sure it took longer than 50 hours. 200 hours might be too much but I think 50 is too low.

            Show
            ewestfal Eric Westfall added a comment - I think my original estimate was likely too low considering that we will need to deal with the user interface extraction which I suspect may be a little bit hairy. We actually had a false start on this once long ago and I'm pretty sure it took longer than 50 hours. 200 hours might be too much but I think 50 is too low.
            Hide
            masargen Matt Sargent added a comment -

            In line with this there has been discussion on the Rice Collab list around what a batch file scheduler/monitor should have....

            "Something similar to spring batch having these qualities:
            · processing large volumes of records
            · logging/tracing
            · transaction management
            · job processing statistics
            · job restart
            · skip
            · resource management

            Particularly of interest is the ability to manage jobs (define batch jobs, schedule jobs, and view the results of jobs and records within those jobs)."

            Show
            masargen Matt Sargent added a comment - In line with this there has been discussion on the Rice Collab list around what a batch file scheduler/monitor should have.... "Something similar to spring batch having these qualities: · processing large volumes of records · logging/tracing · transaction management · job processing statistics · job restart · skip · resource management Particularly of interest is the ability to manage jobs (define batch jobs, schedule jobs, and view the results of jobs and records within those jobs)."

              People

              • Assignee:
                masargen Matt Sargent
                Reporter:
                coppola Chris Coppola (Inactive)
              • Votes:
                0 Vote for this issue
                Watchers:
                1 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: