OPEN - issue BATCH-120: Documentation and samples for correct use of listeners and stream interfaces for stateful custom components
This commit is contained in:
@@ -7,254 +7,211 @@
|
||||
|
||||
<glossentry>
|
||||
<glossterm>Batch</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>An accumulation of business transactions over
|
||||
time.
|
||||
</para>
|
||||
<para>An accumulation of business transactions over time.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>Batch Application Style</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
<para>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.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>Batch Processing</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
<para>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.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>Batch Window</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
<para>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.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>Step Controller</glossterm>
|
||||
<glossterm>Step</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>
|
||||
It is the main batch task or Unit of Work controller. It
|
||||
initializes the tasklet, and controls the transaction
|
||||
environment based on commit interval setting, etc.
|
||||
</para>
|
||||
<para>It is the main batch task or unit of work controller. It
|
||||
initializes the business logic, and controls the transaction
|
||||
environment based on commit interval setting, etc.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>Tasklet</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>
|
||||
The main application program created by application developer to process
|
||||
the business logic for each LUW.
|
||||
</para>
|
||||
<para>An application program created by application developer to
|
||||
process the business logic for an entire Step.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>Batch Job Type</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
<para>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.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>Driving Query</glossterm>
|
||||
<glossdef>
|
||||
<para>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.</para>
|
||||
</glossdef>
|
||||
|
||||
<glossdef>
|
||||
<para>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.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>Item</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>
|
||||
An item represents the smallest ammount of complete data for processing. In the most
|
||||
simple terms this might mean a line in a file, a row in a database table, or a particular
|
||||
element in an XML file.
|
||||
</para>
|
||||
<para>An item represents the smallest ammount of complete data for
|
||||
processing. In the most simple terms this might mean a line in a file,
|
||||
a row in a database table, or a particular element in an XML
|
||||
file.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>Logicial Unit of Work (LUW)</glossterm>
|
||||
|
||||
<glossterm>Logicial Unit of Work
|
||||
(LUW)</glossterm>
|
||||
<glossdef>
|
||||
<para>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.</para>
|
||||
<para>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.</para>
|
||||
</glossdef>
|
||||
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
|
||||
<glossterm>Commit Interval</glossterm>
|
||||
<glossdef>
|
||||
<para>A set of
|
||||
LUWs constitute a commit interval.</para>
|
||||
</glossdef>
|
||||
|
||||
<glossdef>
|
||||
<para>A set of LUWs constitute a commit interval.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
|
||||
<glossterm>Partitioning</glossterm>
|
||||
<glossdef>
|
||||
<para>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.</para>
|
||||
</glossdef>
|
||||
|
||||
<glossdef>
|
||||
<para>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.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
|
||||
<glossterm>Staging Table</glossterm>
|
||||
<glossdef>
|
||||
<para>A table
|
||||
that holds temporary data while it is being processed.</para>
|
||||
</glossdef>
|
||||
|
||||
<glossdef>
|
||||
<para>A table that holds temporary data while it is being
|
||||
processed.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
|
||||
<glossterm>Restartable</glossterm>
|
||||
<glossdef>
|
||||
<para>- 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.</para>
|
||||
</glossdef>
|
||||
|
||||
<glossdef>
|
||||
<para>- 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.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
|
||||
<glossterm>Rerunnable</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>
|
||||
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 driving
|
||||
query can be formed so that it will limit the processed rows
|
||||
when the job is restarted than re-runnable = true. This is
|
||||
managed by the application architecture. 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>
|
||||
<title>Understanding Rerunnable</title>
|
||||
<para>
|
||||
If re-runnable = 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 the architecture will have to persist
|
||||
the restart data, which is only available on a restartable job as the
|
||||
restart data is saved and made available from the execution of the
|
||||
last run if restartable = true. In pseudo code it is the following:
|
||||
</para>
|
||||
<para>
|
||||
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 and we're
|
||||
open to suggestions on how to better explain it.
|
||||
</para>
|
||||
</note>
|
||||
</para>
|
||||
<para>a job that is restartable and manages it's own state in terms of
|
||||
previous run's record processing. An example of a rerunnable step is
|
||||
one based on a driving query. If the driving query can be formed so
|
||||
that it will limit the processed rows when the job is restarted than
|
||||
it is re-runnable. This is managed by the application logic. 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". </para>
|
||||
</glossdef>
|
||||
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>Repeat</glossterm>
|
||||
|
||||
<glossdef>
|
||||
<para>One of the most basic units of batch processing, that
|
||||
defines repeatability calling a portion of code until it is
|
||||
finished, and while there is no error. Typically a batch
|
||||
process would be repeatable as long as there is input.
|
||||
</para>
|
||||
<para>One of the most basic units of batch processing, that defines
|
||||
repeatability calling a portion of code until it is finished, and
|
||||
while there is no error. Typically a batch process would be repeatable
|
||||
as long as there is input.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
<glossentry>
|
||||
|
||||
<glossentry>
|
||||
<glossterm>Retry</glossterm>
|
||||
<glossdef>
|
||||
<para>Simplifies the execution of operations with retry semantics most frequently associated
|
||||
with handling transactional output exceptions. Retry is slightly different from repeat, rather than continually calling a block of code,
|
||||
retry is stateful, and continually calls the same block of code with the same input, until it either succeeds, or some type of retry limit
|
||||
has been exceeded. It is only generally useful if the operation is non-deterministic meaning that a retry on a subsequent invocation might
|
||||
succeed because something in the environment has improved.
|
||||
</para>
|
||||
</glossdef>
|
||||
|
||||
<glossdef>
|
||||
<para>Simplifies the execution of operations with retry semantics most
|
||||
frequently associated with handling transactional output exceptions.
|
||||
Retry is slightly different from repeat, rather than continually
|
||||
calling a block of code, retry is stateful, and continually calls the
|
||||
same block of code with the same input, until it either succeeds, or
|
||||
some type of retry limit has been exceeded. It is only generally
|
||||
useful if the operation is non-deterministic meaning that a retry on a
|
||||
subsequent invocation might succeed because something in the
|
||||
environment has improved.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
|
||||
<glossterm>Recover</glossterm>
|
||||
<glossdef>
|
||||
<para>Recover operations handle an exception in such a way that a repeat process is able to
|
||||
continue.
|
||||
</para>
|
||||
</glossdef>
|
||||
|
||||
<glossdef>
|
||||
<para>Recover operations handle an exception in such a way that a
|
||||
repeat process is able to continue.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
|
||||
<glossentry>
|
||||
|
||||
<glossterm>Skip</glossterm>
|
||||
<glossdef>
|
||||
<para>Skip is a recovery strategy often used on file input sources as the strategy for ignoring
|
||||
bad input records that failed validation.
|
||||
</para>
|
||||
</glossdef>
|
||||
|
||||
<glossdef>
|
||||
<para>Skip is a recovery strategy often used on file input sources as
|
||||
the strategy for ignoring bad input records that failed
|
||||
validation.</para>
|
||||
</glossdef>
|
||||
</glossentry>
|
||||
</glossdiv>
|
||||
</glossary>
|
||||
</glossary>
|
||||
@@ -1090,60 +1090,58 @@
|
||||
<classname>java.io.File</classname>. Both XML and Flat File resources can
|
||||
be configured using standard Spring constructs:</para>
|
||||
|
||||
<programlisting> <bean id="customerFileLocator"
|
||||
class="org.springframework.core.io.FileSystemResource">
|
||||
<constructor-arg type="java.lang.String"
|
||||
value="/outputs/20070122.testStream.CustomerReportStep.TEMP.txt" />
|
||||
<programlisting> <bean id="flatFileItemReader"
|
||||
class="org.springframework.batch.item.file.FlatFileItemReader">
|
||||
<property name="resource"
|
||||
value="file://outputs/20070122.testStream.CustomerReportStep.TEMP.txt" />
|
||||
</bean></programlisting>
|
||||
|
||||
<para>The above <classname>Resource</classname> will load the file from
|
||||
the file system, at the location specificied in the constructor. In most
|
||||
spring applications, this solution is good enough. Resources are primarily
|
||||
used to load spring application context files, and perhaps a properties
|
||||
file. The names of these are known at compile time. However, in many batch
|
||||
scenarios, the file name may need to be determined at runtime as a
|
||||
parameter to the job. This could be solved using a
|
||||
<classname>PropertyPlaceholderConfigurer</classname> and '-D' parameters.
|
||||
(System arguments):</para>
|
||||
the file system, at the location specificied. Note that absolute locations
|
||||
have to start with a double slash ("//"). In most spring applications,
|
||||
this solution is good enough because the names of these are known at
|
||||
compile time. However, in batch scenarios, the file name may need to be
|
||||
determined at runtime as a parameter to the job. This could be solved
|
||||
using '-D' parameters, i.e. a system property:</para>
|
||||
|
||||
<programlisting><bean id="customerFileLocator"
|
||||
class="org.springframework.core.io.FileSystemResource">
|
||||
<constructor-arg type="java.lang.String"
|
||||
value="${file.name}" />
|
||||
</bean></programlisting>
|
||||
<programlisting><bean id="flatFileItemReader"
|
||||
class="org.springframework.batch.item.file.FlatFileItemReader">
|
||||
<property name="resource" value="${input.file.name}" />
|
||||
</bean></programlisting>
|
||||
|
||||
<para>All that would be required for this solution to work would be a
|
||||
placeholder configurer in the <classname>ApplicationContext</classname>
|
||||
and the system arguments provided. (-Dfile.name="/file.txt") This solution
|
||||
will work, but it would be much preferred to place the file name in the
|
||||
<classname>JobParameters</classname> of the job and access them that way.
|
||||
To allow for this, Spring Batch provides the
|
||||
system argument (-Dinput.file.name="file://file.txt"). (Note that although
|
||||
a <classname>PropertyPlaceholderConfigurer</classname> can be used here,
|
||||
it is not necessary if the system property is always set because the
|
||||
<classname>ResourceEditor</classname> in Spring already filters and does
|
||||
placeholder replacement on system properties.) </para>
|
||||
|
||||
<para>Often in a batch setting it is preferable to parameterise the file
|
||||
name in the <classname>JobParameters</classname> of the job, instead of
|
||||
through system properties, and access them that way. To allow for this,
|
||||
Spring Batch provides the
|
||||
<classname>StepExecutionResourceProxy</classname>. The proxy can use
|
||||
either job name, step name, or any values from the
|
||||
<classname>JobParameters</classname>, by surround them with %:</para>
|
||||
|
||||
<programlisting> <bean id="inputFile"
|
||||
class="org.springframework.batch.core.resource.StepExecutionResourceProxy" />
|
||||
<property name="filePattern" value="/%JOB_NAME%/%STEP_NAME%/%file.name%" />
|
||||
<property name="filePattern" value="//%JOB_NAME%/%STEP_NAME%/%file.name%" />
|
||||
</bean></programlisting>
|
||||
|
||||
<para>Assuming a job name of 'fooJob', and a step name of 'fooStep', and
|
||||
the key-value pair of 'file.name="fileName.txt' is in the
|
||||
<classname>JobParameters</classname> the job is start with, the following
|
||||
filename will be passed as the <classname>Resource</classname>:
|
||||
"<filename>/fooJob/fooStep/fileName.txt</filename>". It should be noted
|
||||
"<filename>//fooJob/fooStep/fileName.txt</filename>". It should be noted
|
||||
that in order for the proxy to have access to the
|
||||
<classname>StepExecution</classname>, it must be registered as a
|
||||
<classname>StepListener</classname>: </para>
|
||||
<classname>StepListener</classname>:</para>
|
||||
|
||||
<programlisting> <bean id="fooStep" parent="abstractStep"
|
||||
p:itemReader-ref="itemReader"
|
||||
p:itemWriter-ref="itemWriter">
|
||||
<property name="listeners">
|
||||
<list>
|
||||
<ref bean="inputFile" />
|
||||
</list>
|
||||
</property>
|
||||
<property name="listeners" ref="inputFile" />
|
||||
</bean></programlisting>
|
||||
|
||||
<para>The <classname>StepListener</classname> interface will be discussed
|
||||
|
||||
Reference in New Issue
Block a user