Schema "mule-quartz.xsd"
Target Namespace:
http://www.mulesoft.org/schema/mule/quartz
Defined Components:
11 global elements, 4 local elements, 11 complexTypes, 1 attribute group
Default Namespace-Qualified Form:
Local Elements: qualified; Local Attributes: unqualified
Schema Location:
http://www.mulesoft.org/schema/mule/quartz/3.3/mule-quartz.xsd; see XML source
Imports Schemas (4):
mule-schemadoc.xsd [src], mule.xsd [src], spring-beans-3.1.xsd [src], xml.xsd [src]
Imported by Schema:
_mule-all-included.xsd
Annotation
The Quartz transport provides support for scheduling events and for triggering new events. An inbound quartz endpoint can be used to trigger inbound events that can be repeated, such as every second. Outbound quartz endpoints can be used to schedule an existing event to fire at a later date. Users can create schedules using cron expressions, and events can be persisted in a database. \\ This transport makes use of the [Quartz Project|http://www.opensymphony.com/quartz/] at [Open Symphony|http://www.opensymphony.com/]. The Quartz site has more generic information about how to work with Quartz. \\ This transport becomes very powerful when using cron expressions to trigger events, and some of the examples below provide examples of cron expressions. If you are not familiar with cron syntax, here is a [good tutorial|http://www.opensymphony.com/quartz/wikidocs/CronTriggers%20Tutorial.html].
All Element Summary
abstract-inbound-job A placeholder for Quartz jobs that can be set on inbound endpoints only.
Type:
Content:
empty, 2 attributes
Abstract:
(may not be used directly in instance XML documents)
Defined:
globally; see XML source
Used:
never
abstract-job A placeholder for Quartz jobs that can be set on the endpoint.
Type:
Content:
empty, 2 attributes
Abstract:
(may not be used directly in instance XML documents)
Subst.Gr:
may be substituted with 5 elements
Defined:
globally; see XML source
Used:
connector The Quartz connector is used to configure the default behavior for Quartz endpoints that reference the connector.
Type:
Content:
complex, 5 attributes, attr. wildcard, 7 elements
Subst.Gr:
may substitute for element mule:abstract-connector
Defined:
globally; see XML source
Used:
never
custom-job A custom job can be configured on inbound or outbound endpoints.
Type:
Content:
empty, 3 attributes
Subst.Gr:
may substitute for element abstract-job
Defined:
globally; see XML source
Used:
never
custom-job-from-message Allows a job to be stored on the current message.
Type:
Content:
empty, 5 attributes
Subst.Gr:
may substitute for element abstract-job
Defined:
globally; see XML source
Used:
never
endpoint A global endpoint that can be used as a template to create inbound and outbound Quartz endpoints.
Type:
Content:
complex, 16 attributes, attr. wildcard, 17 elements
Subst.Gr:
may substitute for element mule:abstract-global-endpoint
Defined:
globally; see XML source
Used:
never
endpoint-polling-job An inbound endpoint job that can be used to periodically read from an external source (via another endpoint).
Type:
Content:
complex, 2 attributes, 1 element
Subst.Gr:
may substitute for element abstract-job
Defined:
globally; see XML source
Used:
never
event-generator-job An inbound endpoint job that will trigger a new event for the service according to the schedule on the endpoint.
Type:
Content:
complex, 2 attributes, 1 element
Subst.Gr:
may substitute for element abstract-job
Defined:
globally; see XML source
Used:
never
factory-property Set a property on the factory (see scheduler-ref).
Type:
Content:
empty, 3 attributes
Defined:
locally witnin quartzConnectorType complexType; see XML source
inbound-endpoint A Quartz inbound endpoint can be used to generate events.
Type:
Content:
complex, 15 attributes, attr. wildcard, 17 elements
Subst.Gr:
may substitute for element mule:abstract-inbound-endpoint
Defined:
globally; see XML source
Used:
never
job-endpoint
Type:
Content:
empty, 3 attributes
Defined:
locally at 2 locations
outbound-endpoint An outbound Quartz endpoint allows existing events to be stored and fired at a later time/date.
Type:
Content:
complex, 15 attributes, attr. wildcard, 17 elements
Subst.Gr:
may substitute for element mule:abstract-outbound-endpoint
Defined:
globally; see XML source
Used:
never
payload The payload of the newly created event.
Type:
Content:
mixed (allows character data), 3 attributes
Defined:
locally witnin eventGenerateJobType complexType; see XML source
scheduled-dispatch-job An outbound job that will schedule a job for dispatch at a later time/date.
Type:
Content:
complex, 2 attributes, 1 element
Subst.Gr:
may substitute for element abstract-job
Defined:
globally; see XML source
Used:
never
Complex Type Summary
The base element type for all Quartz jobs
Content:
empty, 2 attributes
Defined:
globally; see XML source
Includes:
definitions of 2 attributes
Used:
Content:
empty, 5 attributes
Defined:
globally; see XML source
Used:
Content:
empty, 3 attributes
Defined:
globally; see XML source
Includes:
definition of 1 attribute
Used:
Content:
complex, 2 attributes, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
Defines an endpoint reference.
Content:
empty, 3 attributes
Defined:
globally; see XML source
Includes:
definitions of 3 attributes
Used:
Content:
complex, 2 attributes, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
Content:
complex, 16 attributes, attr. wildcard, 17 elements
Defined:
globally; see XML source
Includes:
definitions of 1 attribute, 1 element
Used:
Content:
complex, 15 attributes, attr. wildcard, 17 elements
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
Content:
complex, 15 attributes, attr. wildcard, 17 elements
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
Content:
complex, 5 attributes, attr. wildcard, 7 elements
Defined:
globally; see XML source
Includes:
definitions of 1 attribute, 1 element
Used:
Content:
complex, 2 attributes, 1 element
Defined:
globally; see XML source
Includes:
definition of 1 element
Used:
Attribute Group Summary
Content:
Defined:
globally; see XML source
Includes:
definitions of 5 attributes
Used:
XML Source
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<xsd:schema attributeFormDefault="unqualified" elementFormDefault="qualified" targetNamespace="http://www.mulesoft.org/schema/mule/quartz" xmlns="http://www.mulesoft.org/schema/mule/quartz" xmlns:mule="http://www.mulesoft.org/schema/mule/core" xmlns:schemadoc="http://www.mulesoft.org/schema/mule/schemadoc" xmlns:spring="http://www.springframework.org/schema/beans" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<xsd:import namespace="http://www.w3.org/XML/1998/namespace"/>
<xsd:annotation>
<xsd:documentation>
The Quartz transport provides support for scheduling events and for triggering new events. An inbound quartz endpoint can be used to trigger inbound events that can be repeated, such as every second. Outbound quartz endpoints can be used to schedule an existing event to fire at a later date. Users can create schedules using cron expressions, and events can be persisted in a database.
\\
This transport makes use of the [Quartz Project|http://www.opensymphony.com/quartz/] at [Open Symphony|http://www.opensymphony.com/]. The Quartz site has more generic information about how to work with Quartz.
\\
This transport becomes very powerful when using cron expressions to trigger events, and some of the examples below provide examples of cron expressions. If you are not familiar with cron syntax, here is a [good
tutorial|http://www.opensymphony.com/quartz/wikidocs/CronTriggers%20Tutorial.html].
</xsd:documentation>
<xsd:appinfo>
<schemadoc:short-name>Quartz</schemadoc:short-name>
<schemadoc:page-title>Quartz Transport</schemadoc:page-title>
<schemadoc:additional-documentation where="before-specific-elements">
h1. Jobs

Jobs are used to perform an action when a time trigger occurs from the Quartz transport. Mule provides a number of jobs for generating and scheduling events. These are detailed below. Users can also write their own jobs and hook them in using the custom-job type included with Mule.
</schemadoc:additional-documentation>
<schemadoc:transport-features dispatchEvents="true" receiveEvents="true" requestEvents="false" streaming="false" transactions="false">
<schemadoc:MEPs default="one-way" supported="one-way"/>
</schemadoc:transport-features>
</xsd:appinfo>
</xsd:annotation>
<xsd:element name="connector" substitutionGroup="mule:abstract-connector" type="quartzConnectorType">
<xsd:annotation>
<xsd:documentation>
The Quartz connector is used to configure the default behavior for Quartz endpoints that reference the connector. Note if there is only one Quartz connector configured, all Quartz endpoints will use that connector.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="quartzConnectorType">
<xsd:complexContent>
<xsd:extension base="mule:connectorType">
<xsd:sequence>
<xsd:element maxOccurs="unbounded" minOccurs="0" name="factory-property" type="mule:keyValueType">
<xsd:annotation>
<xsd:documentation>
Set a property on the factory (see scheduler-ref).
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
<xsd:attribute name="scheduler-ref" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
Provides an implementation of the Quartz Scheduler interface. If no value is provided, a scheduler is retrieved from the StdSchedulerFactory. If no properties are provided, the getDefaultScheduler method is called. Otherwise, a new factory instance is created using the given properties, and a scheduler is retrieved using the getScheduler method.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="outbound-endpoint" substitutionGroup="mule:abstract-outbound-endpoint" type="outboundEndpointType">
<xsd:annotation>
<xsd:documentation>
An outbound Quartz endpoint allows existing events to be stored and fired at a later time/date. If you are using a persistent event store, the payload of the event must implement java.io.Serializable. You configure an org.quartz.Job implementation on the endpoint to tell it what action to take. Mule has some default jobs, but you can also write your own.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="outboundEndpointType">
<xsd:complexContent>
<!--
The only valid exchange-pattern is one-way which is the default. No need to make
the exchange-pattern attribute configurable.
-->
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1" ref="abstract-job"/>
</xsd:sequence>
<xsd:attributeGroup ref="addressAttributes"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="inbound-endpoint" substitutionGroup="mule:abstract-inbound-endpoint" type="inboundEndpointType">
<xsd:annotation>
<xsd:documentation>
A Quartz inbound endpoint can be used to generate events. It is most useful when you want to trigger a service at a given interval (or cron expression) rather than have an external event trigger the service.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="inboundEndpointType">
<xsd:complexContent>
<!--
The only valid exchange-pattern is one-way which is the default. No need to make
the exchange-pattern attribute configurable.
-->
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="1" ref="abstract-job"/>
</xsd:sequence>
<xsd:attributeGroup ref="addressAttributes"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="endpoint" substitutionGroup="mule:abstract-global-endpoint" type="globalEndpointType">
<xsd:annotation>
<xsd:documentation>
A global endpoint that can be used as a template to create inbound and outbound Quartz endpoints. Common configuration can be set on a global endpoint and then referenced using the @ref attribute on the local endpoint. Note that because jobs sometimes only work on inbound or outbound endpoints, they have to be set on the local endpoint.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="globalEndpointType">
<xsd:complexContent>
<!--
The only valid exchange-pattern is one-way which is the default. No need to make
the exchange-pattern attribute configurable.
-->
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" ref="abstract-job"/>
</xsd:sequence>
<xsd:attributeGroup ref="addressAttributes"/>
<xsd:attribute name="stateful" type="xsd:boolean">
<xsd:annotation>
<xsd:documentation>
Determines if the job is persistent. If so, the job detail state will be persisted for each
request. More importantly, each job triggered will execute sequentially. If the Job takes longer
than the next trigger the next job will wait for the current job to execute.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element abstract="true" name="abstract-job" type="abstractJobType">
<xsd:annotation>
<xsd:documentation>
A placeholder for Quartz jobs that can be set on the endpoint.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element abstract="true" name="abstract-inbound-job" type="abstractJobType">
<xsd:annotation>
<xsd:documentation>
A placeholder for Quartz jobs that can be set on inbound endpoints only.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:element name="event-generator-job" substitutionGroup="abstract-job" type="eventGenerateJobType">
<xsd:annotation>
<xsd:documentation>
An inbound endpoint job that will trigger a new event for the service according to the schedule on the endpoint. This is useful for periodically triggering a service without the need for an external event to occur.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="eventGenerateJobType">
<xsd:complexContent>
<xsd:extension base="abstractJobType">
<xsd:sequence>
<xsd:element maxOccurs="1" minOccurs="0" name="payload" type="mule:dataReferenceType">
<xsd:annotation>
<xsd:documentation>
The payload of the newly created event. The payload can be a reference to a file, fixed string, or object configured as a Spring bean. If this value is not set, an event will be generated with an org.mule.transport.NullPayload instance.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="endpoint-polling-job" substitutionGroup="abstract-job" type="endpointPollingJobType">
<xsd:annotation>
<xsd:documentation>
An inbound endpoint job that can be used to periodically read from an external source (via another endpoint). This can be useful for triggering time-based events from sources that do not support polling or for simply controlling the rate in which events are received from the source.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="endpointPollingJobType">
<xsd:complexContent>
<xsd:extension base="abstractJobType">
<xsd:sequence maxOccurs="1" minOccurs="1">
<xsd:element name="job-endpoint" type="endpointRefType">
<xsd:annotation>
<xsd:documentation>
A reference to another configured endpoint from which events will be received.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="scheduled-dispatch-job" substitutionGroup="abstract-job" type="scheduledDispatchJobType">
<xsd:annotation>
<xsd:documentation>
An outbound job that will schedule a job for dispatch at a later time/date. The event will get dispatched using the configured endpoint reference.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="scheduledDispatchJobType">
<xsd:complexContent>
<xsd:extension base="abstractJobType">
<xsd:sequence maxOccurs="1" minOccurs="1">
<xsd:element name="job-endpoint" type="endpointRefType">
<xsd:annotation>
<xsd:documentation>
The endpoint used to dispatch the scheduled event. The preferred approach is to create a global endpoint and reference it using the ref attribute. However, you can also use the address attribute to define a URI endpoint (which supports expressions). You can use the timeout attribute to specify an arbitrary time-out value associated with the endpoint that can be used by jobs that block waiting to receive events.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
</xsd:sequence>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="custom-job" substitutionGroup="abstract-job" type="customJobType">
<xsd:annotation>
<xsd:documentation>
A custom job can be configured on inbound or outbound endpoints. You can create and configure your own job implementation and use it on a Quartz endpoint. A custom job can be configured as a bean in the XML configuration and referenced using this job.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="customJobType">
<xsd:complexContent>
<xsd:extension base="abstractJobType">
<xsd:attribute name="job-ref" type="xsd:string" use="required">
<xsd:annotation>
<xsd:documentation>
The bean name or ID of the custom job to use when this job gets executed.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:element name="custom-job-from-message" substitutionGroup="abstract-job" type="customFromMessageJobType">
<xsd:annotation>
<xsd:documentation>
Allows a job to be stored on the current message. This can only be used on outbound endpoints. When the message is received, the job is read and the job is added to the scheduler with the current message. This allows for custom scheduling behavior determined by the message itself. Usually the service or a transformer would create the job on the message based on application-specific logic. Any Mule-supported expressions can be used to read the job from the message. Typically, you add the job as a header, but an attachment could also be used.
</xsd:documentation>
</xsd:annotation>
</xsd:element>
<xsd:complexType name="customFromMessageJobType">
<xsd:complexContent>
<xsd:extension base="abstractJobType">
<xsd:attributeGroup ref="mule:expressionAttributes"/>
</xsd:extension>
</xsd:complexContent>
</xsd:complexType>
<xsd:complexType name="abstractJobType">
<xsd:annotation>
<xsd:documentation>
The base element type for all Quartz jobs
</xsd:documentation>
</xsd:annotation>
<xsd:attribute name="groupName" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
The group name of the scheduled job
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="jobGroupName" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
The job group name of the scheduled job.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
<xsd:attributeGroup name="addressAttributes">
<xsd:attribute name="jobName" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
The name to associate with the job on the endpoint. This is only really used internally when storing events.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="cronExpression" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
The cron expression to schedule events at specified dates/times. This attribute or repeatInterval is required. A cron expression is a string comprised by 6 or 7 fields separated by white space. Fields can contain any of the allowed values, along with various combinations of the allowed special characters for that field. The fields are as follows:
{html}
<table>
<th>Field Name</th>
<th>Mandatory</th>
<th>Allowed Values</th>
<th>Allowed Special Chars</th>
<tr>
<td>Seconds</td>
<td>YES</td>
<td>0-59</td>
<td>, - * /</td>
</tr>
<tr>
<td>Minutes</td>
<td>YES</td>
<td>0-59</td>
<td>, - * /</td>
</tr>
<tr>
<td>Hours</td>
<td>YES</td>
<td>0-23</td>
<td>, - * /</td>
</tr>
<tr>
<td>Day of Month</td>
<td>YES</td>
<td>1-31</td>
<td>, - * ? / L W C</td>
</tr>
<tr>
<td>Month</td>
<td>YES</td>
<td>1-12 or JAN-DEC</td>
<td>, - * /</td>
</tr>
<tr>
<td>Day of Week</td>
<td>YES</td>
<td>1-7 or SUN-SAT</td>
<td>, - * ? / L C #</td>
</tr>
<tr>
<td>Year</td>
<td>NO</td>
<td>empty, 1970-2099</td>
<td>, - * /</td>
</tr>
</table>
Cron expressions can be as simple as this:
<b>* * * * ? *</b>
<br/>
or more complex, like this:
<b>
0 0/5 14,18,3-39,52 ? JAN,MAR,SEP MON-FRI 2002-2010
</b>
<h4>Some examples:</h4>
<ul>
<li>
0 0 12 * * ? Fire at 12pm (noon) every day
</li>
<li>0 15 10 ? * * Fire at 10:15am every day</li>
<li>0 15 10 * * ? Fire at 10:15am every day</li>
<li>0 15 10 * * ? * Fire at 10:15am every day</li>
<li>
0 15 10 * * ? 2005 Fire at 10:15am every day during the year 2005
</li>
<li>
0 * 14 * * ? Fire every minute starting at 2pm and ending at 2:59pm, every day
</li>
<li>
0 0/5 14 * * ? Fire every 5 minutes starting at 2pm and ending at 2:55pm, every day
</li>
</ul>
{html}
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="repeatInterval" type="mule:substitutableLong">
<xsd:annotation>
<xsd:documentation>
The number of milliseconds between two events. This attribute or cronExpression is required.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="repeatCount" type="mule:substitutableInt">
<xsd:annotation>
<xsd:documentation>
The number of events to be scheduled. This value defaults to -1, which means that the events will be scheduled indefinitely.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="startDelay" type="mule:substitutableLong">
<xsd:annotation>
<xsd:documentation>
The number of milliseconds that will elapse before the first event is fired.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:attributeGroup>
<xsd:complexType name="endpointRefType">
<xsd:annotation>
<xsd:documentation>
Defines an endpoint reference. The preferred approach is to create a global endpoint and reference that. However, you can also use the address attribute to define a URI endpoint.
</xsd:documentation>
</xsd:annotation>
<xsd:attribute name="ref" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
A reference (name) of a global endpoint configured in your Mule instance. This is the preferred way of configuring an endpoint.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="address" type="xsd:string">
<xsd:annotation>
<xsd:documentation>
A URI address string that will be used to construct a new endpoint for the Quartz endpoint to use.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
<xsd:attribute name="timeout" type="mule:substitutableInt">
<xsd:annotation>
<xsd:documentation>
An arbitrary time-out value associated with the endpoint that can be used by jobs that block waiting to receive events.
</xsd:documentation>
</xsd:annotation>
</xsd:attribute>
</xsd:complexType>
</xsd:schema>

XML schema documentation generated with DocFlex/XML RE 1.8.5 using DocFlex/XML XSDDoc 2.5.0 template set. All content model diagrams generated by Altova XMLSpy via DocFlex/XML XMLSpy Integration.