                                    ------
                                    Glossary
                                    ------
                                    Wayne Lund
                                    ------
                                    May 2007


 [[1]]<<Batch>>: An accumulation of business transactions over time.

 [[2]]<<Batch Application Style>>: Term used to designate batch as an application style in its own right similar to online, Web or SOA. It has standard elements of input, validation, transformation of information to business model, business processing and output.  In addition, it requires monitoring at a macro level.

 [[3]]<<Batch Processing>>: The handling of a batch of many business transactions that have accumulated over a period of time (e.g. an hour,  day, week, month, or year).  It is the application of a process, or set of processes, to many data entities or objects in a repetitive and predictable fashion with either no manual element, or a separate manual element for error processing.

 [[4]]<<Batch Window>>: The time frame within which a batch job must complete.  This can be constrained by other systems coming online, other dependent jobs needing to execute or other factors specific to the batch environment.

 [[5]]<<Step Controller>>:  It is the main batch task or Unit of Work controller.  It initializes the module, and controls the transaction environment based on commit interval setting, etc.

 [[6]]<<Tasklet>>: The main application program created by application developer to process the business logic for each LUW.

 [[7]]<<Batch Job Type>>: Job Types describe application of jobs for particular type of processing.  Common areas are interface processing (typically flat files), forms processing (either for online pdf generation or print formats), report processing.  s

 [[8]]<<Driving Query>>: A driving query identifies the set of work for a job to do; the job then breaks that work into individual units of work.  For instance, identify all financial transactions that have a status of "pending transmission" and send them to our partner system.  The driving query returns a set of record IDs to process; each record ID then becomes a unit of work.  A driving query may involve a join (if the criteria for selection falls across two or more tables) or it may work with a single table.

 [[9]]<<Logicial Unit of Work (LUW)>>:  A batch job iterates through a driving query (or another input source such as a file) to perform the set of work that the job must accomplish.  Each iteration of work performed is a unit of work.

 [[10]]<<Commit Interval>>: A set of LUWs constitute a commit interval.

 [[11]]<<Partitioning>>:  Splitting a job into multiple threads where each thread is responsible for a subset of the overall data to be processed.  The threads of execution may be within the same JVM or they may span JVMs in a clustered environment that supports workload balancing.

 [[12]]<<Staging Table>>:  A table that holds temporary data while it is being processed. 

 [[13]]<<Restartable>>: - a job that can be executed again and will assume the same identity as when run initially.  In othewords, it is has the same job instance id.

 [[14]]Rerunnable - a job that is restartable and manages it's own state in terms of previous run's record processing. Note>>: Rerunnable is tied to the driving query. If the query can be formed so that it will  limit the processed rows when the job is restarted than re-runnable = true.  Often times a condition is added to the where statement to limit the rows returned by the driving query with something like "and processedFlag != true".

---------------------------------------------------------------------
Note:  If its false the architecture assumes responsibility for tracking which rows have been processed. There is a default strategy for tracking the last record processed by partition.  Most batch jobs only have one partition.  The option is only valid for a restartable job. The reason being is that we have to persist the restart data which is only available on a restartable job.  

In DSL it is the following:
    StartOver ::=  restartable = false.  Restartable ::= true | false
    If (Restartable)
        re-runnable ::= true | false

We don't persist restart information for a non-restartable job.  As you can see, it doesn't make sense. Rerunnable has always confused the best of us. 
----------------------------------------------------------------------------
