Background job process 8.3 crashed. Scheduled and Background Jobs (1Cv8)

Allows us to perform any calculations in the system unnoticed by the user, that is, in the background. Moreover, this mechanism allows us to parallelize the calculation process. We can even parallelize the procedure that will be executed. To do this, our background job needs to run a few more background jobs. In this case, the processes are parallelized and, if we have a multiprocessor, multi-core system, our algorithm will work efficiently. After launching several processes, we can tell the system that we need to wait for the execution of these processes to finish in order to somehow consolidate the result.

For example, in typical configurations, while the user is working, various kinds of background service jobs are being performed. This may be evidenced by entries in the log, which records the fact that such actions were performed. Moreover, this does not affect the user's work in any way, he simply does not notice them.

Ideally, a background job is implemented in a client-server variant, in which case the entire load is transferred to the server. As for the file version, the work background job possible, but it has some peculiarities.

This is what the system will give if you do not take into account these features, and run a background task in the file version of the infobase.

1C background task has some limitations. Since it is performed on the server side, there is no possibility of interactive work with the user. For example, you can not display a message, well, in general, some information. All this data must be stored within the infobase and further processed in some way.

By contacting the syntax assistant, you can get more detailed information about 1C background tasks. It should be noted here that this object is purely programmatic and is not stored in the database in any way. That is, we create an instance of the class, initialize the properties and run it for execution.

What tools do we have to manage background jobs? This tool is a metadata object "BackgroundQuest Manager". This object has a method "Run", using this method, the background job is just started.

It has the following options:
"MethodName"- the name of the procedure or function to be executed, and it must be a procedure or function of the server context;

"Options"- an array of parameters, the number of elements of which must correspond to the number of parameters of our procedure / function specified in the parameter "MethodName";

"Key"- a certain uniqueness key, which is a line by which the system understands whether a background task needs to be launched or such a task has already been launched;

"Name"- here you can specify an arbitrary description of our method.

The return value is an object "BackgroundQuest" A that contains the current method name, the current key, and a few more properties and methods. One of these methods is the method "WaitCompletion". Its purpose is that we can tell the system not to do anything until the background job is completed.

Background task 1C 8.2, 8.3 - An example of use

Let's give an example of working with background tasks 1C. First, we will create a simple algorithm that will briefly load the 1C system in such a way that we cannot do anything at this time.

For this:

1. Let's create a common module "BackgroundHandlers", which will be compiled on the server side;

2. Describe the export procedure in it "Produce BackgroundComputation(Parameter)", which takes a single string type parameter;

Procedure PerformBackgroundComputation(Parameter) Export StartTime = CurrentDate() ; While CurrentDate() - StartTime< = 6 Цикл КонецЦикла ; КонецПроцедуры Процедура КнНажатие() ОбработчикиФоновыхЗаданий. ПроизветиФоновоеВычисление("Some Parameter") ; EndProcedure

Ready. Now, when processing is started and the button is pressed, the system freezes for a few seconds, during which nothing can be done. This is exactly what we needed to do.

Now we will ensure that these calculations are performed in the background, that is, that the background task 1C 8.2, 8.3 is performed, but it does not interfere with us.

For this:

1. In processing, in the button click event, write the following code.

Procedure KnPress() Parameters = New Array; Options. Add( "Some Parameter") ; BackgroundJob. Execute ( "BackgroundJobHandlers.PerformBackgroundComputation", Parameters, New UniqueIdentifier, "Test") ; EndProcedure

Here we pass the name of the procedure of the general module as the first parameter, and the array of parameters as the second. The third parameter is to pass a unique key and the fourth parameter is some description of our procedure.

Probably, not a single serious configuration on 1C 8.3 or 8.2 can do without the use of scheduled and background tasks. They are very convenient, as they will be executed according to a clearly defined schedule without user and programmer intervention.

For example, you need to exchange data with another program once a day. Using routine and background tasks, 1C will be able to perform these actions on its own, for example, during non-working hours. This method will not affect the work of users in any way and will save time.

First, let's figure out what they mean and how they differ:

• Scheduled task allows you to run any specific actions according to a pre-configured schedule.
• Background job is an object that contains the actions to be performed.

Suppose that our company sells something and has its own website with prices. Once a day, we want to unload them to maintain relevance.

Open the configuration and add a scheduled task.

Setting properties

Consider the most important parameters that must be filled in its properties.

• In field " Method name» the procedure of some specific general module is selected, which will be directly executed. It will indicate all the actions for uploading prices to our website. Note that the execution will take place on the server. This is logical, because routine operations are performed without user intervention.
• Scheduled task can be disabled or enabled as needed. No need to change his schedule every time. To do this, in the properties palette, check or uncheck the " Usage».
• Another important setting is whether this scheduled task will be predetermined, or not. Predefined scheduled jobs run automatically. If this flag is not set, then you will need to run them programmatically, or use the "Job Console" processing with ITS.
• You can also specify the number of repetitions and the interval between them upon crash. Abnormal completion refers to those situations when tasks did not complete due to an error.

Schedule setting

The final step is to set up a schedule for our upload to the site using the appropriate hyperlink in the properties palette.

You will see a typical schedule setting in 1C 8.3. There is nothing complicated here. As part of this example we set up the launch of our uploading of prices to the site daily from five to seven in the morning. In the event that the scheduled task does not have time to work out before 7:00, it will be completed the next day.

Blocking scheduled tasks

Run the standard 1C Enterprise Server Administration utility and open the properties of the infobase where you created the scheduled task (for 1C client-server versions).

In the window that opens (after entering the login and password for accessing IB), check that the flag on the item "Blocking scheduled tasks is enabled" is not set. If you encounter a situation where the task does not work, check this setting first.

In the same way, you can completely disable scheduled tasks in 1C 8.3. To disable specific background jobs, you can use the "Background Jobs Console" processing built into recent releases.

Background and scheduled jobs in file mode

In this mode, setting up and running these jobs is much more difficult to organize. Most often, an additional Account, whose session will always be open.

Activation of scheduled tasks in this case is performed using the method "PerformProcessingTasks()".

You can also use the following construct:

The procedure name must be the name of the client procedure to be executed. The interval shows how many seconds the execution will take. The "Once" parameter is optional. It reflects whether the given procedure will be performed once or several times.

Tracking errors in background jobs

View the progress of background jobs, as well as the availability possible errors can be in the register. In the filter, set the selection to the "Background task" application and, if necessary, select the importance of interest, for example, only "Errors".

The log will show all entries that match your selection with a comment that you can use to understand the cause of the error.

Job mechanism

The job mechanism is designed to execute any application or functionality on a schedule or asynchronously.

The job mechanism performs the following tasks:

• Ability to determine routine procedures at the stage of system configuration;
• Execution of specified actions according to the schedule;
• The execution of a call to a given procedure or function is asynchronous, i.e. without waiting for its completion;
• Tracking the progress of a specific job and getting its completion status (a value indicating the success or failure of its execution);
• Getting a list of current tasks;
• Ability to wait for the completion of one or more tasks;
• Job management (possibility of cancellation, blocking of execution, etc.).

The job engine consists of the following components:

• Metadata of scheduled tasks;
• Scheduled assignments;
• Background jobs;
• Task Scheduler.

Background jobs - designed to perform application tasks asynchronously. Background jobs are implemented using the built-in language.

Scheduled tasks - designed to perform application tasks on a schedule. Scheduled assignments are stored in information base and are created based on the metadata defined in the configuration. Scheduled job metadata contains information such as name, method, usage, and so on.

A scheduled job has a schedule that determines at what times the method associated with the scheduled job should be executed. The schedule, as a rule, is set in the infobase, but can also be set at the configuration stage (for example, for predefined scheduled tasks).

The task scheduler is used to schedule the execution of scheduled tasks. For each scheduled job, the scheduler periodically checks to see if the The current date and time schedule of the scheduled task. If it matches, the scheduler schedules that job to run. To do this, according to this scheduled task, the scheduler creates a background task that performs the actual processing.

Background jobs

Background jobs are useful for performing complex calculations, when the result of the calculation can be obtained after a long time. The job engine has the means to perform such calculations asynchronously.

A background job has an associated method that is called when the background job runs. A background job method can be any non-Global Shared Module procedure or function that can be called on the server. Background job parameters can be any values ​​that are allowed to be passed to the server. The parameters of a background job must exactly match the parameters of the procedure or function that it calls. If the background job's method is a function, its return value is ignored.

A background job can have a key - any application value. The key introduces a restriction on the launch of background jobs - only one background job can be executed per unit of time with a specific key value and a specified name of the background job method (the method name consists of the module name and the name of the procedure or function). The key allows you to group background jobs that have the same methods according to a certain application attribute so that no more than one background job is executed within one group.

Background jobs are created and managed programmatically from any connection. Any user is allowed to create a background job. At the same time, it is executed on behalf of the user who created it. A user with administrative rights, or the user who created these background tasks, is allowed to receive tasks, as well as wait for their completion, from any connection.

The background job is purely a session object, but does not belong to any user session. For each job, a special system session is created, running on behalf of the user who made the call. Background jobs do not have persistent state.

A background job can spawn other background jobs. In the client-server version, this allows you to parallelize complex calculations across cluster work processes, which can significantly speed up the calculation process as a whole. Parallelization is implemented by spawning several child background jobs, waiting for each of them to complete in the main background job.

Successful or failed background jobs are stored for 24 hours and then deleted. If the number of running background jobs exceeds 1000, then the oldest background jobs are also deleted.

Scheduled assignments

Scheduled tasks are used when you need to perform certain periodic or one-time actions in accordance with the schedule.

Scheduled tasks are stored in the infobase and are created based on the metadata of the scheduled task defined in the configuration. Metadata defines such parameters of a scheduled task as: called method, name, key, ability to use, sign of predetermination, etc. to carry out a scheduled task, etc.

Creation and management routine tasks is executed programmatically from any connection and is only allowed to users with administrative rights.

Note. When working in the file version, it is possible to create and edit scheduled tasks without starting the task scheduler.

A scheduled task is associated with a method that is called when the scheduled task is executed. A scheduled job method can be any procedure or function of a non-global shared module that can be called on the server. Scheduled job parameters can be any values ​​that are allowed to be passed to the server. The parameters of a scheduled job must exactly match the parameters of the procedure or function it calls. If the scheduled job method is a function, then its return value is ignored.

A scheduled task can have a key - any applied value. The key introduces a restriction on the launch of scheduled tasks, since per time unit, among the scheduled tasks associated with the same metadata object, only one scheduled task with a certain key value can be executed. The key allows you to group scheduled tasks associated with the same metadata object according to a certain application attribute so that no more than one scheduled task is executed within one group.

During configuration, you can define predefined scheduled jobs. Predefined scheduled jobs are no different from regular scheduled jobs, except that they cannot be explicitly created or deleted. If the metadata of the scheduled task is set to sign of a predefined scheduled task, then when updating the configuration, a predefined scheduled task will be automatically created in the infobase. If the predefined checkbox is cleared, the predefined scheduled task will be automatically deleted in the infobase when the configuration is updated. The initial values ​​of the properties of a predefined scheduled task (for example, schedule) are set in the metadata. In the future, when the application is running, they can be changed. Predefined scheduled jobs have no parameters.

The scheduled job schedule determines at what time points the scheduled job should be started. The schedule allows you to set: the date and time of the start and end of the task, the period of execution, days of the week and months on which the scheduled task should be performed, etc. (see the description of the built-in language).

Examples of scheduled task schedules:

Every hour, just one day	Retry PeriodDays = 0, Retry PeriodDuringDay = 3600
Every day once a day	Retry PeriodDays = 1, Retry PeriodDuringDay = 0
One day, one time	Retry Period Days = 0
Every other day once a day	Retry Period Days = 2
Every hour from 01.00 to 07.00 every day	Retry Period Days = 1 Retry PeriodDuring the Day = 3600 StartTime = 01.00 End Time = 07.00
Every Saturday and Sunday at 09.00	Retry Period Days = 1 Days of the Week = 6, 7 Start Time = 09.00
Every day one week, week pass	Retry Period Days = 1 PeriodWeeks = 2
At 01.00 one time	StartTime = 01.00
Last day of each month at 9:00.	Retry Period Days = 1 DayInMonth = -1 Start Time = 09.00
Fifth of every month at 9:00	Retry Period Days = 1 DayInMonth = 5 Start Time = 09.00
Second Wednesday of every month at 9:00 am	Retry Period Days = 1 Day of the week in the month = 2 Days of the Week = 3 Start Time = 09.00

You can check if a task is being executed for a given date (the RequiredExecution method of the ScheduledTasks Schedule object). Scheduled tasks are always performed on the name of a specific user. If the user of the scheduled job is not specified, then the execution occurs on behalf of the default user with administrative rights.

Scheduled jobs are executed using background jobs. When the scheduler determines that a scheduled task should be launched, a background task is automatically created based on this scheduled task, which performs all further processing. If this scheduled task is already running, it will not be run again, regardless of its schedule.

Scheduled jobs have the ability to restart. This is especially true when the scheduled task method must be guaranteed to be executed. A scheduled task is restarted when it terminated abnormally, or when the worker process (in the client-server version) or the client process (in the file version) on which the scheduled task was running terminated abnormally. In a scheduled task, you can specify how many times it needs to be restarted, as well as the interval between restarts. When implementing the method of a restartable scheduled job, it should be taken into account that when it is restarted, its execution will start from the beginning, and not continue from the moment it crashed.

It is important to remember that end time will not necessarily finish the background job at the specified time. Some statements:

* A background job may ignore its own automatic cancellation, if it did not freeze, but continues to work on that reason that not all platform operations can be undone. If performed cyclic code built-in language, the job can be canceled otherwise not. It all depends on what the job is doing. * End time - the limit within which a task can start and not end? * Forced completion of the job rolls back the changes to the moment the transaction started?

Peculiarities of performing background tasks in file and client-server versions

Mechanisms for executing background jobs in the file and client-server versions are different.

• In the file version, you need to create a dedicated client process that will perform background tasks. To do this, the global context function ExecuteJobProcessing must be called periodically in the client process. Only one client process per infobase should process background jobs (and therefore call this function). If no client process has been created to process background jobs, then when programmatically accessing the job engine, the error "Job manager is not active" will be generated. It is not recommended to use the client process that processes background jobs for other functions.

After the client process that handles the background jobs is running, other client processes are given the opportunity to program access to the background job mechanism, i.e. can run and manage background jobs.

In the client-server version, the task scheduler is used to execute background jobs, which is physically located in the cluster manager. The scheduler for all queued background jobs gets the least loaded worker process and uses it to run the corresponding background job. The worker process executes the job and notifies the scheduler of the execution results.

In the client-server version, it is possible to block the execution of scheduled tasks. Blocking the execution of scheduled tasks occurs in the following cases:

• An explicit blocking of scheduled tasks has been set on the infobase. The lock can be set via the cluster console;
• A connection block has been set on the infobase. The lock can be set via the cluster console;
• The SetExclusiveMode() method was called from the built-in language with the True parameter;
• In some other cases (for example, when updating the database configuration).

Creating Scheduled Job Metadata

Before you programmatically create a scheduled task in the infobase, you must create a metadata object for it.

To create a scheduled job metadata object in the configuration tree in the General branch for the Scheduled jobs branch, execute the Add command and fill in the following properties of the scheduled job in the properties palette:

Method name - Specify the name of the scheduled job method.

Key - specify an arbitrary string value that will be used as the key of the scheduled task.

Schedule - specifies the schedule of the scheduled task. To generate a schedule, click the "Open" link and set the required values ​​in the schedule form that opens.

The General tab specifies the start and end date of the task and the repeat mode.

The "Daily" tab specifies the daily schedule for the task.

Specify the schedule:

• start time and end time of the task;
• the end time of the task, after which it will be forcefully completed;
• task repeat period;
• the duration of the pause between repetitions;
• execution duration.

An arbitrary combination of conditions is allowed.

The weekly schedule of the task is specified on the Weekly tab.

Select the checkboxes for the days of the week on which the task will run. If you want to repeat the job, specify the retry interval in weeks. For example, the task runs in 2 weeks, the repeat value is 2.

On the tab "Monthly" the monthly schedule of the task is indicated.

Select the checkboxes for the months in which the task will run. If necessary, you can specify a specific day (month or week) of execution from the beginning of the month / week or end.

Usage - if set, the task will be executed according to the schedule.

Predefined - if set, the job is a predefined job.

Retry count on crash - Specifies the number of retries on crash.

Retry interval on crash - Specifies the retry interval on crash. Examples

Creating a background job "Updating the full-text search index":

BackgroundJobs.Run("UpdatingFullTextSearchIndex");

Creating a scheduled task "Restoring sequences":

Schedule = New ScheduleRegulationTask; Schedule.RepeatPeriodDays = 1; Schedule.RepeatPeriodDuringDay = 0;

Task = ScheduledTasks.Create ScheduledTask("RestoringSequences"); Task.Schedule = Schedule; Task.Write();

Job Console

Processing with ITS, manages scheduled tasks:

Work with scheduled tasks

Job objects

Job objects are not referenced, but are stored in the database in some special storage.

If the "Predefined" flag is enabled in the metadata, then such an object is created automatically when 1C:Enterprise starts and always exists in exactly one instance. Such an object cannot be deleted.

If the "Predefined" flag is not set, then the objects of such a task are created and deleted programmatically, specifying the schedule and parameters.

Getting a list of tasks

The list of tasks can be obtained by the method GetRegularAssignments global job manager Scheduled Tasks

Scheduled Jobs Manager

GetScheduledJobs (GetScheduledJobs)

Syntax:

GetRegular Tasks(<Отбор>)

Options:

<Отбор>(optional)

Type: Structure. The structure that defines the selection. Structure values ​​can be: UniqueIdentifier, Key, Metadata, Predefined, Usage, Name. If selection is not set, all scheduled tasks are obtained.

If you are filtering by metadata, you can specify either the scheduled job metadata object or its name as the Metadata value.

Return value:

Type: Array.

Description:

Gets an array of scheduled tasks for the specified selection. Receiving scheduled tasks is possible only for the administrator.

Availability:

Scheduled = ScheduledTasks.Get ScheduledTasks(Selection);

For Each Scheduled from Scheduled Loop NewLine = ScheduledTasksList.Add(); NewString.Metadata = Scheduled.Metadata.View(); NewLine.Name = Scheduled.Name; NewString.Key = Scheduled.Key; NewString.Schedule = Scheduled.Schedule; NewString.User = Regular.UserName; NewString.Predefined = Scheduled.Predefined; NewString.Usage = Regulatory.Usage; NewString.Identifier = Scheduled.UniqueIdentifier;

LastTask = Scheduled.LastTask; If LastQuest<>Undefined Then NewString.Running = LastTask.Start; NewString.Status = LastJob.Status; EndIf; EndCycle;

Creation

Created by the CreateRegularTask method of the scheduled task manager:

ScheduledJob = ScheduledJobs.Create ScheduledJob(MetadataChoice);

Scheduled Task.Name = Name; ScheduledTask.Key = Key; ScheduledTask.Use = Use; ScheduledTask.UserName = UsersChoice; ScheduledTask.Number of RepetitionsWhen Crashing = Number of RetriesWhen Crashing; ScheduledTask.RetryIntervalOnAccident = RetryIntervalOnAccident; ScheduledTask.Schedule = Schedule; ScheduledTask.Write();

TaskObject = ScheduledTasks.Create ScheduledTask("ExecuteExchange");

TaskObject.Name = Name; JobObject.Use = true;

The job object has a "Parameters" field in which the method parameters are set:

ScheduledJob

Options(Parameters)

Usage:

Reading and writing.

Description:

Type: Array. An array of scheduled task parameters. The number and composition of the parameters must correspond to the parameters of the scheduled task method.

Availability:

Server, fat client, outer join.

Note:

The ability to read and write is only available to the administrator.

Removal

Deleted by the Delete() method of the job object:

ScheduledTask.Delete();

Getting a Job Object

• list via the GetRegularTasks method:

Scheduled = ScheduledTasks.Get ScheduledTasks(Selection);

• through the FindByUniqueID method of the job manager:

Task = ScheduledTasks.FindBy UniqueIdentifier(UID);

In this article I will describe my, so far small, experience in organizing data exchange through the universal EnterpriseData format.

In my case, the exchange is configured between the configurations "Trade Management 11.2" (hereinafter referred to as UT) and "Enterprise Accounting 3.0.43" (hereinafter referred to as BP). The exchange is one-way, from UT to BP. Prior to updating Trade Management 11.1 to version 11.2, data exchange was configured using the Data Conversion 2.0 configuration. However, after switching to "11.2" in "Trade Management", errors appeared during the work of users. The procedure for updating the exchange rules was carried out, but this did not give a result. The debugger showed that the problem was in the data exchange. It was decided to remove the data exchange setting in both configurations and set it up again.

Both "Trade Management" and "Enterprise Accounting" work for us in a client-server version. I started setting up synchronization with UT. I performed it in such a way that the data was unloaded from the UT to a file. That is synchronization through the network directory. In the BP, I configured the exchange in such a way that no data was unloaded from the BP.

Error calling context method (Validate): Error validating XDTO data:
The structure of the object "/Counterparty's Bank Account/Bank" does not match the type: (http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1)KeyPropertiesBank
Checking the "BIC" property:
shape: element
name: (http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1)BIC
type:
Required property missing
Object: Agreement with counterparty No. ...

To analyze the error, I clicked on the "Composition of data to be sent" icon and in the list of counterparties registered for sending contracts, I found the contract under which the error appeared. Opened the contract, memorized the bank account of the counterparty specified in the contract. Then I moved on to bank accounts registered for shipping. It turned out that the required account was not in the list of registered ones. I rewired the troubled bank account and contract. After that, manually registered the required bank account.

I tried again to synchronize data from UT. This time the data was uploaded successfully. IN network folder formed XML file, containing data for transfer from UT to BP.

The next step is to upload the data from the file to the Enterprise Accounting Department. In the "Enterprise Accounting" configuration, I clicked the "Synchronize" button, the processing form opened with the message "Data analysis in progress". A little later, the message changed to "Data is being uploaded." At the same time, the indicator and counter showed that more than 80 thousand objects were being unloaded from the BP. This confused me, because I indicated in the settings that nothing should be unloaded from the PSU. Processing took a long time and ended with an error:

Event: Communication
(CommonModule.LongOperations.Module(371)): Background job worker process crashed
ThrowException(ErrorText);

To localize the error, I tried to change the synchronization settings and the operation options of the BP base. As a result, when I converted the database to the file version, the system worked adequately: the form for comparing two databases opened. After matching the objects, the initial synchronization was successful. Then I again transferred the database to the client-server version.

With further "running" of synchronization, it was necessary to make some changes to the rules for converting objects. It's time to use the "Data Conversion 3.0" configuration. The built-in configuration help describes how to work. The articles on the ITS website also helped.

As a result, I loaded the following data into "Data Conversion 3.0":

• Texts of the general module "Data Exchange Manager Via UniversalFormat" from two bases
• Diagram of both bases
• Description of the EnterpriseData format (from any one database)
• Conversion rules

After downloading, I opened the rules for converting data, objects, properties in "Data Conversion 3.0". Made the changes I needed. Then I used the "Unload exchange manager module" button. The text of the module has been copied to the clipboard. It remains only to insert it into the configuration.

Having experimented with setting up rules in "Data Conversion 3.0", I concluded for myself that in the case when the changes made are minor, it is easier to set up rules directly in the UT and BP configurations, in the general module "Data Exchange Manager Via UniversalFormat". If the edits are serious, such as, for example, adding a new object in exchange, then you should use the configuration " Data conversion 3.0".

I performed the task of adding the document "Order to the supplier" to the exchange plan using " Data conversion 3.0". In the standard version of UT - BP, this document is not included in the exchange plan.

Let's remember that the rules for registering objects for unloading are still configured in the "Data Conversion 2.0" configuration.

These are the first impressions about data synchronization through the universal EnterpriseData format.

P.S. If you have questions and your own observations on the exchange of data through Universal Format and config" Data conversion 3.0", write in the comments. We will exchange experiences.

• Data synchronization
• Universal EntepriseData Format
• Data Conversion 3.0
• Data Conversion 2.0
• Trade management
• Enterprise accounting