Scheduler Swiftlet
Introduction
The Scheduler Swiftlet is an enterprise job scheduler to run registered jobs at a configurable schedule which can be based on stackable calendars.
Job Groups and Jobs
Jobs are registered from other Swiftlets at the Scheduler Swiftlet. The registration takes place in job groups, one for each Swiftlet. Each registered job consists of meta data that describes the job and its job parameters.
Schedules
A schedule must be created to run a job. This is done by the user/administrator via SwiftMQ Explorer/CLI. After the schedule has been enabled, the Scheduler Swiftlet takes care to create and run job instances on base of the schedule's time expression. A job is stopped when it reaches the maximum runtime or the job instance marks itself as finished.
A schedule can be based on a calendar. e.g. to run a job on business
days only. See next section. The time when a job should start is
specified as a time expression. It can be a 'at' or a 'repeat'
expression to start the job at fixed time points during a day or in a
repeat interval, respectively. If the job requires parameters, they must
be specified in the schedule and will be passed to the job instance
during the job start. Optionally, a maximum runtime can be specified. If
this amount of time is reached, the job instance is stopped by the
Scheduler Swiftlet. A schedule has a date range in which it is valid.
For example, one can specify a start date 15th February 2003 and an end
date of 14th April 2003. The defaults for start/end date are now and
forever, respectively.
Calendars
A calendar decides at which day a job will run whereas a schedule's time expression decides at which time. A schedule can be optionally based on a calendar. If not, the job will run every day.
A calendar has multiple parts which can be enabled separately. Parts are
week days, month days, last day in month, annual days, date ranges. The
type of a calendar is either include or exclude. A include
calendar includes the calendar dates whereas exclude excludes it.
One or more parts of a calendar can be enabled. It is also possible to
stack calendars by using another calendar as a base calendar for a new
calendar. For example, one may create a calendar Business Days with
Mo-Fr enabled and another calendar Bank Holidays which is based on
Business Days to exclude bank holidays from business days. Arbitrary
trees of calendars can be build with stacked calendars to create
whatever final custom calendar.
Custom Jobs
To create your own jobs with other scheduler products, you have to use their scheduler classes, implement their interfaces, and you become locked into their product. Not so with SwiftMQ! All jobs in SwiftMQ are provided from Swiftlets. They are already there. No need to implement anything. A bunch of functionality is already implemented, for example, a job to move the content of a local queue to a queue on a remote router, a job to perform a backup on the store, or a job to schedule a routing connector, and much more.
However, that's not all. The JMS Application Container Swiftlet provides
a generic Application Invoker job that can invoke any static JMS
application (one which runs embedded in SwiftMQ). Thus, any Java
application, no matter what it does (it doesn't need to use JMS at all),
is a potential job. You only have to configure it in the JMS Application
Container Swiftlet as a static application and you can schedule it as a
job out of the box. The only pre-condition is to have a custom shutdown
method in your application to ensure it can be stopped. This method is
discovered by Java reflection, so no vendor lock-in, no proprietary
interfaces!
If that is not yet enough, you can of course use the Swiftlet API, create your own Swiftlets and register your own jobs.
Job Monitoring
The Scheduler Swiftlets provides 2 scheduler tables to view the status
of all scheduled jobs. Each job contains a
history with the last 20 job events. A schedule can be log-enabled to
log each start/stop in the router's log file.
Job Groups and Jobs
All available jobs are provided from Swiftlets. They are registered in job groups, one for each Swiftlet. A job group can have multiple defined jobs. The registration is added dynamically, usually when a Swiftlet starts (e.g. during hot deployment), and removed when the Swiftlet stops (e.g. during undeployment).
Job Groups
All job groups are shown in folder Registered Job Groups below the
Usage folder of the Scheduler Swiftlet:
Jobs
Within each job group you'll find all jobs a particular Swiftlet
provides. They are shown in folder Registered Jobs below a job group.
Each entry there describes a job; it is meta data to show you what the
job does and what parameters it requires. The parameters, if any, are
listed under folder Parameters of the job. A parameter has a name, an
optional default value and is marked as mandatory or optional.
Basically, if you like to schedule a job, you check the registration of the job, note the job group, job name and the parameters, define a schedule and you're done.
Calendars
A calendar decides at which day a job will run whereas a schedule's time expression decides at which time. A schedule can be optionally based on a calendar. If not, the job will run every day.
Parts of a Calendar
A calendar consists of the following parts:
- Week days
- Month days
- Last month day
- Annual days
- Date ranges
Each part must be enabled separately, only enabled parts are respected.
The type of a calendar, include or exclude, decides whether the
marked dates in an enabled part are included or excluded. Instead of
using multiple parts of a single calendar it is recommended to stack
calendars (described in a further section) which is much more flexible.
Part: Week Days
This part can be used to set the week days of a calendar:
The above example enables Monday to Friday. If the calendar is of type
include, then Monday to Friday are valid but Saturday and Sunday are
invalid. If it is exclude, then Saturday and Sunday are valid but
Monday to Friday are invalid.
If the above calendar is saved in the routerconfig.xml, it looks like this:
<calendar name="Business Days" enable-weekdays="true" type="include">
<weekdays day-02="true" day-03="true" day-04="true" day-05="true" day-06="true"/>
</calendar>
As you see, Monday is day-02, so the first day in a week is always
Sunday (day-01). You might consider it if you configure a calendar
directly in the routerconfig.xml.
Part: Month Days
This part can be used to set the month days of a calendar:
The above example enables the days 5, 10, 15, 20, 25, 30 of a month. If
the calendar is of type include, only these days are valid and the
rest days of the month are invalid. If it is exclude, all days of the
month are valid, except the marked days.
Part: Last Month Days
The last day of a month varies. It might be the 28th February, 30th
April, and so on. Some jobs might run on every last day in a month, e.g.
end of month processing. This can be specified in a calendar by enabling
the part Month Days AND Last Month Day (both!):
The above example enables the last day of a month. If the calendar is of
type include, the day is valid and all other days of a month are
invalid. If it is exclude, all days of a month are valid, except the
last day.
Part: Annual Days
This part of a calendar can be used to specify fixed dates of a year like bank holidays:
The above example defines 2 annual days, the 1st January (New Year) and
the 3rd October (German Reunion Day). Since it is of type exclude,
these days are excluded.
Part: Date Ranges
This part of a calendar can be used to specify date ranges like company holidays and so on:
The above example defines 2 date ranges, Summer Holiday and Winter Holiday. Since it is of type exclude, these date ranges are excluded.
Stacking Calendars
The real power of calendars is that you can build stacks of calendars, that is, you can create a calendar which is based on another calendar which might be based on another calendar and so on. Look at this example:
The left calendar Business Days is of type include and uses the week
days part to enable Monday thru Friday. It hasn't a base calendar, so
it's just that Monday thru Friday are valid.
The middle calendar Bank Holidays is of type exclude and uses the
annual days part with 2 bank holiday entries. It is based on calendar
Business Days, referenced via attribute Base Calendar. The result is
that Monday thru Friday are valid (from Business Days), except 1st
January and 3rd October (from Bank Holidays).
The right calendar Company Holidays is of type exclude and uses the
date range part with a single date range. It is based on calendar "Bank
Holidays". The result is that Monday thru Friday are valid (from
Business Days), except 1st January and 3rd October (from "Bank
Holidays"), and except from 1st February 2002 to 10th February 2002
(from Company Holidays).
Since the calendars are only connected by their name, you can build any combination of calendars, re-use existing calendars and so on. Only the sky is the limit!
Modifying Calendars
All changes you perform on calendars (create a new calendar, modify or delete a calendar) are immediately applied to schedules. That is, all schedules which have a reference to the calendar (directly or indirect via a stacked calendar) are determined. If a job instance of these schedules is currently running, it is stopped and the schedule will be re-scheduled on base of the changes.
Therefore, if you don't want that a running job will be stopped due to a change, wait with your changes until your job(s) are finished, then disable the resp. schedule(s) and apply your calendar changes. Thereafter, enable the schedule(s).
Schedules
Jobs are started and stopped on base of schedules. Before you create a schedule, you should know:
- the name of the calendar to use
- the name of the job group
- the name of the job
- the job parameters
Then select folder Job Schedules, perform a right mouse click, and
select "Create a new Entity":
A dialog to enter the schedule appears:
The fields have the following meanings:
| Field | Description |
|---|---|
| Name | The name of the schedule, e.g. "daily backup". |
| Calendar | The name of the calendar to use. Optional. |
| From Date | The date when the schedule becomes valid. Optional, default is "now". |
| To Date | The date after which the schedule expires. Optional, default is "forever". |
| Enabled | Enables/disables the schedule. |
| Job Group | The name of the job group. |
| Job Name | The name of the job. |
| Logging Enabled | If enabled, start/stop of job instances are logged in the router's log file. |
| Max. Runtime | The maximum runtime of a job. Optional and depends on the job. The format is "<n>('h'|'m'|'s')", e.g. 1h is one hour, 30m is thirty minutes and so on. If specified, a job instance is explicitely stopped from the Scheduler Swiftlet after this amount of runtime. |
| Time Expression | The time expression. See below. |
Time Expressions
The time expression can be specified in 2 different formats: as an 'at' expression or a 'repeat' expression.
'at' Expression
The 'at' expression specifies fixed time points during the day. The format is:
'at' HH:mm[:ss][, HH:mm[:ss]...]
Example:
at 10:00, 12:30:45, 15:15
'repeat' Expression
The 'repeat' expression specifies a repeat interval. The format is:
'start' HH:mm[:ss] 'stop' HH:mm[:ss] 'delay' <n>('h'|'m'|'s') ['repeat' <m>]
Example:
start 09:10:15 stop 18:00 delay 15s
This starts the job at 09:10:15 and repeats it every 15 seconds till 18:00.
Example:
start 09:10:15 stop 18:00 delay 15s repeat 100
This starts the job at 09:10:15 and repeats it every 15 seconds till 18:00 or until it reaches 100 invocations per day. The "repeat 100" is for convenience. You can also compute the absolute stop time.
System Time Changes during Execution
If the system time is changed during execution of a schedule (e.g. due to Summer/Winter time change, NTP synchronization), the following applies:
- A schedule with a 'at' time expression is handled as an absolute time. For example, if the time expression is "at 17:15" and the current time is changed from 16:00 to 15:00, the schedule will be executed at 17:15 of the new time.
- A schedule with a 'repeat' time expression is handled as a relative
time. That is, the delta of a time change is applied to the next
execution time of the schedule. For example, if the time expression
is
start 00:00 stop 23:59 delay 30mand the current time is 17:15 then the next execution will be at 17:30. If the system time is changed to 18:15, the next execution will be at 18:30 and then 19:00, 19:30 etc. Note that until the current execution is finished, theUsagesection of the schedule will display the next execution time on base of the system time before the change (in this example it will display 17:30).
Example
Say, we have a queue containing order messages. The messages are
processed locally from a JMS client (an order processor). However, it
might be that the local order processor is too busy to process all
orders. Thus, we want to move all messages of the local order queue to a
order queue on router2 where another order processor can process it.
This should be done on business days, every 2 hours. Only those messages
should be move which are marked as URGENT via a JMS property
OrderPriority. No problem, we will use the Queue Mover job for this.
First of all, we create the schedule:
<img src=/docs/img/ce/swiftlets/scheduler/sched3.gif class="img-responsive" />
We have to define further job parameters for the Queue Mover job, so
we cannot enable the schedule yet. We will do it later. Click the
Create button. The new schedule will be shown under the
Job Schedules folder. Select folder Parameters, do a right click and
select Create a new Entity:
Specify the Source Queue parameter:
Repeat the step to specify the Target Queue parameter:
The last parameter is Message Selector:
Your schedule is finished now. All you have to do to activate it is to enable it. Thereafter, don't forget to save the router configuration.
To monitor your schedule, please check the Monitoring section.
Message Jobs
We have removed the old-fashioned message job scheduler from this Swiftlet.
Please have a look here:
which is much more scalable.
Monitoring
Overview
Active schedules are shown in the Usage folder of the Scheduler
Swiftlet. There are 2 sub folder, Active Job Schedules and "Active
Message Schedules":
Monitoring Job Schedules
Select folder Active Job Schedules, right mouse click, and select
Show Entity Table:
This shows you a table with all active job schedules and their resp. status:
Monitoring a Schedule's History
Each active schedule has a history with the last 20 state changes. This
history is located in folder History of the resp. entry:
Select the folder, right mouse click, Show Entity Table, and you will
see the history as a table:
Schedule States
An active schedule has a state. The following table shows all states a schedule can have:
| State | Description |
|---|---|
| NONE | Schedule has been activated and has been placed in the Scheduler's queue. |
| WAITING FOR JOB REGISTRATION | Schedule waits for the registration of the job group/job, specified in the schedule. If you have a typo in the job group/name, this might be the reason for this state. |
| SCHEDULED | The next job instance has been scheduled. See "Next Start". |
| RUNNING | A job instance is running. See "Next Stop" if the schedule has a maximum runtime. |
| STOPPED | The job instance has been stopped. See "Message" if the job has returned an informational message. |
| SCHEDULE DISABLED | The schedule is disabled. |
| SCHEDULE EXPIRED | The schedule has been expired. |
| JOB ERROR | The last running job instance has been terminated with an error. See "Message" for the exception message. |
Registry
This job registry contains all job groups and jobs provided from Standard, Kernel, and Swiftlets.
Job Group: Accounting
Job: Accounting Enabler
The Accounting Enabler job activates an accounting connection on job start and deactivates it on job stop. The name of the accounting connection must be specified as parameter. The job requires to set a maximum runtime to deactivate the accounting connection. Otherwise it would be active forever.
The implementation of the Accounting Enabler job is quite simple. It
sets the enabled attribute to true on job start and to false on
job stop. Therefore, an accounting connection which should run as a job
should be initially disabled.
Since 8.0.0.
| Parameter | Mandatory | Description |
|---|---|---|
| Connection Name | Yes | Name of the accounting connection. |
Job Group: File Cache
Job: File Cache Cleanup
The File Cache Cleanup job removes expired files from file caches. The
file caches are determined from a single parameter which contains a
SQL-Like predicate. For example, a predicate of order% performs a
cleanup on all file caches which names start with order. The File
Cache Cleanup job provides more flexibility than to use the
interval-based cleanup per file cache. Keep in mind that you should set
the cleanup intervals to 0 if you use the File Cache Cleanup job.
Since 9.4.0.
| Parameter | Mandatory | Description |
|---|---|---|
| Cache Name Predicate | Yes | SQL-Like predicate to select file cache names |
Job: File Copier
The File Copier job copies files from a source cache, which must reside on the router where the job runs, to a target cache, which can be the local or a remote router. Transferred files at the target cache are identfied by a new link.
Since 9.4.0.
| Parameter | Mandatory | Description |
|---|---|---|
| Source Cache | Yes | Name of the source file cache |
| Target Router | Yes | Name of the target router |
| Target Cache | Yes | Name of the target file cache |
| Message Selector | No | Optional SQL92 message selector to select files |
| Delete After Transfer | No | Delete file after transfer (= move), default is false |
Job: File Purger
The File Purger job removes messages from a single file cache, optionally based on a message selector.
Since 9.4.0.
| Parameter | Mandatory | Description |
|---|---|---|
| Cache Name | Yes | File cache name |
| Message Selector | No | Optional SQL92 message selector to select files |
Job Group: Queue Manager
Job: Queue Cleanup
The Queue Cleanup job removes expired messages from queues. The queues
are determined from a single parameter which contains a SQL-Like
predicate. For example, a predicate of tmp$% performs a cleanup on all
temporary queues, rt$% on all routing queues, test% on all queues
starting with test like testqueue and so on. The Queue Cleanup job
provides more flexibility than to use the interval-based cleanup
processes. Keep in mind that you should set the cleanup intervals
(default or per queue) to 0 if you use the Queue Cleanup job.
| Parameter | Mandatory | Description |
|---|---|---|
| Queue Name Predicate | Yes | SQL-Like predicate to select queue names |
Job: Queue Cleanup DLQ
This job works like the Queue Cleanup job except that it moves expired
messages to the router's deadletter queue routerdlq for further
processing.
| Parameter | Mandatory | Description |
|---|---|---|
| Queue Name Predicate | Yes | SQL-Like predicate to select queue names |
Job: Queue Mover
The Queue Mover job moves messages from a source queue to a target queue. The target queue may reside on a remote router. An optional message selector can be specified to select messages on base of JMS properties out of the source queue. This job is excellent for tasks like end of day processing to move all unprocessed messages to a queue on another router for further processing.
| Parameter | Mandatory | Description |
|---|---|---|
| Source Queue | Yes | Name of the source queue |
| Target Queue | Yes | Name of the target queue |
| Message Selector | No | Optional SQL92 message selector |
Job: Queue Purger
The Queue Purger job removes messages from a single queue, optionally based on a message selector.
| Parameter | Mandatory | Description |
|---|---|---|
| Queue Name | Yes | Queue name |
| Message Selector | No | Optional SQL92 message selector |
Job: Multi Queue Purger
The Multi Queue Purger job removes messages from multiple queues, optionally based on a message selector. Use this job carefully!
| Parameter | Mandatory | Description |
|---|---|---|
| Queue Name Predicate | Yes | SQL-Like predicate to select queue names |
| Message Selector | No | Optional SQL92 message selector |
Job: Queue Reset
The Queue Reset job resets the consumed/produced message counter on the matching queues to zero. This can be used e.g. to reset the counters every day on midnight to get daily counts.
| Parameter | Mandatory | Description |
|---|---|---|
| Queue Name Predicate | Yes | SQL-Like predicate to select queue names |
Job Group: Streams
Job: Stream Activator
The Stream Activator job activates a stream on job start and deactivates it on job stop. The name of the stream must be specified as parameter. The job requires to set a maximum runtime to deactivate the stream. Otherwise it would be active forever.
The implementation of the Stream Activator job is quite simple. It sets
the enabled attribute to true on job start and to false on job
stop. Therefore, a stream which should run as a job should be initially
disabled.
| Parameter | Mandatory | Description |
|---|---|---|
| Domain Name | Yes | Name of the domain. |
| Package Name | Yes | Name of the package. |
| Stream Name | Yes | Name of the stream. |
Job Group: Topic Manager
Job: Delete Durable
The Delete Durable job deletes durable subscribers (incl. all messages)
which are selected by 2 SQL-Like predicates, client id and durable name,
specified as job parameters. For example, a client id predicate of
sales and a durable name predicate of % will delete all durable
subscribers of client id sales whereas a client id predicate of
s__es% and a durable name predicate of dur% will delete those from
saukesta and dur2003. If you set both parameters to %, it will
match all durable subscribers and therefore all durable subscribers are
deleted.
| Parameter | Mandatory | Description |
|---|---|---|
| Client Id Predicate | Yes | SQL-Like predicate for client ids. |
| Durable Name Predicate | Yes | SQL-Like predicate for durable names. |
Job Group: Routing
Job: Routing Connector
This job takes the name of the routing connector as parameter. It enables the connector at job start and disables it at job stop. Therefore, a connector should be configured as being disabled if it should be used in a job:
Example:
<connectors>
<connector name="acme"
enabled="false"
hostname="chb.acme.com"
port="17884"
socketfactory-class="com.swiftmq.net.JSSESocketFactory"
password="let_me_in"
retry-time="120000"/>
</connectors>
The Routing Connector should have a specified maximum runtime in its
schedule, otherwise it will not be disabled. If the connector will be
enabled during job start and the connection cannot be established, the
retry behavior will be executed as described in the section above. Retry
ends at job stop.
Job Group: Store
Job: Backup
This job can be used to schedule a backup at a specific time of a day. It has no parameters.
Job: Shrink
This job can be used to schedule a shrink of the data store at a specific time of a day. It has no parameters.
Job Group: JavaMail
Job: Outbound Bridge
The Outbound Bridge job activates an outbound bridge on job start and deactivates it on job stop. The name of the bridge must be specified as parameter. The job requires to set a maximum runtime to deactivate the bridge. Otherwise it would be active forever.
The implementation of the Outbound Bridge job is quite simple. It sets
the enabled attribute to true on job start and to false on job
stop. Therefore, an outbound bridge which should run as a job should be
initially disabled.
| Parameter | Mandatory | Description |
|---|---|---|
| Bridge Name | Yes | Name of the outbound bridge. |
Job: Inbound Bridge
The Inbound Bridge job activates an inbound bridge on job start and deactivates it on job stop. The name of the bridge must be specified as parameter. The job requires to set a maximum runtime to deactivate the bridge. Otherwise it would be active forever.
The implementation of the Inbound Bridge job is quite simple. It sets
the enabled attribute to true on job start and to false on job
stop. Therefore, an inbound bridge which should run as a job should be
initially disabled.
| Parameter | Mandatory | Description |
|---|---|---|
| Bridge Name | Yes | Name of the inbound bridge. |
Job Group: JMS Bridge
Job: Server Bridge
The Server Bridge job activates a server bridge on job start and deactivates it on job stop. The name of the bridge must be specified as parameter. The job requires to set a maximum runtime to deactivate the bridge. Otherwise it would be active forever.
The implementation of the Server Bridge job is quite simple. It sets the
enabled attribute to true on job start and to false on job stop.
Therefore, a server bridge which should run as a job should be initially
disabled.
| Parameter | Mandatory | Description |
|---|---|---|
| Bridge Name | Yes | Name of the server bridge. |
Job Group: AMQP Bridge
Job: Bridge
The Bridge job activates an AMQP bridge on job start and deactivates it on job stop. The name of the bridge must be specified as parameter. The job requires to set a maximum runtime to deactivate the bridge. Otherwise it would be active forever.
The implementation of the Bridge job is quite simple. It sets the
enabled attribute to true on job start and to false on job stop.
Therefore, a server bridge which should run as a job should be initially
disabled.
| Parameter | Mandatory | Description |
|---|---|---|
| Bridge Type | Yes | Type (AMQP version) of the bridge (091 or 100). |
| Bridge Name | Yes | Name of the bridge. |
Job Group: Replicator
Job: Source
The Source job activates replication source on job start and deactivates it on job stop. The name of the replication source must be specified as parameter. The job requires to set a maximum runtime to deactivate the source. Otherwise it would be active forever.
The implementation of the Source job is quite simple. It sets the
enabled attribute to true on job start and to false on job stop.
Therefore, a replication source which should run as a job should be
initially disabled.
| Parameter | Mandatory | Description |
|---|---|---|
| Source Name | Yes | Name of the replication source. |
Job: Sink
The Sink job activates replication source on job start and deactivates it on job stop. The name of the replication sink must be specified as parameter. The job requires to set a maximum runtime to deactivate the source. Otherwise it would be active forever.
The implementation of the Sink job is quite simple. It sets the
enabled attribute to true on job start and to false on job stop.
Therefore, a replication sink which should run as a job should be
initially disabled.
| Parameter | Mandatory | Description |
|---|---|---|
| Sink Name | Yes | Name of the replication sink. |
Configuration
The configuration of the Scheduler Swiftlet is defined within the element
<swiftlet name="sys$scheduler" .../>
of the router's configuration file. One can use the SwiftMQ Exlorer or CLI for configuration as well. They both save into that file.
Element List "calendars", Parent Element: "swiftlet"
Calendars. This element list contains zero or more "calendar" elements with this template definition:
Definition
| Attribute | Type | Mandatory | Description |
|---|---|---|---|
| name | java.lang.String | Yes | Name of this Calendar |
| type | java.lang.String | No | Calendar Type |
| base-calendar | java.lang.String | No | Calendar which is Base for this Calendar |
| enable-weekdays | java.lang.Boolean | No | Enable Week Days on this Calendar |
| enable-monthdays | java.lang.Boolean | No | Enable Month Days on this Calendar |
| enable-monthdays-last | java.lang.Boolean | No | Enable Last Month Day on this Calendar |
| enable-annualdays | java.lang.Boolean | No | Enable Annual Days on this Calendar |
| enable-dateranges | java.lang.Boolean | No | Enable Dange Ranges on this Calendar |
Values
| Attribute | Values |
|---|---|
| type | Choice: include exclude Default: exclude |
| base-calendar | |
| enable-weekdays | Default: false |
| enable-monthdays | Default: false |
| enable-monthdays-last | Default: false |
| enable-annualdays | Default: false |
| enable-dateranges | Default: false |
Element "weekdays", Parent Element: "calendar"
Week Days.
Definition
| Attribute | Type | Mandatory | Description |
|---|---|---|---|
| day-01 | java.lang.Boolean | No | Sunday |
| day-02 | java.lang.Boolean | No | Monday |
| day-03 | java.lang.Boolean | No | Tuesday |
| day-04 | java.lang.Boolean | No | Wednesday |
| day-05 | java.lang.Boolean | No | Thursday |
| day-06 | java.lang.Boolean | No | Friday |
| day-07 | java.lang.Boolean | No | Saturday |
Values
| Attribute | Values |
|---|---|
| day-01 | Default: false |
| day-02 | Default: false |
| day-03 | Default: false |
| day-04 | Default: false |
| day-05 | Default: false |
| day-06 | Default: false |
| day-07 | Default: false |
Element "monthdays", Parent Element: "calendar"
Month Days.
Definition
| Attribute | Type | Mandatory | Description |
|---|---|---|---|
| day-01 | java.lang.Boolean | No | 01. |
| day-02 | java.lang.Boolean | No | 02. |
| day-03 | java.lang.Boolean | No | 03. |
| day-04 | java.lang.Boolean | No | 04. |
| day-05 | java.lang.Boolean | No | 05. |
| day-06 | java.lang.Boolean | No | 06. |
| day-07 | java.lang.Boolean | No | 07. |
| day-08 | java.lang.Boolean | No | 08. |
| day-09 | java.lang.Boolean | No | 09. |
| day-10 | java.lang.Boolean | No | 10. |
| day-11 | java.lang.Boolean | No | 11. |
| day-12 | java.lang.Boolean | No | 12. |
| day-13 | java.lang.Boolean | No | 13. |
| day-14 | java.lang.Boolean | No | 14. |
| day-15 | java.lang.Boolean | No | 15. |
| day-16 | java.lang.Boolean | No | 16. |
| day-17 | java.lang.Boolean | No | 17. |
| day-18 | java.lang.Boolean | No | 18. |
| day-19 | java.lang.Boolean | No | 19. |
| day-20 | java.lang.Boolean | No | 20. |
| day-21 | java.lang.Boolean | No | 21. |
| day-22 | java.lang.Boolean | No | 22. |
| day-23 | java.lang.Boolean | No | 23. |
| day-24 | java.lang.Boolean | No | 24. |
| day-25 | java.lang.Boolean | No | 25. |
| day-26 | java.lang.Boolean | No | 26. |
| day-27 | java.lang.Boolean | No | 27. |
| day-28 | java.lang.Boolean | No | 28. |
| day-29 | java.lang.Boolean | No | 29. |
| day-30 | java.lang.Boolean | No | 30. |
| day-31 | java.lang.Boolean | No | 31. |
| last | java.lang.Boolean | No | Last Day in Month |
Values
| Attribute | Values |
|---|---|
| day-01 | Default: false |
| day-02 | Default: false |
| day-03 | Default: false |
| day-04 | Default: false |
| day-05 | Default: false |
| day-06 | Default: false |
| day-07 | Default: false |
| day-08 | Default: false |
| day-09 | Default: false |
| day-10 | Default: false |
| day-11 | Default: false |
| day-12 | Default: false |
| day-13 | Default: false |
| day-14 | Default: false |
| day-15 | Default: false |
| day-16 | Default: false |
| day-17 | Default: false |
| day-18 | Default: false |
| day-19 | Default: false |
| day-20 | Default: false |
| day-21 | Default: false |
| day-22 | Default: false |
| day-23 | Default: false |
| day-24 | Default: false |
| day-25 | Default: false |
| day-26 | Default: false |
| day-27 | Default: false |
| day-28 | Default: false |
| day-29 | Default: false |
| day-30 | Default: false |
| day-31 | Default: false |
| last | Default: false |
Element List "annualdays", Parent Element: "calendar"
Annual Days. This element list contains zero or more "annualday" elements with this template definition:
Definition
| Attribute | Type | Mandatory | Description |
|---|---|---|---|
| name | java.lang.String | Yes | Name of this Annual Day |
| day | java.lang.String | Yes | Day |
| month | java.lang.String | Yes | Month |
Values
| Attribute | Values |
|---|---|
| day | Choice: 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
| month | Choice: January February March April May June July August September October November December |
Element List "date-ranges", Parent Element: "calendar"
Date Ranges. This element list contains zero or more "date-range" elements with this template definition:
Definition
| Attribute | Type | Mandatory | Description |
|---|---|---|---|
| name | java.lang.String | Yes | Name of this Date Range |
| from | java.lang.String | Yes | From Date |
| to | java.lang.String | Yes | To Date |
Values
| Attribute | Values |
|---|---|
| from | |
| to |
Element List "schedules", Parent Element: "swiftlet"
Job Schedules. This element list contains zero or more "schedule" elements with this template definition:
Definition
| Attribute | Type | Mandatory | Description |
|---|---|---|---|
| name | java.lang.String | Yes | Name of this Job Schedule |
| enabled | java.lang.Boolean | No | Schedule enabled/disabled |
| logging-enabled | java.lang.Boolean | No | If true, start/stop are logged in SwiftMQ's log file |
| calendar | java.lang.String | No | Apply this Calendar |
| job-group | java.lang.String | Yes | Job Group |
| job-name | java.lang.String | Yes | Job Name |
| date-from | java.lang.String | Yes | From Date |
| date-to | java.lang.String | Yes | To Date |
| max-runtime | java.lang.String | No | n('s'|'m'|'h'), e.g. 30m |
| time-expression | java.lang.String | Yes | ('at' HH:mm[:ss][, HH:mm[:ss]...]) | ('start' HH:mm[:ss] 'stop' HH:mm[:ss] 'delay' n('s'|'m'|'h' ['repeat' n]) |
Values
| Attribute | Values |
|---|---|
| enabled | Default: false |
| logging-enabled | Default: false |
| calendar | |
| job-group | |
| job-name | |
| date-from | Default: now |
| date-to | Default: forever |
| max-runtime | |
| time-expression |
Element List "parameters", Parent Element: "schedule"
Parameters. This element list contains zero or more "parameter" elements with this template definition:
Definition
| Attribute | Type | Mandatory | Description |
|---|---|---|---|
| name | java.lang.String | Yes | Name of this Parameter |
| value | java.lang.String | Yes | Value |
Values
| Attribute | Values |
|---|---|
| value |
Element "usage", Parent Element: "swiftlet"
Usage.
Element List "job-groups", Parent Element: "usage"
Registered Job Groups. This element list contains zero or more "job-group" elements with this template definition:
Definition
| Attribute | Type | Mandatory | Description |
|---|---|---|---|
| name | java.lang.String | Yes | Name of this Registered Job Group |
Element List "jobs", Parent Element: "job-group"
Registered Jobs. This element list contains zero or more "job" elements with this template definition:
Definition
| Attribute | Type | Mandatory | Description |
|---|---|---|---|
| name | java.lang.String | Yes | Name of this Registered Job |
| description | java.lang.String | No | Description |
Values
| Attribute | Values |
|---|---|
| description |
Element List "parameters", Parent Element: "job"
Job Parameters. This element list contains zero or more "parameter" elements with this template definition:
Definition
| Attribute | Type | Mandatory | Description |
|---|---|---|---|
| name | java.lang.String | Yes | Name of this Job Parameter |
| description | java.lang.String | No | Description |
| default | java.lang.String | No | Default Value |
| mandatory | java.lang.Boolean | No | Mandatory |
Values
| Attribute | Values |
|---|---|
| description | |
| default | |
| mandatory |
Element List "active-job-schedules", Parent Element: "usage"
Active Job Schedules. This element list contains zero or more "active-schedule" elements with this template definition:
Definition
| Attribute | Type | Mandatory | Description |
|---|---|---|---|
| name | java.lang.String | Yes | Name of this Active Job Schedule |
| job-group | java.lang.String | No | Job Group |
| job-name | java.lang.String | No | Job Name |
| state | java.lang.String | No | State |
| next-start | java.lang.String | No | Next Start |
| next-stop | java.lang.String | No | Next Stop |
Values
| Attribute | Values |
|---|---|
| job-group | |
| job-name | |
| state | |
| next-start | |
| next-stop |
Element List "history", Parent Element: "active-schedule"
History. This element list contains zero or more "history" elements with this template definition:
Definition
| Attribute | Type | Mandatory | Description |
|---|---|---|---|
| name | java.lang.String | Yes | Name of this History |
| logtime | java.lang.String | No | Time |
| state | java.lang.String | No | State |
| xception | java.lang.String | No | Message |
Values
| Attribute | Values |
|---|---|
| logtime | |
| state | |
| xception |
Element List "active-message-schedules", Parent Element: "usage"
Active Message Schedules. This element list contains zero or more "active-message-schedule" elements with this template definition:
Definition
| Attribute | Type | Mandatory | Description |
|---|---|---|---|
| name | java.lang.String | Yes | Name of this Active Message Schedule |
| state | java.lang.String | No | State |
| next-start | java.lang.String | No | Next Start |
| next-stop | java.lang.String | No | Next Stop |
| schedule-date-from | java.lang.String | No | Date From |
| schedule-date-to | java.lang.String | No | Date To |
| schedule-calendar | java.lang.String | No | Calendar |
| schedule-logging-enabled | java.lang.Boolean | No | Logging Enabled |
| schedule-time-expression | java.lang.String | No | Time Expression |
Values
| Attribute | Values |
|---|---|
| state | |
| next-start | |
| next-stop | |
| schedule-date-from | |
| schedule-date-to | |
| schedule-calendar | |
| schedule-logging-enabled | |
| schedule-time-expression |
Element List "history", Parent Element: "active-message-schedule"
History. This element list contains zero or more "history" elements with this template definition:
Definition
| Attribute | Type | Mandatory | Description |
|---|---|---|---|
| name | java.lang.String | Yes | Name of this History |
| logtime | java.lang.String | No | Time |
| state | java.lang.String | No | State |
| xception | java.lang.String | No | Message |
Values
| Attribute | Values |
|---|---|
| logtime | |
| state | |
| xception |