Scheduled jobs — Starting

Scope: managed applications, ordinary applications.

Best practices

1. It is recommended that you provide users with tools to start scheduled jobs interactively. For example, add a control that populates the data otherwise populated by a background scheduled job. By that, the user experience will not depend on whether scheduled jobs have been executed. In particular, this is driven by the following factors:

The administrator can disable scheduled jobs on the 1C:Enterprise server cluster.
Unlike client/server mode, file-based infobases in 1C:Enterprise 8.2 and earlier do not support scheduled jobs to run automatically.

Depending on its purpose, you can choose different ways to start a scheduled job.

1.1. If a scheduled job processes the data required for a certain form, place the control that starts this job onto this form. Examples:

In a search form, display the time of the latest index update and place the "Update index" button.
In an inbox form, display the time of the latest email server exchange and place the "Receive emails" button.
In a form designed for batch accounting, display the time of the latest batch assignment and place the "Assign batches" button.

Such forms have to inform the users about the data freshness and provide them with a UI control to run the operation that will update or process the data. The command must be available only to the users who have the right to run the operation.

Example of implementing interactive purge of obsolete objects:

&AtServer
Procedure RunScheduledJob()
MethodName = Metadata.ScheduledJobs.ClearObsoleteObjects.MethodName;

// Check whether the job that purges obsolete objects is running in the background.
Filter = New Structure;
Filter.Insert("MethodName", MethodName);
Filter.Insert("State", BackgroundJobState.Active);
CleanupBackgroundJobs = BackgroundJobs.GetBackgroundJobs(Filter);
If CleanupBackgroundJobs.Count() = 0 Then
BackgroundJobDescription = StringFunctionsClientServer.SubstituteParametersToString(
NStr("en = 'Start manually: %1'"), ScheduledJobMetadata.Synonym);
BackgroundJobs.Execute(MethodName,,, BackgroundJobDescription);
EndIf;
EndProcedure

1.2. If a scheduled job affects the data used by an undefined number of forms or by the whole infobase, it is impossible to outline the scope of forms to place the scheduled job start control. For example, this could be scheduled jobs that:

Update and restructure aggregates.
Set calculated totals period.

The abovementioned scheduled jobs affect a large number of reports that gather data from totals and aggregates.

To run these scheduled jobs interactively, place the controls in an ad-hoc form. For configurations that embed Standard Subsystems Library, you can find this form called "Scheduled and background jobs" in subsystem "Scheduled jobs."

1.3. Provide an ad-hoc form to run scheduled jobs that don't affect the application data.

For example, this could be scheduled jobs that:

Distribute emails with error details.
Distribute emails with new or overdue tasks.
Generate and distribute reports.

For configurations that embed Standard Subsystems Library, you can find this form called "Scheduled and background jobs" in subsystem "Scheduled jobs."

2. It is recommended that infobase administrators employ the following best practice: disable all scheduled jobs during infobase update. If an infobase is likely to be updated by an entry-level user, provide the following protective measures:

For file infobases, when users fail to turn on the Exclusive mode, offer them to restart the application with scheduled jobs disabled (startup parameter /AllowExecuteScheduledJobs -Off).
In scheduled job handler code, before the line that runs the handler, provide a check that cancels the scheduled job if the infobase update is in progress.

For configurations that embed Standard Subsystems Library, use the Infobase version update subsystem to implement the first measure and the OnStartExecuteScheduledJob procedure of the Common module to implement the second measure.

See also: