SwiftMQ Documentation

SwiftMQ Documentation

  • Client
  • CE
  • UR
  • HA
  • Javadocs
  • Release Notes

›Swiftlets

SwiftMQ Client

  • Getting Started
  • JNDI Client
  • JMS Client
  • AMQP 1.0 Client
  • Filetransfer Client

SwiftMQ CE

  • Getting Started
  • Installation
  • Upgrade
  • Software Architecture
  • Administration

    • Preconfig
    • CLI Command Line Interface
    • JMX Administration
    • CLI Message Interface
    • routerconfig.xml Watch Dog
    • System Properties

    Swiftlets

    • AMQP Swiftlet
    • Authentication Swiftlet
    • Deploy Swiftlet
    • JMS Swiftlet
    • JNDI Swiftlet
    • Log Swiftlet
    • Management Swiftlet
    • MQTT Swiftlet
    • Network Swiftlet
    • Queue Manager Swiftlet
    • Routing Swiftlet
    • Scheduler Swiftlet
    • Store Swiftlet
    • Streams Swiftlet
    • Threadpool Swiftlet
    • Timer Swiftlet
    • Topic Manager Swiftlet
    • Trace Swiftlet
    • XA Resource Manager Swiftlet

    APIs

    • CLI Admin API

    How To

    • TLS Configuration
    • HTTP Tunneling Configuration
    • Upgrade SwiftMQ Router and Clients

    In Depth

    • Versioning
    • File Store

SwiftMQ UR

  • Getting Started
  • License
  • Installation
  • Upgrade
  • Administration

    • SwiftMQ Explorer

    Swiftlets

    • JDBC Authentication Swiftlet
    • FileCache Swiftlet
    • JMS Application Container Swiftlet
    • JMS XA Swiftlet
    • JDBC Store Swiftlet
    • AMQP Bridge Extension Swiftlet
    • JMS Bridge Extension Swiftlet
    • JavaMail Bridge Extension Swiftlet
    • Replicator Extension Swiftlet

SwiftMQ HA

  • Getting Started
  • License
  • Installation
  • Upgrade
  • HA Introduction
  • HA Deployment
  • Administration
  • JNDI/JMS under HA
  • Routing under HA
  • Advanced Configuration
  • HA Test Suite

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 30m and 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, the Usage section 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:

Message Scheduler

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
← Routing SwiftletStore Swiftlet →
  • Introduction
    • Job Groups and Jobs
    • Schedules
    • Calendars
    • Custom Jobs
    • Job Monitoring
  • Job Groups and Jobs
    • Job Groups
    • Jobs
  • Calendars
    • Parts of a Calendar
    • Stacking Calendars
    • Modifying Calendars
  • Schedules
    • Time Expressions
    • System Time Changes during Execution
    • Example
  • Message Jobs
  • Monitoring
    • Overview
    • Monitoring Job Schedules
    • Monitoring a Schedule's History
    • Schedule States
  • Registry
    • Job Group: Accounting
    • Job Group: File Cache
    • Job Group: Queue Manager
    • Job Group: Streams
    • Job Group: Topic Manager
    • Job Group: Routing
    • Job Group: Store
    • Job Group: JavaMail
    • Job Group: JMS Bridge
    • Job Group: AMQP Bridge
    • Job Group: Replicator
  • Configuration
Copyright © 2020 IIT Software GmbH