Scheduled jobs — SaaS restrictions

Scope: managed applications.

1. SaaS applications running via 1cFresh must not employ scheduled jobs included in separators. Having separated scheduled jobs with multiple data areas in an infobase may overload working processes and cause user experience issues.

2. To regularly execute a particular code in each data area of a separated infobase, use the "Job queue" SSL subsystem or develop identical job queue functionality.

For example, you need to add the PriceCheck scheduled job to check price lists in each area on schedule, compare prices with exchange rate dynamics, and generate messages for users.

Incorrect:

Add the PriceCheck scheduled job to the configuration and include it in the DataAreaMainData common attribute.

Correct:

Implement the applied check functionality. For example, create the CheckPrices procedure in the PriceManagement module.
Include the PriceCheck shared predefined scheduled job in the configuration. Set the PriceManagement.CheckPrices procedure as a handler.
Add the following code to the JobsQueueOverridable common module:

Procedure OnGetTemplateList(Templates) Export
Templates.Add(Metadata.ScheduledJobs.PriceCheck.Name);
EndProcedure

Procedure OnDefineHandlerAliases(NamesAndAliasesMap) Export
NamesAndAliasesMap.Insert(Metadata.ScheduledJobs.PriceCheck.MethodName);
EndProcedure

3. The only exception is when a scheduled job needs to be performed on behalf of a specific user. For example, to take into account access restrictions set for this user. In this case, the scheduled job can be separated, but it must be included in all separators defined in the configuration.

4. In SaaS applications running via 1cFresh, avoid directly managing scheduled jobs from the code. To manage scheduled jobs, use the SSL API implemented in the ScheduledJobsServer module.

Incorrect:

// Search for a job by description.
Filter = New Structure();
Filter.Insert("Metadata", "PriceCheck");
Jobs = ScheduledJobs.GetScheduledJobs(Filter);

// Check if the job is found.
If Jobs.Count() <> 1 Then
// The event log entry is skipped.
Return;
EndIf;

// Enable the found job.
OurJob = Jobs[0];
OurJob.Use = True;
OurJob.Write();

Correct:

// Search for a job by description.
Filter = New Structure();
Filter.Insert("Metadata", "PriceCheck");
Jobs = ScheduledJobsServer.FindJobs(Filter);

// Check if the job is found.
If Jobs.Count() <> 1 Then
// The event log entry is skipped.
Return;
EndIf;

// Enable the found job.
OurJob = Jobs[0];
Parameters = New Structure();
Parameters.Insert("Use", True);
ScheduledJobsServer.ChangeJob(OurJob.UUID, Parameters);

5. Note that the "Job queue" subsystem does not guarantee that a scheduled job is executed in strict compliance with the schedule. The actual timing depends on the total number of scheduled jobs, their duration, and the number of threads of execution (regulated by the "Maximum number of active background jobs" constant).

5.1. In general, users should not be allowed to set up schedules for scheduled jobs in SaaS applications.

5.2. If a scenario requires a real-time system response for information updates, which is not supported by the scheduled job queue, consider other solutions.

If possible, configure push notifications from the system you need to exchange information with instead of using a scheduled job. Import data only when you receive a notification and send data only when necessary. For example, in the Collaboration System, push notifications are sent when the server receives an incoming SIP call.
In other cases, we recommend that you keep the scheduled job running through the job queue and ensure the prompt receipt and sending of data in a busy workspace where real-time information update is expected.

For example, a scheduled job for sending and receiving emails should run every 5 minutes, but in SaaS mode in a loaded infobase, it starts every 1 hour and 40 minutes, which is unacceptable. In this case, organize real-time email operations as follows:

The scheduled job for sending and receiving emails runs as frequently as permitted by the job queue.
Every time a user opens the email list, 1C:Enterprise loads and sends emails for the user's accounts .
The client idle handler is used to regularly send and receive emails at the required frequency, regardless of the job queue .

This approach ensures that users do not have to wait long for emails to be received when they start working with them, as most new emails will have already been received via the job queue. Real-time interaction with email servers only occurs when necessary, during actual email list operations.

* To avoid extended delays during user operations, we recommend that you make a server call in a long-running operation. The server logic must also be executed as quickly as possible and only to the extent necessary for the operation of a particular user, so as not to overload the server or interfere with the operation of other service users.

<< Prev Next >>