Debugging is a step in the application solution development process. It involves finding, isolating and eliminating application errors.
Debugging can include using a debugger (see page 2-1033), performance measurement results (see page 2-1052), output of server calls (see page 2-1057) and limitation of delays for server calls (see page 2-1057). You can also run the automated testing scenario (see page 2-1060).
This chapter describes platform tools that can be used for application debugging and testing.
Debugger is a tool that facilitates program module development and debugging in 1C:Enterprise. Debugger has the following features:
debug module execution (in both file mode and client/server modes) and background jobs. Client modules of web clients cannot be debugged;
execute module step-by-step;
interrupt and resume module execution;
debug multiple modules at once;
calculate expressions for variable status analysis;
view procedure and function call stack;
abort upon error;
edit module during debugging.
Debugger uses debug items. A debug item is 1C:Enterprise script context with a set of parameters:
name of the user executing 1C:Enterprise script code;
debug item type;
name of the machine used to execute 1C:Enterprise script code;
number of the used session;
number of the IP port used by the debugger to control the debug item.
In the client/server version, if there are multiple workflows in a cluster and a session was redirected to another workflow in the process of debugging web client or server code, debugging is impossible. For details on sessions, see the "1C:Enterprise 8.3. Client/Server. Administrator Guide".
Debug items can have the following types:
Thin client – 1C:Enterprise script code executed at the thin client;
Server – 1C:Enterprise script code executed on the server;
Server (file mode version) – 1C:Enterprise script code executed on the server in file mode version;
COM-connection – 1C:Enterprise script code executed through an external connection;
Web-service – 1C:Enterprise script code that handles Web-service method calls;
Background job – 1C:Enterprise script code that handles background jobs;
Thick client – 1C:Enterprise script code executed at the thick client;
To debug 1C:Enterprise script code you should run the application that executes the code in the debug mode.
Debug mode requires TCP/IP support enabled on the computer. You can enable TCP/IP in the corresponding network connection settings.
If 1C:Enterprise is not launched, select Debug – Start Debugging. The Designer will start 1C:Enterprise up in the debug mode.
If debug mode is enabled or debugging is set to begin upon startup in the Designer settings (you can open them by selecting Tools – Options and opening the 1C:Enterprise startup tab; see page 2-1154), you can launch debugging in the run mode by selecting Tools – 1C:Enterprise. If you need to debug the code executed by a specific user, you can specify the user who launches the debug mode in the settings form.
The debugger and debug items use IP-address 127.0.0.1 when they search for each other.
To ensure stable operation of data transport service map address 127.0.0.1 to symbolic name localhost. The following mapping can be written to the file C:\Windows\system32\drivers\etc\hosts:
DNS-server is used when computer name specified in the Debugging Items dialog box and used to search for debug items is not represented as an IP-address or when debugger specified in XML files for debug settings of COM-connections and Web services is not represented as an IP-address. In other words, debugger URL is used for COM-connections and Web services as it is written in the file. If computer name is written instead of IP-address, DNS-server is still called.
To enable debugging you need to enable 1560 – 1591 port range (default) on the computer where the Designer is installed and on computers where debugging objects being used are located. If another port range is selected using the debugcfg.xml file (see page 2-1042), you need to allow usage of the new port range. Moreover, this port range should be specified on all computers where debugging objects are located (except server debugging objects that use the port range set in the 1C:Enterprise server configuration).
If ports required for the debugger are not permitted to be used on the computer where Designer is installed, debugging is not available on that computer and the following may occur:
Starting time of the client application increases.
1C:Enterprise server workflow slows down, if the server uses the debugging mode (-debug switch).
You can use the following launch startup options to enter the debug mode:
In the Designer mode, on the Tools menu, click Options, click 1C:Enterprise startup tab, click Additional tab, and select the Enable debugging mode check box. Then attach the debug item. You can also check the Begin debugging on startup check box to attach the debug item automatically upon 1C:Enterprise startup.
Open the infobase in the 1C:Enterprise mode by using the -debug command line key (debug mode).
If a client application is running, open the settings form (select Tools – Options) and set the debug mode (check the Enable debugging mode check box). Please keep in mind that you cannot uncheck this check box after you apply the settings.
If the 1C:Enterprise mode is launched and you need to enable debugging for the next launch, open the settings form (select Tools – Options), and check the Allow Debug debugging on startup check box.
In the debugging mode configuration objects are loaded when needed rather than upon system startup as in the standard server operation mode. It makes 1C:Enterprise startup faster in case of configuration changes, i.e. accelerates the development process.
Please note that system performance in the debug mode is lower than in standard operation conditions. Therefore, it is not recommended to use server debug mode for real user operations.
For location and configuration of srv1cv83 configuration file and for more details on 1C:Enterprise startup command line parameters, see the "1C:Enterprise 8.3. Client/Server. Administrator Guide".
The Server as an Application
If the 1C:Enterprise server is operating in an application mode (any OS), you should stop the server and restart it to include the -debug parameter in the command line parameters.
ragent -debug <other command line parameters>
The Server as a Windows service
If a server is running as a Windows service, do the following:
1. Stop the 1C:Enterprise server.
2. Re-register a server agent as a Windows service to include the -debug parameter in a list of ragent command parameters.
ragent -instsrvc -debug <other command line parameters>
3. Launch the 1C:Enterprise server.
The Server as a Linux daemon
If you need to transfer a 1C:Enterprise server that is working as a Linux daemon in the debug mode, do the following:
1. Stop the 1C:Enterprise server.
2. Set the SRV1CV8_DEBUG parameter to 1 in the srv1cv83 configuration file.
3. Save the configuration file.
4. Start the 1C:Enterprise server.
To enable debug mode for an external connection use the settings in XML file comcntrcfg.xml that should be located in conf subdirectory of the 1C:Enterprise setup directory. If the file cannot be found, the application runs in the standard mode.
<config xmlns="http://v8.1c.ru/v8/comcntrcfg"> <debugconfig debug="true" debuggerURL="tcp://localhost:1560"/> </config>
For details on comcntrcfg.xml file see "1C:Enterprise 8.3. Administrator Guide".
If the url attribute is specified for the debug item, the Designer should be available at the specified URL when the external connection is accessed. Otherwise, external connection will be paused and the system will wait until the Designer becomes available. You need to connect the required debugging object to continue working in the Designer.
To instruct a web service to start in the debugging mode (only for a file mode infobase), you must use settings in the default.vrd file, which should be located in a virtual application directory. You need to specify the debug item in this file, otherwise,the web service can't be debugged if this item is not present.
Example of the "debug" item from the default.vrd file:
<debug enable="true" url="tcp://localhost"/>
For more details on the default.vrd file, see the "1C:Enterprise 8.3. Administrator Guide".
If the url attribute is specified for the debug item, the Designer should be available at the specified URL when the web service is accessed. Otherwise, the web service will be paused and the system will wait until the Designer becomes available. You will need to connect the required debugging object to continue working in the Designer.
If you need to debug a web service in the client/server version of an infobase, you should enable the debugging mode on the server using the debug command line switch. For more details on 1C:Enterprise startup command line switches, see the "1C:Enterprise 8.3. Client/Server. Administrator Guide".
You can use the following launch options to enter the debug mode:
In the Designer mode, in the settings form (open with Tools – Options) on 1C:Enterprise startup – Additional, check the Enable debugging mode checkbox and then connect the debugged object. Also, you can check Begin debugging on startup, in this case connection is performed automatically when you launch 1C:Enterprise.
Open the infobase in the 1C:Enterprise mode by using the debug command line key (debug mode).
Open the infobase in the 1C:Enterprise mode by using the debug and debuggerurl="ip address" command line key.
ip address is the debugger address. In this case the debugger at 127.0.0.1 automatically connects debugging objects (the debugger should have started at the specified address).
If you need to enable debugging of the server side file mode version, you can use two methods:
Start debugging directly in the Designer as described above. In this case the debugging mode for the server side of the file mode infobase version located on the web client computer is enabled automatically.
Enable the debugging mode using the default.vrd file that should be located in a virtual application directory. You need to specify the debug item in this file, otherwise if this item is not present, the web service can't be debugged.
Example of the "debug" item from the default.vrd file:
<debug enable="true" url="tcp://192.168.0.30"/>
You should also consider the fact that system performance is slower in the debugging mode than in the normal mode. So it is not recommended to use the debugging mode of the file mode server side in real user experience.
For more details on the default.vrd file, see the "1C:Enterprise 8.3. Administrator Guide".
Note the following when debugging a web client:
The ability to interactively enable the debugging mode is not supported.
Automatic search of debugging objects on remote computers is not supported when you are debugging a web client for a file mode infobase.
Activating the Designer from a debugged web client is not supported.
Debugging external reports and processes is not supported.
To debug a web client (including client application code) in the client/server version, the 1C:Enterprise server should be started in the debug mode (the debug switch).
It is not recommended to debug a web client in low-speed communication channels.
To debug a module the debug item should be attached for debugging.
To manage attachment select the Debug – Attach for Debugging menu item. The debug item selection dialog will open. The list contains only items that belong to the infobase being debugged and have debugging enabled. The list includes only those debugging items for which the following conditions are true:
Infobase connection string for the Designer and the debugging item exactly matches with options describing the infobase location (the File option for the file mode version and the Srvr and Ref options for the client/server version), including text case.
Examples of non-matching connections strings:
// network drive R: is connected to folder \\Server\database, // At that, the following addresses are not the same from the // points of the debugger view: File=\\Server\database\mybase; File=R:\mybase; // computer db_server has ip-address 192.168.1.1, // At that, the following addresses are not the same from the // points of the debugger view Srvr=db_server;Ref=my_db; Srvr=192.168.1.1;Ref=my_db;
Debugging should be enabled in the application (for a server – the debug flag, for a client application – the corresponding command line switch or a client application settings dialog flag or a correctly configured configuration file).
Debugging items are available for connection during the session within which a specific background job, web service or external connection is working. This interval can be very short and in this case you can use automatic configuration of the debugging items connection.
When a debugging item is connected, the infobase user list should include users on behalf of which authorization was performed both in the Designer and in the debugging item.
Usually the list contains one line that refers to the configuration running in the 1C:Enterprise mode. If several 1C:Enterprise applications are running with this configuration, the list may contain several lines.
Fig. 405. Attach Debug Items
If the Search for debugging items on remote computer check box is selected, enter computer name or network address in the box to the right of the check box or select it from the list of previously entered names. The debug items found on the remote computer will be added to the available debug items list. The list of attached debug items contains the items already attached to the debugger.
To connect the selected debug item to the debugger, press Attach. In the attachment window, the debug item is moved from the available to the attached list.
To exclude debug item, select it in the list of attached items and press Detach. In the attachment window, the debug item is moved from the attached to the available list and you can attach it once again. At that moment, breakpoints set in detached debug items do not function when execution passes through them.
To close a debug item press Break. To break execution press Stop.
To open range setup dialog box press Options. The range defines limits where the debugger searches for debug items on the current or specified remote computer.
Fig. 406. Debugger Settings
The Debugger field of the dialog box contains settings for the current debugger. You can use them, for example, in command line during client application startup as the /debuggerURL command line key parameter or in an XML file containing debug settings for external connection or Web-service.
To set auto-attachment for debug items on the 1C:Enterprise server running in the debug mode, use the Autoattach dialog box and select the required debug item types.
Fig. 407. Auto-attachment Settings
Auto-connection of a background job run by the client application or web server extension is not managed in this dialog. Background jobs can only be debugged if certain conditions are met:
For the thin or thick client:
○ Allow debugging in client application;
○ Allow auto-connection to background jobs in the auto-connection settings dialog.
For the web server:
○ Allow debugging for debugged infobase in the publication file (default.vrd);
○ Allow auto-connection to background jobs in the auto-connection settings dialog.
If all ports for connection within the standard range are busy, you can specify additional range. This range is configured in the debugcfg.xml file, which should be located in the configuration files directory on the computer where the Designer and debugged client application are located or where an external connection is performed. If a port range is changed on the computer with the debugged application, these ports should be set for the Designer where debugging takes place (if the debugged application and the Designer are located on different computers). If the file cannot be found, you can use ports from the standard range (i.e. 1560:1591) for debugging. Debug items on the server use the same ports that the server processes do: rmngr and rphost. It is not necessary to specify additional port ranges for debug items on the server.
<config xmlns="http://v8.1c.ru/v8/debugcfg"> <debugports range="1540:1550"/> </config>
For details on debugcfg.xml file see "1C:Enterprise 8.3. Administrator Guide".
A breakpoint is a place in the program module where module execution stops and control passes to the debugger.
The current breakpoint, break locations and breakpoint statuses are shown in the left column of the module text, with special marks.
Fig. 408. Breakpoint Types
A breakpoint can be set on any line of the module at any time working with the debugger. If the line with a breakpoint does not contain any operators (e.g., is an empty line), contains non-executable text (e.g., procedure or function header, variable declaration, etc.) or continues an operator that begins on previous lines, breakpoint location is automatically adjusted. Breakpoint location is marked with a special character in the left column of the module window. Different characters are used for enabled and disabled breakpoints (see fig. 408).
The mouse can also be used to set or remove breakpoints. To do this, double-click in the grey margin next to the line where you want to set the breakpoint.
Use the following commands on the Debug menu of the Designer (see table below) to manage breakpoints.
Set or remove a breakpoint on the line where the cursor is located
Set a breakpoint and open the dialog box for break condition entry (a logical expression). If the condition has been entered, the command opens the dialog box for condition editing. If a breakpoint has been set on this line, the command opens the dialog box for breakpoint condition entry. Execution stops at the specified breakpoint only if the condition is satisfied
Toggle Breakpoint Off
Toggle breakpoint on/off. The command is available if the current line has a breakpoint
Clear All Breakpoints
Delete all previously set breakpoints in all modules
Disable All Breakpoints
Disable all previously set breakpoints in all modules without deleting them
View and manage breakpoints
Stop on Errors
When an error is found, the debugger stops execution and moves to the module line that has caused the error
Set breakpoints are saved when the configuration is closed. To view the list of breakpoints open the configuration and use the Debug – Breakpoint List command.
Fig. 409. Breakpoint List
Use check boxes in the On/Off column to manage the breakpoint state. If the check box is selected, the debugger stops execution at the breakpoint.
For description of other buttons see fig. 409.
In the step-by-step execution mode, the debug item completes each command and waits for a debugger command to continue execution.
When the first debug item is attached, the system adds debug management commands to the Debug menu.
There are several options for each step of module execution. Use the following commands from the Debug menu to select an option.
If the next executable module operator calls a function or a procedure, it is executed in step-by-step mode; otherwise the debugger moves to the next operator
If the next executable module operator calls a function or a procedure, it is executed completely (instead of step-by-step) and then the debugger moves to the next operator
Break the step-by-step execution of a function or a procedure and stop at the first operator after its call
Go to Cursor
Break the step-by-step execution, execute all operators up to the cursor position
Break the step-by-step module execution and continue free execution
When applications are debugged, you need to remember the following: if the Execute() operator is used in the debugged code, then:
Step-by-step execution of the code passed as an operator parameter (including procedure and function calls) is not supported.
Interruption of the program code is supported using breakpoints inside procedures and functions called from the code, which was transfered as the Execute() operator.
If you debug multiple debug items, you should remember about some step-by-step execution features:
if you stop a debug item, other debug items are also stopped when you execute the code;
if you select Continue, it results in resuming execution of all debug items;
if you select Step Over, it results in stepping to the next line for all debug items;
if you select Step In (if the executable module operator calls a function or a procedure), it results in stepping to the first operator in the call, while Step Over command is performed for other debug items.
If you debug the client/server mode and the code is sequentially executed on the client and the server (client and server debug items are attached), then:
if you select Step In (if the executable module operator calls a function or a procedure on the server), it results in stepping to the first operator in the call;
if you select Step Out or Step Over for the last executable operator (if the executable module operator calls a function or a procedure executed on the server and called from the module executed in the client application), it results in stepping to the next executable operator in the call.
The current debug item can be selected in a special Debug Items toolbar. It has a single combo box that displays the current debug item. The box is only accessible when the debugger controls one of the attached debug items (e.g., after a breakpoint is activated). The list of debug items only contains items that are currently controlled by the debugger, including the current debug item.
Use the immediate window and the Expression dialog box to get values for the relevant expressions. You may use the Call Stack to trace the sequence of procedures and functions.
If you use step-by-step execution, the call stack and variable values (in the immediate window and the Expression dialog box) are displayed for the current debug item. When you change the debug item, it also changes the call stack and variable values.
If you attach the client and server debug items and move from the client to the server, no calculations are performed at the client levels of the call stack. These levels are highlighted in grey in the call stack window.
If you need to continue module execution, select Debug – Continue Debugging to enable free module execution for the attached debug items (up to the next breakpoint). If a client application is attached for debugging, it is activated automatically.
If you want to end the entire debugging process (except background jobs), remove all breakpoints from all modules and run the Debug – Continue Debugging command if a breakpoint has been activated. If you need to abort debugging and terminate the attached debug items, select Debug – Break. In the latter case BeforeExit() and OnExit() procedures are not executed.
You can edit the current configuration and save changes during debugging.
Although a debugged module may be edited, the debugger does not compile the modified code and debugging is continued for the database configuration code (that existed at the moment when the debugger was launched or when the connection was opened). To debug changes made to the configuration you should update the database configuration.
If you set the exclusive mode in the 1C:Enterprise mode, you will not be able to save the current configuration until the exclusive mode is removed.
If a file mode infobase is executed step-by-step in 1C:Enterprise or it is in a breakpoint and there is an open transaction (explicit or implicit), some operations (e.g., an attempt to lock objects in configuration storage) can cause an error: Configuration repository operation failed. (Information collection error for configuration storage) Lock conflict during transaction. Couldn't lock table FILES. We recommend shutting client applications down before retrying. To perform the operation that caused an error, you should continue 1C:Enterprise script execution until the transaction is completed.
For a table of shortcuts for the debugger see the Help menu.
To debug external data processor (report) modules you have to open the external data processor file in the Designer using the File – Open command.
Then you may work with external data processor (report) modules in the same way as with any other modules.
Use the Debug – Restart command to stop configuration execution and restart it in the 1C:Enterprise mode. If the configuration has been modified, the program asks the user whether the database configuration should be updated.
The Debug – Break command aborts debugging and terminates current debug item.
The Debug – Stop command stops module execution on the current operator. This command allows you to start module debugging from the next executable line. This command is useful for module "cycling" analysis.
The Debug – Stop on Errors command opens the dialog box to set up the Stop on Error procedure.
The Stop on Errors check box status indicates whether debugging should stop if an error occurs during execution. If execution stops on error, the Runtime error warning appears on the screen with an explanation of the location and cause for this error.
If the Stop on errors with text only flag is set, then debugging is stopped in the place of an error occurrence (if the error message contains the substring indicated in the table box). If the check box is not selected, debugging stops on an error irrespective of the error message text. At the same time the substring specified is taken into account only if you select the check box next to it.
The current execution point for the current debug item is moved to the location of the error and the debug item with the error becomes active. You may view expression and variable values to pinpoint the cause of the error.
Expressions can be calculated using the Expression window during step-by-step execution. Use the Debug – Evaluate Expression command to open this window.
Fig. 410. Evaluate Expression
Enter an expression in the 1C:Enterprise script into the Expression field of this window. You may enter an expression "manually" or select it from a list of previously entered expressions.
If the cursor in module window is placed over an expression or if an expression is selected when you open the Expression window, this expression is automatically entered into the Expression field.
Use the Evaluate button to calculate an expression. The expression evaluation result is displayed in the Value field.
The Add to immediate window button places the expression into the immediate window. This helps track expression changes during debugging. The expression is placed in a new line of the immediate window. The immediate window is opened if it has not been opened yet.
If an expression has a String type or is a collection of values or an array, the Show Values in Separate Window button becomes available.
The Evaluate Expression window is used for a more convenient view of long lines. This window contains a control of Label type that displays the line value for viewing.
To make it easier to view a collection of values or an array, a window containing a table box is opened. Columns in this window correspond to attribute names and rows contain attribute values. The window also shows the count of items in a collection and the first column contains an index of each collection item.
If a specific value is also a collection of values or an array and a row, you may view these values in a separate window (as shown on fig. 411). To do this, select the required value and select the Show Values in Separate Window command from the context menu or press the F2 key.
Fig. 411. Display Values
A window with the line expression in a multi-line field will open. You may copy this expression to the clipboard.
The contents of the calculation result from the table box can be output to a text or spreadsheet document using the Output list button. If the calculated value is represented as a tree, you can only output data from the opened strings of this tree.
You may also view current value of the expression by moving the mouse over it. The current value is shown as a tooltip near the variable. You may view it if the value can be represented as text. In the same way, you may view the property value. If the property is represented as <Object>.[<Object>. …]<Property> (Example: FormElements.CommandBar.Buttons.Get.Enabled), you may view its value by moving the mouse over the text. The value is displayed if the text does not contain parentheses or square brackets. You may also view the value of the array item that has an index (as a number or variable with a value specified at the moment of viewing). To do this, you need to select the array ID and index.
When you move the mouse over an object or over a selected object or a group of objects in <Object>.[<Object>. …]<Property> text, its type is displayed. For example, if you select FormElements.CommandBar1 in text FormEle- ments.CommandBar1.Buttons.Get.Enabled, CommandBar type is shown.
Immediate window is a special window that contains calculation results for variables and formulas that have been entered into it during debugging. Use the Debug – Immediate Window command to open it.
Fig. 412. Immediate Window
An immediate window is a four-page form. Each page of the form contains a table box for entering variables and formulas for control. Formulas may include arithmetical expressions, expressions using 1C:Enterprise script functions and application module and common module functions.
Each formula is entered into the first column of the table box and should be located on a separate line. The formula calculation result is displayed in the Value column. Enter the expression type into the Type column. If you have made mistakes when entering a formula, the following error message is displayed: Syntax errors found!
You can control the immediate window and the calculated results using commands from the context menu.
You may copy calculation results to the clipboard using the Copy Result command from the context menu of the second column.
Some types of data (see the previous paragraph) can be viewed in a separate window.
The immediate window can also be output to a spreadsheet or text document.
If the source data for the expressions change during processing, you must do a refresh to obtain valid results. Run the Recalculate or Recalculate All command from the context menu of the immediate window to perform recalculation.
The immediate window uses two modes for page selection: in the first mode, the pages are selected using tabs below; in the second mode, they are selected using the context menu. You may select the mode by checking or unchecking the Tabs option in the context menu.
To clear the contents of a line in the immediate window, select it and press the Del key.
The immediate window may be shown in different modes. After debugging the window automatically closes.
Call stack contains a sequence of function and procedure calls that leads to the currently debugged module line.
Fig. 413. Call Stack
The window shows:
executed method – the Name column
module string number – the Line column
the debugging item where the module is located – the Item column The first column of the window can contain two icons:
the yellow arrow indicates a top of the call stack.
the green arrow (to the left of the CommonForm.CallStack.Form.ServerMethod() row) indicates a method in the context of which variables will be calculated in the Expression window and the Immediate window. If the top of the stack matches the current context, the green arrow is not shown. To change context (and position the pointer to the row indicated in the Line column) you need to double click the required row in the Call Stack window.
In the example shown in fig. 413, the VariableAtServer variable is set to AtServer, since the debugger is switched to the ServerMethod() context (as indicated by the green arrow next to CommonForm.CallStack.Form.ServerMethod().
If you switch the context to the top of the stack (double click the row with the yellow arrow), the value of VariableOnServer will be set to Recall, since the context is switched.
Some rows in the Call Stack window are shown in grey (the last two rows in fig. 413). This means that you can switch to a module row, but you can't evaluate expressions in the context of the called method. Thus those stack items are selected that are "located" on the client, and the top of the stack is "located" on the server.
If the module line calls a procedure or function that is located in a protected module (see page 2-956) and you use the Step In command to move to this procedure or function, the debugger asks you to enter a password.
If you enter the password correctly, the debugger opens the protected module and passes control to the first line of the called procedure or function. When you move to the protected module again in the same session, you are not asked to enter the password.
If you decide not to enter the password, the debugger skips the protected code (but still executes it) and moves to the first line of code following the protected module. The same procedure is followed for the Step Out command.
A call stack always contains the procedure and function names. If the protected module has not been opened yet, the debugger asks you to enter a password when you try to move to the selected procedure for the first time. When you try to move to the protected module from the call stack again (during the same session) you are not asked to enter a password.
27.1.10. Use Options
This section contains a brief description of typical debugger operation scenarios.
To start up 1C:Enterprise in debug mode select Debug – Start Debugging or press F5. Type of the client launched in this case is defined by the Designer settings (see page 2-1154) and default configuration run mode (see page 1-165).
To debug a mechanism in the running 1C:Enterprise do the following:
Enable debugging in the running 1C:Enterprise instance. To do this, select the Allow Debugging in Current Session check box in the parameter setting window (Main Menu – Tools – Options).
Not available in a web client.
Define number of the session to be debugged. To do this, enable display of the All functions command (select the Show "All functions" command check box in the parameter setting window). Then open a list of active users (Main Menu – All functions – Standard – Active users) and save Session column status for the selected user (current user). The list of active users can only be viewed by users with sufficient access rights.
Then use the Designer to open the infobase to be debugged (for details on starting up various 1C:Enterprise modes see "1C:Enterprise 8.3. Administrator Guide").
After this open the debug item attachment window (see page 2-1039) and attach the debug item with the Session value equaling the Session value in the list of active users (see above).
Now, breakpoints get activated in the attached debug item and program code can be debugged.
Performance meter can be used to evaluate performance of the entire configuration or its part running within a debug item of any type. You may measure use frequency for specific code areas and execution speed, specify code to be executed on the server or the client and select code lines that have initiated server calls. If there are several methods of solving a task, you may try all methods and then select the fastest.
Please remember that you need to perform the comparison in the same conditions. For example, if CPU resources are used up by another application during task execution, this may influence the comparison reliability. Other circumstances may also influence the comparison results. Therefore, when you compare two methods of task solution with similar performance, it is recommended to perform several measurements for each method to determine possible variance.
Use the Debug – Performance Meter command to measure performance. When you run this command again, the measurement stops and the measurement results window opens. Enabling and disabling the performance meter affects all debug items currently attached to the debugger.
If you need to measure configuration performance, including the startup section, first run the Debug – Performance Meter command and then launch 1C:Enterprise. The time between the start of measurement and the commencement of work is not considered in the measurement results.
If you do not want to include the startup section in the measurement, first launch 1C:Enterprise and prepare it for execution of the required part. Then switch to the Designer and turn performance meter on.
If you want to include 1C:Enterprise shutdown section into measurement, you have to exit 1C:Enterprise and switch to the Designer regardless of the option used to start the measurement. In this case you do not have to stop the meter manually. When measurement results are ready, they are displayed.
If you do not want to include the 1C:Enterprise shutdown section in the measurement, it must be finished to view the measurement results. For example, if you want to analyze the posting procedure for a document, run 1C:Enterprise, open the document, fill it in, switch to the Designer mode, turn the meter on, then switch to the 1C:Enterprise mode, post the document, switch to the Designer mode and end the measurement.
Measurement results contain references to specific module lines that specify the frequency and length of execution. They are displayed as a table box with the following columns:
Module – contains the module name;
Line number – module line number;
String – module line text;
Usage count – number of line calls during measurement;
Time (net) – total execution time (in seconds) for this line during measurement;
%(Time) (net) – percentage of the total execution time for this line in relation to the total measurement time (total measurement time equals the sum of all time periods when the configuration code was executed). The code execution time on the client is taken as 100%.
Fig. 414. Performance Meter Icons
Client – this icon (see fig. 414) marks code lines executed at the client; Server – this icon (see fig. 414) marks code lines executed on the server;
Processing by server – these icons mark code lines that initiate server calls:
○ server was called at the platform level or procedures and functions executed on the server were called directly (Direct server call on fig. 414);
○ local call of procedure/function executed on the client where the server call was executed at the platform level or procedures/functions executed on the server were called directly (Nested server call on fig. 414).
Execution time for each line in execution measurement results is made up of time of operator line execution (net time) and of procedure (function) call time if they are in the line. Use Include execution time for procedure and function calls check box to select which time to indicate: full time (as a sum of call time and net time) or net time of execution.
Fig. 415. Measurement Result
If the line contains at least one procedure (function) call, execution time contains operator line execution and procedure (function) call time.
If the check box is selected, procedure (function) call time is included in the full execution time.
If this check box is deselected, measurement results include only execution time for code lines, but not execution time of procedure (function) that is called by this line. In this case the total execution time for this line (in Time column) is not the same as the actual time spent by the system in processing this line. Please remember that execution of called procedure (function) may be time-consuming and this time is not included in the result (net time).
The check box is selected by default and its state is recorded between sessions.
If the state is changed, names of time columns are also change.
If the Client check box is selected, results of code execution measurement on the client are displayed.
If the Server check box is selected, results of code execution measurement on the server are displayed.
If the Client and Server check boxes are selected, results of code execution measurement on the client and on the server are displayed.
The check boxes are displayed only during server infobase debugging. The check boxes are available only during server debug item debugging.
If there are several open windows with performance measurement results, when you place the mouse pointer onto the results column, you can see a tooltip with the URL of the file reflected in this column.
When you double click the mouse on the column with the performance measurement results, the module editor moves to the appropriate string in the file with the performance measurement results.
In addition to the special window, measurement results can also be viewed in the module source code window. If a performance meter window is opened in the debugger, the module windows contain a column that shows the total number of calls for the current line and the percentage of its work in relation to the total time.
Fig. 416. Measurement Results in Module Text
Icons are used to indicate code execution on the client or server as well as server calls (similar to the measurement results window; for a description see fig. 414).
Double-click a line in the measurement results window to switch to the corresponding line in module window.
If several measurements are opened at the same time, the module text windows will contain the corresponding number of columns.
Close the measurement results window to remove the columns with the number of calls and work time percentage from modules.
Measurement results can be sorted by any column in the report.
Sorting can be done by clicking on the header of one of the columns. Clicking Module or Line number sorts the results by line number, Usage count – by the number of line calls, Time (net) or %(Time) (net) – by work time. If performance measurement has been performed on both the client and the server, sorting by these columns is also available.
Summaries may be useful for the purpose of results analysis. If you mark several lines in the results window, their summaries (total number of calls, total working time in seconds and percentages) are displayed in the bottom part of the window.
Use the Include execution time for procedure and function calls check box to select one of two methods for approximate tracking of nesting levels for summarization. If the current module has a line that calls a procedure and a line with the procedure text, then you should not mark both since it can cause double count of runtime. If you still have to select them (e.g., when it would take too much effort to track these duplicate items), you may uncheck this option to avoid duplicate accounting. However, if all called procedures are external to the module, it is better to turn this option on. In this case the total execution time includes execution time of external procedures providing more accurate results.
When performance is measured, results for the 1C:Enterprise script code executed for the same connection number on both the client and the server are summarized. In this case the results indicate which code lines have been executed on the client or the server; which lines have called procedures or functions executed on the server or have made system calls (to the platform, e.g., Execute operator for a query or database object write operator) on the server.
As the user views the results, he/she can select what should be displayed: measurement for client, measurement for server, measurement for client and server combined. The mode is selected by setting/unsetting check boxes in the bottom right corner of the performance measurement results window.
For server calls, time of server call execution on the server is accounted for. The entire procedure can be compared to execution time of nested procedure and function calls for a client application.
Measurement results can be saved in a file using the File – Save and File – Save As commands. Select directory and specify file name in the standard save dialog box.
The results file has a *.pff extension.
A measurement file can be opened using the File – Open command. To filter measurement files use the Performance analyzer (*.pff) filter.
This mechanism aims to imitate application solution operation with significant delays in interaction with the server.
This mechanism can only be enabled in the thin client or the thick client in managed application mode.
The mechanism can imitate delays that can occur in the following cases:
Server call delay: in seconds per server call;
Send data to server delay: in seconds per 1 KB (1024 bytes) of data sent to the server.
Get data from server delay: in seconds per 1 KB (1024 bytes) of data received from the server.
The mechanism can be enabled through appropriate setup of Designer parameters (see page 2-1154) or by using the command line key /SimulateServerCallDelay [-CallXXXX] [-SendYYYY] [-ReceiveZZZZ] where:
Call – parameter that specifies the server call delay in seconds; 1 s is used if none specified.
Send – specifies the delay in seconds per 1 KB of data sent to the server. 1 s is used if none specified.
Receive – specifies the delay in seconds per 1 KB of data received from the server. 1 s is used if none specified.
/SimulateServerCallDelay -Call2.1 -Send1.3 -Receive1.2
The maximum delay value can be 9.99 s. 0 means delay is not applied.
Server call delay imitation can also be enabled in the 1C:Enterprise mode. To do this, use the Tools – Options dialog box. Setup of server call delay imitation in the 1C:Enterprise mode is only valid in the current session and is not preserved.
This mechanism is used to debug client/server system and assess the amount of data passed between the client and the server.
The mechanism can be enabled through appropriate setup of Designer parameters (see page 2-1157) or by using the command line key /DisplayPerformance.
Performance display can also be enabled in the 1C:Enterprise mode by selecting the Show performance indicators check box in the Tools – Options dialog box. By default the mechanism is disabled.
If this mode is enabled, 1C:Enterprise displays performance indicators in the performance indicator panel at the bottom of the main application window.
Fig. 417. Performance indicator panel
If the delay simulation mode is enabled when a server is called, the picture in the window showing server calls will look differently.
Fig. 418. Server Calls in Slow Connection Imitation Mode
If you have not yet opened or have already closed the main application window of an applied solution, the performance indicator window looks like this:
Fig. 419. Server Calls
If the server delay simulation mode is enabled, the performance indicator window looks like this:
Fig. 420. Delay simulation during server call
The current server call status (in progress, completed, none) is displayed as an icon in the top left corner of the window. Size and position of the performance indicators window are saved between the sessions.
When data displayed in the server call window is changed, it is highlighted with red color.
By default the window displays two counters, Current ñalls and Accumulated calls:
Current calls – shows statistics of server calls since a certain point in time:
engine start time or the last user action not followed by any other user action within 0.2 s.
Accumulated calls – shows statistics of the server calls since the engine start or its last forced reset triggered from the context menu.
This is done using the Performance indicator settings. You can open this dialog by clicking the button in the performance indicator panel and selecting Settings in the menu.
Fig. 421. Settings menu
You can specify the following parameters in the settings dialog:
Periodicity group – indicates the period to display counter values for;
Indicators group – defines which indicators are to be displayed in counters.
Fig. 422. Performance Indicators Settings
The context menu of this window also includes the following commands:
Clear accumulated – clears the accumulated calls counter.
History of current – opens the history window for the current calls counter.
History of the accumulated – opens the history window for the accumulated calls counter.
The settings are shared by all users and all infobases of the current computer.
Setup of server call display window in the 1C:Enterprise mode is only valid in the current session and is not preserved.
The user should be aware of the following peculiarities of this mechanism:
In the file mode version (direct infobase connection) the amount of data is displayed without compression as compression is not used in this case.
In the client/server or file mode version with Web server connection or in the SDC traffic compression mode, indicator values can be affected by actions sequences since previously transferred data are used in compression.
This mechanism has peculiar features in the web client:
Only synchronous calls are taken into account.
The amount of transferred data is displayed in characters instead of bytes. Measurement results can be used to compare various call options in the web client; it is not recommended to use the results to compare the amount of transferred data for different client types.
Performance indicators are only displayed after the main application window opens, and indicator values add up. After the main application window is displayed, you can see the relevant results from running the web client.
The indicators window is bigger than in other clients and does not appear on top of other windows.
27.5. AUTOMATED TESTING OF APPLIED SOLUTIONS
Automated testing comprises the simulation of interactive user actions and checking up action results.
Automated testing is only supported for managed applications.
The automated testing scenario is a program written in the 1C:Enterprise script. The scenario describes a sequence of actions and the results checkup. The 1C:Enterprise script has special objects that allow you to simulate interactive actions in the tested application and provide access to the logical model of the client application interface and managed form items.
Automated testing is not supported by the Taxi interface.
Two systems participate in the testing process: the testing manager and testing client. The testing manager handles the following:
Connection to the testing client in order to run the testing scenario (test connection)
Execution of the testing scenario Evaluation of test results (if necessary) The testing client handles the following:
Execution of testing scenario commands received from the testing manager
Transfer of data required for test results evaluation to the testing manager
You can use the thick or thin client as the testing manager, and you can use the thick, thin or web client as the testing client. A single testing manager can be simultaneously connected to multiple testing clients, whereas a testing client can only be connected to one testing manager. The testing manager and the testing client communicate using a direct TCP/IP connection via a specific port (that has to be open). The testing manager and the testing client represented by a web client communicate via the 1C:Enterprise server (for client-server version of the tested application) or a web server (for file mode version). Testing does not require any changes to be made to the tested application.
The testing scenario can be stored either in the tested applied solution or in a separate applied solution. It does not affect how the testing manager and the testing client communicate.
Please note that the testing manager (and the testing scenario you execute) has no direct access to the tested application. In other words, the testing scenario can access all features of the application where the scenario is run (testing manager) as well as the logical model of the tested application interface and forms.
If you launch a client application in the testing client mode, it does not affect its performance nor any other characteristics; however, any testing manager can connect to this application if it knows the computer name (or IP-address) and the port used for communication.
The system also allows you to write interactive user actions to an XML file. You can use this file later for automated testing. To write this file, you should launch the tested application in a special run mode. You can also manage interactive action write operations via the 1C:Enterprise script.
For the testing scenario to run, both the testing manager and the testing client must be running. You can launch them in any order. It is important that, before you execute the testing scenario, the testing client is running and available at the address used for connection by the testing manager.
You can use either the command line (this method is discussed below) or Designer for startup. The application you start from Designer can be assigned either role (testing manager or testing client), depending on the settings specified in the Designer settings dialog (for a detailed description of the settings, see page 2-1148).
You can run the testing client using the TestClient command-line parameter for client application startup. You can also specify the number of the TCP port to be used for testing manager – testing client communication. To do this, use the TPort option of the TestClient parameter. If no value is entered for this option, 1538 is used. This option must be specified if multiple testing clients run on a single computer.
So startup command line for the client application that is to be used as the testing client looks as shown below:
1cv8c ENTERPRISE /IBName "Test Application" /TestClient -TPort 1843
In this example, the thin client (1cv8c) is used as the testing client for the Test Application infobase, and TCP-port 1843 is used for communicating with the testing manager.
Therefore, if you want to connect to the testing client represented by the thin or thick client, you should know two parameters: the IP-address (or computer name) where the testing client is running, and number of the TCP-port to be used for communicating.
Running a web client is a little more complicated. In addition to the TestClient option, you should specify another startup command-line option: the TestClientID<ID> that contains a unique identifier for the tested client application. If the web client is used, unique identification of the testing client requires three parameters:
Address of the web server where the tested application is deployed. You do not have to know the infobase address.
The number of the TCP-port to be used by the web server to transfer data between the testing manager and the testing client.
The identifier of a specific instance of the tested application running on the web client.
In other words, a single web server can work with multiple infobases and with multiple connections to a single infobase (also for testing purposes), but for the web server you have to specify which TCP-ports are to be used for communicating with the testing manager. You can do this in the testcfg.xml file stored in the web server extension settings directory. For details about this file, see "1C:Enterprise 8.3. Administrator Manual".
To be able to run a testing scenario, run your client application in the testing manager mode. Use the TestManager command-line parameter to run the client application. The web client cannot be used as the testing manager.
So the startup command line for the client application that is to be used as the testing client looks as shown below:
1cv8c ENTERPRISE /IBName "Test Manager" /TestManager
If you want to run your client application to record the interactive action log, you can use either the UILogRecorder command-line parameter or a special command in Designer menu: Tools – Run to record user actions log.
You can also specify the number of the TCP port to be used by the testing manager to control recording to the interactive action log. To do this, use the TPort option of the UILogRecorder parameter. If no value is entered for this option, 1538 is used. You can also select the location where the system saves the log file. To do this, use the File option of the UILogRecorder parameter. If this option is not specified, after the file is recorded the client application opens a text document window containing the written log.
So the startup command line for the client application that is to generate an interactive action log looks as shown below:
1cv8c ENTERPRISE /IBName "Test Manager" /UILogRecorder
With this startup option, the right-hand top corner of the main client application window displays a special command panel that manages log recording.
Fig. 423. Testing command panel
To start recording user actions, click the only available button on this panel.
This changes the panel appearance (all buttons become available).
Fig. 424. Testing command panel during recording
You can use the command panel to stop interactive action recording. This operation writes an action list to the file (if the File option is specified) or opens a text document window with a list of actions. You can also interrupt or pause and restart log recording.
In terms of the testing scenario, the tested application is a set of objects that can simulate interactive actions in the tested application and provide access to the logical model of the client application interface and managed form items:
Fig. 425. Outline of the tested application
In the sections below objects shown in the above figure are discussed in greater detail.
You can use this object to do the following:
Connect to the tested application.
Disconnect from the tested application.
Get an active window.
Get a list of tested application windows.
Get current information about an error.
Find an object with specified parameters in the subordinate object hierarchy.
Wait until an object with specified parameters is displayed on the screen.
Manage interactive user action logging in the tested application.
This object describes the client application window and provides methods of window management:
Get a collection of subordinate objects for the window.
Search for an object with specified parameters in the subordinate object hierarchy for the client application window.
Get the command interface of the tested client application.
Work with user messages.
Close the tested form.
Execute a command using a navigation link.
This object describes the command interface for the tested form of the applied solution. It has three subordinate TestedCommandInterfaceGroup objects:
For auxiliary windows, the command interface of the form only has the form navigation panel.
This object describes the command interface group and allows you to get a collection of subordinate objects for the group as well as search for an object with specified parameters in the subordinate object hierarchy.
TestedCommandInterfaceGroup can comprise items of two types:
This object describes a command of the command interface and can be used to simulate a button click.
This object describes the tested application form and provides methods of form management:
Get a collection of subordinate objects for the form.
Find an object with specified parameters in the form subordinate object hierarchy.
Get the current active item of the form.
Get the default button.
Get the Modified attribute.
Get the command panel of the form.
Change the current form item to the next/previous item based on the form item tab order (the item list in the managed form editor).
This object describes a text box in the form and provides methods for managing this form item:
Get a collection of subordinate objects for the form field.
Find an object with specified parameters in the subordinate object hierarchy for the form field.
Define form item appearance.
Simulate interactive actions for the following types of managed form fields:
○ Text box
○ Label field
○ Picture field
○ Radio button field
○ Checkbox field
○ Calendar field
○ Spreadsheet document field
No simulation of interactive actions is available for the following types of managed form fields: ○ Progress bar field
○ Track bar field
○ Text document field
○ HTML document field
○ Geographical schema field;
○ Formatted document field
○ Chart fields (all types)
○ Graphical schema fields
If the object is associated with a text box, the following capabilities are available:
○ Get text being edited in the text box.
○ Simulate clicking the Clear button.
○ Simulate clicking the Select button.
○ Simulate clicking the Open button.
○ Simulate opening a choice list.
○ Simulate selecting a line in the choice list.
○ Simulate clicking slider buttons.
If the object is associated with a checkbox field, the following capabilities are available:
○ Simulate changing checkbox status.
If the object is associated with a radio button field, the following capabilities are available:
○ Simulate selecting a radio button value.
If the object is associated with a calendar field, the following capabilities are available:
○ Simulate setting a selected date.
○ Simulate date selection.
○ Simulate moving a month or a year forwards and backwards.
If the object is associated with a spreadsheet document field, the following capabilities are available: ○ Get the current region address.
○ Get the current region text.
○ Simulate the start of editing the current region.
○ Simulate the conclusion of editing the current region.
○ Get current editing mode for spreadsheet document.
This object describes a form table and provides methods for managing this form item:
Get active table item.
Get table cell text.
Navigate through table rows and columns.
Select a row.
Add or remove a row.
Get current table editing mode.
Navigate through hierarchical list levels.
Collapse or expand node for hierarchical lists.
Check the state of the hierarchical list node (whether it is collapsed or expanded) and the expandability of current row in hierarchical list.
This object describes a form button and can be used to simulate a button click.
This object describes a group of form items and provides methods for group management.
This object describes form decoration and can be used to simulate clicking a hyperlink or image.
Below is a simplified sample that creates a new item in the Goods catalog in a configuration. It is important that the main form contains a field with the Name header and a button with the Write and close title.
// Connect to the tested application TestedApplication = New TestedApplication ("localhost"); TestedApplication.Connect(); // Find main window MainTestedApplicationWindow = TestedApplication.FindObject(Type("TestedClientApplicationWindow")); MainTestedApplicationWindow.Activate(); // Execute command of item creation in the Goods catalog MainTestedApplicationWindow.RunCommand("e1cib/command/Catalog.Goods.Create"); TestedApplication.WaitForObjectDisplayed(Type("TestedForm"), "Good*"); TestedForm = TestedApplication.FindObject(Type("TestedForm"), "Good*"); TestedForm.Activate(); // Set name for a new item FormItem = TestedForm.FindObject(Type("TestedFormField"), "Name"); FormItem.Activate(); FormItem.InputText("New item"); // Write item FormItem = TestedForm.FindObject(Type("TestedFormButton"), "Write and close"); FormItem.Click();
27.5.5. Service Options
You can run the client application in the mode that supports logging interactive actions. This log can later be saved to a file. For a detailed description of this mode, see page 2-1063.
You can convert a saved user action log into 1C:Enterprise script code for subsequent use. You can perform this conversion using a special tool located on site http://1c-dn.com/developer_tools/user_action_log_conversion/).
Using this tool, you can do the following:
Convert both the log file (e.g., a file saved earlier) and the text entered manually (in the log format).
Specify the script variant for the resulting code written in the 1C:Enterprise script.
Add code to implement the connection to the testing client.
Indicate whether long sequences of actions should be split into procedures, each working with a single tested window of the applied solution.
The code resulting from the conversion can, for example, be used for multiple automated executions of the converted set of actions.