Job management

This page gives you general information on the purpose and function of jobs. The individual, specific jobs together with their function & configuration options are each described on the corresponding module pages.
--> straight to the jobs in the "Portal & Organisation" module

Jobs serve as periodically running utilities for synchronising and processing data.
Examples of possible jobs:

• Creating groups on the basis of particular criteria
• Synchronising department and person data from the time management system, or
• Synchronising calendar data from the groupware system
• Synchronising absence reasons from the time management system
• Filtering defined irregularities in the time management system and, as a result
• Automatic generation of particular workflow requests
• Notifications in the event of particular occurrences (e.g. exceeding working time)
• Automated report generation and dispatch by mail

Jobs can be started automatically, with the help of a so-called trigger. The trigger creates a schedule, so that the jobs can be started as desired (hourly, daily, weekly or monthly, ...). The setting can be configured to the exact day, hour and minute.
If required, the jobs can also be started manually at any time.

Jobs can also have an active or inactive status. With an active status the jobs are started according to the configured trigger. If they are inactive, however, they can only be started manually. The status can be changed at any time.

Monitoring of jobs is made possible by the "Active jobs" view, where all active jobs can be seen at a glance. In addition, with the appropriate parameterisation, the course of the job can be traced with the help of the log entries. The parameterised log level (a defined status during the course of the job, such as error, warning, ...) shows whether a job ran without problems or whether particular problems occurred.
If required, mail dispatch can also be configured here. The mail is sent to a defined person if a log entry with a specified level exists.

Some jobs are standard jobs, which can only be executed as predefined - configurable jobs can be adapted individually to user requirements:
--> creating and editing job configurations

Definitions of terms

• A job is a periodically running utility that is necessary for the correct operation of the customer system. It carries out system activities that can be performed in the background.

• A configured job is a Webdesk standard job with a parameterised customer-specific configuration. This parameterisation is carried out via the 'Job configuration' tab in the job form. A configured job therefore uses the functions of a standard job, but with the settings that make sense for the customer.

• A job trigger is scheduling information per job that specifies the intervals at which the job is to be started. Several job triggers can be defined per job.

• A standard job that is configurable provides its own configuration form and is not yet executable as such. Only once a new job configuration has been created can it be started. A "non-configurable" job, by contrast, appears in the list of jobs immediately, so it is immediately executable (and schedulable), but provides no further parameterisation options.

Thanks to the flexible configuration option, a standard job can run in several "variations" in one system. Each configured job forms a new unit that can be scheduled separately.

Every module can "contribute" new jobs (both configurable and non-configurable) and thereby extend the "toolbox" of the Webdesk system in the job area.

Trigger

Jobs can be started automatically with the help of a so-called trigger. The trigger creates a schedule, so that the jobs can be started as desired (hourly, daily, weekly or monthly, ...). The setting can be configured to the exact day, hour and minute.
If required, the jobs can also be started manually at any time.
Jobs can also have an active or inactive status. With an active status the jobs are started according to the configured trigger. If they are inactive, however, they can only be started manually. The status can be changed at any time.

• Schedule type
  The trigger is selected here:
• minutely trigger
  If this parameter is selected, the job is restarted every minute
• hourly trigger
  With this parameter the job is restarted every hour
• daily trigger
  The exact time (hours and minutes) can be selected
• weekly trigger
  The day of the week and the time can be selected
• monthly trigger
  Selection of the day and the time at which the trigger is to start
• Simple trigger
  Possible settings are the number of repetitions, start and end date, minutes in the interval.
• Cron trigger
  This is a special kind of trigger. The cron expression can consist of 6 or 7 characters separated by spaces. These characters can represent all permitted values and can also contain some special characters (e.g. , - * / ). The character * stands here, for example, for all possible values (wildcard). The meaning of the other special characters can be found under the link given below.
  In this way a point in time (hour, minutes, date, day, month, year, etc.) can be determined for the trigger. The cron expression can look like this, for example: 0 0 12 * * ?, and means that the trigger should fire daily at 12 o'clock (midday).
• Legend (fields in the correct order):

• Field name	Permitted values	Permitted special characters
  Seconds	0-59	, - * /
  Minutes	0-59	, - * /
  Hours	0-23	, - * /
  Day-of-month	1-31	, - * ? / L W C
  Month	1-12 or JAN-DEC	, - * /
  Day-of-Week	1-7 or SUN-SAT	, - * ? / L C #
  Year (Optional)	empty, 1970-2099	, - * /

• Examples:

  Expressions	Meaning
  0 0 12 * * ?	Starts daily at 12:00
  0 15 10 ? * *	Starts daily at 10:15
  0 15 10 * * ?	Starts daily at 10:15
  0 15 10 * * ? *	Starts daily at 10:15
  0 15 10 * * ? 2005	Starts daily at 10:15 during the year 2005
  0 * 14 * * ?	Starts daily every minute beginning at 14:00 and ending at 14:59
  0 0/5 14 * * ?	Starts daily every 5 minutes beginning at 14:00 and ending at 14:55
  0 0/5 14,18 * * ?	Starts daily every 5 minutes beginning at 14:00 and ending at 14:55, AND every 5 minutes beginning at 18:00 and ending at 18:55
  0 0-5 14 * * ?	Starts daily every minute beginning at 14:00 and ending at 14:05
  0 10,44 14 ? 3 WED	Starts at 14:10 and at 14:44 every Wednesday in the month of March
  0 15 10 ? * MON-FRI	Starts at 10:15 every Monday, Tuesday, Wednesday, Thursday and Friday
  0 15 10 15 * ?	Starts at 10:15 on the 15th of every month
  0 15 10 L * ?	Starts at 10:15 on the last day of every month
  0 15 10 ? * 6L	Starts at 10:15 on the last Friday of every month
  0 15 10 ? * 6L 2002-2005	Starts at 10:15 on the last Friday of every month in the years 2002, 2003, 2004 and 2005
  0 15 10 ? * 6#3	Starts at 10:15 on the third Friday of every month

  Further information on the subject of cron triggers can be found at: http://quartz.sourceforge.net/javadoc/org/quartz/CronTrigger.html

• Settings
• Name
  If several triggers are provided for, they can be named individually
• Active
  Where there are several triggers, individual ones can be set to active / inactive without the job being affected.
• Delete
  Activating the check box deletes the existing trigger (activate the check box by clicking it, then "Save" or "Save & Close")
• New trigger
  A new trigger can be created here. Selection works the same way as for the schedule type
• Save, Save & Close
  Clicking Save applies the change; the form could still be edited further. "Save & Close" saves the job and returns you to the job overview

Relevant menu items / actions

The following menu items in the Full System Administrator contain the relevant functions for managing and monitoring jobs:

• System > Jobs
• Monitoring > Active jobs
• Monitoring > Log entries

Monitoring / log entries

For the monitoring of jobs it is extremely important that the implementing job classes also log appropriately. This logging information is then usually written to the Webdesk database logs and can then be evaluated via the Monitoring > Log entries view.

Monitoring of jobs is made possible by the "Active jobs" view, where all active jobs can be seen at a glance. In addition, with the appropriate parameterisation, the course of the job can be traced with the help of the log entries. The parameterised log level (a defined status during the course of the job, such as error, warning, ...) shows whether a job ran without problems or whether particular problems occurred.

Recommended log settings

In principle the Loglevel of Jobs in the log settings (Full System Administrator: System--> Log settings) should be set at least to INFO. This ensures that all log information qualified by the programmer as INFO or higher is written to the database log. With batch processing, for example, this should usually log the number of records processed. In any case errors (exceptions) are then definitely logged!
If errors occur in the job, it can be worthwhile raising the logging level for jobs to DEBUG!

Mail dispatch

If required, mail dispatch can also be configured in the jobs. The mail notification contains only the job log, and is sent to a defined person if a log entry with a specified level exists.

• Activate mail notification
  If the checkbox is ticked, mail notification is activated
• Log level
  An e-mail is sent if a log entry with the specified level exists. Prioritisation of error messages
• Fatal - only error messages are output
• Error - all error messages
• Warn
• Info
• Debug - outputs the most messages (e.g. "loading record with number xy...")
• All - all messages are output
• Search criterion
  If one of the log entries contains one of the specified words, a mail is sent.
• Send only a link to the logs
  If the parameter is ticked, only a link to the log entries is sent. Otherwise all log details are sent.
• Address of the server
  Enter the address of the server here. E.g. http://myserver.com/webdesk
• Persons to be informed
  Entry of a valid e-mail address for notifications that the job has run, or that errors have occurred.
• Add > add new e-mail addresses
• Delete > delete existing e-mail addresses

Best practice

If many jobs are used in one system, the following basic rules should be observed:

• A customer-specific naming convention should be adhered to when assigning the job name, so that the purpose of the job can be grasped quickly later on.
  The job configuration should not have the same name as the job it is derived from. If the same name is entered, an error message occurs and the new job cannot be saved.
• The description field should genuinely be used to describe the purpose of the job for the administrator (e.g. import of person master data from IF6020)
• If Webdesk runs in a cluster (more than one server), it makes sense to concentrate the jobs on one server. Running the same job in parallel (simultaneously) on different cluster nodes can lead to unpredictable results - in the worst case to database inconsistencies.
• Computationally intensive jobs should run in the evening or at night, so as not to place unnecessary load on the server hardware during "rush hour". With nightly jobs, however, the scheduling of the jobs must be coordinated with the database backup schedule in order to avoid problems!
• Sending log information by mail regularly makes it possible to react early to particular errors in the jobs.

Log entries in the Webdesk database should be deleted regularly (there is a dedicated job for this!), otherwise the Webdesk database can become too full, which can subsequently lead to performance problems.