Scope: managed applications, ordinary applications.
1. We recommend that you alternatively enable users to execute scheduled jobs manually. For example, you can offer users to process data by clicking a button instead of processing it by scheduled jobs in the background. The system operation must not depend on automatic execution of scheduled jobs. In particular:
- Execution of scheduled jobs can be deliberately disabled on 1C:Enterprise server cluster.
- Unlike client/server mode of 1C:Enterprise 8.2 or earlier, in which scheduled and background jobs are executed on the server, their automatic execution in the file mode was unavailable.
Startup options depend on scheduled jobs.
1.1. If a scheduled job changes system data required by a business process or displayed in a workstation (form), we recommend that you display a command to execute this action in such workstations. For example:
- In the data search form, display the index relevance date if it is outdated and the Update command.
- In the incoming messages list, the date and time of incoming messages are specified and the "Receive emails" command is available.
- In the workstation of an employee responsible for batch accounting, the date and time when goods are last divided into batches and the "Execute" command to divide into batches.
Make sure in such workstations users can see the data relevance and access a command to update or process the data. The command must perform the same action as a scheduled job. The command must be available only to authorized users.
Example of manual start of a job to delete obsolete object versions:
// Checking whether the background job to clear obsolete versions is executed.
Filter = New Structure;
If CleanupBackgroundJobs.Count() = 0,
BackgroundJobDescription = StringFunctionsClientServer.SubstituteParametersToString(
NStr("en = "Start manually: %1'"), ScheduledJobMetadata.Synonym);
1.2. If execution of a scheduled job affects the data displayed in an unknown number of workstations or affects the infobase in general, it is impossible to select a single workstation for commands to start all such jobs. Examples of scheduled jobs, which are not displayed in particular workstations:
- Update and rebuild aggregates.
- Set calculated totals period.
Execution of such scheduled jobs simultaneously affects numerous internal and external system reports, which are based on totals and aggregates.
In this case, we recommend that you create a separate workstation to execute these scheduled jobs. If Standard Subsystems Library is used in a configuration, such workstation is already included in the "Scheduled jobs" subsystem ("Scheduled and background jobs" form).
Examples of scheduled jobs that do not change infobase data:
- Mailings of event log error details.
- Mailings of new and expired tasks.
- Periodic start of external data processors to mail reports.
If Standard Subsystems Library is used in a configuration, such workstation is already included in the "Scheduled jobs" subsystem ("Scheduled and background jobs" form).
2. Recommendations for infobase administrators: block execution of scheduled jobs upon the infobase update. If the infobase is updated by an inexperienced user, particularly, in the file mode, take the following measures as well:
- In the file mode, upon an unsuccessful attempt to set an exclusive mode to update the infobase data, offer to automatically block scheduled jobs (the application is restarted using /AllowExecuteScheduledJobs -Off command line).
- At the beginning of scheduled job handler code, check the mode and stop a scheduled job by throwing an exception if the infobase update is not completed yet.
If Standard Subsystems Library is used in a configuration, the first recommendation is implemented in the "Infobase version update" subsystem. To fulfill the second recommendation, use the OnStartExecuteScheduledJob procedure of the Common common module. Place the procedure call at the beginning of the scheduled job handler code.