...
| Info |
|---|
There is no requirement to use the KFS batch framework. The "Step"s described below are simple Java classes that may be scheduled/executed in a number of ways. See Batch Container for information on hooking into KFS batch from an external scheduler. |
...
This is a sample trigger Spring bean for the scheduleJob. Note that it inherits from the "cronTrigger" parent, and the format of the cron expression.
| Code Block | ||
|---|---|---|
| ||
<bean id="cfdaJobTrigger" parent="cronTrigger">
<property name="jobName" value="cfdaJob" />
<property name="cronExpression" value="00 00 00 1 1,4,7,10 ?" />
</bean>
|
...
There are several properties that are used to control how the batch schedule system behaves. Prior to building KFS, these properties can be overridden by modifying the kuali-build.properites file in the home directory of the user building the application (for other overriding mechanisms, consult the build overview page). Changing these properties will require a rebuild and restart of the application server.
...
use.quartz.scheduling: true or false, used to indicate whether KFS's batch scheduling mechanism should be turned onbatch.mailing.list: the email address to notify regarding the batch execution status. This address may be used by other components as wellbatch.schedule.cron.expression: a cron expression that indicates when all scheduled jobs will be eligible to run, subject to any dependencies. Note that if a trigger is defined for a job, then it will not be affected by the value of this parameter.use.quartz.jdbc.jobstore: true or false. True indicates that the database should be used as a job store, and if false, memory is used. The advantage of using the database as the job store is that the scheduling state of jobs is retained when the application server shuts down or crashes.
...
The namespace and component of the parameter are configured dynamically based on the class name of the running step. The namespace generally corresponds to the package in which the step class is located. The detail type is the simple class name (i.e. without the package name) of the Step class. For more information, consult documentation about the parameter service.
There are two parameter names that apply for the namespace and component described above:
...
For example, to create parameters to control the step class org.kuali.module.gl.batch.ScrubberStep, parameters should have
- namespace KFS-GL because the org.kuali.module.gl) package belongs to the GL module
- component name
ScrubberStep, because it's the simple class name of the class.
...
As KFS was developed, there was no way for us to know how to parse all of the various data files which come in from banks, vendors, credit card companies, travel agencies, and departments. Because of that, there was a preference to build XML abstractions of the files which KFS would pull in. However, a lot of files which a financial system has to deal with are flat files. Because of that, an institutional partner created an XML-configurable flat file parser, which you can read all about.
Batch Container
The original KFS Batch Step Runner would start up, load the application, and shut down - once per step. Over the course of a nighly batch run, the add-on time of that could easily tack half an hour on to the batch window. To deal with that, partner schools developed and contributed a Batch Container, which starts up once and runs all jobs in a batch run, using semaphores to notify it when it should run steps. Read more about it here.
...
Test Batch Jobs - jobs which are useful for development or testing but not for production - are documented in detail here.
| Include Page | ||||
|---|---|---|---|---|
|