The file containing the XML configuration should be specified when starting the Job Scheduler.
The following shows a simple configuration file with a shell job:
<?xml version="1.0">
<spooler>
<config>
<jobs>
<job name="hello_world">
<script language="shell"><![CDATA[
echo hello world
]]></script>
<run_time repeat="10"/>
</job>
</jobs>
</config>
</spooler>
This example shows the configuration of the hello_world job, which the Job Scheduler repeats every 10 seconds.
When this configuration is saved in the hello_world.xml file, the Job Scheduler could be started as follows (for Windows):
…scheduler installation path…\bin\scheduler.exe -config=hello_world.xml
Note that if the Job Scheduler has been started at the command line, it can be stopped using the "Ctrl-C" keys.
Alternatively you could create individual configuration files per job, job chain etc. that would contain exclusively the elements required by these objects:
<?xml version="1.0">
<job>
<script language="shell"><![CDATA[
echo hello world
]]></script>
<run_time repeat="10"/>
</job>
When this configuration is saved in a file
scheduler installation path/config/live/hello_world.job.xml,
then it would be automatically used by a running Job Scheduler.
<?xml encoding="UTF-8"?> and
<?xml encoding="ISO-8859-1"?> are allowed.
Note that the Job Scheduler only processes 8 bit Characters (ISO-8859-1).
The Job Scheduler verifies the XML configuration according to the
Job Scheduler XML Schema.
When the Job Scheduler has been started using the command line,
then the XML schema can be shown using the
-show-xml-schema
command:
…installation path…\bin\scheduler.exe -show-xml-schema
Clicking on an XML element in the schema list below leads to a description of the element:
<spooler
<config central_configuration_directory = "…"
configuration_add_event = "…"
configuration_delete_event = "…"
configuration_directory = "…"
configuration_update_event = "…"
include_path = "…"
ip_address = "…"
java_class_path = "…"
java_options = "…"
log_dir = "…"
mail_xslt_stylesheet = "…"
param = "…"
port = "4444"
priority_max = "1000"
spooler_id = ""
supervisor = "…"
tcp_port = "4444"
udp_port = "4444">
<base file="…"/>
<params>
<param name="…" value="…"/>
</params>
<security>
<allowed_host name="…" level="…"/>
…
</security>
<cluster heart_beat_own_timeout = "…"
heart_beat_timeout = "…"
heart_beat_warn_timeout = "…"/>
<process_classes ignore = "no">
<process_class max_processes = "…"
name = "…"
spooler_id = "…"/>
…
</process_classes>
<schedules>
<schedule name = "…"
substitute = "…"
valid_from = "…"
valid_to = "…"/>
…
</schedules>
<locks>
<lock name= "…" …/>
…
</locks>
<script com_class = "…"
filename = "…"
java_class = "…"
language = "…" >
<include file="…"/>
<![CDATA[
program-code…
]]>
</script>
<http_server>
<http.authentication scheme="basic">
<http.users>
<http.user name="…" password_md5="…"/>
…
</http.users>
</http.authentication>
<http_directory path="…" url_path="…"/>
<web_service job_chain="…" url_path="…" …>
<params>
<param name="…" value="…"/>
…
</params>
</web_service>
…
</http_server>
<holidays>
<holiday date="…"/>
<include file="…"/>
<weekdays date="…"/>
</holidays>
<jobs>
<job
force_idle_timeout = "yes|no"
idle_timeout = "…"
ignore_signals = "…"
java_options = "…"
min_tasks = "…"
name = "…"
order = "no"
priority = "…"
process_class = "…"
spooler_id = "…"
stop_on_error = "yes"
tasks = "1"
temporary = "no"
timeout = "…"
title = "…"
visible = "yes"
>
<settings>
…
</settings>
<description> … </description>
<lock.use lock="…" …/>
<environment>
<variable name="…" value="…"/>
…
</environment>
<params>
<param name="…" value="…"/>
…
</params>
<script com_class = "…"
filename = "…"
java_class = "…"
language = "…" >
<include file="…"/>
<![CDATA[ program-code… ]]>
</script>
or
<process file = "…"
ignore_error = "no"
ignore_signal= "no"
log_file = ""
param = "" >
</process>
<monitor name = "…"
ordering = "…">
<script language="…" …>…<script/>
</monitor>
<start_when_directory_changed directory="…" regex="…" />
<delay_after_error delay="…" error_count="…" />
<delay_order_after_setback delay="…" is_maximum="yes|no"
setback_count="…" />
<run_time let_run="no">
<period begin = "00:00"
end = "24:00"
let_run = "…"
repeat = "…"
single_start = "…"
when_holiday = "…" />
<date date="yyyy-mm-dd"/>
…
<weekdays>
<day day="…">
<period …/>
…
</day>
…
</weekdays>
<monthdays>
<day day="…">
<period …/>
…
</day>
<weekday weekday="…" which="…">
<period …/>
…
</weekday>
…
</monthdays>
<ultimos>
<day day="…">
<period …/>
…
</day>
…
</ultimos>
<month month="…">
<period begin = "00:00"
end = "24:00"
let_run = "…"
repeat = "…"
single_start = "…" />
<weekdays>
<day day="…">
<period …/>
…
</day>
…
</weekdays>
<monthdays>
<day day="…">
<period …/>
…
</day>
<weekday weekday="…" which="…">
<period …/>
…
</weekday>
…
</monthdays>
<ultimos>
<day day="…">
<period …/>
…
</day>
…
</ultimos>
…
</month>
<holidays>
<holiday date="yyyy-mm-dd"/>
<include file="…"/>
…
</holidays>
<at at="yyyy-mm-dd HH:MM:SS"/>
</run_time>
<commands on_exit_code="…"
<start_job job="…" …>
<params>
<param name="…" value="…"/>
<copy_params from="task"/>
<copy_params from="order"/>
…
</params>
</start_job>
<add_order job_chain="…" …>
<params>
<param name="…" value="…"/>
<copy_params from="task"/>
<copy_params from="order"/>
…
</params>
</add_order>
…
</commands>
</job>
…
</jobs>
<job_chains>
<job_chain
distributed = "no"
name = "…"
orders_recoverable= "yes"
title = "…"
visible = "yes"
>
<file_order_source
delay_after_error = "…"
directory = "…"
max = "…"
next_state = "…"
regex = "…"
repeat = "…"
/>
…
<job_chain_node
delay = "…"
error_state = "…"
job = "…"
next_state = "…"
on_error = "suspend|resume"
state = "…"
/>
…
<file_order_sink
move_to = "…"
remove = "yes"
state = "…"
/>
…
</job_chain>
<job_chain name="…">
<job_chain_node.job_chain
job_chain = "…"
error_state = "…"
next_state = "…"
state = "…"
/>
…
<job_chain_node.end
state = "…"
/>
…
</job_chain>
…
</job_chains>
<commands>
…
</commands>
</config>
</spooler>
<add_order>
<add_order
>
job_chain
= "name"
id
= "id"
priority
= "number"
title
= "text"
state
= "text"
job
= "name"
web_service
= "name"
at
= "timestamp"
Order Starting Time
end_state
= "text"
State before which the order should be successfully completed and should leave the job chain
</add_order>
params
Parameters
run_time
The Job Run Time
xml_payload
Adds a new order.
When the <params> element is specified,
then the Scheduler creates a
Variable_set
and makes it available in
Order.payload()
.
<add_order job_chain="job_chain" id="1234" title="My First Order" state="100 at="now+3:00">
<params>
<param name="a_parameter" value="a value"/>
</params>
</add_order>
<commands>
- XML Commands
job_chain="name"
The name of the job chain in which the order is being processed.
id="id"
The alphanumerical identification of the order.
(Note that this parameter may not be set to id - which is an XML reserved word.)
priority="number"
title="text"
The title of the order.
state="text"
job="name"
web_service="name"
When an order has been completed and the end of the job chain reached, it is then transformed with a style sheet and forwarded to a Web Service.
See
<web_service>
.
at="timestamp"
(Initial value:now) Order Starting Time
"now",
"yyyy-mm-dd HH:MM[:SS]",
"now + HH:MM[:SS]" and
"now + SECONDS"
are possible.
See also
Order.at
.
end_state="text"
State before which the order should be successfully completed and should leave the job chain
See
Order.end_state
.
<allowed_host>
<allowed_host
>
</allowed_host>
host
= "host"
level
= "level"
<allowed_host> -
the name or IP address of a computer which is allowed to communicate with the Job Scheduler.
The IP number may be a network address (class A, B or C), in which case all computers belonging to the network are allowed by default. A network address can be recognized in that the last part of the IP number is 0. Note that the Job Scheduler handles the permissions for exact IP numbers with higher priority than network addresses.
<security>
<allowed_host host="127.0.0.1" level="all"/>
<allowed_host host="admin.company.com" level="all"/>
<allowed_host host="192.168.1.0" level="info"/>
</security>
The IP addresses 127.0.0.1 and admin.company.com and the addresses in the Class-C-Network 192.168.1 are allowed to connect with the Job Scheduler. The last entry, however, restricts the commands which may be carried out to those which deliver information.
<security>
<allowed_host host="0.0.0.0" level="all"/>
</security>
Any computer has full access to the Job Scheduler.
Behavior with
<base>
Supplements the <allowed_host> element in the corresponding node of the basic XML configuration with the attribute host= .
Attributes specified here have precedence over those entered in the basic XML configuration.
<security>
- Access Protection for TCP, HTTP and UDP
host="host"
host is the name or the IP address of the computer for which the access protection should be set. It can also be the IP address of a network.
An entry with the host="0.0.0.0" will be used for all hosts which are not specified here.
level="level"
level="none"
The computer has no access.
level="signal"
The computer may carry out signalizing commands.
level="info"
The computer may carry out commands which convey information, but which do not change the Job Scheduler's state.
level="no_add"
The computer has full access,
with the exception of
<add_jobs>
,
<job>
and
<add_order>
.
level="all"
The computer has full access.
<at>
<at
>
</at>
at
= "yyyy-mm-dd hh:mm[:ss]"
<run_time>
- The Job Run Time
at="yyyy-mm-dd hh:mm[:ss]"
Defines a starting point with date and time.
<base>
<base
>
</base>
file
= "filename"
The element <base> references to a basic configuration.
A basic configuration lies in a separate file and has the same structure as a
XML-Konfiguration
(that is to say that it starts with
<spooler>
).
Settings can be made in a basic configuration,
and then either extended or overwritten by those of a higher level configuration.
(A higher level configuration is that containing the <base>
element which references a lower level configuration.)
The scheduler processes the basic configuration first.
For example, jobs can be defined in a basic configuration,
and the higher level configuration can specify the job run times (
<run_time>
).
A basic configuration can call up another basic configuration. However, note that the Job Scheduler does not test whether a basic configuration refers to itself.
<base> can be called repeatedly.
The Job Scheduler works through base configurations in the order in which they are called.
A second basic configuration can either supplement or overwrite a first.
<config>
- Configuration
file="filename"
filename is the name of the file in which the basic configuration is held.
When the file name is not given absolutely,
then the Job Scheduler assumes that the file is to be found in the directory in which the
<base> element is to be found.
The XML elements are executed in the basic configuration with the rights
<allowed_host level="all">
.
Environment variables (e.g. $HOME) are replaced by this attribute (see
Settings which Allow Environment Variables to be Called).
<cluster>
<cluster
>
</cluster>
heart_beat_timeout
= "seconds"
heart_beat_own_timeout
= "seconds"
heart_beat_warn_timeout
= "seconds"
This element can only be used in conjunction with the
-exclusive
or
-distributed-orders
options.
Behavior with
<base>
Supplements the <cluster> element in the corresponding node of the basic XML configuration .
Attributes specified here have precedence over those entered in the basic XML configuration.
<config>
- Configuration
heart_beat_timeout="seconds"
(Initial value:60)
The time limit allowed for the heartbeat of another active Job Scheduler in a cluster to be delayed before the Scheduler is declared dead.
When a Job Scheduler is inactive and operated with the
-exclusive
option set,
then it may then become active.
Messages
|
|
Deactivating that dead Scheduler |
|
|
|
No heart beat for seconds (time) - Scheduler seems to be dead |
heart_beat_own_timeout="seconds"
(Initial value:55)
This setting is used for self-regulation of a Job Scheduler. When a Job Scheduler notices that its own heartbeat has been delayed longer than the time specified in this parameter, then it immediately stops and restarts itself. This means that a Job Scheduler preempts being deactivated by another Scheduler and avoids the short-term possibility of parallel operation because of a delayed heartbeat.
Messages
|
|
Last heart beat was time, seconds ago. Something is delaying Scheduler execution, the Scheduler is aborted immediately |
heart_beat_warn_timeout="seconds"
(Initial value:10)
The time allowed for a delay in the heartbeat of a Job Scheduler before a warning is given out.
Messages
|
|
No heart beat for seconds (time), expecting heart beat within seconds |
|
|
|
No heart beat for seconds (time), ignored for seconds because of recent database reconnect |
<commands>
<commands
>
on_exit_code
= "exitcodes"
This element allows a series of commands to be grouped together. The starting point for these commands then depends upon the relevant parent elements.
<config>
- Configuration
<job>
- Definition of jobs
on_exit_code="exitcodes"
This attribute is mandatory within
<job>
-
it cannot be used anywhere else.
Defines the exit codes which are to cause the commands listed here to be carried out. The following values can be specified here:
on_exit_code="success" is the same as on_exit_code="0".
on_exit_code="error" is valid for all exit codes with the exception of 0
and the exit codes already specified in other
<commands exit_code="…">
.
kill or a program error)
has an exit code with the negative signal value.
For example, for kill this would be -15.
SIGHUP,
SIGINT,
SIGQUIT,
SIGILL,
SIGTRAP,
SIGABRT,
SIGIOT,
SIGBUS,
SIGFPE,
SIGKILL,
SIGUSR1,
SIGSEGV,
SIGUSR2,
SIGPIPE,
SIGALRM,
SIGTERM,
SIGSTKFLT,
SIGCHLD,
SIGCONT,
SIGSTOP,
SIGTSTP,
SIGTTIN,
SIGTTOU,
SIGURG,
SIGXCPU,
SIGXFSZ,
SIGVTALRM,
SIGPROF,
SIGWINCH,
SIGPOLL,
SIGIO,
SIGPWR and
SIGSYS.
Signal names which are not recognised by the operating system are ignored and a warning is given out.
See also
<job ignore_signals="…">
.
on_exit_code="0" on_exit_code="1 2 3 99" on_exit_code="error" on_exit_code="SIGTERM SIGKILL"
Messages
|
|
Invalid value for attribute exit_code="" in <commands> |
|
|
|
Attribute exit_code is not applicable here |
|
|
|
<commands on_exit_code="">: <commands> for exit code is already defined |
|
|
|
Last error occurred when executing command: xml_command |
|
|
|
Signal is unknown on this operating system and is ignored |
|
|
|
Executing <commands on_exit_code="">: |
<config>
<config
>
central_configuration_directory
= "path"
configuration_directory
= "path"
Path to the Configuration Directory
configuration_add_event
= "job_path"
Job for Creating a New Configuration File
configuration_modify_event
= "job_path"
Job for Modifying a Configuration File
configuration_delete_event
= "job_path"
Job for Deleting a Configuration File
supervisor
= "host:port"
spooler_id
= "spooler_id"
port
= "number"
Port Number for TCP and UDP
tcp_port
= "number"
Port for HTTP and TCP commands for the Job Scheduler
udp_port
= "number"
Port for UDP commands for the Job Scheduler
param
= "text"
For free use
log_dir
= "directory"
Protocol directory
include_path
= "directory"
Directory path for <include>
mail_xslt_stylesheet
= "path"
The path to the XSLT style sheet used for the preparation of e-mails
java_class_path
= "file_names"
Java class path
java_options
= "text"
Java options
ip_address
= "ip_number"
The interface IP address for TCP and UDP
</config>
base
Basic Configuration
params
Parameters
security
Access Protection for TCP, HTTP and UDP
cluster
Settings for cluster operation
process_classes
Process Classes
script
Program code
scheduler_script
http_server
HTTP server
holidays
Holidays
jobs
Jobs
job_chains
Job Chains
commands
XML Commands
<config> contains the Job Scheduler configuration information -
in particular, information related to the configuration of jobs.
The <config> element can be repeated when the the spooler_id attribute changes.
Should the -id= parameter not be specified on starting the Job Scheduler,
then the first specified <config> will be used.
Otherwise the spooler_id attribute with the same value will be used.
Behavior with
<base>
Supplements the <config> element in the corresponding node of the basic XML configuration with the attribute spooler_id= .
Attributes specified here have precedence over those entered in the basic XML configuration.
<spooler>
- Root Element of the XML Document
central_configuration_directory="path"
(Initial value:remote)
The default directory is remote
in the configuration file directory -
see
-config
.
This directory is for operation as a supervisory Job Scheduler.
Other Workload Job Schedulers register with the supervisory Job Scheduler using
<config main_scheduler="…">
.
This directory can contain a sub-directory, also containing configuration files,
which the supervisory Job Scheduler replicates when in operation.
Schedulers in a
-exclusive
or
-distributed-orders
cluster
obtain their configuration from a directory with the name of the Scheduler ID
(
-id
).
Job Schedulers that do not belong to a cluster obtain their configuration from a directory
whose name is made up from the computer's name and TCP port number (
<config tcp_port="…">
):
hostname#tcpport
.
In both cases, additional configuration files will be forwarded by the supervisory Scheduler from its
_all directory .
These files are of lesser priority.
It is possible that no directory is specified for a Workload Job Scheduler.
In this case, however, the configuration from the _all directory, if available,
will still be transmitted.
Messages
|
|
Remote configuration directories '' and '' refer to the same IP number |
|
|
|
Remote scheduler '' has not been registered |
|
|
|
No configuration directory for '' |
configuration_directory="path"
(Initial value:live) Path to the Configuration Directory
The default setting is the live directory,
which itself is to be found in the same directory as the configuration file -
see
-config
.
Use of this directory takes the definitions of jobs, job chains and other objects away from the Job Scheduler - see .
configuration_add_event="job_path"
Job for Creating a New Configuration File
The job in question is started when the Job Scheduler loads a new file from its configuration directory.
The job is started when allowed by its
<run_time>
parameter.
It should be defined in the Job Scheduler configuration file,
so that it is recognised when the Job Scheduler reads the configuration directory.
The task which is started by this job has three parameters
(which can be reached using
Task.params
):
The following task parameters are available as environment variables
SCHEDULER_LIVE_EVENT,
SCHEDULER_LIVE_FILEPATH and
SCHEDULER_LIVE_FILEBASE.
configuration_modify_event="job_path"
Job for Modifying a Configuration File
The job in question is started when the Job Scheduler loads a modified file from its configuration directory.
The job is started when allowed by its
<run_time>
parameter.
It should be defined in the Job Scheduler configuration file,
so that it is recognised when the Job Scheduler reads the configuration directory.
Parameters and environment variables are set as for
<config configuration_add_event="…">
.
configuration_delete_event="job_path"
Job for Deleting a Configuration File
The job in question is started when a file which has been loaded by the Job Scheduler is removed from its configuration directory.
The job is started when allowed by its
<run_time>
parameter.
It should be defined in the Job Scheduler configuration file,
so that it is recognised when the Job Scheduler reads the configuration directory.
Parameters and environment variables are set as for
<config configuration_add_event="…">
.
supervisor="host:port"
The supervisory Job Scheduler, at which the current Scheduler should log on and off. This takes place asynchronously and errors do not affect operation.
No more than 4 other (Workload) Schedulers should log on to a supervisory Job Scheduler running on Windows.
The supervisor can set the configuration for the Workload (secondary) Job Schedulers,
see.
<config central_configuration_directory="…">
.
The Job Scheduler retains this new configuration in its cache directory.
spooler_id="spooler_id"
This element is only effective when its attribute is identical to the -id=
parameter which was set as the Job Scheduler was started, or when the -id= parameter
was not set as the Job Scheduler was started.
port="number"
(Initial value:0) Port Number for TCP and UDP
Combines the tcp_port and udp_port settings.
See also
<config tcp_port="…">
.
and
<config udp_port="…">
.
<config port="4444">
The
-port
option has precedence over this parameter.
tcp_port="number"
(Initial value:0) Port for HTTP and TCP commands for the Job Scheduler
The Job Scheduler can accept commands via a TCP port whilst it is running. The number of this port is set here - depending on the operating system - with a number between 2048 and 65535. The default value is 4444.
The Job Scheduler operates a HTTP/HTML server on the same port, enabling it to be reached using a web browser - e.g. via http://localhost:4444.
The Job Scheduler does not respond to the tcp_port=0 default setting either with TCP or HTTP protocols.
This setting can therefore be used to block a Job Scheduler from being accessed - for example via TCP.
See also
<config port="…">
.
<config tcp_port="4444">
The
-tcp-port
option has precedence over this parameter.
udp_port="number"
(Initial value:0) Port for UDP commands for the Job Scheduler
The Job Scheduler can also accept UDP commands addressed to the port specified in this setting. Note that a UDP command must fit in a message and that the Job Scheduler does not answer UDP commands.
The default value of udp_port=0 does not allow the Job Scheduler to open a UDP port.
See also
<config port="…">
.
<config udp_port="4444">
The
-udp-port
option has precedence over this parameter.
param="text"
For free use
Sets the value of spooler.param (Object spooler, property param). For free use in scripts.
log_dir="directory"
Protocol directory
The directory in which the scheduler writes protocols.
log_dir="*stderr" allows the Job Scheduler to write the main protocol to the standard error output (stderr).
include_path="directory"
Directory path for <include>
The directory of the files which are to be included by the
<include>
element.
Environment variables (e.g. $HOME) are replaced by this attribute (see
Settings which Allow Environment Variables to be Called).
The
-include-path
option has precedence over this parameter.
The
factory.ini
(section [spooler],
entry include_path=
…) setting is overwritten by this parameter.
mail_xslt_stylesheet="path"
The path to the XSLT style sheet used for the preparation of e-mails
The path to the XSLT style sheet. XSLT style sheets are used by the Job Scheduler for the preparation of e-mails. At the time of writing (April 2006) this subject is not documented.
java_class_path="file_names"
Java class path
The Java CLASS_PATH setting is made here.
This is a list of paths - on Windows Systems these paths are separated by semi-colons (;),
on Unix systems by colons (:).
Note that jokers can be used in these paths. The Job Scheduler then replaces these jokers with the respective file names. i.e. those existing in the file system.
* and ? characters may be used after the last directory separator.
[ and ] characters can also be
used.
Jokers can be used in every folder name of a path
(as in the csh shell).
{,} characters,
when used in the following syntax:
"xxx
{
alternative1
,
alternative2
,...}
xxx",
e.g. /dir/sos.{hostware,mail.spooler}.jar.
The following points apply to every path in the class_path:
${HOME}) will be replaced
before a path is converted.
These settings are generally made in the
sos.ini
(section [java],
entry class_path=
…) file.
class_path = s:\prod\bind\sos.*.jar;c:\jar\my.jar;c:\jar\*
Environment variables (e.g. $HOME) are replaced by this attribute (see
Settings which Allow Environment Variables to be Called).
The
sos.ini
(section [java],
entry class_path=
…) setting is overwritten by this parameter.
java_options="text"
Java options
This setting specifies the directory in which the HostJava is installed -
e.g. -Djava.library.path=.
These options are passed to the Java Virtual Machine.
These settings are generally made using
sos.ini
(section [java],
entry options=
…).
options = -Xdebug -Djava.library.path=s:/prod/bind
Environment variables (e.g. $HOME) are replaced by this attribute (see
Settings which Allow Environment Variables to be Called).
The
sos.ini
(section [java],
entry options=
…) setting is overwritten by this parameter.
ip_address="ip_number"
(Initial value:0.0.0.0) The interface IP address for TCP and UDP
The IP address to which the TCP and UDP ports are bound. The Job Scheduler can then only be reached by way of this address.
A host name can also be specified.
The default setting is 0.0.0.0, which stands for all IP addresses.
When another IP address as 127.0.0.1 or localhost is given, then the Job Scheduler cannot be reached by way of localhost.
The
-ip-address
option has precedence over this parameter.
<content>
<content
>
</content>
<service_request>
- Web-Dienst-Anforderung
<copy_params>
<copy_params
>
</copy_params>
from
= ""
Parameter Sources
The element hands over the parameters from a task or order.
This can be used in
<start_job>
and
<add_order>
according to the following hierarchy:
<job>
…
<commands on_exit_value="…">
…
<start_job>
or
<add_order>
…
<params>
…
<copy_params from="order">
Should the same parameter name occur twice then the parameter value will be set
according to the order in which the parameters with
<copy_params> and
<param>
are specified.
When the same parameter name occurs more than once, the last value will be used (
any subsequent parameter overrides the value of a predecessor having the same name).
<params>
- Parameters
from=""
Parameter Sources
from="task"
Task parameters (
Task.params
) will be handed over.
from="order"
The parameters of the last order executed
(
Order.params
)
will be handed over.
Note that the order parameters are available after a task has been carried out when:
<process>
or
<script language="shell">
;
Task.end()
method has been called or
An error (
SCHEDULER-329
)
occurs when the job is not order driven
(
<job order="no">
).
Messages
|
|
<copy_params from=""/>: requested parameters are not available |
<copy_params>
<copy_params
>
</copy_params>
from
= ""
Parameter Sources
The element hands over the parameters from a task or order.
This can be used in
<start_job>
and
<add_order>
according to the following hierarchy:
<job>
…
<commands on_exit_value="…">
…
<start_job>
or
<add_order>
…
<params>
…
<copy_params from="order">
Should the same parameter name occur twice then the parameter value will be set
according to the order in which the parameters with
<copy_params> and
<param>
are specified.
When the same parameter name occurs more than once, the last value will be used (
any subsequent parameter overrides the value of a predecessor having the same name).
<params>
- Parameters
from=""
Parameter Sources
from="task"
Task parameters (
Task.params
) will be handed over.
from="order"
The parameters of the last order executed
(
Order.params
)
will be handed over.
Note that the order parameters are available after a task has been carried out when:
<process>
or
<script language="shell">
;
Task.end()
method has been called or
An error (
SCHEDULER-329
)
occurs when the job is not order driven
(
<job order="no">
).
Messages
|
|
<copy_params from=""/>: requested parameters are not available |
<copy_params>
<copy_params
>
</copy_params>
from
= ""
Parameter Sources
The element hands over the parameters from a task or order.
This can be used in
<start_job>
and
<add_order>
according to the following hierarchy:
<job>
…
<commands on_exit_value="…">
…
<start_job>
or
<add_order>
…
<params>
…
<copy_params from="order">
Should the same parameter name occur twice then the parameter value will be set
according to the order in which the parameters with
<copy_params> and
<param>
are specified.
When the same parameter name occurs more than once, the last value will be used (
any subsequent parameter overrides the value of a predecessor having the same name).
<params>
- Parameters
from=""
Parameter Sources
from="task"
Task parameters (
Task.params
) will be handed over.
from="order"
The parameters of the last order executed
(
Order.params
)
will be handed over.
Note that the order parameters are available after a task has been carried out when:
<process>
or
<script language="shell">
;
Task.end()
method has been called or
An error (
SCHEDULER-329
)
occurs when the job is not order driven
(
<job order="no">
).
Messages
|
|
<copy_params from=""/>: requested parameters are not available |
<copy_params>
<copy_params
>
</copy_params>
from
= ""
Parameter Sources
The element hands over the parameters from a task or order.
This can be used in
<start_job>
and
<add_order>
according to the following hierarchy:
<job>
…
<commands on_exit_value="…">
…
<start_job>
or
<add_order>
…
<params>
…
<copy_params from="order">
Should the same parameter name occur twice then the parameter value will be set
according to the order in which the parameters with
<copy_params> and
<param>
are specified.
When the same parameter name occurs more than once, the last value will be used (
any subsequent parameter overrides the value of a predecessor having the same name).
<params>
- Parameters
from=""
Parameter Sources
from="task"
Task parameters (
Task.params
) will be handed over.
from="order"
The parameters of the last order executed
(
Order.params
)
will be handed over.
Note that the order parameters are available after a task has been carried out when:
<process>
or
<script language="shell">
;
Task.end()
method has been called or
An error (
SCHEDULER-329
)
occurs when the job is not order driven
(
<job order="no">
).
Messages
|
|
<copy_params from=""/>: requested parameters are not available |
<date>
<date
>
date
= "yyyy-mm-dd"
</date>
period
Operating period
defines the operating times for a particular day.
See also
<at>
.
<date date="2004-08-22">
<period begin="10:00" end="12:00"/>
<period begin="16:00" end="22:00"/>
</date>
<date date="2004-09-02" begin="14:00" end="18:00"/>
Behavior with
<base>
Replaces the <date> element in the corresponding node of the basic XML configuration with the attribute date= .
<run_time>
- The Job Run Time
date="yyyy-mm-dd"
The Date.
<day>
<day
>
day
= "number"
</day>
period
Operating period
Defines the periods for a particular day.
Behavior with
<base>
Replaces the <day> element in the corresponding node of the basic XML configuration with the attribute day= .
<weekdays>
- Operating Periods for Weekdays
<monthdays>
- Operating periods on particular days of the month
<ultimos>
- Ultimos - Operating Periods for Particular Days of the Month - Counted from the End of the Month
day="number"
defines the day number, which is dependant on the context of the parent element. In the case of days of the week, the English names can be entered here. Note that the names must begin with a small letter.
Mehrere Tage können durch Leerzeichen getrennt angegeben werden.
<delay_after_error>
<delay_after_error
>
</delay_after_error>
error_count
= "integer"
delay
= "seconds|HH:MM|HH:MM:SS|stop"
See
Job.delay_after_error
.
<job …>
<script …>…</script>
<delay_after_error error_count= "2" delay="10" /> <!-- 10 Seconds -->
<delay_after_error error_count= "5" delay="00:01" /> <!-- One Minute -->
<delay_after_error error_count="10" delay="24:00" /> <!-- A Day -->
<delay_after_error error_count="20" delay="STOP" />
</job>
The job is immediately restarted after the first error.
The job is restarted after a delay of 10 seconds after the 2nd, 3rd & 4th consecutive errors, after between 5 and 9 errors the job is delayed each time by a minute, after between 10 and 19 errors the job is delayed 24 hours, after 20 consecutive errors the Job Scheduler stops the job immediately.
<job>
- Definition of jobs
error_count="integer"
The number of consecutively occurring errors before which a job will be delayed.
delay="seconds|HH:MM|HH:MM:SS|stop"
Delay before the job will be rerun.
delay="stop" or delay="STOP"
stops a job after the specified number of consecutive errors.
<delay_order_after_setback>
<delay_order_after_setback
>
</delay_order_after_setback>
setback_count
= "integer"
delay
= "seconds|HH:MM|HH:MM:SS"
is_maximum
= "yes|no"
See
Job.delay_order_after_setback
,
Job.max_order_setbacks
and
Order.setback()
.
<job>
- Definition of jobs
setback_count="integer"
The number of successive setbacks occurring for an order. Different delays can be set for each setback - e.g. 1st setback, 1 second; 2nd setback, 10 seconds; etc.
Specifies the number of sebacks after which an XML element applies. For example, wheresetback_count=5,
the element applies after the 5th setback.
delay="seconds|HH:MM|HH:MM:SS"
The period an order waits after a setback before being restarted in a job.
is_maximum="yes|no"
(Initial value:no)
setback_count= specifies the maximum number of sequential setbacks allowed.
A further setback occurring after this number of setbacks has been reached
(
Order.setback()
)
causes the Job Scheduler to give the order the error state
Job_chain_node.error_state
.
See
Job.max_order_setbacks
.
<description>
<description
>
</description>
include
Includes text from a file
A description of a job which will be shown in the HTML interface.
The text should be coded in HTML.
(This is only possible if <![CDATA[...]]> or <include> is used, because of the strict DTD.)
<job name="my_job">
<description>
This is the description of my job:
<include file="description_of_my_job.txt"/>
</description>
...
</job>
Behavior with
<base>
Replaces the <description> element in the corresponding node of the basic XML configuration .
<job>
- Definition of jobs
<environment>
<environment
>
</environment>
variable
A Variable
Defines additional environment variables for a process.
<job>
- Definition of jobs
<process>
- External programs (as an alternative to <script>)
<start_job>
- start a Task
<file_order_sink>
<file_order_sink
>
</file_order_sink>
state
= "string"
remove
= "yes|no"
move_to
= "directory_path"
<file_order_sink> is implemented using the internal scheduler_file_order_sink job.
The order is completed after the operation.
Should it not be possible to move or remove a file,
then the order will be added to the blacklist.
This ensures that the still existing file can result in a new order being started.
Blacklisted orders can still be removed using
<remove_order>
.
Once the Job Scheduler realises that a blacklisted file has been removed,
then the file will be deleted from the list.
The file can then be re-added to the monitored directory if required.
See also
Directory Monitoring with File Orders and
<file_order_source>
.
<job_chain>
- Job chain
state="string"
The state valid for a job chain node. This state is an end state.
remove="yes|no"
remove="yes" removes the file.
Messages
|
|
Removing file |
move_to="directory_path"
The file will be moved to the directory specified. An already existing file of the same name will be overwritten.
On Unix systems the file can only be moved within the same file system.
Environment variables (e.g. $HOME) are replaced by this attribute (see
Settings which Allow Environment Variables to be Called).
Messages
|
|
Moving file to |
<file_order_source>
<file_order_source
>
</file_order_source>
directory
= "directory_path"
regex
= "regex"
delay_after_error
= "seconds"
repeat
= "no|seconds"
max
= "integer"
next_state
= "string"
Adds a file order source to a job chain. Every file in the source directory with a name corresponding to a regular expression can be added to the job chain as a file order.
See also
Directory Monitoring with File Orders and
<file_order_sink>
.
<job_chain name="my_job_chain">
<file_order_source directory="/tmp/input"/>
<job_chain_node state="first" job="process_file" error_state="ERROR"/>
<file_order_sink state="remove" remove="yes"/>
<file_order_sink state="ERROR" move_to="/tmp/input.error"/>
</job_chain>
<job_chain>
- Job chain
directory="directory_path"
the path to the directory containing the files.
Environment variables (e.g. $HOME) are replaced by this attribute (see
Settings which Allow Environment Variables to be Called).
regex="regex"
A regular expression used to select files according to their names.
delay_after_error="seconds"
(Initial value:repeat)
The default setting is the repeat="…" attribute value.
Should the directory not be readable, then the Job Scheduler will first send an e-mail and then repeatedly try to read the directory until it is successful. The Scheduler will then send a further mail.
Messages
|
|
Recovered from previous error in directory |
repeat="no|seconds"
The Job Scheduler checks for changes in the directory on a regular basis. . The length of time between these checks can be set here.
The default setting on Windows systems is repeat="60".
Further, the Job Scheduler also uses the Windows system directory monitoring,
in order to be able to react immediately to a change in a directory.
This is renewed regularly after the repeat interval has elapsed.
On Unix systems the default value is repeat="10".
This means that the directory is checked every 10 seconds for changes.
Messages
|
|
Recovered from previous error in directory |
max="integer"
(Initial value:100)
The maximum number of files to be taken as orders. Should more files be present, then these extra files are taken on as soon as the first job in the job chain can take on a new order.
Messages
|
|
number more file orders will be added later, after previous orders have been processed |
|
|
|
Continuing reading buffered directory (as of time) |
next_state="string"
Should it not be possible to start the orders in the first job of the job chain, then the initial state of the orders can be specified using this attribute.
<holiday>
<holiday
>
</holiday>
date
= "yyyy-mm-dd"
Defines a holiday - a day on which the Job Scheduler should not run a job.
<holiday date="2004-12-24"/>
Behavior with
<base>
Replaces the <holiday> element in the corresponding node of the basic XML configuration with the attribute date= .
<holidays>
- Holidays
date="yyyy-mm-dd"
The date of the holiday.
<holidays>
<holidays
>
</holidays>
weekdays
Operating Periods for Weekdays
holiday
Holidays on Which a Job Should not Run
include
Includes text from a file
<holidays>
<holiday date="2004-12-24"/>
<holiday date="2004-12-25"/>
<holiday date="2004-12-26"/>
<holiday date="2004-12-31"/>
<include file="holidays-2007.xml"/>
<include file="holidays-2008.xml"/>
</holidays>
<config>
- Configuration
<run_time>
- The Job Run Time
<http.authentication>
<http.authentication
>
scheme
= "scheme"
Authentication
</http.authentication>
http.users
HTTP User Authentication
The Job Scheduler usess this element to obtain authentication from the HTTP client (browser) according to the »Basic« RFC 2617 scheme.
The authentication also applies for the
<web_service>
.
<http_server>
<http.authentication>
<http.users>
<http.user name="Rose Kemp" password_md5="701d051b67bc5fc7c7c919d01f0aa7cb"/>
<http.user name="Jeff Beck" password_md5="eb6801a466d5376639e29cd1d11ecb9f"/>
</http.users>
</http.authentication>
…
</http_server>
Behavior with
<base>
Supplements the <http.authentication> element in the corresponding node of the basic XML configuration .
Attributes specified here have precedence over those entered in the basic XML configuration.
<http_server>
- HTTP server
scheme="scheme"
(Initial value:basic) Authentication
Only the scheme="basic" authentication scheme is implemented.
<http.user>
<http.user
>
</http.user>
name
= "name"
User Authentication
password_md5
= "string"
The Password MD5 Sum
See
<http.authentication>
.
Behavior with
<base>
Replaces the <http.user> element in the corresponding node of the basic XML configuration with the attribute name= .
<http.users>
- HTTP User Authentication
name="name"
User Authentication
password_md5="string"
The Password MD5 Sum
On Unix systems the MD5 password check-sum can generally be obtained using the md5sum command:
echo -n 'password' | md5sum
The MD5 sum comprises only the hexadecimal characters 0-9, a-f and A-F and is 32 characters long.
<http.users>
<http.users
>
</http.users>
http.user
HTTP User Authentication
See
<http.authentication>
.
Behavior with
<base>
Supplements the <http.users> element in the corresponding node of the basic XML configuration .
Attributes specified here have precedence over those entered in the basic XML configuration.
<http.authentication>
- HTTP Authentication
<http_directory>
<http_directory
>
</http_directory>
url_path
= "url_path"
The first directory in a URL path
path
= "path"
File system path
Specifies a directory in the file system which is to be mapped to a directory in a URL path,
The example returns the URL http://host:port/doc/xml/http_directory.html
c:\pub\html\doc\xml/http_directory.html.
Behavior with
<base>
Supplements the <http_directory> element in the corresponding node of the basic XML configuration .
Attributes specified here have precedence over those entered in the basic XML configuration.
<http_server>
- HTTP server
url_path="url_path"
The first directory in a URL path
Specifies the first directory in a URL path, which is be mapped from a file system directory.
The directory specified should start with a forward stroke (/).
<http_directory url_path="/doc/" path="c:/html/my_doc/" />Creates the
c:/html/my_doc/ directory on the URL
starting with /doc/.
path="path"
File system path
The file system path to be mapped to the directory specified in url_path="".
path="c:\pub\html\doc\"
Environment variables (e.g. $HOME) are replaced by this attribute (see
Settings which Allow Environment Variables to be Called).
<http_server>
<http_server
>
</http_server>
http_directory
HTTP File Directory
web_service
Web Service
Behavior with
<base>
Supplements the <http_server> element in the corresponding node of the basic XML configuration .
Attributes specified here have precedence over those entered in the basic XML configuration.
<config>
- Configuration
<include>
<include
>
</include>
file
= "filename"
Path to file to be included
live_file
= "path"
Path to the file to be added from the configuration directory
node
= "xpath"
XPath expression
This element may be included in the text
(outside of <![CDATA[ and ]]>),
in order to include source code which is to be found in other files.
The file is read on a remote computer when such a computer is specified using
<process_class remote_scheduler="…">
.
Should the Job Scheduler not be able to read a file:
<description> element: the Scheduler ignores errors
but adds the error message to the <description>.
<script> element: the Job Scheduler puts the job in the read_error state.
The
<modify_job cmd="reread">
command allows the Scheduler to reread a script.
<script>
- Program code
<description>
- Description
<holidays>
- Holidays
<params>
- Parameters
file="filename"
Path to file to be included
The name of the file whose content is to be included. Should the name of the file not be absolute, then the Job Scheduler assumes different directories, independent of surrounding XML elements:
Environment variables (e.g. $HOME) are replaced by this attribute (see
Settings which Allow Environment Variables to be Called).
live_file="path"
Path to the file to be added from the configuration directory
This attribute can be used directly in:
and specifies, for the file whose content is to be included,
the file path relative to the directory of the file which the <include> came from.
This file must lie within the configuration directory tree.
"/" at the beginning of this path denotes the configuration directory root.
Windows drive letters cannot be used.
When the file containing the <include> does not come from a configuration directory,
the Job Scheduler assumes the configuration directory root.
A change in the file for a file-based job or order
under
<job><params>
or
<order><params>
to be re-read
when the job or order comes from a configuration directory.
|
|
Path reaches beyond root (too many '..'): |
|
|
Invalid name: '' |
Environment variables (e.g. $HOME) are replaced by this attribute (see
Settings which Allow Environment Variables to be Called).
node="xpath"
XPath expression
Only applies for <include> in
<params>
and
selects the
<param>
elements.
The default setting is xpath="params/*".
<job>
<job
>
spooler_id
= ""
name
= "jobname"
title
= "text"
order
= "yes_no"
Order Controlled Job
process_class
= "process_class"
tasks
= "number"
The maximum number of tasks
min_tasks
= "number"
The minimum number of tasks kept running
timeout
= "duration"
The time allowed for an operation
idle_timeout
= "duration"
Limit for the waiting_for_order state
force_idle_timeout
= "yes_no"
Task ended by idle_timeout despite min_task
priority
= "process_priority"
temporary
= "yes_no"
java_options
= "string"
visible
= "yes|no|never"
ignore_signals
= "all|signalnames"
stop_on_error
= "yes|no"
replace
= "yes|no"
warn_if_shorter_than
= "HH:MM:SS|seconds|percentage%"
warn_if_longer_than
= "HH:MM:SS|seconds|percentage%"
</job>
settings
Job Settings
description
Description
lock.use
Lock declaration
environment
Environment Variables
params
Parameters
script
Program code
process
External programs (as an alternative to <script>)
monitor
Job Monitor
start_when_directory_changed
Directory Monitoring
delay_after_error
Job Delay after an Error
delay_order_after_setback
Delay Order after Setback
run_time
The Job Run Time
commands
XML Commands
Defines a job with program code, runtime, etc.
Behavior with
<base>
Supplements the <job> element in the corresponding node of the basic XML configuration with the attribute name= .
Attributes specified here have precedence over those entered in the basic XML configuration.
<jobs>
- Jobs
spooler_id=""
name="jobname"
Every job has a unique name.
Should a job with the same name be defined in one of the basic configurations, then this parameter can be used to change or supplement the settings made in that job.
title="text"
A description of the job (max. 1 line).
order="yes_no"
Order Controlled Job
order="yes" defines a job as being order controlled.
The Job Scheduler will only start an order controlled job when an order for the job exists.
A script can check this attribute using the
Job.order_queue
method.
process_class="process_class"
Defines the name of the process class in which the job should run.
Note that process classes are defined with
<process_classes>
.
tasks="number"
(Initial value:1) The maximum number of tasks
A number of tasks can run in parallel from one job. This attribute specifies the maximum number of tasks for a job.
<lock.use>
: only tasks="1", which only allows one task,
makes sense in combination with an exclusive lock.
min_tasks="number"
(Initial value:0) The minimum number of tasks kept running
The Job Scheduler keeps this minimum number of tasks running. This allows order controlled tasks, which require a long time to initialize, to be held in waiting.
Note that the
<job tasks="…">
element must be large enough.
The Job Scheduler will start additional tasks when:
<run_time>
)
<modify_job cmd="unstop">
<modify_job cmd="continue">
<modify_job cmd="wake">
min_tasks are running
<run_time>
period
pending or running states
(that is, it is not being stopped or has not already stopped).
In order to prevent an overload, the Job Scheduler does not start any new tasks immediately after a task has been completed. The completion of a task causes a new one to be started only in the following situations:
spooler_process()
is called
running_waiting_for_order,
when
<job idle_timeout="0">
)
Task.delay_spooler_process
method
<process>
or
<script language="shell">
)
and the process has not terminated itself immediately after starting
Messages
|
|
min_tasks= is greater than max_tasks= |
|
|
|
task ended immediately after start, so min_tasks= doesn't lead to new tasks |
|
|
|
Less than min_tasks= are running. New tasks will be started. Reason: |
timeout="duration"
The time allowed for an operation
Limits the duration of a task operation (spooler_open, spooler_process etc.)
or the whole task for a non-API task
(
<process>
or
<script language="shell">
).
An error does not occur when the priority of a job has not been set.
Should a task exceed the time allowed, then the Job Scheduler aborts the task.
duration can be specified in seconds or
in the HH:MM or HH:MM:SS formats.
idle_timeout="duration"
(Initial value:5) Limit for the waiting_for_order state
Limits the idle time of an order controlled job (order="yes").
When a task is waiting on the next order and this idle time is exceeded,
then the Job Scheduler ends the task.
The duration can be specified in seconds or in the
HH:MM or HH:MM:SS formats.
idle_timeout="never" allows a job to run indefinitely,
only limited by
<run_time>
.
See also
<job force_idle_timeout="…">
.
force_idle_timeout="yes_no"
(Initial value:no) Task ended by idle_timeout despite min_task
Note that this is only effective with
<job min_tasks ≥ "0">
and
<job idle_timeout="…">
.
force_idle_timeout="yes" ends a task after
idle_timeout has expired,
even when fewer tasks than specified in min_tasks are running.
min_tasks only starts new tasks after the task termination.
In this way tasks can be ended which may not take up a resource such as a database too long when idle.
priority="process_priority"
Sets the priority of a task.
This attribute can be given the following values:
idle,
below_normal,
normal,
above_normal and
high
or the numerical values allowed for the operating system being used.
An error does not occur when the priority of a job is not set.
A task with a higher priority can block the computer.
See
Task.priority_class
.
temporary="yes_no"
temporary="yes" defines a job as being temporary.
This setting is only for
<add_jobs>
.
A job will then be deleted after being carried out and will no longer be recognized.
java_options="string"
Is only effective when a job runs as its own process
(see
<process_classes>
)
and either the job or monitor is implemented in Java.
The options are handed over together with the
<config java_options="…">
Java options.
The interpretation of these options depends on Java.
visible="yes|no|never"
(Initial value:yes)
visible="no" and visible="never" make a job invisible in the results of
<show_jobs>
and
<show_state>
.
The Job Scheduler makes a job visible as soon as a task has been loaded when visible="no" is set.
When visible="never" is set, then this job will never be returned when querying using the
<show_state>
command.
ignore_signals="all|signalnames"
(Initial value:no)
Is only relevant for UNIX systems.
A job whose task process ends with a signal, causes the job to be stopped.
Signals are sent when the task ends either by way of the kill system command or
by way of a program being aborted.
If ignore_signals has not been specified,
then a task ending with a signal stops the job (with the message
SCHEDULER-279
).
ignore_signals="all" means that a job will not be stopped by a signal.
A list of signal names (separated by blanks) can be specified instead of "all".
The following signal names are recognized, depending on the operating system:
SIGHUP,
SIGINT,
SIGQUIT,
SIGILL,
SIGTRAP,
SIGABRT,
SIGIOT,
SIGBUS,
SIGFPE,
SIGKILL,
SIGUSR1,
SIGSEGV,
SIGUSR2,
SIGPIPE,
SIGALRM,
SIGTERM,
SIGSTKFLT,
SIGCHLD,
SIGCONT,
SIGSTOP,
SIGTSTP,
SIGTTIN,
SIGTTOU,
SIGURG,
SIGXCPU,
SIGXFSZ,
SIGVTALRM,
SIGPROF,
SIGWINCH,
SIGPOLL,
SIGIO,
SIGPWR und
SIGSYS.
Signal names which are not recognized by an operating system are ignored and a warning given.
Note that because a task ending with a signal which may be ignored can
cause a TCP connection error (ECONNRESET),
the Job Scheduler is so configured that TCP connection errors only lead to a job being stopped
when ignore_signals="…" does not apply.
The Job Scheduler reacts to this situation with the
SCHEDULER-974
message.
See also
<commands on_exit_code="SIGTERM">
and the Gnu man 7 signal command.
<job name="my_job" ignore_signals="SIGTERM SIGKILL">
Messages
|
|
Process terminated with signal (name) |
|
|
|
Signal is unknown on this operating system and is ignored |
|
|
|
Last error does not stop the job if the task aborts (after kill or crash) with any signal listed in ignore_signals="". In
this case, expect warning SCHEDULER-279 |
stop_on_error="yes|no"
(Initial value:yes)
The default stop_on_error="yes" setting stops a job
when a task ends with an exception or has an "[ERROR]" message in its log file.
An error message can then be written, for example with
Log.error()
.
Specifying stop_on_error="no" does not allow a job to be stopped in this situation.
Should
spooler_process()
end with an exception, then the Job Scheduler sets the order in the error state
(
<job_chain_node error_state="…">
).
This setting is not effective, when either
<delay_after_error>
or
Job.delay_after_error
are used.
Messages
|
|
After task exception and due to stop_on_error='no', the order has been moved to error_state='' |
|
|
|
Job is not stopping because of <job stop_on_error="no">. Task error was: |
|
|
|
Job is stopping because of <job stop_on_error="yes">. Task error was: |
replace="yes|no"
(Initial value:yes)
replace="yes" causes any already existing job definition
to be replaced.
Should this not be possible - for example because a task is running -
then the Job Scheduler will replace the job later.
An order controlled job (
<job order="yes">
)
cannot be replaced.
warn_if_shorter_than="HH:MM:SS|seconds|percentage%"
When a job step is completed in less than the time specified then
the Job Scheduler issues a
SCHEDULER-711
warning.
The time can be specified in the formats HH:MM or HH:MM:SS or
specified as a number of seconds or as percentage.
If specified as a percentage, then 100% is determined from the average run times of previous job steps,
as recorded in the SCHEDULER_HISTORY databese.
warn_if_longer_than="HH:MM:SS|seconds|percentage%"
When a job step is completed in more than the time specified then
the Job Scheduler issues a
SCHEDULER-711
warning.
The time can be specified in the formats HH:MM or HH:MM:SS or
specified as a number of seconds or as percentage.
If specified as a percentage, then 100% is determined from the average run times of previous job steps,
as recorded in the SCHEDULER_HISTORY databese.
<job_chain>
<job_chain
>
name
= "name"
visible
= "yes|no|never"
orders_recoverable
= "yes|no"
distributed
= "yes|no"
title
= "String"
</job_chain>
file_order_source
File Order Source
job_chain_node
Job Chain Nodes
file_order_sink
File Order Sink
job_chain_node.job_chain
Job Chain Nodes
job_chain_node.end
Job chain ends
Adds a new job chain (see the
Job_chain
class).
See Orders,
Job_chain
,
Spooler.create_job_chain()
and
Spooler.add_job_chain()
Simple Job Chains - a Chain of Jobs
Simple job chains contain jobs and are described using the
<job_chain_node>
,
<file_order_source>
and
<file_order_sink>
XML elements.
Superordinate Job Chains - a Chain of Job Chains
Superordinate job chains refer to other job chains and are described using the
<job_chain_node.job_chain>
.
<job_chain_node.end>
XML elements.
A superordinate job chain can only contain simple job chains.
Superordinate job chains cannot be used in combination with distributed orders.
<job_chains>
<job_chain name="Chain_A">
<job_chain_node state= "1" job="job_a" next_state= "2" error_state="999" />
<job_chain_node state= "2" job="job_b" next_state="100" error_state="999" />
<job_chain_node state="100" />
<job_chain_node state="999" />
</job_chain>
</job_chains>
This is the same as the following Scheduler script:
<script language="javascript"><![CDATA[
var job_chain = spooler.create_job_chain();
job_chain.name = "Chain_A";
job_chain.add_job( "job_a", 1, 2, 999 );
job_chain.add_job( "job_b", 2, 100, 999 );
job_chain.add_end_state( 100 );
job_chain.add_end_state( 999 );
spooler.add_job_chain( job_chain );
]]></script>
<job_chains>
<job_chain name="superchain">
<job_chain_node.job_chain state="A" job_chain="job_chain_a"
next_state="B" error_state="ERROR" />
<job_chain_node.job_chain state="B" job_chain="job_chain_b"
next_state="OK" error_state="ERROR" />
<job_chain_node.end state="OK" />
<job_chain_node.end state="ERROR" />
</job_chain>
</job_chains>
Behavior with
<base>
This element may not be specified here when it has already been specified in the basic XML configuration.
<job_chain name="Name"> can be added with unique name.
<job_chains>
- Job Chains
name="name"
The name of the job chain. Note that a job chain can only be defined once.
visible="yes|no|never"
(Initial value:yes)
visible="no" and visible="never" make a job chain invisible in the results of
<show_job_chains>
and
<show_state>
.
The Job Scheduler makes a job chain visible as soon as an order has been added to the chain.
orders_recoverable="yes|no"
(Initial value:yes)
orders_recoverable="yes"
When the Job Scheduler has been configured to store orders in the database, as soon as an order is added to a job's order queue it will be also be stored in the database. After the order has completed the job chain, it will be deleted from the database
The Job Scheduler loads orders from the database on starting and setting up the job chains.
See
Spooler.add_job_chain()
.
This attribute does not function when the Job Scheduler has been configured to work without a database
-
see
factory.ini
(section [spooler],
entry db=
…).
orders_recoverable="no"
The Job Scheduler does not store orders in or load orders from a database.
See Database.
distributed="yes|no"
(Initial value:no)
Only works when specified in conjunction with
-distributed-orders
and causes orders to be distributed over more than one Job Scheduler.
distributed="no" prevents a job chain from being processed by more than one Job Scheduler.
Instead, causes a job chain to be processed on the one Job Scheduler,
as if it were in a non-distributed environment.
Note that in this situation, the name of the job chain must be unique in the cluster
(Note that this is not checked by the Job Scheduler).
title="String"
A job chain can also be given a title.
See also
Job_chain.title
.
<job_chain_node>
<job_chain_node
>
</job_chain_node>
state
= "string"
job
= "job_name"
next_state
= "string"
error_state
= "string"
delay
= "seconds"
on_error
= "suspend|setback"
Adds a new job chain node to a job chain (see the
Job_chain_node
class).
The XML elements
<job_chain_node state="STATE" job="JOB" next_state="NEXT_STATE" error_state="ERROR_STATE"/> <job_chain_node state="ERROR_STATE" />
correspond to the following API calls
job_chain.add_job( "JOB", "STATE", "NEXT_STATE", "ERROR_STATE" ); job_chain.add_end_state( "ERROR_STATE" );
See
Job_chain_node
,
Job_chain.add_job()
and
Job_chain.add_end_state()
.
<job_chain>
- Job chain
state="string"
The state valid for a job chain node.
job="job_name"
The name of the job to be called when an order reaches the state specified.
This attribute should not be specified for the end state.
<job_chain_node state="1" job="my_job"/>
<job_chain_node state="2" job="../job_in_parent_folder"/>
next_state="string"
An order is given the next state when the
spooler_process()
returns return true for the order.
The default setting is the state= attribute of the following <job_chain_node>.
error_state="string"
When return false is returned by a job's
spooler_process()
method,
then the order state is changed to error.
delay="seconds"
(Initial value:0)
Delays an order before handing it over to a job.
on_error="suspend|setback"
After an order processing step,
which the order designates as containing an error,
the Job Scheduler normally allocates the order the error_state state.
The on_error attribute can, however, be used to define another behaviour.
on_error="suspend" has the same effect as
Order.suspended
=true:
the Job Scheduler leaves the order in its current state, however,
the next processing step is not carried out and the order is suspended.
on_error="setback" has the same effect as
Order.setback()
:
the Job Scheduler leaves the order in its current state,
the next processing step is not carried out and the order is treated in the same way as
<delay_order_after_setback>
.
<job_chain_node.end>
<job_chain_node.end
>
</job_chain_node.end>
state
= "string"
End state
Sets a chain of job chains in the end state.
<job_chain>
- Job chain
state="string"
End state
The state valid for this job chain node.
<job_chain_node.job_chain>
<job_chain_node.job_chain
>
</job_chain_node.job_chain>
state
= "string"
job_chain
= "job_chain_name"
next_state
= "string"
error_state
= "string"
Adds a new job chain node to a chain of job chains - i.e. in nested job chains.
Job chains which contain nested job chains cannot be nested in other job chains.
Job chains grouped together through nesting build a common Order_id_space, in which the uniqueness of an order identifier is tested when the order is submitted.
The Job Scheduler does not accept the submission of an order in a job chain, when the order ID has already been allocated in that Order_id_space.
When an order within an Order_id_space is replaced in one job chain in the ID space, then to will also be replaced in other job chains in the same Order_id_space.
<job_chain>
- Job chain
state="string"
The state valid for this job chain node.
job_chain="job_chain_name"
The job chain to which the order is to be handed over when it reaches this state.
next_state="string"
spooler_process()
with return true
from the last completed job, sets an order in this state.
The default value is the value of the state= attribute of the next job chain node.
error_state="string"
spooler_process()
with return false
from the last completed job, sets an order in this error state..
<job_chains>
<job_chains
>
</job_chains>
job_chain
Job chain
See
<job_chain>
.
Behavior with
<base>
Supplements the <job_chains> element in the corresponding node of the basic XML configuration .
Attributes specified here have precedence over those entered in the basic XML configuration.
<config>
- Configuration
<jobs>
<jobs
>
</jobs>
job
Definition of jobs
Behavior with
<base>
Supplements the <jobs> element in the corresponding node of the basic XML configuration .
Attributes specified here have precedence over those entered in the basic XML configuration.
<config>
- Configuration
<lock>
<lock
>
</lock>
name
= "name"
The lock name
max_non_exclusive
= "integer"
Restricting Non-Exclusive Use
A lock can stop two tasks from running at the same time.
See
<lock.use>
for information about the use of locks.
See also
<lock.remove>
<locks>
<lock name="switching_database"/>
<lock name="only_three_tasks" max_non_exclusive="3"/>
</locks>
Behavior with
<base>
Supplements the <lock> element in the corresponding node of the basic XML configuration .
Attributes specified here have precedence over those entered in the basic XML configuration.
<locks>
- Declaration of locks
name="name"
The lock name
max_non_exclusive="integer"
Restricting Non-Exclusive Use
The default setting is unlimited -
which means that with
<lock.use exclusive="no">
an unlimited number of non-exclusive tasks can be started
(but only one exclusive).
Messages
|
|
More lock holders than new max_non_exclusive=: holders |
<lock.use>
<lock.use
>
</lock.use>
lock
= "name"
The name of the lock
exclusive
= "yes|no"
The lock can be made exclusive or non-exclusive
<locks>
<lock name="my_file"/>
</lock>
<job name="my_file_reader" tasks="3">
<lock.use lock="my_file" exclusive="no"/>
…
</job>
<job name="my_other_file_reader">
<lock.use lock="my_file" exclusive="no"/>
…
</job>
<job name="my_file_writer">
<lock.use lock="my_file"/>
…
</job>
The my_file_reader and my_other_file_reads jobs do not use the locks exclusively
and can run at the same time as other jobs.
The my_file_writer job has an exclusive lock and can only run when no other job is running.
This job can change the data set and can be used with the certainty that
no other jobs will attempt to read the data while this job is running.
See also
Task.try_hold_lock()
.
Behavior with
<base>
Supplements the <lock.use> element in the corresponding node of the basic XML configuration .
Attributes specified here have precedence over those entered in the basic XML configuration.
<job>
- Definition of jobs
lock="name"
The name of the lock
The lock itself must have been declared using
<lock>
.
exclusive="yes|no"
(Initial value:yes) The lock can be made exclusive or non-exclusive
exclusive="yes" is the default setting.
This means that the lock is made exclusive and that only one task can acquire the lock and start a task.
All other jobs with the same lock are added to a queue.
Jobs with exclusive="yes" are started before jobs with exclusive="no".
exclusive="no" only blocks exclusive use (exclusive="yes").
A task with exclusive="no" only exclude tasks with exclusive="yes".
The total number of tasks with exclusive="no" can be limited using
<lock max_non_exclusive="…">
.
<locks>
<locks
>
</locks>
lock
Lock Declaration
Behavior with
<base>
Supplements the <locks> element in the corresponding node of the basic XML configuration .
Attributes specified here have precedence over those entered in the basic XML configuration.
<config>
- Configuration
<monitor>
<monitor
>
name
= "Name"
ordering
= "Number"
</monitor>
script
Program code
A monitor makes functions available which can be called before and after a class and before and after
spooler_process()
.
A monitor can start the task or stop the execution of
spooler_process()
.
See the
Monitor_impl
superclass
whose methods can be implemented by a monitor.
<monitor>
<script java_class="spooler_job.Java_monitor"><![CDATA[
package spooler_job;
import sos.spooler.*;
public class Java_monitor extends sos.spooler.Monitor_impl
{
public boolean spooler_task_before() throws Exception
{
spooler_log.info( "SPOOLER_TASK_BEFORE()" );
return true;
}
public void spooler_task_after() throws Exception
{
spooler_log.info( "SPOOLER_TASK_AFTER()" );
}
public boolean spooler_process_before() throws Exception
{
spooler_log.info( "SPOOLER_PROCESS_BEFORE()" );
return true;
}
public boolean spooler_process_after( boolean spooler_process_result ) throws Exception
{
spooler_log.info( "SPOOLER_PROCESS_AFTER(" + spooler_process_result + ")" );
return spooler_process_result;
}
}
]]></script>
</monitor>
Behavior with
<base>
This element may not be specified here when it has already been specified in the basic XML configuration.
<job>
- Definition of jobs
name="Name"
More than one monitor can be set, as long as they have unique names.
The monitors are started in the order specified in the ordering attribute.
spooler_process_after() and spooler_task_after()
are called in reverse order.
ordering="Number"
Specifies the ordering of the monitors - i.e. their .
<month>
<month
>
month
= "month"
</month>
period
Operating period
monthdays
Operating periods on particular days of the month
ultimos
Ultimos - Operating Periods for Particular Days of the Month - Counted from the End of the Month
weekdays
Operating Periods for Weekdays
Sets the periods for a particular day of the month.
In contrast to other elements,
<month> does not take over the attributes from
<run_time>
or the default
<period>
settings.
When <month> is set, then values of
<weekdays>
,
<monthdays>
or
<ultimos>
directly set under
<run_time>
do not apply.
<run_time>
- The Job Run Time
month="month"
One of more names of months, seperated by empty spaces (" "):
"january",
"february",
"march",
"april",
"may",
"june",
"july",
"august",
"september",
"october",
"november",
"december".
<monthdays>
<monthdays
>
</monthdays>
day
Periods for Particular Days
weekday
Periods for a Particular Week Day
Sets the operating period for a particular day of the month.
<monthdays>
<day day="1">
<period begin="10:00" end="12:00"/>
</day>
<day day="2">
<period begin="08:00" end="12:00"/>
<period begin="15:00" end="18:00"/>
</day>
<weekday day="monday" which="1">
<period single_start="02:00"/>
</weekday>
</day>
The example defines the operating periods as being the first day of the month, from 10:00 to 12:00 and the second day of the month from 08:00 to 12:00 and 15:00 to 18:00. In addition, the job should be run on the first Monday of the month at 02:00.
<monthdays>
<day day="5">
<period single_start="16:00"/>
</day>
</monthdays>
This example starts a job on the 5th of each month at 16 Uhr.
Behavior with
<base>
Supplements the <monthdays> element in the corresponding node of the basic XML configuration .
Attributes specified here have precedence over those entered in the basic XML configuration.
<run_time>
- The Job Run Time
<param>
<param
>
</param>
name
= ""
Unique Name
value
= ""
See
<params>
.
Defines the individual parameters for the Job Scheduler, a job or an order. Parameters can be overwritten and extended whilst a job or order is being executed.
Job Scheduler parameters can be called using the
Spooler.variables()
method.
Job parameters can be called using the
Task.params()
method.
The parameters of an order can be called using the
Order.params()
method.
See also the
Variable_set
class.
Behavior with
<base>
Supplements the <param> element in the corresponding node of the basic XML configuration with the attribute name= .
Attributes specified here have precedence over those entered in the basic XML configuration.
<params>
- Parameters
name=""
Unique Name
value=""
<params>
<params
>
</params>
param
Single Parameters
copy_params
Passing Parameters
include
Includes text from a file
Specifies the parameters for the Job Scheduler, a job or an order. The parameters can be overwritten and extended whilst the Job Scheduler is running.
Job Scheduler parameters can be called up using the
Spooler.variables()
method.
Job parameters are called using the
Task.params()
method.
The parameters for an order can be called using the
Order.payload()
method.
See also the
Variable_set
and
<sos.spooler.variable_set>
classes.
Behavior with
<base>
Supplements the <params> element in the corresponding node of the basic XML configuration .
Attributes specified here have precedence over those entered in the basic XML configuration.
<job>
- Definition of jobs
<config>
- Configuration
<web_service>
- Web Service
<period>
<period
>
</period>
begin
= "hh:mm[:ss]"
end
= "hh:mm[:ss]"
repeat
= "hh:mm[:ss] or seconds"
absolute_repeat
= "hh:mm[:ss] | seconds"
single_start
= "hh:mm[:ss]"
let_run
= "yes_no"
when_holiday
= ""
Treatment of Holidays
An operating period defines when a job may run.
This can be a period of time within a day
(with the begin and end attributes) or a start time
(with the single_start attribute).
<run_time>
- The Job Run Time
begin="hh:mm[:ss]"
(Initial value:00:00)
The start of the operating period for the job.
end="hh:mm[:ss]"
(Initial value:24:00)
The end of the operating period.
Should let_run="no" have been set and no further operating period is designated,
then the Job Scheduler ends all tasks which are running (using spooler_close()).
repeat="hh:mm[:ss] or seconds"
Should a job not already be running, then it will be started at the start of the operating period.
After the job has ended, it will be restarted after the time specified,
as far as allowed by the <run_time> attribute.
This repeat interval can be specified in hh:mm, in hh:mm:ss or in seconds.
Cannot be combined with the single_start= attribute.
The job will not be repeated, if repeat="0" (the default value) is set.
absolute_repeat="hh:mm[:ss] | seconds"
Similar to repeat but allows the begin and end times to be specified
independently of a Job Scheduler's operating period.
Starts a job, should it not already be running, at the beginning of a specified time period.
Thereafter, the job will be restarted at regular intervals.
The job starting times then result from the begin time plus a multiple of the
absolute_repeat interval.
This repeat interval can be specified in hh:mm, in hh:mm:ss or in seconds.
Cannot be combined with the single_start= attribute.
single_start="hh:mm[:ss]"
The job should start at the time given.
Cannot be used in combination with the begin=, end= or repeat= attributes.
let_run="yes_no"
This attribute can only be used for jobs and not for orders.
The let_run="no" setting should be made for order controlled jobs.
let_run="yes" allows the Job Scheduler to let a task continue running,
even though this is not allowed by the <run_time> attribute.
let_run="no" causes the Job Scheduler to end a task
(spooler_close is evoked instead of spooler_process),
as soon as the <run_time> is no longer valid.
when_holiday=""
Treatment of Holidays
A period landing on a holiday
<holidays>
is usually suppressed.
Other settings are however possible.
when_holiday="suppress"
The default setting. A period landing on a holiday is suppressed.
when_holiday="ignore_holiday"
A period landing on a holiday is not suppressed.
when_holiday="previous_non_holiday"
When a period occurs on a holiday, it will be brought forward to the last preceding non-holiday.
when_holiday="next_non_holiday"
When a period occurs on a holiday, it will be postponed to the next non-holiday.
<process>
<process
>
file
= "filename"
Path of the Executing Program
param
= "text"
Parameter Line
log_file
= "file_name"
ignore_error
= "yes|no"
ignore_signal
= "yes|no"
</process>
environment
Environment Variables
A process is mounted at the start of a job - that is at the start of a task.
The Job Scheduler monitors this process and closes the task after the process has ended.
An exit code other than 0 will be interpreted as an error.
The exit code is the result of the task and is to be found in task.result.
SCHEDULER-280
).
Task.exit_code
method
and determines the subsequent commands to be carried out.
See <job>
<commands on_exit_code="…">
for further information.
The Job Scheduler hands over the following environment variables:
Is the same as
Spooler.configuration_directory
.
Is the same as
Spooler.hostname
.
For an order controlled job (
<job order="yes">
)
Task.order
.
Order.job_chain
.
Job_chain.name
.
The job chain cofiguration directory path:
is "", when either the job chain did not come from a cofiguration directory
or there is no order available.
Is the same as
Job.configuration_directory
.
The job name
For an order controlled job (
<job order="yes">
)
Task.order
.
Order.id
.
The computer name from
<config supervisor="…">
Port number from
<config supervisor="…">
The same as
Task.id
.
Is the same as
Task.trigger_files
.
As per
Spooler.tcp_port
or empty, when a port has not been set.
As per
Spooler.udp_port
or empty, when a port has not been set.
Behavior with
<base>
This element may not be specified here when it has already been specified in the basic XML configuration.
<job>
- Definition of jobs
file="filename"
Path of the Executing Program
The name of the file containing the program or script with which the process is to be started. The file must be capable of being executed by the operating system.
Environment variables (e.g. $HOME) are replaced by this attribute (see
Settings which Allow Environment Variables to be Called).
param="text"
Parameter Line
Defines the parameter string which will be assigned to the process.
Task parameters can be called using
$
name or
${
name
}
in addition to environment variables.
Variables specified in
<environment>
have no influence on the substitution.
<process file="/tmp/test.cmd" param="ONE=$ONE TWO=$TWO HOME=$HOME LOG=$LOG PATH=$PATH">
<environment>
<variable name="PATH" value="$PATH;/extra"/> <!-- not used for param="" -->
</environment>
</process>
var params = spooler.create_variable_set(); params.value( "ONE" ) = "1"; params.value( "TWO" ) = "2"; spooler.job( "process" ).start( params );
Environment variables (e.g. $HOME) are replaced by this attribute (see
Settings which Allow Environment Variables to be Called).
log_file="file_name"
The Job Scheduler includes the content of this file in its protocol after the process has ended.
Environment variables (e.g. $HOME) are replaced by this attribute (see
Settings which Allow Environment Variables to be Called).
ignore_error="yes|no"
(Initial value:no)
An exit code ≠ 0 causes a job error when ignore_error="no" (the default setting).
The job is then stopped.
An exit code ≠ 0 does not cause a job error when ignore_error="yes".
ignore_signal="yes|no"
(Initial value:no)
Functions on Unix systems.
(An interrupted process returns a Exit code on Windows.
This code is, however, recognized by ignore_error="".)
A signal (i.e. a process termination, such as kill) leads to a job error
when the (default) setting ignore_signal="no" is used.
The job is then stopped.
However the setting ignore_signal="yes" causes a signal not to result in a job error.
ignore_signal="yes" has the same effect as
<job ignore_signals="all">
.
<process_class>
<process_class
>
</process_class>
spooler_id
= "scheduler_id"
name
= "name"
max_processes
= "number"
remote_scheduler
= "host:port"
Task execution on remote computers
replace
= "yes|no"
Defines or modifies a process class.
See also
<process_class.remove>
.
Behavior with
<base>
Supplements the <process_class> element in the corresponding node of the basic XML configuration .
Attributes specified here have precedence over those entered in the basic XML configuration.
<process_classes>
- Process Classes
spooler_id="scheduler_id"
An element having this attribute is only active when the attribute is either:
-id= Job Scheduler start parameter
-id
option is not specified
when starting the Job Scheduler.
name="name"
The name of the process class. Should this attribute be missing or empty ("")
then the default process class will be changed.
See the process_class= attribute of the
<job>
element.
max_processes="number"
(Initial value:30)
Limits the number of processes.
Some operating systems limit the number of processes which the Job Scheduler can start. The number of processes configured here should not exceed the number allowed by the operating system. A value below 64 is usually safe.
For Microsoft Windows systems, the maximum number of processes that are allowed to be executed in parallel is currently 30.
remote_scheduler="host:port"
Task execution on remote computers
Specifies the remote computer
on which the tasks of this process class are to be executed.
This computer is specified using its host name or IP number and TCP port
(see
<config tcp_port="…">
).
The remote computer must allow access with
<allowed_host level="all">
.
Tasks executed communicate with the controlling Job Scheduler via the API. However, the following points should be noted:
<include>
within
<script>
is executed by a task process.
The file to be included is thereby read by the computer which carries out the task.
Subprocess.timeout
and
Task.add_pid()
methods do not work.
The Job Scheduler cannot terminate remote subprocesses whose time limits have been exceeded.
Log.log_file()
is,
as with almost all methods, carried out on the computer on which the Job Scheduler is running
and thereby accesses the files of its local file system.
Some settings are taken from the remote instead of from the controlling Job Scheduler:
sos.ini
(section [java],
entry javac=
…)
factory.ini
(section [spooler],
entry tmp=
…)
<config java_options="…">
<config java_class_path="…">
<config include_path="…">
Messages
|
|
Timeout is not possible for a subprocess running on a remote host (it cannot be killed), pid= |
|
|
|
After lost connection to remote scheduler, process is going to be killed |
|
|
|
Task pid= started for remote scheduler |
replace="yes|no"
(Initial value:yes)
replace="yes" replaces the existing process class.
replace="no" only changes the attributes which are set by the process class.
<process_classes>
<process_classes
>
ignore
= "yes|no"
</process_classes>
process_class
Process classes
Behavior with
<base>
Supplements the <process_classes> element in the corresponding node of the basic XML configuration .
Attributes specified here have precedence over those entered in the basic XML configuration.
<config>
- Configuration
ignore="yes|no"
(Initial value:no)
ignore="yes" allows operation with process classes to be disabled.
This means that tasks run as a part of the Job Scheduler process,
which enables debugging of tasks and orders to be carried out.
<run_time>
<run_time
>
schedule
= ""
Operating Schedule
start_time_function
= "name"
once
= "yes_no"
begin
= "hh:mm[:ss]"
end
= "hh:mm[:ss]"
repeat
= "hh:mm[:ss] or seconds"
single_start
= "hh:mm[:ss]"
let_run
= "yes_no"
when_holiday
= ""
</run_time>
period
Operating period
at
Start Time
date
Operating Times for Particular Days
weekdays
Operating Periods for Weekdays
monthdays
Operating periods on particular days of the month
month
The names of the months
ultimos
Ultimos - Operating Periods for Particular Days of the Month - Counted from the End of the Month
holidays
Holidays
<run_time> defines the times at which the Job Scheduler allows the tasks of this job to run.
This is achieved through the use of operating periods (see
<period>
).
At startup the Job Scheduler selects the first period which is valid (that is, which has not yet ended).
This operating period remains valid until its end. The Job Scheduler then selects the next possible period.
An operating period with single_start is only valid at one point in time.
Daylight Saving Time
The Scheduler recognizes the time changes at the beginning and end of daylight saving time. It always uses local time.
A job with a start time between 02:00 and 03:00 on the night at the end of summer time may be started twice.
Shortened Form Using <period> and the begin=, end=, repeat=, let_run= and single_start= Attributes
<period>
may be used within the <run_time>
the elements
<date>
,
<weekdays>
,
<monthdays>
and
<ultimos>
,
should these possess no
<period>
element of their own.
<run_time>
<period begin="07:00" end="09:00"/>
<monthdays>
<day day="1"/>
<day day="2">
<period begin="22:00" end="23:00"/>
</day>
</monthdays>
</run_time>
becomes
<run_time>
<monthdays>
<day day="1">
<period begin="07:00" end="09:00"/>
</day>
<day day="2">
<period begin="22:00" end="23:00"/>
</day>
</monthdays>
</run_time>
Should none of the
<date>
,
<weekdays>
,
<monthdays>
or
<ultimos>
elements be listed,
then the
<period>
element is applied for every day of the week.
The
begin=,
end=,
repeat=,
let_run= and
single_start= attributes
apply when
<period>
is specified,
and allow the Job Scheduler to create a similar attribute of the same name.
<run_time begin="07:00" end="09:00"/>
becomes
<run_time>
<period begin="07:00" end="09:00"/>
<run_time>
<run_time/>
is, because of the default settings for begin= and end=, the same as
<run_time begin="00:00" end="24:00"/>
is, because <run_time> is empty, the same as
<run_time>
<period begin="00:00" end="24:00"/>
</run_time>
is an operating period valid 24 hours every day.
The job can always run.
<job>
- Definition of jobs
<order>
-
schedule=""
Operating Schedule
Specifies the
<schedule>
that is to be used.
All other attributes and child elements are ignored.
start_time_function="name"
Gives the name of a function in the Job Scheduler script which returns the next start time. The Job Scheduler hands over two parameters to this function.
In the first parameter, the Job Scheduler specifies the point in time
after which the function should return a start time.
This time is specified as a string with the format "yyyy-mm-dd HH:MM:SS".
The function is given the job name or order id in the second parameter.
The function returns a point in time after that specified in the first parameter,
or nothing (i.e. "" or Empty).
The Job Scheduler expects the script to return a string in the format "yyyy-mm-dd hh:mm:ss".
Messages
|
|
Error when calling <run_time> function '': |
|
|
|
<run_time>-Function '' returned start time which is earlier than the requested beginning |
once="yes_no"
(Initial value:no)
When once="yes" the Scheduler
starts a job once after starting itself,
in so far as this is allowed by the <run_time>.
begin="hh:mm[:ss]"
(Initial value:00:00)
Should the <run_time> element be empty
(i.e. it does not contain a <period>),
then the Job Scheduler will generate an operating period using this setting.
This setting is also the default setting for the <run_time>
child elements
(see the shortened form above).
end="hh:mm[:ss]"
(Initial value:24:00)
Should the <run_time> element be empty
(i.e. it does not contain a <period>),
then the Job Scheduler will generate an operating period using this setting.
This setting is also the default setting for the <run_time>
child elements
(see the shortened form above).
repeat="hh:mm[:ss] or seconds"
Should the <run_time> element be empty
(i.e. it does not contain a <period>),
then the Job Scheduler will generate an operating period using this setting.
This setting is also the default setting for the <run_time>
child elements
(see the shortened form above).
single_start="hh:mm[:ss]"
Should the <run_time> element be empty
(i.e. it does not contain a <period>),
then the Job Scheduler will generate an operating period using this setting.
This setting is also the default setting for the <run_time>
child elements
(see the shortened form above).
let_run="yes_no"
This attribute determines whether a running task should be stopped or
allowed to carry out further process steps after a <run_time> period has ended.
The default setting here is that a job does not carry out any further process steps after the period has
ended.
The job is then ended (let_run="no").
The following applies for order controlled jobs:
When an order controlled job defines a period such as 12:00 - 14:00 and an order is started during this time, the order will be completely carried out. After the order has been completed, the idle_timeout value is used to determine whether the task remains active and open for further orders. It is only after the task remains started and has accepted an order that the value of let_run will be considered. let_run="yes": the order will be carried out. let_run="no": the order will only be carried out when its starting time lies within the job<run_time> period.
Should the <run_time> element be empty
(i.e. it does not contain a <period>),
then the Job Scheduler will generate an operating period using this setting.
This setting is also the default setting for the <run_time>
child elements
(see the shortened form above).
when_holiday=""
When this element is empty (i.e. does not contain any <period>),
then the Job Scheduler generates a period with this setting.
Otherwise, this is the default setting for the child elements
(see Shortened Form above).
<schedule>
<schedule
>
</schedule>
name
= "name"
substitute
= "schedule_path"
A schedule for temporary substitution
valid_from
= "yyyy-mm-dd HH:MM[:ss]"
valid_to
= "yyyy-mm-dd HH:MM[:ss]"
The other elements and attributes that can be specified for
<run_time>
can also be specified here,
with the exception of schedule=.
With distributed orders, a change in <schedule> only takes effect
the next time the order proceeds along the job chain.
<schedules>
- Timetables
name="name"
The schedule name.
A named schedule can be called up using
<run_time schedule="…">
.
substitute="schedule_path"
A schedule for temporary substitution
The schedule specified using substitute="schedule_path"
should be replaced with the temporary schedule defined here.
The substitution period is specified using valid_from= and valid_to=.
A temporary schedule cannot be directly called using
<run_time schedule="…">
.
Messages
|
|
schedule: substituted 'schedule' is a substitute |
|
|
|
Substitute 'schedule' is valid now |
|
|
|
Standard 'schedule' is valid now |
valid_from="yyyy-mm-dd HH:MM[:ss]"
If substitute= has been specified and valid_from= not specified,
then the schedule specified will be substituted immediately.
Messages
|
|
'schedule' overlaps schedule |
|
|
|
'schedule' is a substitute for another schedule and cannot be used directly |
valid_to="yyyy-mm-dd HH:MM[:ss]"
If substitute= has been specified and valid_from= not,
then substitution will continue indefinitely.
Messages
|
|
schedule: valid_from=""> is not before valid_to="" |
|
|
|
'schedule' overlaps schedule |
|
|
|
'schedule' is a substitute for another schedule and cannot be used directly |
<schedules>
<schedules
>
</schedules>
schedule
Schedule
Behavior with
<base>
Supplements the <schedules> element in the corresponding node of the basic XML configuration .
Attributes specified here have precedence over those entered in the basic XML configuration.
<config>
- Configuration
<script>
<script
language
= "language"
com_class
= "com_class_name"
encoding
= "encoding"