Debugging server procedures (1Cv82). Debugging server procedures (1Cv82) How to run 1s enterprise in debug mode
Implemented in version 8.3.7.1759.
We have significantly redesigned the debugging mechanism. There were several reasons for this. First, we wanted to give you the ability to debug all applications available today. Secondly, the old debugger architecture required changes in order to keep up with current trends and be able to evolve in the future. Thirdly, a universal debugging interface was needed, with which not only the 1C:Enterprise configurator could work, but also .
Main advantages
To give you an idea of the scope of the changes we've made, let's briefly list the main advantages of the new mechanism.
Debugging over HTTP
The previous debugging mechanism was based on the fact that the debugger implemented in the 1C:Enterprise configurator interacted directly with debugging objects (client and server applications). This interaction was carried out using the TCP/IP protocol.
However, with the release of 1C:Enterprise applications on the Internet, and especially with the advent of mobile applications, this approach has become a source of limitations and inconveniences. Not always the TCP / IP protocol allows the debugger to "get through" to the debugging items. After all, they can be outside the local network in which the debugger is running.
Therefore, in the new mechanism, we chose the more “all-terrain” HTTP protocol as the transport protocol, which, by the way, is also used by client applications to connect to infobases.
Modern Debugging Architecture
A feature of the previous debugging mechanism was the need to connect to the infobase using the configurator. As a result, the debugging developer had full access to all administrative functions.
The new debugging mechanism no longer needs to connect to the infobase being debugged. The main thing that the debugger now needs is the same configuration that works for clients. To get it, there is no need to connect to the debugged infobase. You can load it, for example, from a file.
Debugging mobile applications
Thanks to the use of the HTTP protocol, it became possible to debug applications executed by the mobile platform. Moreover, you can debug any contexts: client, server, as well as background jobs.
Now, while debugging, you can change the values of any writable variables. To quickly view and change local variables, we have implemented a separate window. And the very evaluation of expressions displayed by the debugger is now performed in asynchronous mode.
Debugging in Development Tools
When creating a new debugging mechanism, we implemented a new, universal programming interface for interacting with it. This interface is used by the 1C:Enterprise configurator, and the new development environment now uses the same interface. Thus, all debugging options are now available when working in .
Debug Process Architecture
The new debug architecture looks like this:
Debugging involves the debugger, debug items, and a new item - debug server.
There is no direct transfer of information between the debugger and debug items. All interaction is organized through the debug server. This is the main element of the mechanism. The debug server has a message queue through which the debugger and debug objects pass information to each other.
Both the debugger itself and the debug items communicate with the debug server over HTTP. So now it doesn't matter where these debug items are located.
Communication with the debug server is initiated by the debugger and debug items. For this, additional connections are organized. Their main purpose is to find out if there is information for them on the debug server. And if it appears, get this information.
Thus, the interaction is one-way. Information is constantly passed from the debug server to the debugger, and to debug items.
Infobase identification
The old mechanism used a connection string to identify infobases. This decision in some cases caused difficulties in matching debug items and the configurator. Because, firstly, it was case-sensitive, and secondly, when debugging some contexts, the platform automatically formed the connection string. And it did not always match the one you specified when connecting the infobase in the configurator. Finding and fixing such situations complicated the debugging process.
In the new mechanism, we got rid of the connection string. Now we are using infobase identifier. In the file infobase, such an identifier is generated when a client connection is first connected. In the server infobase, the ID of the infobase registration in the cluster is used as such an identifier.
A nice additional point here is that we have kept the old debugging mechanism in the platform for now (it may be excluded in the future). And you can use it if you want, or if you need to. So, we have improved the old mechanism, and now it also uses the infobase identifier, and not the connection string.
Typical Debugging Scenarios
From the perspective of an application developer, typical debugging scenarios have not changed. The only significant difference is that the new debugging mechanism needs to be enabled. Because it is disabled by default.
Despite this, it makes sense to get acquainted with what happens now when you start debugging. Because it may be useful to you in some non-standard work scenarios.
File option
Before you start debugging in the file mode, you need to specify in the configurator settings that you want to use the new debugging mechanism - " Debugging over HTTP».
In this case, the configurator will automatically prompt you to use the local debug server. You must agree with this and restart the configurator.
The debugging method you set is saved between Designer sessions, but it is stored in the context of infobases. Therefore, for another infobase, you will need to enable it again.
Now, at the start of the configurator, or when it is restarted, the platform will automatically start the debug server as well. This is a standalone dbgs.exe application. You can see it in the task manager.
Its ownerPID parameter contains the ID of the application that owns this debug server. In this case, this is the 1C:Enterprise configurator.
Now, if you start a 1C:Enterprise debugging session from the configurator, it will automatically connect to the debug server, and in the configurator you will see connected debugging items.
If the 1C:Enterprise session was launched without debugging, then, as before, you can connect it to the debugger. Only now you need to specify the address of the debug server:
You can find out this address from the settings of debug items:
There is one unusual moment associated with working with several file bases at once. In the file version, each configurator with http debugging enabled runs its own copy of the debug server on different ports:
Therefore, if you have several configurators open at once, then to connect the client application to the debugger, you need to select the correct one from them.
Client-server option
Before you start debugging in the client-server mode, you need to start the 1C:Enterprise server in debug mode, as before, but specify that the new HTTP mechanism will be used for debugging. For example, like this:
ragent.exe -debug -http
When the server is started in this way, the debug server will also be started.
In the ownerPID parameter, it will have the ID of the 1C:Enterprise cluster manager.
Now in the configurator settings, as in the case of the file base, you need to specify that you want to use the new debugging mechanism - " Debugging over HTTP».
In this case, the configurator will automatically prompt you to use the cluster debug server, and not the local server. You must agree with this and restart the configurator.
Connecting debug items
When starting debugging sessions from the configurator, applications automatically connect debugging items (both client and server) to the debug server.
At the same time, as before, you have the opportunity to configure the automatic connection of debug items in the configurator, regardless of how they were launched. Now these opportunities have become much richer.
First, the platform now offers you all possible debugging items to choose from.
And secondly, another, more subtle way of tuning has appeared. This is the use of pre-created selections.
You can use such filters both when connecting debug items and to view available debug items.
In the selection, in addition to the debugging items themselves, you can specify specific users whose sessions you are interested in, and also, if data separation is used, specify the area of the infobase that will be debugged.
Changing variables, object properties, and asynchronous expression evaluation
The new debugging mechanism allows you to change the values of variables while debugging. There was no such possibility in the previous mechanism.
For convenient viewing and changing local variables, which seems to be the most common task, we have implemented the window " Local variables».
Outwardly, it is very similar to the familiar to you "Scoreboard". But, firstly, this window is already automatically filled with all local variables, and secondly, you can now change the values of variables.
You can change the values of primitive types directly in the cell " Meaning»:
And to change other values, you can use the expression input window:
A nice bonus is that contextual help is fully functional in this window.
In exactly the same way, you can change the values of any (not only local) variables, properties, available for writing. In the expression calculation window (which is called by the Shift+F9 command), you can change the values of variables both in the "Value" cell and using a separate dialog.
By the way, expression evaluation itself is now performed asynchronously. This means that the configurator orders the calculation of the debug item. And some time this calculation is expected on the server. If the calculation is completed, the results are immediately sent to the configurator. If the calculation is running for a long time, then the results of these calculations asynchronously come to the configurator later. This approach allows you not to wait for long calculations in the configurator, and continue your work.
How to start debugging on server 1C...
By default, when using the 1C:Enterprise client-server architecture, the 1C code debugging mode works only on the client side. Server procedures and functions are not visible to the client machine.
To enable the use of debugging on the 1C server, you must perform the following steps:
1. Find and stop the "Server Agent 1C: Enterprise 8.3" service in the service manager (for version 8.3).
2. Open the system registry editor. You can use the command line or the Start menu tool - Run ... and the command regedit.
3. Find the branch in the registry:
- For version 1C 8.1
- For version 1C 8.2
- For version 1C 8.3
4. Change the ImagePath property, add the "-debug" directive to the end of the line. The resulting property string is: "C:\Program Files (x86)\1cv8\8.3.6.2152\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files (x86)\1cv8\srvinfo" --debug
After that, the 1C server code can be safely checked with a debugger and set breakpoints wherever required.
This article talks about how to enable debugging on a 1C 8.1, 8.2 and 8.3 server in Windows and Ubuntu operating systems.
In addition, I note that this article is included in a small series of articles about debugging in 1C:
- How to enable debugging on the 1C server
Turn on debugging on the 1C server in Windows
We launch the registry editor by running the regedit command (using Win + R or Start-> Run).
You can read more about HTTP debugging and the debug server in the next article in the series.
Enable debugging on the 1C server in Ubuntu
First we set up the server:
sudo service srv1cv83 stop
After that, open the file /etc/init.d/srv1cv83 as the superuser and find the line in it:
And we bring it to this form:
Then start the server again:
sudo service srv1cv83 start
In the configurator on the client machine, go to "Settings" -> "Launch 1C:Enterprise" -> "Additional" and enable two items:
- "Set debug permission mode"
- "Start debugging at startup"
You can read about how to install a 1C server on Ubuntu 16.04 / 18.04 in.
That's all, I hope this article was useful to you. I will also remind you about other articles in the series about debugging in 1C, links to them can be found at the beginning of this article.
8, there is a need (more on that below) for a significant reworking of the debugging procedure. This was reflected in version 8.3.7.1759. Firstly, a universal interface was created for this procedure, and secondly, such a change ensures the further development of the program itself. After all, now you can work with debugging not only through the Configurator, but also with the help of Development Tools. Consider how to enable debugging on the 1C server starting from the new version.
Using the new protocol
The previous debugger, which was implemented in previous versions, managed client and server applications using the TCP/IP protocol.
Currently, the use of such a protocol has begun to limit the access of the 1C:Enterprise program to the Internet and has created inconvenience for the operation of mobile applications.
Therefore, for free access to infobases that may be outside the local grid, the flexible HTTP protocol is now accepted for use.
New architecture
Previously, when performing configuration debugging, an employee had to connect to the infobase. To do this, it was required to give him administrator rights.
In the new version, there is no need for a direct connection to the databases - it is enough just to have the same database as the client. And you can load it from a file.
Mobile applications
Using the HTTP protocol, it is now possible to debug server data, client data, and applications.
Other changes
With the new version, it is possible to change the values for local variables in the debug procedure - a new quick view window has been implemented for this purpose.
The calculation mode has been changed to asynchronous, which allows you to continue working without waiting for the results.
Debugger in Development Tools
Interaction with the new procedure is performed in a specially designed universal programming interface. On the one hand, this interface is used by the Configurator. On the other hand, it is implemented in the new 1C:Enterprise Development Tools environment.
What does it look like now
After changing the program, the procedure proceeds according to the following scenario:
Now it involves not only the debugger and objects, as it was before. Now an additional element has been added to the chain - Server.
Not only is it added - it serves as the main element of information exchange between the debugger and objects. And the exchange itself occurs through messages queued.
And since this exchange is carried out through the HTTP protocol, now it does not matter where exactly the data can be located.
Server requests are formed by the debugger and objects in the form of additional connection requests. When they appear, they are sent the appropriate responses.
Enable debugging in different scenarios
There has been no change for the application developer. The significant difference is that the new mechanism needs to be enabled. After all, by default it is now disabled.
Let's consider what happens when the mode starts if we choose one of the two scenarios.
File script
At the beginning of the file version, it is necessary to specify in the configuration settings the use of a new mechanism - "Debugging via HTTP protocol".
Then the Configurator will automatically suggest using the local server. This condition must be accepted and the program restarted in the Configurator mode.
After that, the newly launched Configurator will save the new method we have chosen during the next session. But for the same information base. Therefore, when accessing another infobase, it must also be enabled.
The enabled mechanism will now automatically launch the Debugger Server, which is a special dbgs.exe application. It is displayed in the Task Manager window.
The value of the ownerPID parameter will match the ID of the application that is bound to it.
When you start a debugging session through the Configurator, a server connection will be made automatically. And it will reflect the connected objects.
If the 1C program was activated without a new mechanism, then you will need to enable debugging on the 1C server manually. Only now you will need to specify the server address:
Go to Tools - Options
It's in the item settings:
We go Connection - Settings
When using a file script with several databases at the same time, you need to take into account an important nuance - each of the Configurators (with the HTTP mechanism enabled) sends its own Server:
Therefore, if several Configurators are open, then the correct one must be specified to connect the Client.
Client-Server Scenario
Debugging on the 1C server according to the client-server scenario, as in the previous case, begins by starting the mode. This specifies the use of the new HTTP mechanism. This is done in this way:
ragent.exe -debug -http
When it is launched, the debugger automatically starts behind it.
The value of the ownerPID parameter will correspond to the identification number of the 1C cluster manager.
The program will generate an offer to use now the debug server of the cluster (and not the local one as in the previous scenario). We agree and restart it.
In the future, everything will go like a file script. Only when the Server Base Configurator is launched, the local debugger server will no longer start.
We hope that our publication helped you deal with the problem of how to enable debugging on the 1C server.
18.10.2016
Debugging on 1C server (8.2, 8.3...)
If the 1C database works in the client-server version, the code debugging mode on the server side is disabled. Therefore, it will not work to see step by step what happens when a function or procedure is executed. To enable server-side debugging, you need to follow a few simple steps.
Enable debugging on the server "1C:Enterprise" 8.2, 8.3
The first thing to do is to stop the 1C:Enterprise server service. We go "Start - Run" (or the key combination "Windows + R"), write "services.msc" (of course, you need to open the management of Windows services from the Administrator)After stopping, open the Windows registry editor ("Start - Run" (or the key combination "Windows + R"), write "regedit"), and find a branch with the name "" or "" depending on platform version
We are interested in the registry key named "ImagePath". Add "-debug" to the end of the key value. This means that the debugging mode on the 1C server side is activated.
It was: "C:\Program Files\1cv8\8.3.6.2530\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo"
It became: "C:\Program Files\1cv8\8.3.6.2530\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" -debug
We save and start the 1C service. All is ready! Happy debugging!
- Dignities and clothes of Orthodox priests and monasticism
- Healers and fortune tellers - why do people go to them?
- During confession. Preparation for confession. List of sins for confession. How to dress for confession
- Praise of the Most Holy Theotokos Praise of the Mother of God with an akathist what they pray for