Databases Reference
In-Depth Information
Recycling the scheduling file
As we've already covered, the scheduling process is triggered by the file adapter
reading in the
schedule.xml
file. As part of this activity, the file adapter will move
it to an
archive
directory to ensure that the file is processed just once.
However, in our case, we actually want the file adapter to process the scheduling file
on a daily basis, and to do this, we need to move the file back into the directory being
polled by the adapter.
For this purpose, we have defined the following two directories:
<SOA_HOME>/scheduler/config
<SOA_HOME>/scheduler/execute
When creating our scheduling process, we have configured the file adapter to poll
the
execute
directory on a regular basis (for example, every five minutes), and
archive processed files to the
config
directory.
When the
schedule.xml
file is placed into the
execute
directory for the first time,
this will trigger file adapter to pick up the file and launch the scheduler process, and
at the same time, move the schedule file into the
config
directory.
Within the scheduler process, we then invoke the file adapter to move the
schedule.
xml
file from the
config
directory back to the
execute
directory (see
Chapter 3
,
Service-enabling Existing Systems
for details on how to do this). However, rather than
invoking the
moveFile
operation immediately, we have placed a
<wait>
activity in
front of it that waits until the
startTime
defined at the head of the schedule file, as
shown in the following code snippet:
<?xmlversion="1.0"encoding="UTF-8"?>
<schedulexmlns="http://rubiconred.com/obay/xsd/schedule">
<startTime>0:2:55.125</startTime>
<job>
…
</job>
</schedule>
This has a couple of advantages. The first is we use the
schedule.xml
file to control
when the scheduling process is run, as opposed to configuring the file adapter to poll
the
execute
directory once every 24 hours and then deploy the process at the right
time to start the clock counting.
