To come in
All computer secrets for beginners and professionals
  • Changing the text and background color
  • Creating your own presentation How to change the background in an openoffice presentation
  • How to remove headers and footers in Excel Insert a header and footers in Excel
  • How to set, change, scale dimensions in AutoCAD?
  • FTP service - file transfer
  • Using layers in AutoCAD Creating a new layer in AutoCAD
  • How to shut down the 1c task scheduler program. Automatic shutdown of the computer. Asynchronous programming concept

    How to shut down the 1c task scheduler program.  Automatic shutdown of the computer.  Asynchronous programming concept

    Probably every 1C 8.3 programmer sooner or later had to set up the execution of certain tasks on a schedule. Below I will give a detailed description of these mechanisms, I hope this will be useful information for novice 1C programmers. This is very convenient, because it does not require human action, the routine task is configured once and works according to your schedule.

    You will find detailed instructions using an example below.

    What are routine and background tasks in 1C

    • Scheduled tasks is a special 1C Enterprise 8.3 mechanism designed to perform a specific action according to a given schedule.
    • Background job- objects generated by a routine task that directly perform the intended action without the participation of the user or 1C 8.2 programmer.

    The mechanism of scheduled and background jobs works in client-server mode (SQL), thanks to the functionality of the DBMS. If you have a file database, then the task can also be configured, but according to a slightly different principle.

    Setting up background jobs in 1C client-server mode

    First, let's create a new metadata object - a routine task. I will call my task “Loading Currency Rates”. Let's look at the properties palette of this configuration object:

    Get 267 video lessons on 1C for free:

    • Method name— path to the procedure that will be executed in a background job according to a given schedule. The procedure must be in a common module. It is recommended not to use standard ones, but to create your own. Don't forget that background jobs run on the server!
    • Usage— a sign of using a routine task.
    • Predetermined— indicates whether the routine task is predetermined. If you want the routine task to work immediately after being placed in the database, specify this flag. Otherwise, you will need to use Job Console processing or cause the job to run programmatically.
    • Number of retries when a job terminates abnormally— how many times the background job was restarted if it was executed with an error.
    • Retry interval when job terminates abnormally— how often the background job will be restarted if it was completed with an error.

    And the most interesting setting is Schedule:

    Here you configure the launch interval of the procedure specified in the “Method name” field. Let's say I configured

    Attention! Don't forget to disable blocking the execution of routine and background jobs at the DBMS level!

    This can be done in the administration utility of the client-server version or when creating a new database:

    Setting up routine tasks in 1C file mode

    In file mode, setting up such jobs is somewhat more difficult. For such a task, a separate session of the 1C program must be launched. This is often solved by creating a “technical” user whose session is always running.

    In file mode, a routine job is initialized when the “RunTaskProcessing()” method is launched.

    For a specific user, you can configure this method to run using another method −

    ConnectWaitHandler( <ИмяПроцедуры>, <Интервал>, <Однократно>).

    • Procedure name— the name of the procedure connected as a wait handler. The name of the exported procedure of a managed application module (a regular application module) or a global shared module. The procedure must be located on the client.
    • Interval— period between executions of operations in seconds.
    • One time- how to complete the task, once or not.

    ConnectWaitHandler, 3600 ) ;

    A two-minute video that shows how to set up a routine task in the 1C configurator:

    Probably, not a single serious configuration on 1C 8.3 or 8.2 can do without the use of routine and background tasks. They are very convenient, since they will be executed according to a clearly defined schedule without user or 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 independently, for example, during non-working hours. This method will not affect the user experience in any way and will help save time.

    First, let's figure out what they mean and what is their difference:

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

    Let's assume that our company sells something and has its own website where prices are located. We want to upload them once a day to maintain relevance.

    Open the configuration and add a scheduled task.

    Setting properties

    Let's look at the most important parameters that need to be filled in its properties.

    • In field " Method name» selects the procedure of a specific general module that will be directly executed. It will indicate all the steps for uploading prices to our website. Please note that execution will take place on the server. This is logical, because routine operations are performed without user participation.
    • The scheduled task can be disabled or enabled as needed. There is no need to edit his schedule every time. To do this, in the properties palette, set or clear the flag " Usage».
    • Another important thing is to set whether this routine task will be predetermined, or not. Predefined scheduled tasks are launched automatically. If this feature is not installed, then you will need to launch them programmatically, or use the “Task Console” processing with ITS.
    • You can also specify number of repetitions and interval between them in case of abnormal termination. Abnormal termination refers to those situations when jobs were not completed due to an error.

    Setting up a schedule

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

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

    Blocking scheduled tasks

    Run the standard utility “Administering 1C Enterprise Servers” and open the properties of the infobase where you created the routine task (for client-server versions of 1C).

    In the window that opens (after entering your login and password to access the information security), check that the checkbox “Blocking of routine tasks is enabled” is not selected. If you encounter a situation where the task does not work, check this setting first.

    In the same way, you can completely disable routine tasks in 1C 8.3. To disable specific background jobs, you can use the “Background Job Console” processing built into the latest releases.

    Background and scheduled tasks in file mode

    In this mode, setting up and launching these tasks is much more difficult to organize. Most often, an additional account is created, the session of which will always be open.

    In this case, routine tasks are activated using the “RunTaskProcessing()” method.

    You can also use the following construction:

    As the procedure name, you must specify the name of the client procedure that will be executed. The interval shows how many seconds later the execution will take place. The “One time” parameter is not required. It reflects whether this procedure will be performed once or several times.

    Tracking errors in background jobs

    You can view the progress of background jobs, as well as the presence of possible errors, in the log. In the filter, select the “Background job” application and, if necessary, select the importance of interest, for example, only “Errors”.

    The log will show all entries that match your selection, along with a comment that will help you understand the reason for the error.

    1 Job mechanism
    2 Background jobs
    3 Scheduled tasks
    4 Features of performing background jobs in file and client-server versions
    5 Creating metadata for a routine task
    6 Job Console
    7 Working with routine tasks
    7.1 Job objects
    7.2 Getting a list of tasks
    7.3 Creation
    7.4 Uninstallation
    7.5 Getting a job object

    Job mechanism

    The job engine is designed to perform any application or functionality on a schedule or asynchronously.

    The task mechanism solves the following problems:

    • Ability to define regulatory procedures at the system configuration stage;
    • Execution of specified actions according to schedule;
    • Making a call to a given procedure or function asynchronously, i.e. without waiting for its completion;
    • Tracking the progress of a specific task and obtaining its completion status (a value indicating whether it was successful or not);
    • Obtaining a list of current tasks;
    • Ability to wait for one or more tasks to complete;
    • Job management (possibility of cancellation, blocking of execution, etc.).

    The job mechanism consists of the following components:

    • Metadata of routine tasks;
    • Regular tasks;
    • Background jobs;
    • Task Scheduler.

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

    Scheduled tasks - designed to perform applied tasks on a schedule. Routine tasks are stored in the information base and are created based on metadata defined in the configuration. Metadata of a regulatory task contains information such as name, method, use, etc.

    A routine task has a schedule that determines at what times the method associated with the routine task must be executed. The schedule, as a rule, is specified in the information base, but can also be specified at the configuration stage (for example, for predefined routine tasks).

    The task scheduler is used to schedule the execution of routine tasks. For each scheduled job, the scheduler periodically checks whether the current date and time matches the schedule of the scheduled job. If it matches, the scheduler assigns that task to execution. To do this, for this scheduled task, the scheduler creates a background task, which performs the actual processing.

    Background jobs

    Background jobs are convenient to use to perform complex calculations when the result of the calculation can take a long time to obtain. The job engine has the means to perform such calculations asynchronously.

    Associated with a background job is a method that is called when the background job runs. A background job method can be any procedure or function of a non-global common module 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 given background job method name (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 specific application characteristic 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. Moreover, it is executed on behalf of the user who created it. Receiving tasks, as well as waiting for their completion, is allowed from any connection to a user with administrative rights, or to the user who created these background jobs.

    A background job is a purely session object and does not belong to any user session. For each task, 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 worker processes, which can significantly speed up the calculation process as a whole. Parallelization is implemented by spawning several child background jobs and waiting for each of them to complete in the main background job.

    Background jobs that complete successfully or fail are stored for 24 hours and then deleted. If the number of completed background jobs exceeds 1000, the oldest background jobs are also deleted.

    Scheduled tasks

    Scheduled tasks are used when it is necessary to perform certain periodic or one-time actions according to a schedule.

    Scheduled tasks are stored in the information base and are created based on the metadata of the routine task defined in the configuration. Metadata specifies such parameters of a routine task as: called method, name, key, possibility of use, sign of predetermination, etc. When creating a routine task, you can additionally specify the schedule (can be specified in the metadata), values ​​of the method parameters, name of the user on whose behalf the carry out routine tasks, etc.

    The creation and management of scheduled tasks is performed programmatically from any connection and is permitted only to users with administrative rights.

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

    Associated with a routine task is a method that is called when the routine task is executed. The routine task method can be any procedure or function of a non-global common module that can be called on the server. The parameters of a routine task can be any values ​​that are allowed to be transmitted to the server. The parameters of a routine task must exactly match the parameters of the procedure or function that it calls. If the routine task method is a function, then its return value is ignored.

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

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

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

    Examples of routine task schedules:

    Every hour, just one day

    RepeatDays Period = 0, RepeatDays Period = 3600

    Every day once a day

    RepeatDays Period = 1, RepeatDays Period = 0

    One day, one time

    PeriodRepeatDays = 0

    Every other day once a day

    PeriodRepeatDays = 2

    Every hour from 01.00 to 07.00 every day

    PeriodRepeatDays = 1
    Repeat PeriodDuring Day = 3600
    Start Time = 01.00
    End Time = 07.00

    Every Saturday and Sunday at 09.00

    PeriodRepeatDays = 1
    Days of the Week = 6, 7
    Start Time = 09.00

    Every day for one week, skip a week

    PeriodRepeatDays = 1
    PeriodWeeks = 2

    At 01.00 once

    Start Time = 01.00

    Last day of every month at 9:00.

    PeriodRepeatDays = 1
    DayInMonth = -1
    Start Time = 09.00

    Fifth day of every month at 9:00

    PeriodRepeatDays = 1
    DayInMonth = 5
    Start Time = 09.00

    Second Wednesday of every month at 9:00

    PeriodRepeatDays = 1
    DayWeekInMonth = 2
    Days of the Week = 3
    Start Time = 09.00

    You can check whether a task is running for a given date (the RequiredExecution method of the ScheduleTasks object). Scheduled tasks are always performed under the name of a specific user. If the user of the scheduled task is not specified, then execution occurs on behalf of the default user who has administrative rights.

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

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

    It's important to remember that End time will not necessarily complete the background job at the specified time. Some statements:
    * A background job can ignore its automatic cancellation if it is not stuck but continues to run for some reason
    that not all platform operations can be reversed. If the built-in language cyclic code is executed, then cancel the job
    maybe otherwise no. It all depends on what the job does.
    * End time - the boundary within which a task can start rather than end?
    * Forced termination of a task rolls back the changes made to the start of the transaction?

    Features of executing background jobs in file and client-server variants

    The 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 jobs. To do this, the client process must periodically call the global context function ExecuteJobProcessing. Only one client process per infobase should process background jobs (and, accordingly, call this function). If a client process has not been created to process background jobs, then when programmatically accessing the job engine, the error “Job Manager is not active” will be displayed. It is not recommended to use a client process that processes background jobs for other functions.

    Once the client process processing background jobs is started, other client processes are able to programmatically access the background job engine, i.e. can run and manage background jobs.

    In the client-server version, a task scheduler is used to execute background jobs, which is physically located in the cluster manager. For all queued background jobs, the scheduler 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 routine tasks. The execution of routine tasks is blocked in the following cases:

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

    Creating metadata for a routine task

    Before you programmatically create a routine task in the infobase, you need to create a metadata object for it.

    To create a metadata object for a routine task in the configuration tree in the “General” branch for the “Routine tasks” branch, execute the “Add” command and fill in the following properties of the routine task in the properties palette:

    Method name - indicate the name of the routine task method.

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

    Schedule - indicates the schedule of the routine task. To create a schedule, click the “Open” link and in the schedule form that opens, set the required values.

    On the “General” tab, the start and end dates of the task and the repeat mode are indicated.

    On the “Daily” tab, the daily schedule of the task is indicated.

    Specify the schedule:

    • start time and end time of the task;
    • task completion time, after which it will be forcibly terminated;
    • task repetition period;
    • duration of pause between repetitions;
    • execution duration.

    It is allowed to specify an arbitrary combination of conditions.

    On the “Weekly” tab, the weekly schedule of the task is indicated.

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

    On the “Monthly” tab, the monthly schedule of the task is indicated.

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

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

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

    Number of retries in case of abnormal termination - indicates the number of retries in case of abnormal termination.

    Retry interval on abnormal termination - specifies the retry interval upon abnormal termination. Examples

    Creating a background job “Full-text search index update”:

    BackgroundTasks.Run("UpdatingFullTextSearchIndex");

    Creating a routine task “Recovery of sequences”:

    Schedule = New ScheduleTask;
    Schedule.PeriodRepeatDays = 1;
    Schedule.RepeatPeriodDuringDay = 0;

    Task = RoutineTasks.CreateRoutineTask("Restoring Sequences");
    Job.Schedule = Schedule;
    Task.Write();

    Job Console

    Processing with ITS, manages routine tasks: ConsoleTasks.epf

    Working with routine 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 is launched and always exists in exactly one instance. Such an object cannot be deleted.

    If the "Predefined" flag is not set, then 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 using the method Get RoutineTasks global job manager RoutineTasks

    ScheduledJobsManager

    Get ScheduledJobs (GetScheduledJobs)

    Syntax:

    Get RoutineTasks(<Отбор>)

    Options:

    <Отбор>(optional)

    Type: Structure. Structure defining selection. Structure values ​​can be: UniqueIdentifier, Key, Metadata, Predefined, Usage, Name. If selection is not specified, all routine tasks are obtained.

    If you are filtering by metadata, then as the Metadata value you can specify either the metadata object of the routine task or its name.

    Return value:

    Type: Array.

    Description:

    Receives an array of routine tasks for a given selection. Receiving scheduled tasks is only possible for the administrator.

    Availability:

    For Each Regular of the Regulatory Cycle
    NewLine = List of ScheduledTasks.Add();
    NewRow.Metadata = Regular.Metadata.View();
    NewLine.Name = Regular.Name;
    NewString.Key = Regular.Key;
    NewLine.Schedule = Schedule.Schedule;
    NewLine.User = Regular.UserName;
    NewString.Predefined = Regular.Predefined;
    NewString.Use = Regular.Use;
    NewString.Identifier = Regular.UniqueIdentifier;

    LastTask = Regular.LastTask;
    If LastTask is Undefined Then
    NewLine.Running = LastTask.Start;
    NewRow.State = LastTask.State;
    endIf;
    EndCycle;

    Creation

    Created by the Create RoutineTask method for the manager of routine tasks:

    RoutineTask = RoutineTasks.CreateRoutineTask(MetadataSelection);

    RegularTask.Name = Name;
    RegularTask.Key = Key;
    RegularTask.Use = Usage;
    RoutineTask.UserName = UsersChoice;
    RoutineTask.Number ofRepetitionsAtEmergencyCompletion =NumberofRepetitionsAtEmergencyCompletion;
    ScheduledTask.RepeatIntervalAtEmergencyCompletion = RetryIntervalAtEmergencyCompletion;
    ScheduleTask.Schedule = Schedule;
    RegularTask.Record();

    TaskObject = RoutineTasks.CreateRoutineTask("ExchangeExchange");

    TaskObject.Name = Name;
    JobObject.Use = True;

    The task object has a "Parameters" field in which the method parameters are specified:

    ScheduledJob

    Parameters

    Usage:

    Read and write.

    Description:

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

    Availability:

    Server, thick client, external connection.

    Note:

    Read and write capabilities are only available to the administrator.

    Removal

    Deleted using the Delete() method of the task object:

    ScheduledTask.Delete();

    Getting a Job Object

    • list via the GetRoutineTasks method:
      Routine = RoutineTasks.GetRoutineTasks(Selection);
    • via the FindByUniqueIdentifier of the task manager method:
      Task = ScheduledTasks.FindByUniqueIdentifier(UID);

    [you must register to view the link]

    When working in 1C, there are many routine operations that must be launched or formed according to a schedule to perform one or another action, for example: posting documents or loading data into 1C from a website.

    I recently posted an article: It's time to automate this:

    Routine and background tasks

    The job engine is designed to perform any application or functionality on a schedule or asynchronously.

    The task mechanism solves the following problems:

    • Ability to define regulatory procedures at the system configuration stage;
    • Execution of specified actions according to schedule;
    • Making a call to a given procedure or function asynchronously, i.e. without waiting for its completion;
    • Tracking the progress of a specific task and obtaining its completion status (a value indicating whether it was successful or not);
    • Obtaining a list of current tasks;
    • Ability to wait for one or more tasks to complete;
    • Job management (possibility of cancellation, blocking of execution, etc.).

    The job mechanism consists of the following components:

    • Metadata of routine tasks;
    • Regular tasks;
    • Background jobs;
    • Task Scheduler.

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

    Scheduled tasks & are designed to perform application tasks on a schedule. Routine tasks are stored in the information base and are created based on metadata defined in the configuration. Metadata of a regulatory task contains information such as name, method, use, etc.

    A routine task has a schedule that determines at what times the method associated with the routine task must be executed. The schedule, as a rule, is specified in the information base, but can also be specified at the configuration stage (for example, for predefined routine tasks).

    The task scheduler is used to schedule the execution of routine tasks. For each scheduled job, the scheduler periodically checks whether the current date and time matches the schedule of the scheduled job. If it matches, the scheduler assigns that task to execution. To do this, for this scheduled task, the scheduler creates a background task, which performs the actual processing.

    I think that’s enough with the description - let’s get down to implementation:

    Creating a routine task

    Method name– path to the procedure that will be executed in a background job according to a given schedule. The procedure must be in a common module. It is recommended not to use standard common modules, but to create your own. Don't forget that background jobs run on the server!

    Usage– sign of using a routine task.

    Predetermined– indicates whether the routine task is predetermined.

    If you want the routine task to work immediately after being placed in the database, specify the attribute Predetermined. Otherwise, you will need to use the “Job Console” processing or trigger the task to run programmatically.

    Number of retries when a job terminates abnormally– how many times the background job was restarted if it was executed with an error.

    Retry interval when job terminates abnormally– how often the background job will be restarted if it was completed with an error.

    Setting up a schedule

    Schedule completing the task:

    Every hour, just one dayRepeatDays Period = 0, RepeatDays Period = 3600
    Every day once a dayRepeatDays Period = 1, RepeatDays Period = 0
    One day, one timePeriodRepeatDays = 0
    Every other day once a dayPeriodRepeatDays = 2
    Every hour from 01.00 to 07.00 every dayPeriodRepeatDays = 1RepeatPeriodDuringDay = 3600StartTime = 01.00

    End Time = 07.00

    Every Saturday and Sunday at 09.00RepeatDays Period = 1WeekDays = 6, 7StartTime = 09.00
    Every day for one week, skip a weekPeriodRepeatDays = 1PeriodWeeks = 2
    At 01.00 onceStart Time = 01.00
    Last day of every month at 9:00.PeriodRepeatDays = 1DayInMonth = -1StartTime = 09.00
    Fifth day of every month at 9:00PeriodRepeatDays = 1DayInMonth = 5StartTime = 09.00
    Second Wednesday of every month at 9:00PeriodRepeatDays = 1DayWeekMonth = 2DaysWeek = 3

    Start Time = 09.00

    Features of executing background jobs in file and client-server variants

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

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

    Once the client process processing background jobs is started, other client processes are able to programmatically access the background job engine, i.e. can run and manage background jobs.

    In client-server version To execute background jobs, a task scheduler is used, which is physically located in the cluster manager. For all queued background jobs, the scheduler 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 routine tasks. The execution of routine tasks is blocked in the following cases:

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

    Processing the launch and viewing of scheduled tasks you can download here.

    A new one came out not long ago version 8.3.6 programs "1C:Enterprise".

    A number of changes have been prepared that should make the interface Taxi more convenient, improve its usability.

    Usability of the Taxi interface in version 8.3.6

    "Show in list" command.

    In the old, unmanaged interface, there was a “Find in List” command. This command was not implemented in the managed interface. But after analyzing the accumulated experience and feedback, it was decided to return this command to the interface. Because users of previous versions of 1C:Enterprise considered it necessary and convenient. Because the presence of such a command certainly increases the usability of the program.

    Now it's called "Show in list":

    This command will appear in the form of an information register entry and in the forms of objects: reference books, documents, characteristics types, business processes, tasks, calculation types, accounts, exchange plan nodes, external source tables and external data source cube dimension tables.

    For documents included in journals, this will not be one command, but a submenu. It will allow you to go both to the list of documents and to any of the journals in which this document is included.

    Displaying pictures and text in the section panel.

    Now the user can independently choose one or another location option:

    picture on the left, text on the right

    or text under the picture.

    Graphical diagram command panel.

    To the interface Taxi The graphical diagram command bar has been returned. No special skills are required to use this feature. It’s just that the command panel of the form now has another source of commands - a graphical diagram. Place a graphic diagram on the form. Add a group to the form - command panel. Specify the source of commands for it - a graphical diagram.

    Taxi interface in version 8.3.6.

    Search in the function menu.

    The use of the function menu in large configurations has been greatly simplified. Now you can quickly find commands, even if you don't know which section they are in.

    The appearance of the function menu has changed slightly. A search field and a settings icon appeared in the upper right corner. The settings commands for the “Navigation Settings” and “Action Settings” panels have been removed under the settings icon.

    And to find any command, now you just need to start typing the words you are looking for on the keyboard. The cursor will automatically move to the search field and the characters you type will be displayed in it. The search is performed simultaneously across several string fragments. When typing from the keyboard, fragments of lines must be separated from each other by spaces.

    For example, if you want to find receipt documents, you can type “doc” and then separated by a space “post”:

    To make it easier to navigate search results, the platform:

    • Highlights found string fragments (including in the names of subsystems and command groups);
    • Displays results in a hierarchy of sections and subsystems.

    If all the results do not fit into the function menu, a vertical scroll bar appears and the menu can be scrolled with the mouse.

    When searching, you can only use the keyboard. It's comfortable. You can clear the search field by pressing the Esc key. And you can now call the function menu itself using the F10 key.

    The search is performed on the server. When performing a search, instead of a magnifying glass icon, an animated “circle” icon is displayed in the upper left corner.

    Working with non-standard screen resolution (DPI).

    Small print and low vision are long-standing problems in human-computer interaction. They tried to solve it at different times, by different people, in different ways. Programmers increased the font size in their applications. Users reduced screen sizes and increased screen resolution (dpi). Windows developers implemented interface scaling. But all these methods did not provide the user with a simple and convenient way to customize the application to suit their needs.

    After analyzing these problems and feedback, 1C:Enterprise was switched to dpi-aware mode. That is, now 1C:Enterprise independently performs scaling.

    You can notice that the blurriness of the texts has disappeared. Form elements began to be scaled and displayed as they should (in the old version, the footer of the tabular section was “under” the screen). The correct internal padding, placement and size of panel elements are used (scrolling of the section panel has disappeared).

    Scheduler.

    In many configurations, there is a need to display data in the form of a calendar or schedule. Visual planning tasks, for example, often arise when automating beauty salons, dental and veterinary clinics, fitness centers, etc. If desired, such tasks could be partially automated using existing tools in the platform. However, the implementation of such solutions has always been very labor-intensive, and their functionality is insufficient. In addition, they did not transfer well from one configuration to another, and did not guarantee the same performance in different client applications and different operating systems.

    For these reasons, the platform version 8.3.6 a new tool was implemented - Scheduler. It is designed to automate the planning of tasks, events, meetings, calendars, schedules and similar tasks.

    The scheduler can contain not one, but several time scales, each with its own frequency. This is convenient in cases where the displayed data needs to be identified, for example, with an accuracy of day and hour:

    If all the elements that need to be displayed do not fit into one cell, the Planner displays “+ More” and the number of elements that are hidden instead. By clicking on this inscription you can see a list of all hidden elements and open any of them:

    If desired, you can turn on or off the display of the current time in the scheduler.

    Scheduler items can display start and end times, only start times, or no time at all.

    You can color the background intervals to, for example, highlight non-working hours or weekends with a different color.

    Adding data to the scheduler is a simple mouse click. This opens a window for quickly editing the scheduler element:

    In this window you can set the text of the element (event). If you need to change other properties of an element, click the button « Edit" This window opens a standard form for editing a planner element:

    In it you can already set the beginning and end of the element, specify the measurement values ​​if they are used, and also set a schedule for the element if this event is recurring.

    You can edit existing elements either through these forms or by dragging elements and changing their borders using the mouse:

    The scheduler supports group editing operations. That is, you can select several elements at once and move, copy, change or delete them:

    The planner provides drag and drop not only within itself, but also to/from other form elements. This feature can be useful, for example, so that individual events can be dragged into the planner from a general to-do list shown in a table form.

    For any element, you can set a schedule - the frequency with which this event will be repeated. In this case, you can limit the interval during which the event will be repeated.

    If necessary, you can change not only one of the recurring events, but all events at the same time. To do this, in the editing form you need to check the box « Apply editing to all repeats":