Menu
Is free
registration
home  /  Installation and configuration/ Routine and background jobs (1Cv8). Background job process terminated Abnormally background job process terminated 8.3

Routine and background jobs (1Cv8). Background job process terminated Abnormally background job process terminated 8.3

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 UT) and "Enterprise Accounting 3.0.43" (hereinafter BP). The exchange is one-way, from UT to BP. Prior to the upgrade from 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 in the work of users. The procedure for updating the exchange rules was carried out, but this did not give any result. The debugger showed that the problem was communication. It was decided to remove the communication 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 executed it in such a way that the data was unloaded from UT to a file. That is, synchronization via a network directory. In the power supply unit, I set up the exchange in such a way that no data is unloaded from the power supply unit.

An error occurred when calling the context method (Check): Error checking XDTO data:
The structure of the object "/ Counterparty's Bank Account / Bank" does not correspond to the type: (http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1)
Checking the "BIC" property:
Shape: Element
name: (http://v8.1c.ru/edi/edi_stnd/EnterpriseData/1.1) BIC
a type:
Required property missing
Object: Contract with counterparty No. ...

To analyze the error, I clicked on the icon "Composition of the data to be sent" and in the list of contractors registered for dispatch, I found an agreement under which an error appeared. Opened a contract, remembered the counterparty's bank account specified in the contract. Then I went over to the bank accounts registered for shipment. It turned out that the required account was not in the list of registered ones. I re-posted the problem bank account and contract. After that, I manually registered the required bank account.

I tried to synchronize data from UT again. This time, the data was successfully unloaded. An XML file was generated in the network folder containing data for transfer from UT to BP.

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

Event: Data Exchange
(SharedModule.LongedOperations.Module (371)): Background job workflow terminated abnormally
CallException (ErrorText);

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

During the further "run-in" of synchronization, it was necessary to make some changes to the rules for converting objects. Now is the time to use the Data Conversion 3.0 configuration. The online configuration help describes how to work. Articles on the ITS website also helped.

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

  • Texts of the common module "DataExchangeManagerViaUniversalFormat" from two bases
  • Scheme of both bases
  • Description of the EnterpriseData format (from any one database)
  • Conversion rules

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

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

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

Remember that the rules for registering objects for unloading are still configured in the "Data Conversion 2.0" configuration.

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

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

  • Data sync
  • Generic EntepriseData Format
  • Data Conversion 3.0
  • Data Conversion 2.0
  • Trade management
  • Enterprise accounting

It allows us to perform any calculations in the system without the user noticing, that is, in the background. Moreover, this mechanism allows us to parallelize the computation 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 starting several processes, we can tell the system that it is necessary to wait until the completion of these processes in order to then somehow reduce the result.

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

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

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


1C background job has some limitations. Since it runs on the server side, there is no interactive user experience. For example, you cannot display a message, or any information at all. 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 jobs. It should be noted here that this is a purely programmatic object and is not stored in the database in any way. That is, we create an instance of the class, initialize the properties and launch it for execution.

What tools do we have for managing background jobs? This facility is a metadata object "BackdropManager"... This object has a method "Run", with this method, the background job is started.

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

"Parameters"- 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 it is necessary to start a background task or such a task has already been started;

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

The return value is an object "BackgroundJob" containing the current name of the method, the current key, and a few more properties and methods. One of these methods is the method "Wait for Completion"... Its purpose is that we can tell the system not to do anything until the background job completes.

Background task 1C 8.2, 8.3 - Example of use

Let's give an example of working with 1C background jobs. 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 general module "BackgroundJob Handlers" which will be compiled on the server side;


2. Let's describe the export procedure in it. "PerformBackgroundCalculation (Parameter)" which takes one parameter of a string type;

Procedure ProduceBackgroundCalculation (Parameter) ExportStartTime = CurrentDate (); While CurrentDate () - TimeStart< = 6 Цикл КонецЦикла ; КонецПроцедуры Процедура КнНажатие() ОбработчикиФоновыхЗаданий. ПроизветиФоновоеВычисление("Some parameter"); End of Procedure
Ready. Now, when you start processing and press the button, 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, so that the background task 1C 8.2, 8.3 is performed, but it does not bother us.

For this:

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

Procedure KnNazenie () Parameters = New Array; Options. Add( "Some parameter"); Background Job. Execute ( "BackgroundJob Handlers.Produce andBackgroundCompute", Parameters, New UniqueIdentifier, "Test"); End of Procedure

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

The problem is not new and is discussed from time to time on all kinds of 1C forums. The simplest and most popular solution is to restart the 1C server. Unfortunately, this option is not always acceptable or highly undesirable. In such a case, there are more delicate solutions.

Here one of these methods in the form of a short step-by-step instruction:

1. Using the 1C server administration console, we are looking for a problematic filea new task in the list of connections (for example, by the start time of its work, compared with the start time of a scheduled task in the task console). We definethe workflow that contains the hung connection.

2. Open the properties of this process and mark it as unused (if only one process is used, then you must first create a new workflow so that all active connections are reconnected to it). We remember the PID number of this process.


3. We are waiting for all the current connections to move from the disconnected process to one of the used ones. Ultimately, only problematic connections should remain in our process, which we want to remove.

4. On the computer with the 1C server, using the task manager, we look for the corresponding rphost.exe process by the PID of the disabled worker process and delete it.

5 ... Just in case, you can delete the 1C workflow that we have disabled with the admin post. console and, if necessary, create a new one.

6... Ready. You can enter the job console and check the performance of the scheduled job.

Asynchronous programming concept

Asynchronous programming concept is that the result of the function execution is not available immediately, but after some time in the form of some asynchronous (breaking the usual execution order) call.

Those. The main idea of ​​asynchronous programming is to run separate method calls and continue doing other work in parallel without waiting for the calls to end.

Some methods, the probability of which exceptions is minimized, do not need an asynchronous approach, but others do require it at the very beginning of development.

As can be seen from the graphs, the coefficient of useful interactive user actions in the synchronous programming model is absent, since the system blocks the user interface, while in the asynchronous model, the user continues to actively work in the system.

When running synchronously, the application has only one thread. With the asynchronous programming model, you can launch many concurrent threads and react to new user actions as they run. After the n-thread is done, you display the result to the screen.

Background tasks in "1C: Enterprise 8"

In 1C: Enterprise 8, background jobs are designed to perform applied tasks asynchronously. They can spawn child background jobs, for example, to parallelize complex computations across different working servers of the cluster in a client-server way.

It is possible to restrict the execution of background jobs that have the same methods, according to a specific application criterion. Programmatic creation and management of background jobs is possible from any user connection to the system infobase. The background job runs on behalf of the user who created it.

The task mechanism functions both in the client-server and in the file mode of operation, but the possibilities for administration and execution of tasks in both options are slightly different.

Client-server option

In the client-server version, the task scheduling is handled by the task scheduler, which is physically located in the cluster manager.

The scheduler periodically checks to see if there are any requests for background jobs. If there are tasks to be performed, the scheduler identifies the least loaded cluster worker processes and sequentially assigns each of them its own task to be executed. Thus, the same workflow can potentially run multiple jobs in parallel. After the task is received by the workflow, the workflow establishes a connection to the infobase and executes the task within this connection. After the job completes, the workflow notifies the scheduler of the success or failure of the job.

File option

Starting from version 8.3.3.641 of the platform, the developers have greatly simplified the work with background jobs in the file version.

Previously, automatic execution of tasks required launching a separate, additional 1C: Enterprise session used as a task scheduler. And in this session, it was necessary to periodically execute the embedded language method ExecuteJobProcessing (). This approach was rather cumbersome, inconvenient, and severely limited the use of background and scheduled jobs in the file mode of operation.

Now everything has become much easier. If a thin or fat client starts, or if the web server has client connections, then in each of these applications another thread is automatically launched with a connection to the database. These threads are responsible for performing background and scheduled jobs.

Each of the listed applications has its own background jobs. If the application has initiated several background jobs, then they are executed sequentially, in the order in which they are received.

An obvious disadvantage of 1C background jobs: since they are executed on the server side, there is no possibility of interactive work with the user (for example, you cannot display a message or any other information; all this data must be stored within the infobase and further processed in some way).

It should be noted that background jobs are purely programmatic objects and cannot be saved to the database. That is, we can only create an instance of the class, initialize its properties and launch it for execution.

An example of asynchronous code execution in 1C: Enterprise 8

“Writing programs in which the result of a function call arrives at an unknown date is much more difficult than usual. Nested calls, error handling, control over what is happening - everything becomes more complicated, ”- only those who do not know how to properly use the platform's capabilities will say this, but not us!

Let's demonstrate all the simplicity and grace of asynchronous code execution in 1C: Enterprise 8!

Step 1. Let's create a new information security for configuration development

Step 2. In the configuration, add a common module "AsynchronousHandlers"

Why did we add a common module? Everything is simple here: to perform asynchronous operations in "1C: Enterprise 8" background tasks are used, which have their own manager - "BackgroundJobs Manager". This object has the Run method, which is used to start the background job.

Let's turn to the syntax helper.

Thus, we need a common module.

Step 3. In the general module "AysynchronousProcessors" we will add the export procedure OurLongedOperation ()

Procedure OurLongedOperation (Duration) Export // Simulation of continuous operation (Duration sec.). OperationStartDate = CurrentDate (); While CurrentDate () - Date of OperationStart< Длительность Цикл КонецЦикла; КонецПроцедуры

Step 4. Add the processing "AsynchronousProgrammingConcept" to the configuration (you can create external processing)

Add one props to the form:

Duration (Number)

and two teams

Perform a Long Operation;

ExecuteLongOperationAsynchronously.

Step 5. According to the syntax helper, fill out the form module

& On the Client Procedure ExecuteLongOperation (Command) ExecuteLongOperationAtServer (); EndProcedure & AtServer Procedure ExecuteLongServerOperation () AsynchronousHandlers.OurLongOperation (Duration); EndProcedure & OnClient Procedure ExecuteLongOperationAsynchronously (Command) ExecuteLongOperationAsynchronouslyAtServer (); EndProcedure & AtServer Procedure ExecuteLongOperationAsynchronouslyOnServer () Parameters = New Array; Options.Add (Duration); BackgroundJobs.Run ("AsynchronousHandlers.OurLongOperation", Parameters, New UniqueIdentifier, "An example of an asynchronous programming concept"); End of Procedure

Step 6. Let's launch and check!

Result:

If we click on the "Perform a long operation" button, then the user interface is blocked for "Duration" seconds;

If we click on the "Execute a long operation asynchronously" button, then the user interface is not blocked, but the program code is executed in parallel.

We can verify that the program code is executed asynchronously by looking at the log.

We can debug the program code that is executed in the "background" if we set the corresponding property in the debug parameters.

An example of asynchronous code execution in 1C: Enterprise 8 using BSP

An example of the implementation of an asynchronous programming concept in "1C: Enterprise 8" in the BSP will be considered on the example of processing "Current affairs".

The logic is as follows: during the start of the program, the work area of ​​the start page is initialized, where you can display the "Current affairs" processing form. This form is filled with the user's current affairs, and it takes time to complete. If the developers did not have the opportunity to execute the code asynchronously, then the user interface would be blocked for the entire time of filling out the processing form!

Let's analyze the program code of the form.

The event of the form "OnCreateAtServer" calls the procedure "RunBackgroundJob" - this is what we need.

Without being distracted by the nuances, we analyze this procedure

And here we can see that the background job manager and its Run method are used. Note that developers keep a unique ID for the background job.

For this, the developers use the method ConnectWaitingHandler (<ИмяПроцедуры>, <Интервал>, <Однократно>).



In a pluggable procedure Connectable_VerifyJobProcessing () developers call a function Job Completed (Job ID)


This function checks the execution of the background job by identifier.

It should be noted that BSP has developed common modules to support the operation of long-term server operations.

Thus, the asynchronous programming concept in 1C: Enterprise 8 slightly increases the complexity of solving problems for the developer, but noticeably improves the functionality of the program from the user's point of view.

Probably not a single serious configuration on 1C 8.3 or 8.2 can do without the use of scheduled and background jobs. 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 scheduled and background tasks, 1C will be able to perform these actions on its own, for example, during off-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:

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

Suppose our firm sells something and has its own website with prices. We want to unload them once a day to maintain their relevance.

Open the configuration and add a scheduled job.

Setting properties

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

  • In field " Method name»The procedure of a certain general module is selected, which will be directly executed. It will indicate all actions to upload prices to our site. Note that the execution will take place on the server. This is logical, because routine operations are performed without user intervention.
  • The scheduled job can be disabled or enabled as needed. You don't have to change his schedule every time. To do this, set or uncheck the " Usage».
  • Another important thing is the setting whether this scheduled task will be predetermined, or not. Predefined scheduled jobs start automatically. If this sign is not set, then you will need to run them programmatically, or use the "Task Console" processing from the ITS.
  • You can also specify the number of repetitions and the interval between them on abnormal termination. Abnormal termination refers to those situations when the tasks did not work due to an error.

Schedule setup

The final step is to set up the 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 difficult here. As part of this example, we configured the launch of our unloading of prices on the site every day 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 jobs

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

In the window that opens (after entering the login and password for accessing the IB), check that the flag on the item "Blocking of scheduled tasks is enabled" is not set. If you are faced with a situation where the task does not work out, 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 Job Console" processing built into the latest releases.

Background and scheduled tasks in file mode

In this mode, setting up and running 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, scheduled jobs are activated using the "RunJobProcessing ()" method.

You can also use the following construction:

As the name of the procedure, you must specify 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 this procedure will be performed once, or several times.

Tracking errors in background jobs

You can view the progress of background tasks, as well as the presence of possible errors in the log. In the filter, set the filter to 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, with a comment indicating the reason for the error.