• Overview
• Integration
• Geography
• Workflow
• Customization
• Gantt Information Format
• Preferences
• Startup Options
• Constraint Parameters
• Return Codes and Warnings
• Algorithms
• Timeline
• Skill Constraint Expressions

Overview

This document describes technical aspects of the Scheduler. The core component of the Scheduler is the planning engine, which in turn is used by the following application components: Batch Scheduler, Visual Scheduler and the Scheduler Web Services.

The Batch Scheduler is used for background processes, during which the input for the Scheduler is turned into an output that can be processed further by the caller. The processing of the input depends on the Scheduler preferences, which define in detail the various cost-related parameters and algorithm settings. Often, the Batch Scheduler is used on a regular basis, once an hour or once a day, depending on the requirements. Implementations of the Scheduler may define several Batch Scheduler configurations for different planning purposes.

The Visual Scheduler is a front-end application that can be used by planners, dispatchers or supervisors. Apart from visualizing the planning, it allows users to trigger planning or request advices for new or currently planned visits. The Visual Scheduler also provides online KPI calculations that can help measuring service performance.

The Scheduler Web Services contain a set of REST-based services to retrieve, insert, update or delete planning objects and to request planning options. It also contains services for rendering of resource trips and maps. Usually, the web services are used when intergrating the Scheduler with other front-end applications.

Integration

The Scheduler does not necessarily require its own database. In many cases, it it more appropiate to use a bi-directional online interface to the back office system to receive planning information from and store the results in a central database. Keep in mind that read and write modes may differ. However, if working in a transactional environment with large volumes of updates during the day, the SQL interface might be more appropriate than the XML interface. There are other proprietary interface modes that are not part of this ducumentation.

XML
SQL
HTTP
Excel
Google

The Scheduler allows to read and write data in different modes. For example, the read activity may use the SQL mode, the write activity may use the XML interface mode. The read and write interface modes are set in the Interface tab of the Preferences dialog. The following sections describe the schemas that need to be used when exchanging data in XML and SQL mode. Before implementing an interface to a customer's ERP system, it is important to read this section carefully. Make sure right from the beginning that the ERP system is capable of providing all required data. If not, the Scheduler might be unable to perform the required task correctly. Any false address or invalid calendar data may corrupt the planning and may turn the result of the planning into unusable data. It is therefore important to validate any provided data before sending it to the planning engine.

XML Interface

Planning data can be provided in an XML file. The Scheduler schema describes the detailed definitions of the data. Note that the XML file can be opened manually with the Visual Scheduler through the File->Open menu or with the urlin command line option (both with Visual Scheduler and Batch Scheduler).

SQL Interface

In case read mode is SQL, the Scheduler behaves as a standard client application, retrieving data from a central SQL database server. Updates by concurrent users are not recognized until the data is refreshed.

Note that this mode is also used if running the Scheduler as an application server. In that case, all HTTP-based web requests will be responded to by using the SQL interface between the application server and the database.

The Scheduler will create a backup file called sqlin_backup.xml during the load process containing all information that has been retrieved from the database. The file is created for support convenience. The format of the backup XML file conforms to the standard XML input format.

To exchange data with a SQL database, a set of tables or views need to be implemented. These database objects are used to retrieve the information about resources, their skills, availablities and tasks.

View a description of the required database objects carefully before implementing them.

To increase data accuracy, it is a wise to use the Geocoder to geocode all customer addresses. The Geocoder can work on any SQL table or key-preserving view. An additional geocode column for the address table is required to store the geocode permanently. This geocode may then be added to the task view to inform the Scheduler about the exact location.

Note that all column names must match these view column definitions. Only the name of the view object is adjustable by setting the below preferences accordingly.

Use this DDL template for the creation of the database tables or use the DDL views template as a starting point for views.

Make sure that all plannable tasks and tasks that are currently planned will appear in the task view. Even if a task is closed today, it should appear in the view to inform the planner about the change. Tasks that are closed before today are not relevant for the planner.

You may choose to provide unplannable tasks if they are in a wait state. This will inform the planner about upcoming tasks.

To update the planning, several funtions must be provided. Use the function template as a starting point. Make sure that the functions return an error code if they were not able to perform a lock on the required row. This is to avoid a hanging process if several users are working with the same data.

During installation of the Scheduler, all SQL parameters need to be defined. Use the Edit->Preferences menu option and click on the Interface tab to set the values for the organization's environment in the SQL Parameters section.
 

SchedulerResult

When using a SchedulerResult table, the following columns are saved to the table with the name as indicated in the preferences:
 

Excel Interface

The Excel adapter allows to read and write Excel documents with planning data. The format of the Excel document must conform to the Scheduler schema definition, i.e. all column headers must identify a specific attribute. Furthermore, date and time fields such as earliest and latest must have the Excel date format YYYY-MM-DD hh:mm

Each worksheet corresponds to one of the Scheduler elements.

HTTP Interface

The HTTP interface uses HTTP as the protocol for loading and saving planning data. Usually, this implementation is set when working remotely from a client with limited access privilege, such as a web browser. See Web Services for further details.

Google Interface

Implementation of a data provider, exchanging information with Google Apps environments.

Refresh

During the planning, other users may insert new or update existing tasks or unavailabilities in the central database. Also, existing data such as the location of an unavailability or the remarks on a task may have changed. The following situations may occur:

A new task is inserted into the database
If the task is unassigned, it will be added to the plan as an unplanned task. If the task is assigned, it will be added to the resource's trip. Conflicts may occur with existing tasks or unavailabilities on that day.

An existing task is updated during the planning
The task in memory is updated with the new information, regardless of changes that have been made by the user.

A new break is inserted into the database
The unavailability is added to the resource's trip. Conflicts may occur with existing tasks or unavailabilities on that day.

If a conflict occurs, the corresponding trip will not be recalculated, but overlaps will be visualized in the Gantt charts.

Note that the visual environment has two buttons to activate the Refresh functionality: the Rollback button and the Commit & Refresh button. The first one performs a refresh without committing the posted changes, the second button does commit the data before refreshing.

When using the lastUpdate information for breaks and tasks, the refresh method only considers data that has been updated since the planning was last opened or refreshed. This may significantly increase performance during refresh.

Geography

Digital Map

The Scheduler can be used in combination with various digital maps. Currently, Locatienet, MapPoint Web Services, infoware mapsuite, map&guide MapServer and Google are supported. Some maps are online services requiring specific map parameters but no installation on your production machine. For infoware mapsuite and map&guide mapserver, the maps and drivers are delivered along with your purchase. If not included in the bundled distribution, install the Runtime Kit and the provided map according to the installation instructions delivered with the CD material. Note that some map modules are restricted to specific platforms.

Cache

The Scheduler uses a cache mechanism to increase the performance of the map module. Whenever a geocode or a time distance has been calculated, an entry is added to the cache. This entry contains the address information and the geocode or the coordinates along with the time distance values. The cache is implemented as an XML document and is saved when the map module is shutdown. The XML file can be manipulated from outside. For legal reasons, the file may not be used otherwise than in conjunction with the Scheduler. The cache can be turned off by unchecking the "use cache" preference on the Geography tab of the Preferences dialog.

Workflow

The workflow during the planning process of a task is defined by a set of status values and transitions between these status values. Most organizations use different names to identify these state values. the Scheduler has a predefined set of status values which correspond to the most simple possible workflow:
 

The table is stored in the preference file and is only editable in an editor. The workflow for a specific implementation should not change frequently. It is possible to specify a color for each status in the workflow. If specified, all tasks in the Gantt charts that have a colored status will be displayed in the defined status color. Tasks with status PL are displayed in the Plannable tab. Tasks with status IP are displayed in the Planned tab.

By setting the closed attribute to true, a status is recognized as a final state. These tasks will not be editable anymore.

By setting the remove attribute to true, tasks with the state will be removed from the Gantt charts. They will still appear in the list of closed tasks.

The replicate attribute indicates that the status is to be replicated between an administrative system and a Scheduler database. The default is true. If set to false, the status will not be overwritten by the replicator.

If the optimizeWithinTrip attribute is set to true, the visit may be moved within the current trip. this is very often useful when reassignment to another resource or day is not possible anymore but moving the visit into a better position within the trip is still allowed.

If the onTheWay attribute is set to true, the visit is a status that may not be changed anymore because the resource is currently on its way to the location.

The email attribute is used to identify a list of e-mail accounts that are to be notified if a task is changed into the according status. If running in interactive mode, the application will ask for a reason to be added to the message.
 

Example

<Workflow default="PL">
    <Status code="OS" color="ffcc99"/>
    <Status code="RM" color="ffcc99" remove="true"/>
    <Status code="RC" closed="true" color="fafafa"/>
    <Status code="IP" unplan="PL" color="ccccff"/>
    <Status code="PL" plan="IP" color="99ff99"/>
    <Status code="IP" unplan="PL" color="ccccff"/>
</Workflow>

Customization

The Scheduler allows the customization of task data. By splitting the remarks field into various sections, information can be divided into separate fields. These fields occur in a separate tab of the task dialog. Editable fields are updateable by the user. In that case, updates will adapt the section in the remarks field accordingly. Administrative systems may reuse this information to trigger other activities. Note that not all administrative systems allow updates of custom information.

Custom information is specified in the preference file, gathered in a CustomSplit tag. Each section must contain a unique name, a description, a start and end position, a datatype and a flag to indicate whether the field is updateable by the user. The confirm attribute indicates that the user is signalled with an information icon that there is additional information to be viewed. Furthermore, attributes width and height can be specified to determine the preferred size of the field in the form and the displayInRemarksflag is used to specify if the section is to be displayed in the standard remarks field. Default for this flag is true, all sections are displayed in the remarks field by default.

The skip attribute allows customers to remove a leading portion of a specific remarks section. The attribute value must be an integer, specifying the number of leading characters that need to be skipped.

Example

Gantt Information Format

If existant, the Scheduler uses a standard XSL stylesheet to format the layout of the visit info in the Gantt chart. If no stylesheet is found, a standard layout will be used. The stylesheet must be called gantt.xsl and must be placed into the product directory.

Below is an example of a stylesheet that displays detailed task information:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:s4="http://www.oracle.com/XSL/Transform/java/com.crmalliance.common.GenString">
<xsl:output method="text" encoding="ISO-8859-1"/>
<xsl:decimal-format name="numbers" decimal-separator=","
grouping-separator="."/>
<xsl:template match="/Task"><xsl:value-of select="s4:fromXMLString(@name)"/>
<xsl:value-of select="s4:newLine()"/>
<xsl:value-of select="@postalCode"/>
<xsl:value-of select="s4:newLine()"/>
<xsl:value-of select="@city"/>
<xsl:value-of select="s4:newLine()"/>
<xsl:value-of select="s4:substring(@id, 3, 9)"/>
<xsl:text> </xsl:text>
<xsl:value-of select="s4:substring(@id, 9, 12)"/>
<xsl:value-of select="s4:newLine()"/>
<xsl:value-of select="@skill"/>
<xsl:value-of select="s4:newLine()"/>
<xsl:value-of select="@contractType"/>
</xsl:template>
</xsl:stylesheet>

To insert a task attribute, use the @ notation. Available task attributes are: name, territory, department, street, postalCode, city, country, skill, estimatedDuration, earliest, latest, scheduled, scheduledFor, requiredResource, preferredResource, backupResource, fixed, status, actualDateTime, actualDuration, openingHoursMon, openingHoursTue, openingHoursWed, openingHoursThu, openingHoursFri, openingHoursSat, openingHoursSun, remarks, weight, geocode, volume, lastUpdate, messageConfirmed, contractType, requiresParts, holidayCalendarId, planAutomatically, assignedDateTime, minimumResources, maximumResources.

Preferences

The Scheduler has a set of more than 300 preferences. Most of them are configurable through the Preferences dialog by selecting the menu option Edit->Preferences in the GUI front-end or by running the edit_preferences.bat batch file. All preferences are stored in a XML document. Usually, this file is located in the local directory. The standard preference file is called schedulerprefs.xml . Other locations of the preference file can be specified with the urlreferences parameter.

Preference XML documents that are retrieved from a web server (i.e. urlreferences=http://.... ) are read-only and can not be stored due to the fact that the HTTP connection will not allow writing to an HTTP server.

Most planning preferences are defined during the implementation phase. However, for better performance or usuability, adjustments to the constraints parameters might be required from time to time. These parameters are editable in the Constraints tab of the preference dialog.

It is possible to run the Scheduler with different preference settings. In visual mode, the user may import (and export) preferences from the Preferences dialog. Furthermore, the Scheduler may be started with different configurations. The urlwork startup parameter allows the definition of a different working directory for different planning tasks. This is particularly useful when planning disjunct sets of tasks. For example, in SQL mode, different sets of tasks and/or resources can be retrieved from different SQL queries.

To view all preferences and their meanings, go here. The list is ordered by the tabs that occur in the preference dialog.

Startup Options

The Scheduler is called from the command line or a batch, using various options that identify parameters which are independent of the preference setttings, such as the input file URL.

Usage

java -classpath <path> com.crmalliance.s4.S4 <parameters>

Possible parameters

[batch urlin={sql | <plan url>} urlout={sql | <plan out url>}]
[nosplash] [urlsplash=<splash url>]
[urlpreferences=<preferences url>]
[dayoffset=<plan number of days ahead>]
[urlcache=<TDS cache url>]
[urlwork=<working directory url>]
[language=<language>]
[replicate= {nothing | tasks | breaks| breaks-tasks | all }]
[silent] [nosplash]
[urlpreferences=<preferences url>]
[dayoffset=<plan number of days ahead>]
[urlcache=<TDS cache url>]
[urlwork=<working directory url>]
[nomap] [readonly] [noload]

The path must contain the list of distribution jar dist1.jar and dist2.jar. Additionally, required libraries such as a JDBC driver library may be added.

If running in batch mode, input and output datasources need to be specified. If either input ( urlin ) or output ( urlout ) or both are a SQL database, it should be specified as such. URLs may be absolute or relative, i.e. file://./mySched/plan.xml relates to the plan.xml file in the local directory mySched.

If running in silent mode, no copyright messages are logged.

If nosplash is specified, no splash screen will appear.

if the preferences should be loaded from another file than the local schedulerprefs.xml file, it can be specified by using the urlpreferences option.

The dayoffset may be used to disable the creation of assignments during a number of days. If 0, all days are plannable. If greater or equal to 1, no trips are created for the days specified.

The location of the Time Distance cache can be specified with the urlcache option.

Usually, preferences are loaded frrom the local directory and logging occurs in the local log directory. By setting the urlwork parameter, this local directory may be redirected to another location. The specified directory should contain a log directory with the s4log.xsl stylesheet.and the logger DTD.

Currently, the Scheduler supports Dutch, German, English and French. The language can be specified with the language option, i.e. language=en_UK specifies English as the language and the UK as the Locale. If no language is specified, the language will be determined by reading the operation system settings.

If data is to be replicated from the input to the output datasource, only portions may be replicated. Use one of the settings replicate=nothing | tasks | breaks | breaks-tasks | all to specify which part of the plan is to be replicated.
 

The nomap parameter must be specified if no map viewer license has been purchased. This parameter will disable the map background in map panels.

The readonly parameter enables users to read all information, but planning functions are all disabled.

Constraint Parameters

Any real world task planning has a number of constraints, such as working hours, opening hours or travel time. The Scheduler uses a cost function when estimating the fitness of a plan. This cost function considers a set of real-world constraints that reflect the quality of a plan. The term cost as such does not have a financial meaning (although theoretically possible), but rather a virtual cost (or penalty) that allows to compare one plan with another. In some cases, one might also want to refer to a fitness parameter.

Let p be a plan for the assignment of tasks to resources. The assignments result in trips, consisting of several stops, starting with a departure and an arrival. All other stops are visits to a client's site or other locatable activities.

The total cost of a plan is the sum of the costs for each trip in the plan:

total cost(p) = sum(cost(each trip in p)) + sum(cost(each unplanned task))

The cost of a trip consists of the costs of each stop in the trip plus a cost for possible overtime (in case the trip is longer than the resource's working hours):

cost(trip) = sum(cost(each stop in trip)) + overtime(trip)

The following list contains a summary of all cost parameters that are adjustable.

Change these values with caution, inefficient or unwanted planning may occur if the parameters are not set correctly.

Make a backup of the implementation preference file before making any changes to the contraint settings.

OvertimeFactor
MaxOvertime
MaxWorkload
TravelTime
TravelDistance
Overlap
TaskTooEarly
TaskTooLate
Fixed
BestAge
SkillMismatch
SkillLevelTooHigh
SkillLevelTooLow
PreferredResourceMismatch
BackupResourceMismatch
StartsOutsideOpeningHours
EndsOutsideOpeningHours
PlannedShiftDuration
ExcessiveWeight
ExcessiveVolume

Note

The fact that a task is not planned yet is not considered a cost.
 

Overtime Factor

The overtime costs are calculated by comparing the (end) time of the arrival to the end time of the second last stop. In case they are subsequent in time, no costs are applied. Otherwise, the time difference (in minutes) is multiplied with the overtime factor . The overtime factor defaults to 1 and can be influenced in the Preferences dialog.

overtime(trip) = (time(arrival) > time(second last stop)) ? 0 : (time(second last stop) - time(arrival)) * overtime factor
 

Maximum Overtime

During assignment of a task, overtime is limited by the maximum overtime parameter. If this parameter is exceeded, the task will not be considered as an option. During planning, this parameter is considered a hard restriction.
 

Maximum Workload

The amount of time of the available standard working hours of a resource can be limited to a certain percentage. The MaxWorkload parameter indicates this percentage. The value may be higher than 100 to indicate that overtime is accepted. The workload is based on the sum of all stop durations in a trip. During planning, this parameter is considered a hard restriction.
 

Travel Time and Travel Distance

In general, each stop adds a cost to the plan that is relative to the travel time (in minutes) and distance (in kilometers) to reach the location of the next stop.

cost(stop) =(travel time(stop) * travelTime + travel distance(stop) * travelDistance + overlap(stop)

where

The duration of an unplanned task is not considered during the cost calculation.
 

Overlap

A possible time overlap with the next stop (including the second last stop that might overlap with the arrival) results in additional costs. The overlap in (minutes) is multplied with the Overlap factor and is added to the total cost of a trip:

overlap(stop) = (time(stop) + travel time(stop) < time(next stop)) ? 0 : time(stop) + travel time(stop) - time(next stop)
 

Task Too Early and Task Too Late

Different stop types may have different cost parameters. For example, visits are bound to certain time limits, called earliest and latest . The Scheduler tries to place the task between these boundaries. In case this is not possible, the visit will exceed one of these boundaries which will provoke additional costs. The costs for an excess of the boundaries are calculated as follows:

excess costs(stop) = excess earliest(stop) + excess latest(stop)

where

excess earliest(stop) = (earliest(stop) > start(stop)) ? earliest(stop) - start(stop) * TaskTooEarly : 0

and

excess latest(stop) = (latest(stop) < start(stop)) ? start(stop) - latest(stop) * TaskTooLate : 0
 

Best Age

Whenever a task is plannable between a earliest and latest boundary, there is usually a certain point that would be the best point for insertion. Imagine a regular task that is to be scheduled every seven weeks. Each single task will have an earliest and a latest, but getting close to the boundaries is not favorable, since the repetitive series will result in too short or too long time differences between the tasks. The best option to schedule the task would be at a certain point between earliest and latest, for example, in the sixth week.

We herefore define a parameter called best age which is the percentage of the latest-earliest range where the task is preferably planned. In our example above, this would be 6/7 = 86%. Any scheduling before that point would result in larger costs, any schedling beyond this point will also result in additional costs. The absolute cost is called Fixed , representing the cost that is applied whenever the task is scheduled at exacty one of the boundaries. If planned at the best age, the cost is zero.

The best starting time for a task is calculated by the following formula:

best start(task) = earliest(task) + (latest(task) - earliest(task)) * BestAge /100

Setting best age to 0% indicates that the task should be planned as early as possible. Setting BestAge to 100% indicates that the task should be planned as late as possible. Costs planning outside of the earliest/latest bounderies is reflected by the TaskTooEarly and TaskTooLate parameters. In that case, the BestAge and Fixed parameters are not applied.

The BestAge cost is only considered if the Fixed value is not 0.
 

Skills and Skill Levels

Whenever a task requires a certain skill, the Scheduler only considers those resources that have this skill assigned. Resources may have different skill levels attached to the skill itself. For example, one resource is an expert for one particular machine. Another resource is recently trained and is only considered as a trainee. It is expected that the trainee will perform the task in a longer time that the expert.

A mismatch of skills may result in a very high penalty/cost. A skill level mismatch may result in lower but still considerable costs.

skill cost(visit) = skill level cost(visit) + (supports skill(resource, skill(visit))) ? 0 : skillMismatch

where

skill level cost(visit) = skill level too low cost(visit) + skill level too high cost(visit)

and

skill level too high cost(visit) = (skill level(resource, skill (visit)) > skill level(visit)) ? skillLevelTooHigh * skill level(resource, skill (visit)) - skill level(visit)) : 0
skill level too low cost(visit) = (skill level(resource, skill (visit)) < skill level(visit)) ? skillLevelTooLow * skill level(resource, skill (visit)) - skill level(visit)) : 0

This parameter is only applicable when the use Skills checkbox is selected.
 

Preferred Resources and Backup Resources

Service tasks may have preferred resources assigned. This is to increase the customer royalty towards a constant service representative and to limit costs during the travel to unknown sites. In case the preferred resource is not available or the costs to let this resource perform the task is too high, the backup resource may perform the task. In case the backup resource is not available or the costs are too high, another resource needs to perform the task. The preferred mismatch cost and the backup mismatch cost factors indicate the costs that need to be calculated when a task is not performed by a requested resource.

preferred resource cost(visit) = (resource(visit) = preferred resource(task(visit))) ? 0 : preferred mismatch cost + backup resource cost(visit)

and

backup resource cost(visit) = (resource(visit) = backup resource(task(visit))) ? 0 : backup mismatch cost
 

Opening Hours

Costs may occur whenever a task is planned outside of the customer's opening hours. Starting the service outside opening hours is prohibitive. Although in some cases the resource may start the task within the opening hours, it may be possible to extend the service beyond the opening hours. The endsOutsideOpeningHours factor and startsOutsideOpeningHours factor reflect the costs that are applied whenever visiting a customer outside the opening hours of that day.

opening hours cost(visit) = (starts during opening hours(start(visit), day(visit))) ? opening hours excess cost(visit) : startsOutsideOpeningHours

where

opening hours excess cost(visit) = (ends during opening hours(end(visit), day(visit))) ? 0 : (end(visit) - end(opening hour(visit)) * endOutsideOpeningHours

This parameter is only valid if the use Opening Hours checkbox is selected.
 

Planned Shift Duration

This is particularly useful with opening hours.to plan visits rather in the morning than in the afternoon since the costs for a visit later in the afternoon results in a long shift duration. The planned shift duration is calculated as the amount of minutes from the departure of a trip to the last visit for that day. Each minute of the planned shift duration is multiplied with the PlannedShiftDuration .
 

Excessive Weight and Volume

Each resource has a default maximum weight and volume it can carry (in a car or a truck). Any weight or volumne surplus results in additional costs as defined by the ExcessiveWright and ExcessiveVolume parameters.

The parameter is only applicable if the use Weight and use Volume preferences are selected.
 

Return Codes and Warnings

The Scheduler may stop processing under certain conditions. For example, if the maximum number of warnings is exceeded in batch mode, the Scheduler is shutdown. Return codes other than 0 indicate that there has been an error during the planning process. A subsequent program may react on the return code, i.e. an error report may be generated.
 

Apart from unexpected errors, the following warnings are identified:
 

Timeline

The closer the planning reaches the timeline, the more important it is to adapt the planning to the current situation. Therefore, the Scheduler extends visits that are currently active but have not been closed yet, if the preference "extend exceeding visits" is set and the timeline has exceeded the planned visit end. The extension is performed whenever a recalculation of the trip occurs. It is possible to combine the recalculation with the refresh process. In that case, the Scheduler automatically adapts the plan after having refreshed the data and immediately commits the changes.
 

Skill Constraint Expressions

If the implementation of the Scheduler requires to handle more than one skill for each task, the skill field of the task can be used to express this constraint as a logical expression. The logical expression can contain logical and (&&), logical or (||) and logical negation(!) predicates as well as parentheses for cascaded logical expressions. Furthermore, comparisons are allowed. They can be used to compare required skill levels by using the level() function.

Examples

The requirement for skills A and B would be expressed as:
"A" && "B"

The requirement for A or B, with the constraint that B should not occur in combination with skill C would be expressed as:
"A" || ("B" && !"C")

Only resources that have a matching skill set will be considered a candidate for the task. Note that all skills need to be quoted to allow any string literal as a skill identifier. There is one limitation for skill identifiers: they may not contain linefeed or end of line characters nor the " character.

The level() method retrieves the level of the resource's skill definition. This allows expressions such as

level("A") > 1.5 or level("A") == level("B").

Supported comparisons are <, >, <=,>=, == (equal) and != (not equal).The level function will cause an exception to be thrown if the resource does not have the provided skill, causing the evaluation of the expression to return false.lt; level("A") constraint.

In case the expression is not recognized by the Scheduler constraint parser, the string will be interpreted as a single unquoted skill identifier. Evaluation of the constraint will then return true if and only if one of the resource's skills matches the unquoted skill identifier.