# APPENDIX 3. SERVICE FILES DESCRIPTION AND LOCATION

This Appendix provides description and location of various service files that may be needed in the process of 1C:Enterprise operation.

## 3.1. *.1CCR

The configuration file of the web service intended to work with a remote repository can have an arbitrary name (the 1ccr extension is mandatory) and should be in XML format; it contains a single node with an arbitrary name and the connectString attribute – this attribute indicates the tcp address of the Configuration Repository server.

For example, the configuration file may have the name repository.1ccr and the content as follows:

<?xml version="1.0" encoding="UTF-8"?> <repository connectString="tcp://RepServ"/>

In this case repository stands for an arbitrary node name, and tcp://RepServ is the Configuration Repository server address.

## 3.2. *.MFT

The file having mft as its extension is a manifest file – a file dedicated to describe the configuration template. The file name can be arbitrary.

The file is located in the installed configuration template directory.

A manifest file has an arbitrary name with the mft extension. The internal format of manifest files is similar to the format of ini files. UTF-8 encoding is used by manifest files to support multiple languages. A manifest file begins with the following parameters:

Vendor

Solution vendor. Matches the value specified in the configuration.

Name

Solution name. Matches the value specified in the configuration.

Version

Solution version. Matches the value specified in the configuration.

AppVersion

1C:Enterprise version used to develop the distribution kit.

The following parameters are related to solution components and are divided by section names. Section names are arbitrary and are enclosed in square brackets.

Source

Relative path to the configuration file (cf), update file (cfu) or database dump file (dt).

Catalog_<language suffix>

Solution name in the solutions directory. A manifest file may contain multiple Catalog_<language suffix> parameters. The suffix determines the user interface language of 1C:Enterprise 8 (e.g. ru to specify Russian). If no language suffix is specified (the parameter name is set to Catalog), this value will be used for all the user interfaces except those for which the Catalog parameter is specified in this section with a required language suffix.

Destination

Recommended directory to create an infobase in. This parameter is used when an infobase is created based on a template. The directory represents a partial path. The directory should contain a vendor directory to prevent different solutions from having the same directory names.

Multiple cfu files may exist in the configuration template directory.

Vendor=1C Company
Version=8.10.0.2
[Main]
Source=Main\1cv8.cf
[Demo]
Source=Demo\1cv8.dt
Destination=1C\DemoTrd

## 3.3. *.V8I

This chapter describes the file format for descriptions of registered infobases. This list is used by all client types. The default file name is ibases.v8i.

File location:

 For Windows: in the %APPDATA%\1C\1CEStart\ directory of the local computer.

 For Linux: in the ~\.1C\1cestart directory.

The file is a UTF-8 encoded text document consisting of multiple sections. Each section describes one infobase.

The file consists of infobase description sections.

## Infobase description section

[Section name]
Connect=
ID=
OrderInList=
Folder=
OrderInTree=
External=
ClientConnectionSpeed=
App=
DefaultApp=
WA=
WSA=
Version=
DefaultVersion=
WebCommonInfobaseURL=

A section consists of its name and parameters.

The section name and each section parameter are recorded on separate lines of the description file.

Section name

Section name matches the infobase name and is required. The name is enclosed in square brackets.

The parameter can be edited in the infobase properties window.

Example:

[Demoversion8.3]

ID

Internal infobase identifier (optional parameter).

Example:

ID=cf9f0d4b-b4a3-11d8-861e-0050baaa2f3f

Connect optional

Infobase connection string. Multiple infobase descriptions may exist with the same command line but different names. This may be needed when you want to be able to launch the same infobase in multiple operation modes (e.g. thin and thick clients) without modifying the infobase properties.

Example:

The file infobase mode is specified as follows:

Connect=File=<path>;

The client/server infobase mode is specified as follows:

Connect=Srvr=<1C:EnterpriseServerName>;Ref=<InfobaseNameOnServer>;

Folder optional

Folder name in the infobase tree.

NOTE

If no folder name is specified or the parameter is omitted, this infobase is located in the root of the infobase list.

Example:

OrderInList

The order in the list when list view is used. This parameter is specified as a number that is the infobase sequence number in the list (no sorting by name is applied).

Example:

OrderInList=5

OrderInTree

Order in the branch when tree view is used.

Example:

OrderInTree=16358

UseProxy                                             optional

Specifies a proxy server usage mode for ws-connection variant.

 0 – no proxy server is used.

 1 – proxy server settings are determined automatically.

 2 – proxy server settings are defined explicitly.

If UseProxy is not specified, proxy server settings are determined automatically. It is not reasonable for file mode and client/server infobase version.

Example:

UseProxy=1

ProxyServer

The string containing the proxy server address (only required when UseProxy value is 2).

Example:

ProxyServer=192.168.0.1

ProxyPort

Proxy server port number (only required when UseProxy value is 2).

Example:

ProxyPort=123

 ProxyUser Proxy server user name. Example: optional

Example:

ClientConnectionSpeed

Client connection speed (only reasonable for the thin and web clients). The following values are possible:

 Normal – standard connection speed

 Low – slow connection

If the parameter is omitted, the client connection speed will be determined by the Slow connection checkbox value in the startup window (this is similar to using Select at startup for the Connection speed parameter in the infobase startup options window, see page 87).

Example:

ClientConnectionSpeed=Low

WA

Defines user authentication version. The following values are possible:

Example:

WA=1

WSA

Defines user authentication version on the web server if web server is used as an intermediate link (thin client connected via a web server and web client). The following values are possible:

 1 – attempt OS authentication on the web server. If failed, prompt for login/ password.

Example:

WSA=1

App

Defines client application type.

 Auto – select client application type automatically

 ThinClient – thin client

 ThickClient – thick client

 WebClient – web client

The parameter can be edited in the infobase properties window.

Example:

App=Auto

DefaultApp

The client type that is determined and recorded to this file by the launcher when client application type is determined automatically (/AppAutoCheckMode option):

 ThinClient – thin client

 ThickClient – thick client

If the App parameter value is Auto and DefaultApp parameter is omitted, thin client is launched with /AppAutoCheckMode command line option.

If DefaultApp parameter is available, the defined client is launched with the /AppAutoCheckMode option.

Example:

DefaultApp=ThinClient

Version

1C:Enterprise version to be used to run the infobase.

The parameter can be edited in the infobase properties window.

Example:

Version=8.3.9

DefaultVersion

The 1C:Enterprise version that was actually used when this infobase was last run. It is defined and recorded to this file by the launcher automatically if /AppAutoCheckVersion option is used for startup.

For the future startups this particular version will be used instead of the one specified in the Version parameter.

Example:

DefaultVersion=8.3.3.657

Contains additional startup parameters that can be entered in the infobase properties window under Additional startup options.

Example:

WebCommonInfoBaseURL

If an infobase was added to the current list via the internet service for obtaining the list of common infobases (see page 98), this parameter will include the address of the service that provided the infobase details.

If when you start the interactive launcher (1cv8s) it is discovered that the list of common infobases obtained via the internet service does not require updating (the WebCommonInfoBases.CheckInfoBases() web service is called and the returned value of the InfoBaseChanged parameter is False), the descriptions of all the infobases received from this source are kept in this list until restart.

If the InternetService or WebCommonInfoBases parameters are deleted from the 1CEStart.cfg file, the infobase details received from the sources deleted will be excluded from the infobase list.

Example:

WebCommonInfoBaseURL=http://info-server/listservice

### 3.4. 1CESCMN.CFG

The 1CEScmn.cfg file contains general settings for the launchers (1cestart.exe and 1Cv8s).

The file is located in the directory from which the system is installed if the distribution kit is located in the network directory (see page 41).

NOTE

Applicable only to 1C:Enterprise running under Windows.

The file is a UTF-8 or UTF-16LE encoded text document that contains strings in the <Parameter>=<Value> format.

The description of the file is equivalent to the 1CEStart.cfg file description (see page 241) with the exception that a shared configuration file cannot contain a string with the CommonCfgLocation parameter.

Example:

CommonInfoBases=ibcommon.v8i
DistributiveLocation=\\server\v8dst

This example specifies the name of the file containing a list of shared infobases (ibcommon.v8i), which should be located in the same directory as the file containing an interactive launcher (1cestart). Also, the directory with the distribution kits of different system versions is specified: \\server\v8dst.

### 3.5. 1CESTART.CFG

The 1cestart.cfg file contains settings that use the launchers (1cestart and 1cv8s), client applications (1cv8 and 1cv8c) and an external connection.

File location:

 For Windows:

%APPDATA%\1C\1CEStart – for a specific user. The file changes when the user configures the launch window (see page 93).

%ALLUSERSPROFILE%\Application                                       Data\1C\1CEStart

(%ALLUSERSPROFILE%\1C\1CEStart for Windows Vista and above) – for all users of the computer. The file changes only when the 1C:Enterprise system is installed.

 For Linux: ~/.1C/1cestart

The file is a UTF-16LE encoded text document that contains strings of the <Parameter>=<Value> format. The parameters that this file can contain are described below.

Example:

DefaultVersion=8.2-8.2.16
DefaultVersion=8.3-8.3.3
CommonCfgLocation=\\Server\v8\1CESCmn.cfg
CommonInfoBases=\\Server\common\common_dblist.v8i
InstalledLocation=C:\Program  Files\1cv8
DistributiveLocation=\\Server\dst1C\v8
ConfigurationTemplatesLocation=\\Server\tmplts
ConfigurationTemplatesLocation=C:\Documents  and Settings\User\Application Data\1C\1cv8\tmplts
InstallComponents=DESIGNERALLCLIENTS=1  THINCLIENT=1 WEBSERVEREXT=1 SERVER=
1  CONFREPOSSERVER=0 CONVERTER77=1 SERVERCLIENT=1 LANGUAGES=RU
AppAutoInstallLastVersion=0

DefaultVersion

This parameter defines the version used by default. Multiple strings with this parameter can exist.

The values from all the configuration files are used.

Example 1:

DefaultVersion=8.3.3.657

This string means that if an infobase is launched and version 8.3 is specified, version 8.3.3.657 will be used.

Example 2:

DefaultVersion=8.2.15-8.2.15.315

This string means that if an infobase is launched and version 8.2.15 is specified, version 8.2.15.315 will be used.

CommonInfoBases

The parameter specifies the path and name of the file containing a list of shared infobases.

The values from all the configuration files are used.

For a description of the format of the file containing a list of infobases, see page 235.

InstalledLocation

This parameter specifies the directory in which 1C:Enterprise has been installed. C:\Program Files\1cv8 is used by default.

The values from all the configuration files are used in the following order:

 from the shared configuration file

 from the local configuration file for all users

 from the local configuration file

NOTE

It is not recommended to use this parameter in the shared configuration file (1CEScmn.cfg).

DistributiveLocation

This parameter specifies the directory where the new version to be installed automatically will be searched for.

The values from all the configuration files are used.

A directory with new version distribution kits will also be searched for in the directory where the common configuration file is located (1CESCmn.cfg).

CommonCfgLocation

This parameter specifies the path and the name of the shared configuration file. Multiple strings with this parameter can exist.

The values from all the configuration files are used.

NOTE

Use of this parameter in the shared configuration file (1CEScmn.cfg) is not recommended.

InstallComponents

The local configuration file and the local configuration file for all users (1CEStart.cfg) contain a list of all the components installed.

The shared configuration file (1CEScmn.cfg) contains a list of the components to be installed (created by the system administrator).

The parameter value from one configuration file is used in the following priority:

 a local configuration file for all users

 a local configuration file

 a shared configuration file

The parameter contains a string of components with installation requisite feature divided with a space:

 0 – do not install

 1 – install

The following components are possible:

 DESIGNERALLCLIENTS – all clients and the Designer.

 THINCLIENT – thin client for client/server operation.

 THINCLIENTFILE – thin client supporting file infobases.

 SERVER – the 1C:Enterprise server. If the installer is initiated by the launcher, the server will be installed as an application.

 WEBSERVEREXT – extension components for the web server.

 CONFREPOSSERVER – the 1C:Enterprise configuration repository server.

 SERVERCLIENT – components which are required to administer the

1C:Enterprise server cluster.

 CONVERTER77 – the 1C:Enterprise 7.7 infobase converter.

 LANGUAGES – the list of interface languages to be installed. If several languages are specified, they should be separated by commas (","). For the list of localization language codes, see page 28.

NOTE

English (language code EN) will be installed even if it has not been specified in the LANGUAGES parameter or if the LANGUAGES parameter has not been specified at all.

Example:

LANGUAGES=RU,UK,BG

Parameter example:

InstallComponents=DESIGNERALLCLIENTS=0  THINCLIENT=1 WEBSERVEREXT=0 SERVER=0
CONFREPOSSERVER=0  CONVERTER77=0 SERVERCLIENT=1 LANGUAGES=RU,EN

ConfigurationTemplatesLocation

This parameter specifies the path of the configuration template directory. Multiple records may exist.

The values from all the configuration files are used.

This parameter controls the search of the protection key when 1C:Enterprise is launched.

 1 – the protection key is searched (the default value);  0 – the protection key is not searched.

The parameter value from one configuration file is used in the following priority:

 a local configuration file

 a local configuration file for all users

 a shared configuration file

This parameter helps disable the search of the protection key when client licenses are received through a web server extension or the 1C:Enterprise server or if a basic version is used.

The system will change the parameter value in the following cases:

 If the protection key search is enabled, the duration of the search is analyzed when a client application is launched. If the protection key is not found, the launch is successful and the duration of the search exceeds 3 seconds,

the user is prompted to disable the protection key search to accelerate launches in the future. If the user agrees, the UseHwLicenses=0 parameter is written into the 1CEStart.cfg file of the user.

 If the protection key search is disabled and it is detected at launch that the license has not been received from the 1C:Enterprise server or the web server extension, the user is prompted to enable the protection key search. If the user agrees, the UseHwLicenses=1 parameter is written into the 1CEStart.cfg file of the user, and the client application is restarted.

If the external connection is launched, the system tries to analyze the parameter from the 1CEStart.cfg file located in the user profile under which the external connection is launched. If the user has no profile (for example, the LocalSystem user in the Windows OS), the protection key is always searched.

InternetService

The URL of the internet service that provides a list of common infobases and a client application distribution set.

First, the system attempts to obtain the required file (with the list of common infobases or the client application distribution set) via an HTTP query. If this attempt fails, the system tries to get the file via the web service.

The full web service URL for the HTTP query should look as follows: <Address from the InternetService parameter>/<Service name>/<Method name>/?<Method parameters>.

The description address (in WSDL format) for a query via the web service should look as follows: <Address from the InternetService parameter>/<Service name>/?wsdl.

The URL of the internet service providing the list of common infobases.

First, the system attempts to obtain the list of common infobases via HTTP query. If this attempt fails, the system tries to get the file via the web service.

The full web service URL for an HTTP query should look as follows: <Address from the WebCommonInfoBases parameter>/<Service name>/<Method Name>/?<Method parameters>.

The description address (in WSDL format) for a query via the web service should look as follows: <Address from the WebCommonInfoBases>/<Service name>/?wsdl.

If both the InternetService and WebCommonInfoBases parameters are specified, the address from the WebCommonInfoBases parameter is used first, and if it fails, the address specified in the InternetService parameter is used.

WebDistributiveLocation

The URL of the internet service that provides a client application distribution set.

First, the system attempts to obtain the client application distribution set via HTTP query. If this attempt fails, the system tries to get the file via the web service.

The full web service URL for an HTTP query should look as follows: <Address from               the          WebDistributiveLocation          parameter>/<Service         name>/<Method name>/?<Method parameters>.

The description address (in WSDL format) for a query via the web service should look as follows: <Address from the WebDistributiveLocation>/<Service name>/?wsdl.

If both the InternetService and WebDistributiveLocation parameters are specified, the address from the WebDistributiveLocation parameter is used first, and if it fails, the address specified in the InternetService parameter is used.

AppAutoInstallLastVersion

This parameter defines whether automatic installation of a new 1C:Enterprise version is required:

 0 disables automatic installation of a new version;

 1 enables automatic installation of a new version (default value).

The parameter value from one of the configuration files is used, subject to the following priorities:

 local configuration file;

 local configuration file for all users;  common configuration file.

If a version installed on the local computer differs from the one required by the server in the client/server mode or one that is explicitly specified for the infobase, the AppAutoInstallLastVersion key value (from the configuration files or command line) will be ignored and installation of a new version will be attempted.

### 3.6. 1CV8WSRV.LST

This file is stored on the computer of the working server marked as a central server in the cluster service file directory and includes the list of clusters registered on this computer of the 1C:Enterprise server. The data it stores is necessary for the proper operation of applications using this 1C:Enterprise server.

Example:

C:\Program Files\1cv8\srvinfo\1cv8wsrv.lst

### 3.7. 1CV8CLST.LST

This file is located in the data directory of each working server marked as a central server.

The file includes the cluster register and the following information:

 list of infobases recorded in this cluster

 list of working servers forming the cluster

 list of work processes forming the cluster

 list of cluster managers

 list of cluster services  list of cluster administrators Example:

C:\Program Files\1cv8\srvinfo\reg_1541\1CV8Clst.lst

The adminstall.cfg file indicates that 1C:Enterprise system was installed using Windows administration tools.

NOTE

Applicable only to 1C:Enterprise running under Windows.

The file is located in the 1C:Enterprise configuration files directory and is a UTF-8 encoded text document.

The file may contain only a single string defining the installation variant:

<Mode>

It defines installation mode:

 Logon – installation by logon script when the user accessed the domain

 Restart – installation using Group Policies

The following is a sample installation script that can be used to install 1C:Enterprise using Windows administration tools (see page 35).

 Option Explicit 'Change user interface Const msiUILevelNoChange = 0 'Use default user interface Const msiUILevelDefault = 1 'Do not display user interface (silent installation) Const msiUILevelNone = 2 'Only display progress bar and errors Const msiUILevelBasic = 3 'User interface without dialogs Const msiUILevelReduced = 4 'Full user interface Const msiUILevelFull = 5 'If used with msiUILevelBasic, progress bar is displayed 'without Cancel button Const msiUILevelHideCancel = 32 'If used with msiUILevelBasic, progress bar is displayed 'only without any dialogs, including error messages. Const msiUILevelProgressOnly = 64 'If used with any of the specified values, the installer 'will display the results message when the installation is completed. Const msiUILevelEndDialog = 128 '***** Replace with the actual installation directory Const DistrFolder="\\Server\1CDistr\" Const shortcutName = "1C:Enterprise Startup" Dim shortcutTarget : shortcutTarget = DistrFolder & "1cestart.exe" 'Constants intended to determine the actions ' installation required Const requiredInstall = 1 ' ininstall required Const requiredUninstall = 0 'ProductCode parameter value from setup.ini file ... '... for the uninstalled version Const unInstallUID="{9173B91C-FF56-4F25- 83D1-7F6 8344044CD}" '... for the installed version Const InstallUID="{0BC98727-04AD-470F-9EEE-0162C543833F}" 'To uninstall version 260 installOrUninstall unInstallUID, DistrFolder + "8.3.9.260\setup\1CEnterprise 8.3.msi", "1049.mst", requiredUninstall 'To install version 356 installOrUninstall InstallUID, DistrFolder + "8.3.9.356\setup\1CEnterprise 8.3.msi", "1049.mst", requiredInstall 'Install or uninstall procedure for the specified product version Sub installOrUninstall (ByVal productCode, ByVal msiPackage, ByVal mstTransform, ByVal requiredAction)

### 3.9. APPSRVRS.LST

Contains the list of 1C:Enterprise servers registered in the infobase administration utility in the client/server mode.

NOTE

Applicable only to 1C:Enterprise running under Windows.

The file is located at %APPDATA%\1C\1cv8.

Example:

C:/Documents  and Settings/User/Local Settings/Application Data/1C/1cv8/appsrvrs.lst
C:/Users/User/AppData/Roaming/1C/1cv8/appsrvrs.lst

### 3.10. COMCNTRCFG.XML

comcntrcfg.xml is intended to instruct the external connection that debug mode should be used for execution.

NOTE

Applicable only to 1C:Enterprise running under Windows.

The file is located in the 1C:Enterprise configuration files directory and it is optional.

If the file cannot be found, the external connection is opened in the standard mode.

Example:

<config  xmlns="http://v8.1c.ru/v8/comcntrcfg">
<debugconfig debug="true"  debuggerURL="tcp://localhost:1560"/>
</config>

The debugconfig item has the attributes described below.

debug attribute

Type:boolean. Instructs if debug mode should be used:

 debug="true" – debugging is enabled;

 debug="false" – debugging is disabled.

debug="true"

debuggerURL attribute

Type: String. Specifies the URL of the debugger to be connected to automatically for debugging where localhost instructs to search on the local computer while 1560 is the number of the network port. If no port is specified, all the ports in the range 1560 – 1591 will be checked. Entering tcp:// is similar to entering tcp://localhost. If the debugger URL is not specified, debugging will not be applied in the process of 1C:Enterprise script code execution.

debuggerURL="tcp://localhost:1560"

### 3.11. CONF.CFG

The conf.cfg file determines the location of the shared configuration files directory and the default system interface language.

File location:

 For Windows:

In the bin\conf directory of a particular version of 1C:Enterprise.

In the C:\Program Files\1cv8\conf directory.

 For Linux:

In the conf directory of the version installed. The path to this directory in the 32-bit 1C:Enterprise version will look as follows: /opt/1C/v8.3/i386/ conf, in the 64-bit version: /opt/1C/v8.3/x86_64/conf.

In the ~/.1cv8/1C/1cv8/conf directory (~ is a home directory of the account under which the 1C:Enterprise server is run).

The file is a UTF-8 encoded text document.

The following parameters may be specified in the file:

ConfLocation

This parameter defines a directory in which the system will search the configuration files (logcfg.xml, nethasp.ini, etc.) if they are not found through standard search paths. This parameter is only meaningful if the file is located in the conf directory of a specific version.

By default, the following parameter value is used:

 For Windows: C:\Program Files\1cv8\conf.

 For Linux:

For 32-bit version: /opt/1C/v8.3/i386/conf.

For 64-bit version: /opt/1C/v8.3/x86_64/conf.

Example:

ConfLocation=C:\MySettings\v8\conf

SystemLanguage

This parameter defines the system interface language. Interface language codes or the System value may be specified as the parameter value (see page 28). If the language value is set, this language will be used. If the System value is specified, an interface language will be defined by the OS localization.

If a non-existing localization language is specified, the system will try to use the localization language matching the OS regional settings.

The English interface will be used if the user interface with the language specified is not installed.

When using a client application run under Windows, remember that if the conf.cfg file specifying the interface language is located in the conf directory of a particular version, the specified interface language will be used for this particular version, and if it is in the C:\Program Files\1cv8\conf directory, the specified interface language will be used for all versions installed on this computer.

If the configuration file does not specify the SystemLanguage parameter, the *.res file will be used to determine the interface language. If the *.res file is missing, an interface language matching the OS regional settings will be selected at launch. If you specify an interface language code that is unknown or does not exist, it will be equivalent to such a file being missing.

Example:

SystemLanguage=System

Indicates that an interface language matching the OS regional settings should be used.

SystemLanguage=RU

Indicates that Russian (RU) should be used as the interface language.

PublishDistributiveLocation

This parameter defines the location of the client application distribution set. Its behavior and contents are identical to those of the pubdst attribute of the point item of the default.vrd file (see page 253).

NOTE

Applicable only to 1C:Enterprise running under Windows.

### 3.12. DEBUGCFG.XML

debugcfg.xml is intended to customize an additional range of the ports used in configurations debugging.

The file is located in the 1C:Enterprise configuration files directory and it is optional.

If the file cannot be found, ports from the standard range (i.e. 1560–1591) are used 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.

Example:

<config  xmlns="http://v8.1c.ru/v8/debugcfg">
<debugports range="1540:1550"/>
</config>

The debugports item has the attributes described below.

range attribute

Type: String. It contains an additional ports range used for debugging.

### 3.13. DEF.USR

The file contains the user name for the user who last opened the infobase.

File location:

 For Windows: %APPDATA%\1C\1cv8\<Unique infobase ID>.

 For Linux: ~/.1cv8/1C/1cv8/<Unique infobase ID>.

Example:

C:\Documents  and Settings\User\Application  Data\1C\1Cv8\4129dbdb-b495-41cb-99ea-ef315060a03e\def.usr
~/.1cv8/1C/1cv8/4129dbdb-b495-41cb-99ea-ef315060a03e/def.usr

### 3.14. DEFAULT.VRD

This file is intended to customize the web client and web services usage. It is located in the virtual application directory.

NOTE

The format of references used in the file should comply with RFC 1738

(http://www.faqs.org/rfcs/rfc1738.html) and RFC 2396 (http://www.faqs.org/rfcs/rfc2396.html).

<point> is the root element of the configuration file that defines virtual resource settings. It may contain one of each of the following items: <zones>, <ws>, <pool> , <debug> and <openid>, where the <ws> item may contain several nested <point> items, and the <zones> item may contain several nested <zone> items:

<point...>
<ws...>
<point>...</point>
<zones>
<zone>...</zone>
<zone>...</zone>
</zones>
<point>...</point>
</ws>
<pool.../>
<debug.../>
<openid>
<rely...  />
<provider>
</provider>
<openid>
</point>

Example:

<?xml version="1.0"  encoding="UTF-8"?>
<point  xmlns="http://v8.1c.ru/8.3/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/demo"
ib="Srvr=&quot;tcp://Server&quot;;Ref=&quot;demo&quot;;"
enable="false"
allowexecutescheduledjobs="force">

<ws>
<point name="OperationalData" alias="OperData"/>
<point name="AnalyticalData"  alias="AnalytData"/>
</ws>
<pool  size="50" maxAge="10" attempts="2"/>
<debug enable="true"  url="tcp://localhost"/>
<zones>
<zone  value=" 8314" safe="true"/>
<zone value="last" specify="true" />
</zones>
</point>

The root item of default.vrd may contain the following attributes:

base attribute

The base item specifies the relative path to the virtual application folder (in relation to the website root directory).

TIP

We recommend you to only use US ASCII characters in the virtual application folder name.

Example:

base="/demoMA"

ib attribute

This contains the 1C:Enterprise infobase connection string. Please note that the connection strings are different for the file mode and the client/server mode.

NOTE

All characters of the connection string that are unacceptable under the XML standard (http://www.w3.org/TR/xml11/) will be replaced accordingly.

File infobase example:

ib="File=c:/bases/demo;"

Client/Server infobase example:

ib="Srvr=&quot;tcp://myServer&quot;;Ref=&quot;mybase&quot;;"

You may specify the user’s login and password in the connection string. In this case, the infobase will be connected to under this account. The following example connects to the infobase under the Seller account:

ib="Srvr=&quot;tcp://myServer&quot;;Ref=&quot;mybase&quot;;Usr=Seller;Pwd=123;"

However, if the client application launch command line contains a login and a password, the infobase will be connected to with the parameters specified in the command line.

enable attribute

It defines if thin and web clients should be able to work with a published infobase. If the attribute value is true, it will be possible for thin and web clients to work with the published infobase. In this case the connection string will look as follows (for the example given in the beginning of the section:

http://host/demo

Otherwise (if the attribute value is false), it will not be possible to work via thin and web clients.

Default value: true (operation via thin and web clients is enabled).

temp attribute

Intended to specify a temporary files directory for web server extension (wsisapi.dll, wsap22.dll, wsapch2.dll) or for file infobase operation. If the attribute is omitted, then:

 the 1Cv8Tmp subdirectory will be used in the directory containing the file infobase for the file infobase

 In other cases the temporary files directory of the user, from which name the request is performed, is used.

pubdst attribute

Specifies the full URL of the file with a client application distribution set to be loaded and installed in case the client application and server versions mismatch.

NOTE

Applicable only to 1C:Enterprise under Windows OS.

Archive type: zip. Structure of files in the archive: only files of the client application distribution set, without any hierarchy or directories.

Example:

pubdst="http://www.myhost.ru/files/client.zip"

In case the server version changes, you need to change only the file with the client application archive.

allowexecutescheduledjobs Attribute

The attribute controls whether scheduled jobs can be executed by the web server extension in the file-mode infobase.

The attribute may have the following values:

 off – the web server extension will not execute scheduled jobs. In this event, scheduled jobs are executed by the client application (if available) that is connected to the infobase directly without using the web server.

 force – the web server extension will execute scheduled jobs.

Default value: not set. In this event, scheduled jobs will be executed by the application used to establish the first connection to the infobase.

### 3.14.1. <ws> Item

This item contains the web services publication settings. This item is subordinate to the <point> item. No more than one <ws> item may exist. This item may contain an arbitrary number of <point> items.

This item may contain the following attributes:

enable attribute

This enables web services operation in the current infobase. If the attribute is set to true (or the attribute is missing), the web services may function. Otherwise (if the attribute is set to false), you will not be able to work with the web services.

Default value: true (web services may function).

pointEnableCommon Attribute

The attribute is responsible for using those web services in the given infobase that are published without any explicit indication to use authorizations (the enable attribute of the point item). If the attribute value is true, then the use of all web services for which the value of the enable attribute of the point item is not explicitly specified is allowed. Otherwise, such web services cannot be used.

Default value: true (web services operation is allowed).

## 3.14.1.1. <point> Item

Description:

The item describes the published web service. This item is subordinate to ws item. At least one point item should exist.

If the web service is not explicitly specified in the default.vrd file and the web services of the applied solution can be used, then such a web service can only be called by the web service name (the Name property of the web service). The web service cannot be called by its alias, even when this alias is specified in the Publishing file name web service property. The required web service should be explicitly specified in the default.vrd file (including its alias) if you want to call the web service by both its name and alias. This item may have the attributes as follows:

name attribute

Name of the published web service. A service can be accessed using either the reference containing a name of the web service or the reference containing the web service synonym.

A web service described with the string:

…
base="/demo"
…
<point  name="OperationalData" alias="OperData"/>

can be accessed using the following references:

http://host/demo/ws/OperationalData
http://host/demo/ws/OperData

TIP

We recommend you to only use US ASCII characters in the web service name.

alias attribute

Synonym of the published web service. A service can be accessed using either the reference containing a name of the web service or the reference containing the web service synonym (provided that this other name is specified in the default.vrd file).

A web service described with the string:

…
base="/demo"
…
<point  name="OperationalData" alias="OperData"/>

can be accessed using the following references:

http://host/demo/ws/OperationalData
http://host/demo/ws/OperData

TIP

We recommend you to only use US ASCII characters in the web service synonym.

enable attribute

It defines if web service usage should be enabled or disabled.

Default value: true (publishing enabled).

### 3.14.2. <pool> Item

The item contains the settings for infobase connection pool. No more than one pool item may exist.

This item may have the attributes as follows:

size attribute

Pool size – maximum number of connections in the pool.

The default value is 100.

maxAge attribute

Pool connection life – the maximum lifetime for a connection in the pool (in seconds). If the connection is not used over the specified lifetime, it will be removed from the pool. The default value is 20 seconds.

attempts attribute

Maximum number of attempts to connect to the 1C:Enterprise server.

The default value is 5.

attemptTimeout attribute

The 1C:Enterprise server connection timeout (in seconds).

The default value is 0.5 seconds.

waitTimeout attribute

The timeout between 1C:Enterprise server connection attempts (in seconds).

The default value is 0.5 seconds.

Example:

<pool  size="50" maxAge="10" attempts="2"  attepmtTimeout="1"
waitTimeout="1"/>

### 3.14.3. <debug> Item

enable attribute

Instructs if debug mode should be used:

 enable="true" – debugging is enabled;  enable="false" – debugging is disabled.

url attribute

Specifies the URL of the debugger to be connected to automatically for debugging where localhost instructs to search on the local computer while 1560 is the number of the network port. If no port is specified, all the ports in the 1560–1591 ports range will be checked. Entering tcp:// is similar to entering tcp://localhost. If the debugger URL is not specified, debugging will not be applied in the process of 1C:Enterprise script code execution.

Example:

<debug   enable="true"         url="tñp://localhost"/>

### 3.14.4. <zones> Item

The <zones> item is subordinate to the <point> item. There may be only one item or no items at all. One or several <zone> items are subordinate to the <zones> item.

This item contains no attributes.

## 3.14.4.1. <zone> Item

Each <zone> item describes one separator. The sequence of the <zone> items in the <zones> item matches the sequence of the separators in the Designer. You should change the default.vrd file if the sequence of the separators changes. The number of <zone> items should not exceed the number of separators. If the number of items exceeds the number of separators, an exception will be created when you are connecting to an infobase which is published that way. If the number of items is less than the number of separators, the separators that are not specified will have the default value for the corresponding separator type, and use of separators will be disabled.

The <zone> item may contain the following attributes: safe attribute

Defines whether values of objects related to the data separation mechanism can be changed in case the infobase is accessed through a web client or thin client connected via a web server (safe data separation mode).

This attribute should be used if you want to block access to other data areas when the infobase is being accessed through the Internet.

The default value is false (changes are possible).

If the attribute is set to true, the following actions will be prohibited in any session that uses this infobase publication:

 Disabling the separator if the separation is not conditionally disabled.

 Changing the value of the separator used if the separation is not conditionally disabled.

 Modifying entities controlling conditional separation:

those specified for the separator itself;

those specified for the objects within the separator.

specify attribute

This specifies whether the value of this attribute will be included in the address of the database published.

The default value is false (the separator does not form the address).

value attribute

This is used to explicitly specify the value of the separator in this position.

If the value attribute is not specified, and the specify attribute is set to false, this is interpreted as absence of the separator’s value (corresponds to the "-" value in the Zn parameter value of the connection string).

If the specify attribute is set to true, and some value is set for the value attribute, this value (not case sensitive) must be explicitly specified in the appropriate position of the infobase address bar. Otherwise, a 404 (Web page not found) error is created when you try to access the infobase.

The characters that are prohibited in the URL (RFC 1738, http://www.faqs.org/ rfcs/rfc1738.html) are changed to UTF-8 characters and coded in accordance with section 2.2. URL Character Encoding Issues of the RFC 1738 standard (with the help of the "%" character and two hexadecimal characters).

Sample default.vrd file:

<?xml version="1.0"  encoding="UTF-8"?>
<point  xmlns="http://v8.1c.ru/8.3/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/test"
ib="File=&quot;ñ:\base&quot;;">
<ws enable="false"/>
<zones>
<zone  value=" 8314" safe="true"/>
<zone  specify="true" />
<zone  />
<zone  specify="true" />
<zone value="last" specify="true" />
</zones>
</point>

In this example, 5 separators are defined in the application. An infobase address will appear as follows:

http://hostname/test/01/20101231235959/last

This will be interpreted as follows:

 http://hostname/test – the address of the infobase itself.

 The first separator will not be specified in the address (the specify attribute is set to false by default), its value is equal to 8314 and you cannot control this separator programmatically (the safe attribute is set to true). Other separators may be controlled programmatically, as the safe attribute for the zone items is not set, and the default value (false) enables programmatic control.

 The second separator will be specified in the address (the specify attribute is set to true) and its value is equal to 01.

 The third separator is disabled.

 The fourth separator will be specified in the address (the specify attribute is set to true) and its value is equal to 31-12-2010 23:59:59.

 The last separator will be specified in the address and its value must be equal to last only.

Such an approach to separator specification may be used for a thin client working through the web server, for the web client and web services.

If separator values are specified in different ways at the same time, the values of the separators to be used in the session are defined as follows:

 If the default.vrd file specifies the <zones> item, the values of the separators specified in the infobase address have top priority. This means:

The values specified in the launch parameter (the Z parameter) are ignored.

The values specified in the infobase connection string are ignored (the Zn parameter in the ib attribute of the <point> item).

 If the default.vrd file does not specify the <zones> item, the following applies:

The system tries to define the separator values from the Z parameter of the address bar.

If the parameter is not specified, the system tries to use the values specified in the infobase connection string (the Zn parameter in the ib attribute of the <point> item).

 In the standard scenario, the priority of locations where the separator values may be specified is as follows (top down priority):

The infobase address (if the default.vrd file specifies the <zones> item).

The launch command line (the Z parameter).

The values specified in the infobase connection string are ignored (the Zn parameter in the ib attribute of the <point> item).

### 3.14.5. <openid> Item

The item describes settings, related to the OpenID-authentication. The <openid> item is subordinated to the <point> item. There can be one or none such item. The <rely> and <provider> items are subordinate to <openid>. Subordinate elements can be either in the singular number or missing.

This item contains no attributes.

## 3.14.5.1. <rely> Item

Item contains address of the infobased us as the OpenID-provider.

url attribute

Specifies URL for the 1C:Enterprise infobase used as the OpenID-provider. The infobase must be published in aspecial way.

IMPORTANT!

Interaction with the OpenID provider is only supported via an HTTPS connection.

NOTE

The OpenID provider’s URL cannot end with the "/" character. Correct:

https://myserver.org/users-ib/e1cib/oid2op, e1cib/oid2op/.  Example:      incorrect:       https://myserver.org/users-ib/
<rely  url="http://myserver.org/users-ib/e1cib/oida"/>

## 3.14.5.2. <provider> Item

Item specifies that the given infovase is an OpenID provider. The <lifetime> item is subordinate to this item. There can be one or no <lifetime> items.

Example:

<?xml version="1.0"  encoding="UTF-8"?>
<point  xmlns="http://v8.1c.ru/8.3/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/demo"
ib="Srvr=&quot;tcp://Server&quot;;Ref=&quot;demo&quot;;"  enable="false">
<openid>
<provider/>
</openid>
</point>

Item specifies the lifetime of the autentificate flag of the identifier in seconds. If not specified, the default value is 86 400 seconds (24 hours). The maximum lifetime of the authentication flag of the identifier is 604 800 seconds (1 week). When the lifetime item is set to a greater value, the greatest value is used.

Example:

<?xml version="1.0"  encoding="UTF-8"?>
<point  xmlns="http://v8.1c.ru/8.3/virtual-resource-system"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
base="/demo"
ib="Srvr=&quot;tcp://Server&quot;;Ref=&quot;demo&quot;;"  enable="false">
<openid>
<provider>
<provider>
</openid>
</point>

### 3.15. INETCFG.XML

inetcfg.xml is intended to specify default proxy settings. The file has a higher priority than the default Windows proxy settings.

The file is located in the 1C:Enterprise configuration files directory and it is optional.

If the file is not available, Internet Explorer settings are used as Windows settings.

Under Linux inetcfg.xml should be available if proxy needs to be used.

The User-Agent information from the HTTP request can be used for proxy setup:

 thin client – 1CV8C

 web service – 1C+Enterprise/8.3

 web client – this parameter is generated by the web browser Example:

<InternetProxy
protocols="http=10.1.0.8:808010.1.0.9:8080"
user="proxyUser"
bypassOnLocal="true"
/>

The InternetProxy root item that specifies the default proxy settings, is structured as described below with the following attributes used.

ntlm attribute

Type: boolean (optional). Defines if NTLM authentication should be used:

 true – NTLM authentication is enabled;  false – the authentication is disabled. NTLM authentication is enabled by default.

protocols attribute

Type: String (optional). It defines the name and the port of the host for the protocols. The format is as follows:

ProxyProtocolParameters1ProxyProtocolParameters2
…ProxyProtocolParametersN
ProxyProtocolParameters:=[Protocol]"="host":"port

The list of proxy protocols parameters is spaces separated. Every parameter contains an optional protocol name, the "=" character, the host name and the port of the proxy server separated by a colon. If protocol name is omitted, the proxy parameters are applied to all the protocols without explicit definition of the parameters. The following names for the protocols are possible:

 http

 https

 ftp

The names are case sensitive. No other protocol names are supported.

Example:

protocols="http=10.1.0.8:808010.1.0.9:8080"

Where:

 The following proxy parameters are defined for http protocol: host – 10.1.0.8, port – 8080.

 For other protocols (https, ftp): host – 10.1.0.9, port – 8080.

user attribute

Type: String (optional). User name for proxy server authorization.

Example:

user="proxyUser"

Type: String (optional). Proxy server user authentication password.

Example:

bypassOnLocal attribute

Type: boolean (optional). It defines if proxy server should be used for local addresses:

 true – disabled;

 false – enabled.

A dot in the DNS address name is used to decide if an address is local (this means that all the IP addresses are not local). Therefore, it may happen that an actual local address will not be recognized as such.

For example, <user>.<domain> is a local address in Windows XP but it is not recognized as such. To disable use of proxy for the addresses that are recognized as local addresses, the following parameter is used:

bypassOnLocal="true"

Type: String (optional). The list of addresses proxy is not used for. The format is as follows:

host1 host2 … hostN

Host names are spaces separated. The host name may contain special mask characters: * – any number of characters, ? – any character. For example, to disable proxy for all the hosts within a domain, use it as follows: *.<domain name>.

Example:

In the above example proxy is disabled for the address 127.0.0.1 (localhost) and all the addresses within the master domain.

### 3.16. LOCATION.CFG

The location.cfg file is intended to specify the directory where user settings files are stored as well as the location of the software license file. The location parameter is used to specify the directory location.

location

Directory path.

Example:

### 3.17. LOGCFG.XML

logcfg.xml is intended to customize the technological log parameters and dumps generation mechanism in case of failure.

The file is located in the 1C:Enterprise configuration files directory and it is optional.

If the file is not available, the following default settings will be used for the technological log:

 Technological log is disabled;

 Technological log is enabled by default;

 The dumps are saved to %USERPROFILE%\Local Settings\Application Data\1C\1cv8\dumps;

 Minimum dumps are saved upon failure;

 Technological log is saved to %USERPROFILE%\Local Settings\1C\1cv8\logs (%LOCALAPPDATA%\1C\1cv8\logs for OS Windows Vista or later) by default. The information is deleted after 24 hours by default;

 The level of generating event in the technological log is set to Error by default.

Example:

<config  xmlns="http://v8.1c.ru/v8/tech-log">
<log location="c:\v8\logs"history="1">
<event>
<eq property="name"  value="conn"/>
</event>
</log>
<dump location="c:\v8\dumps" create="1"  type="2"/>
</config>

Here is the meaning of the configuration file content:

 All the client connections to the server and disconnections are recorded in the technological log;

 The technological log files are located at c:\v8\logs;

 The technological log files are stored for one hour;

 The dump files are located at c:\v8\dumps;

 The dump files contain all the information available (the content of the entire process memory).

### 3.17.1. Configuration File Structure

The root item of the configuration file is <config> that defines the settings of the technological log. It may contain multiple <log> items, one <dump> item, one <leaks> item, one <plansql> item, one <defaultlog> item and one or several <system> items:

<config…>
<log…>…</log>
<log…>…</log>
<log…>…</log>
<dump  … />
<leaks>…</leaks>
<mem/>
<plansql/>
<system  … />
<system  … />
<system  … />
<defaultlog  … />
</config>

These elements are for the following:

 The <log> item defines the directory of the technological log and its contents (see page 268).

 The <dump> item defines the directory to record the failure dumps to (see page 285).

 The <leaks> item toggles tracking of memory leaks (see page 287) that can be caused by configuration code errors. Memory leaks tracking damages performance to a certain extent.

 The <mem> item is intended to track memory usage (see page 292).

 The <plansql> item controls the collection of the query plans created by the DBMS. The query plans themselves are stored in the <planSQLText> property of the events related to the DBMS.

 The <defaultlog> item defines the directory and lifetime for the default technological log (see page 298).

 The <system> item defines settings for generating the system events (see page 300).

Items can be divided into three groups:

1.     Items which manage generating one or another event. Such are the <dump>, <leaks>, <mem>, <plansql>, <system>. At the same time if reguired item is not specified in the technological log settings file, then the corresponding event is not generated by the system. In other words, if the track memory usage is not enabled using the <mem> item, then filtering by the MEM event will not affect filling of the technological log, because the event is not generated.

2.     Items which specify filter for events already generated technological log data. Such are <event> and <property>. Using these items you can "process" events, generated by the system. Using these items you can only reduce the number of data written to the technological log files.

3.     Items which manage the location of files with data (technological log and dumps). Such are <log>, <defaultlog>, <dump>.

## 3.17.1.1. <log> Item

The <log> item defines the directory of the technological log and conditions by which generated events are placed into the technological log.

Item attributes:

location attribute

Directory name to host the technological log.

IMPORTANT!

Please note that the technological log directory is not intended for storing files which are not related to the technological log. So do not place dumps in it and do not use a directory which may contain files that are not related to the 1C:Enterprise technological log. If the directory specified as a technological log directory contains any unrelated files, specification of the catalog will fail and the technological log will not be created.

NOTE

You should specify different directories in the location attribute for the <log>, <dump> and <defaultlog> items.

history attribute

The number of hours the records are deleted from the technological log after.

The <log> item may have <event> and <property> items nested. Their assortment defines the criteria for recording every event in the log as well as the criteria for recording every event property.

If this item does not contain any <event> items, no events will be recorded to the log.

## 3.17.1.2. <event> Item

The sequence of <event> items defines the criterion for an event to be recorded in the log. Only the events that meet the criterion will be recorded to the log. In other words, if the criterion defined by the <event> items sequence is True, the event will be recorded in the log. An event is only recorded in the log if it satisfies all the criteria within at least one of the <event> items. It means that the criteria within <event> are grouped by AND while the <event> items are grouped by OR.

The criteria are defined using the following items:

 eq – equal to

 ne – not equal to  gt – greater than

 ge – greater or equal

 lt – less than

 le – less or equal

 like – compliance with a mask

Every item (except for like) instructs to simply compare the event parameter value (with its name defined by the property attribute) with the value attribute value.

Example:

<event>
<eq property="name" value="proc"/>
</event>

In this case the events belonging to the group named PROC will be recorded in the technological log.

The following names are available for events groups:

Managing actions by the 1C:Enterprise server cluster administrator.

CALL

Incoming remote call (remote call at the call receiver side).

CLSTR

Execution of operations changing the way server cluster work.

CONN

Client connection to the server or disconnection from it.

DB2

Execution of SQL operators of the DB2 database management system.

DBMSSQL

Execution of SQL operators of Microsoft SQL Server database management system.

DBPOSTGRS

Execution of SQL operators of PostgreSQL database management system.

DBORACLE

Execution of SQL operators of Oracle Database database management system. DBV8DBENG

Execution of SQL operators of the file mode database management system. EDS

External data sources access.

EXCP

1C:Enterprise applications exceptions that cannot be processed normally and can result in failures of a server process or a client process connected to it.

EXCPCNTX

The events that were initiated but were not ended by the moment of an exception.

LEAKS

The events related to memory leaks that can be caused by configuration code errors.

MEM

The events related to increase in memory volume used by server processes (ragent, rmngr, rphost).

PROC

The events related to the entire process and impacting its further operation capacity. Example: start, end, failure, etc.

QERR

The events related to identification of errors in request compilation errors or limitations at the level of records and fields in the database.

SCALL

Originating remote call (remote call at the call source side).

SCOM

The events of creating or deleting server context that is usually related to the infobase.

SDBL

The events related to execution of queries to the database model of 1C:Enterprise.

SESN

The actions related to the work session. Example: session start, session end, etc.

Deadlock in the managed mode detected.

TTIMEOUT

TLOCK

Management of transactional locks in the managed mode.

VRSCACHE

Server queries cache operation.

VRSREQUEST

Server query for some resource.

VRSRESPONCE

Server response.

Please note that only events from the following groups can occur on a client computer: PROC, EXCP, SDBL.

Also note that the events from the following groups are quite rare and only contain minor volumes of information: PROC, SCOM, EXCP, CONN, and ADMIN. At the same time recording of events from the following groups may result in significant increase of technological log volume: SDBL, DB2, DBMSSQL, DBPOSTGRS, DBORACLE.

The like item defines if a technological log event property complies with some mask. A mask is a sequence of characters where some of them are used as the characters they represent while others serve as templates intended to describe a group of characters.

For example, the item <like property="SDBL" value=" reference "/> means that the value of the SDBL property of the technological log event will be checked to see if it complies with reference mask.

The templates include:

 % – 0 or more arbitrary characters;

_ – 1 arbitrary character;

[...] – one of the characters specified. At that [...] may contain arbitrary characters or ranges formatted as ñ-C where ñ is the first character in the range while C is the last character in the range;

[^...] – any character except for those specified;

\ – prefix character. The prefix itself is ignored as it means that the character it precedes is simply the character representing itself (and not a template). All the other characters – simple characters representing themselves.

Comparison of simple characters is not case sensitive.

Examples of templates:

 "template" – a string with some specific text. In this case the like comparison is absolutely similar to eq comparison. It is not case sensitive.

 "%reference%" – the string containing the reference context in an arbitrary location. It is not case sensitive.

 "reference%" – the string containing the reference context in the beginning. It is not case sensitive.

 "%reference" – the string containing the reference context in the end. It is not case sensitive.

 "%[a-z]" – a string starting with a lowercase English letter from a to z in the end.

 "%[^a-z]%" – a string containing at least one character other than a lowercase English letter.

NOTE

When events are filtered by templates, it takes longer than other comparison items. Complex filters of technological log events and properties may somewhat slow 1C:Enterprise down.

Example:

<log  location="c:\logs" history="1">
<event>
<eq property="name" value="proc"/>
</event>
<event>
<eq property="name" value="scom"/>
</event>
<event>
<eq property="name" value="conn"/>
</event>
<event>
<eq property="name" value="excp"/>
</event>
<event>
<eq property="name" value="dbmssql"/>
</event>
</log>

This example defines that all the events from the following groups will be recorded to the technological log: PROC, SCOM, CONN, EXCP, and DBMSSQL.

## 3.17.1.3. <property> Item

<property> defines the criteria for recording the event property to the log. The name of such a property is defined as the name attribute value provided that the event itself should be recorded in the log. The criteria are defined in the <event> nested items with the following rules applied to them as the rules for the events.

If <property> item with a defined name is not available, the respective property is not recorded. If the <property> item does not contain any nested <event> items, the property it defines is recorded for all the events to be recorded in the log if the property is available for the events. If the <property> item contains nested <event> items, the property will only be recorded for the events complying with the criterion (provided that the events themselves are recorded to the log and contain this property).

The item <property name="all"> </property> includes the records to the log of all the event properties.

The <log> item below defines record to the event log for: process, server context, connection, exceptions and SQL operators' execution. At that the SQL operator code will only be recorded in the log if execution of the operator took longer than a second. The log is located at c:\logs and is stored for 1 hour.

Example:

<log  location="c:\logs" history="1">
<event>
<eq property="name" value="proc"/>
</event>
<event>
<eq property="name" value="scom"/>
</event>
<event>
<eq property="name" value="conn"/>
</event>
<event>
<eq property="name" value="excp"/>
</event>
<event>
<eq property="name" value="dbmssql"/>
</event>
<property  name="sql">
<event>
<eq property="name"  value="mssql"/>
<gt property="duration"  value="10000"/>
</event>
</property>
</log>

Every event has a set of properties. Every property has a name. An event may have multiple properties sharing the same names. The property names may be used to filter the events and properties. Names comparisons are not case sensitive. An empty criterion in the <property> item will mean that the property will be recorded for any criterion.

NOTE

An event property is recorded only if <property> item is available for this property.

The major event properties that may be needed for configuration file customization and for technological log viewing are listed below:

 All – to enable recording of all the log events.

 ApplicationExt – updating the requirement for assigning functionality (for the CLSTR event).

 Body – request/response body size in bites (for the VRSREQUEST, VRSRESPONSE events).

 Calls – the number of client application queries to the server application via TCP.

 Class – name of the class, in which the event is generated (for the SYSTEM event only).

 Cluster – the number of the server cluster primary port.

 ñn – the number of the dynamic memory fractions used by the process at the moment of MEM event recording.

 ñnd – the change in the number of the dynamic memory fractions used by the process versus recording of the previous MEM event.

 Component – name of the platform component, where the event is generated (for the SYSTEM event only).

 Connection – infobase connection number.

 ConnLimit – maximum connections defined per working process (for the CLSTR event).

 Context – execution context.

 Dbms – database management system of an external data source (only for the EDS event). The following values are possible:

DBMSSQL – Microsoft SQL Server.

DBOracle – Oracle Database.

DB2 – IBM DB2.

DBPOSTGRS – PostgreSQL.

DBUnkn – other database management systems.

 DBConnStr – string for connection with an external data source (only for the EDS event).

 DBUsr – name of the user of the external data source database management system (only for the EDS event).

 DBConnID – ID of the connection with the database management system of an external data source (only for the EDS event).

 dbpid – string presentation of identifier of 1C:Enterprise server connection to database server in terms of database server (for the events: DBMSSQL, DBPOSTGRS, DB2, DBORACLE).

 Descr – a description for a software exception.

 dumpError – a description of the error occurred in the process of dump generation.

 DumpFile – dump file name.

 Duration – event duration, hundreds of microseconds.

 Durationus – event duration, microseconds.

 Err – console message:

0 – information messages.

1 – error messages.

 Event – contains the description of the action executed by the server cluster (for the CLSTR event) and defines the existence of other attributes in this event. Set out below are the property values and properties that will additionally be set in this event:

distrib obsolete – cache of cluster functionality assignments is obsolete for the current working process.

current version older – the active instance of the service has received a replica with a new service status version, it must become a redundant one.

current version newer – the active instance of the service has received a replica with an old service status version, and rejected it.

For the CLSTR event whose Event property has one of the values above, the event properties listed below are applicable:

ServiceName – cluster service name.

Ref – infobase name.

SessionID – session number.

MyVer – current version of the service status.

SrcVer – received version of the service status.

NeedResync – service data needs synchronizing (only for the current version older event).

service assign require – the service is unavailable, reassigning is required. For the CLSTR event whose Event property has this value, the event properties listed below are applicable:

ServiceName – cluster service name.

Ref – infobase name.

working process not found – the working process to establish connection with the infobase is not found. For the CLSTR event whose Event property has this value, the event properties listed below are applicable:

Ref – infobase name.

SrcURL – preferred address of the working process.

ApplicationExt – adjustment for the requirement for assigning functionality.

process unavailable – the working process cannot be used to connect to the infobase. For the CLSTR event whose Event property has this value, the event properties listed below make sense:

Reason – describes the reason for the unavailability of the working process:

IBLimit – maximum infobases per working process is reached.

ConnLimit – maximum connections per working process is reached. □ IBLimit – maximum infobases defined per working process.

ConnLimit – maximum connections defined per working process.

data replication start – replicating data from the current active instance to the backup one has started. For the CLSTR event whose Event property has this value, the event properties listed below are applicable:

ServiceName – server cluster service name.

Ref – infobase name.

SessionID – session number.

destination version older – the replica was passed to the active instance of the service with an old service status version.

destination version newer – the replica was passed to the active instance of the service with a new service status version; the replica was rejected, and the current service must become a backup one.

For the CLSTR event whose Event property has one of the foregoing values, the event properties listed below are applicable:

ServiceName – server cluster service name.

Ref – infobase name.

SessionID – session number.

finish replication – replicating is over. For the CLSTR event whose Event property has this value, the event properties listed below make sense:

ServiceName – server cluster service name.

Ref – infobase name.

SessionID – session number.

register rphost – registration of cluster work processes.

register rphost – registration of cluster managers.

register rphost – registration of cluster work processes is cancelled.

register rphost – registration of cluster managers is cancelled.

main rmngr is down – Error calling the cluster service on the main manager. The working process should be ended. For the CLSTR event whose Event property has this value, the event properties listed below make sense:

ServiceName – name of the service being called when the cluster manager has turned out to be unavailable.

 Exception – software exception name.

 Finish – reason for process termination.

 File – name of the file in which the event was generated (for the SYSTEM event).

 Func – executed function name:

connect – connection with an external data source.

disconnect – disconnection with an external data source.

beginTransaction – beginning of a transaction (SDBL event is recorded to a log when a transaction begins and has no duration).

transaction – beginning of a transaction (SDBL event begins when a transaction begins and ends when the transaction ends).

commitTransaction – transaction commitment.

rollbackTransaction – cancelling a transaction.

setRollbackOnly – checking a checkbox for error availability in a transaction (in this case the transaction can only be rolled back).

getTransactionSplitter – getting a totals splitter.

quickInsert – quick insert of data to the database table.

insertRecords – adding a record to the database table.

suspendIndexing – suspending database tables indexing.

resumeIndexing – resuming database tables indexing.

holdConnection – holding a connection.

saveObject – saving an object.

restoreObject – restoring an object.

createFile – creating a file.

deleteFile – deleting a file.

searchFile – searching for a file.

modifyFile – editing a file.

isProperLocale – checking the locales specified for the database.

changeLocale – changing the locales of the database.

takeKeyVal – getting the value of the tabular section record key.

lockRecord – locking a record.

serializeTable – saving table data to a file.

deserializeTable – restoring a database table from file.

xlockTables – applying exclusive lock to a table.

xlockTablesShared – applying shared lock to a table.

copyMoveFile – copying/moving a configuration fragment between database tables records.

moveFile – moving a file.

securedInsert – inserting records with data access restrictions.

selectFileName – selecting a file name.

setSingleUser – enabling exclusive mode.

insertIBRegistry – creating a cluster.

eraseIBRegistry – removing a cluster.

setRegMultiProcEnable – selecting a value for the checkbox that defines support of multiple working processes by the cluster.

setServerProcessCapacity – defining the value for working process throughput.

agentAuthenticate – central server administrator authentication.

setRegSecLevel – defining the cluster security level.

setRegDescr – defining a cluster description.

setInfoBaseDescr – defining an infobase description.

insertServerProcess – adding a working process. eraseServerProcess – deleting a working process.

eraseRegUser – deleting a cluster administrator.

setServerProcessEnable – selecting a value for the checkbox that enables working process startup.

insertRegServer – adding a Working server.

eraseRegServer – deleting a Working server.

updateRegServer – modifying the Working server parameters.

createInfoBase – creating an infobase.

dropInfoBase – deleting an infobase.

killClient – disconnection of a client from the 1C:Enterprise server cluster.

authenticateSrvrUser – cluster administrator authentication in the working process.

 Method – HTTP method of calling a resource (for the VRSREQUEST, VRSRESPONSE events).

 Host – computer name.

 Ib – name of a client/server mode infobase.

 IBLimit – maximum infobases defined per working process (for the CLSTR event).

 InBytes – volume of data read from the disc during the call (in bytes).

 Level – level of event importance (for the SYSTEM event). Possible values of the event are listed in the description of the <system> item of the technological log settings file logcfg.xml (see page 266).

 Line – number of line in the file, where the SYSTEM event was generated.

 Locks – list of managed transaction locks (for the TLOCK event).

 Method – name of the method called for the CALL event of the remote method call that is different from the call method. The Interface property (interface indicator) and the Method property (interface method number) are recorded for the remote call of the call method in the CALL event.

setInfoBaseConnectingDeny – enabling the mode where infobase connections will be denied.

lookupTmpTable – getting/creating a temporary database table.

returnTmpTable – releasing a temporary database table.

start – beginning of a session (SESN event is recorded to a log when a session begins and has no duration).

finish – session end (SESN event is recorded to a log when session ends and the duration of the event equals the duration of the entire session):

attach – attaching a session to a connection (SESN event is recorded to a log when the session is detached from the connection). The duration demonstrates the time the session was attached to the connection;

busy – the session is already attached to the connection (SESN event is recorded to the log when you attempt to attach an already attached session to the connection). No duration;

wait – waiting for an attachment (SESN event is recorded when waiting to attach a session to a connection is completed). The event duration equals the time of waiting for a connection. If an already attached session is attached to a connection, the current stream of the current connection waits for the session to be detached from another connection;

setSrcProcessName – means that common infobase data are created in the working process and a shared name is specified for the data. An event is recorded when the first user is connected to the infobase via this working process or when the infobase configuration is updated dynamically.

 Memory – memory space (in bytes), occupied but not freed during the server call.

 MemoryPeak – peak value of the memory (in bytes), occupied but not freed during the server call.

 Name – event name.

 NParams – number of SQL operator parameters for the file-mode infobase (the DBV8DBENG event). Parameters, the count of which is specified in this property, are used to transmit long binary data.

 MyVer – current version of the service status (for the CLSTR event).

 NeedResync – service data needs synchronizing (only for the CLSTR event where the Event property value is current version older).

 OSException – operating system exception description.

 OutBytes – volume of data written to the disc during the call (in bytes).

 Phrase – text phrase matching the status code (for the VRSRESPONSE events).

 planSQLText – a plan of the query from the Sql property (for DBV8DBENG, DBMSSQL, DBPOSTGRS, DB2, DBORACLE, EDS events).

 Process – application name as displayed by the operating system (file name of the application running module).

 p:processName – server context name which usually matches the infobase name.

 Port – number of the process primary network port.

 ProcessName – process name.

 Ref – infobase name.

 Reason – reason for the working process being unavailable (for the CLSTR event).

 Regions – names of managed transaction deadlock regions (for the TLOCK event).

 Report – name of the object of metadata of the report being executed (executed in a background job).

 Rows – number of received database records.

 RowsAffected – number of modified database records.

 RunAs – process operation mode (an application or a service).

 Sdbl – query text in the integrated database model script.

 ServerComputerName – Working server name.

 ServiceName – name of the cluster server service (for the CLSTR event).

 SessionID – number of the session attached to the current stream. If no session is attached to the current stream, the property will not be added.

 Status – http status code (for the VRSRESPONSE events).

 srcProcessName – recorded when common infobase data are released by the working process. The value of the ProcessName property is the name of the shared data at the moment of their release. The value of the srcProcessName property is the common infobase data name when they are created.

 Sql – SQL operator code.

 SrcVer – received version of the server cluster status (for the CLSTR event).

 SrcURL – preferred address of the working server (for the CLSTR event).

 SyncPort – number of the process secondary network port.

 sz – the volume of the dynamic memory taken by the process at the moment of MEM event recording (in bites).

 szd – change in the volume of the dynamic memory taken by the process from the moment of the previous MEM event recording (in bites).

 t:applicationName – client program identifier.

 t:clientID – identifier of client connection via TCP.

 t:computerName – client computer name.

 t:connectID – infobase connection identifier.

 Trans – transaction activity identifier when event begins: 0 – transaction not opened; 1 – transaction opened.

 Txt – information message text.

For the HASP this property contains source data and result of calling the dongle in the following format: <Operation>(<List of input parameters>)-><List of output parameters>. At the same time:

<Operation> – operation, being processes during the given call to a dongle.

<List of input parameters> – list of input operation parameters and their values separated by commas.

<List of output parameters> – list of output operation parameters and their values separated by commas.

Full list of operations, their parameters and results is contained in the HASP4 Programmer's Guide          (http://sentineldiscussion.safenet-inc.com/topic/hasp4programmer-s-guide).

For the CLSTR event, this property contains values of parameters involved in the calculation of the available work process performance in the Parameter:Value form, separated by a space.

 URI – called resource (for the VRSREQUEST, VRSRESPONSE events);

 Usr – infobase user name (if no users are defined in the infobase, the value for this property will be DefUser). The property value is taken from the attached session;

 IB infobase name (for the SESN event);

 Nmbsession number (for the SESN event);

 Val – the value with its meaning depending on the Func parameter value;

 WaitConnections – a list of connections with which managed transaction deadlock clashes occur (for the TLOCK and TTIMEOUT events).

Execution context can be recorded in the technological log using the <property> item properties. There are two types of execution context: 1C:Enterprise script context and interface context. The 1C:Enterprise script context is a list of 1C:Enterprise script operators and contains the following:

 Module name

 Module string number

 Text presentation of the 1C:Enterprise script call list item of the respective module string

The interface context includes:

 Full form name

 Active form control type

 Active form control name

 Command panel button name (if clicked)

 Action executed by form control

For example, 1C:Enterprise script context in the technological log file may look as follows:

Document.ReceiptOfGoods:23:Movement.NomenclatureAccounting.Write();
ApplicationModule:18:CheckStandbyHandlerConnection(True);
ApplicationModule:230:IfGetDefaultValue(CurrentUser,"UseReminders")
CommonModule.UserSettings:481:Selection=Query.Execute().Select();

Interface context in the technological log file may look as follows:

{Document.Document1.ListForm}/{TableBox:
DocumentList}/{RefreshDisplay}
{Document.Document1.Form.DocumentForm}/{CommandBar:
FormMainActions}/{FormMainActionsOK}
{Document.Document1.Form.DocumentForm}/{Button:
Button1}/{Click}

In order to enable context recording, you should write <property name="Context"> item or <property name="all"> item among properties' filters.

In order to record the SDBL events (SDBL requests) and DBMSSQL events (SQL operators for MS SQL Server database management system) accompanied by execution context, the technological log setup file will look as follows:

<config  xmlns="http://v8.1c.ru/v8/tech-log">
<log location="c:\v8\logs" history="1">
<event>
<eq property="name"  value="sdbl"/>
</event>
<event>
<eq property="name"  value="dbmssql"/>
</event>
<property  name="Context">
</property>
</log>
</config>

In order to record the SDBL events (SDBL requests) and DBMSSQL events (SQL operators for MS SQL Server database management system) without execution context, the technological log setup file should have the content as follows:

<config  xmlns="http://v8.1c.ru/v8/tech-log">
<log location="c:\v8\logs" history="1">
<event>
<eq property="name"  value="sdbl"/>
</event>
<event>
<eq property="name"  value="dbmssql"/>
</event>
</log>
</config>

If you want to record the SDBL events (SDBL requests) and DBMSSQL events (SQL operators for MS SQL Server database management system) without execution context but accompanied by all the remaining properties, the settings file should have the content as follows:

<config  xmlns="http://v8.1c.ru/v8/tech-log">
<log location="c:\v8\logs" history="1">
<event>
<eq property="name"  value="sdbl"/>
</event>
<event>
<eq property="name"  value="dbmssql"/>
</event>
<property  name="all">
</property>
<property  name="context">
<eq  property="name" value=""/>
</property>
</log>
</config>

In order to record SDBL events (SDBL requests) accompanied by execution context and DBMSSQL events (SQL operators for MS SQL Server database management system) without execution context, the setup file should have the content as follows:

<config  xmlns="http://v8.1c.ru/v8/tech-log">
<log location="c:\v8\logs" history="1">
<event>
<eq property="name"  value="sdbl"/>
</event>
<event>
<eq property="name"  value="dbmssql"/>
</event>
<property  name="context">
<event>
<eq  property="name" value="sdbl"/>
</event>
</property>
</log>
</config>

Availability of <property name="context"> item means that when the criteria specified in this item are complied with for the events to be recorded in the log, context information will also be recorded. After that for every technological log event the execution context information in the current process will be added and after the event an instant event will be added that contains information on execution context of the client process.

The technological log may also have the messages recorded about the exceptions related to lock manager. To make this possible, the configuration file should look approximately as follows:

<config  xmlns="http://v8.1c.ru/v8/tech-log">
<log location="c:\v8\logs" history="7">
<event>
<eq property="name"  value="excp"/>
</event>
<event>
<eq property="name"  value="tlock"/>
<gt property="duration"  value="100000"/>
</event>
<property  name="all"/>
<property  name="context">
<event>
<eq  property="name" value=""/>
</event>
</property>
</log>
<dump location="c:\v8\dumps" create="1"  type="2"/>
</config>

In the above example all the exceptions related to locks will be recorded (including DEADLOCK – connection interlocks and TIMEOUT – specified timeouts; at that in both cases the exception message text will contain the connection number that caused the exception) as well as all the timeouts over 10 seconds. The information for all the properties will be recorded except for Context property.

## 3.17.1.4. <dump> Item

<dump> defines parameters of the dump that is created upon application failure.

To disable generation of dumps, you should use create = "0" or create = "false" as a value for the <dump> item. If <dump> is not available, the following directory will be used to save dumps to: %USERPROFILE%\Local Settings\Application Data\1C\1cv8\dumps (for Windows).

IMPORTANT!

For Linux generation of dumps is customized using operating system tools. Hence <dump> is ignored. For details on dumps generation setup under Linux, see page 122.

Item attributes:

location attribute

Name for the directory to save dump files to.

NOTE

You should specify different directories in the location attributes for the <log>, <dump> and <defaultlog> items.

create attribute

Defines if dump file should be created or not.

 0 ("false") – do not create  1 ("true") – create

type attribute

Dump type that is an arbitrary combination of the flags below in decimal or hex format (addition of flag values). Hex representation should begin with "x" character, e.g. x0002.

The following values are available:

 0 (x0000) – minimum

 1 (x0001) – extra data segment

 2 (x0002) – content of the entire process memory

 4 (x0004) – handle data

 8 (x0008) – the dump should only contain the information required to restore call stacks

 16 (x0010) – if a stack contains references to module memory, add 0x0040 flag

 32 (x0020) – the dump should include memory from the dumped modules

 64 (0x0040) – the dump should include the memory with references to it

 128 (x0080) – the dump should include detailed information on module files

 256 (0x0100) – local data of streams should be added to the dump

 512 (0x0200) – the dump should include memory from the entire available virtual address space

TIP

In the majority of situations it will be sufficient to use 3 as the value for type attribute, e.g. type="3".

prntscrn attribute

It defines if a print screen file should be created upon failure of 1C:Enterprise front end. The file name is the same as the dump name but has png as its extension. Print screen files are created in the same directory the dumps are saved to (see location attribute).

 0 ("false") – do not create

 1 ("true") – create

Upon 1C:Enterprise failure the system will display the dialog with information on dump recording process. This dialog will be automatically closed when dump recording is completed.

## 3.16.1.5. <leaks> Item

<leaks> enables or disables tracking of memory leaks caused by configuration code problems. By default leaks tracking is disabled and does not affect the performance.

To enable leaks data recording to logcfg.xml, you should have <leaks> item added: <leaks collect=1> or <leaks collect=true>.

To disable memory leaks tracking, the <leaks> item should be changed as follows: <leaks collect=0> or <leaks collect=False>.

If leaks tracking is enabled, creating and deleting the following objects will be tracked for the users:

 Form

 ManagedForm

 FixedStructure

 Fixed Map

 FormDataStructure

 FormDataCollection

 FormDataStructureAndCollection

 FormDataCollectionItem

 FormDataTree

 FormDataTreeItemCollection

 FormDataTreeItem

 AccountingRegisterManager

 AccountingRegisterRecordSet

 ChartOfAccountsManager

 ChartOfAccountsObject

 ExchangePlanManager

 ExchangePlanObject

 SettingsStoragesManager

 AccumulationRegisterManager

 AccumulationRegisterRecordSet

 ChartOfCharacteristicTypesManager

 ChartOfCharacteristicTypesObject

 ConstantManager

 DocumentManager

 DocumentObject

 EnumManager

 ExternalDataProcessor

 ExternalReport

 InformationRegisterManager

 InformationRegisterRecordSet

 DataProcessorManager

 DataProcessor

 CatalogManager

 CatalogObject

 ReportManager

 Report

 SequenceRecordSet

 ChartOfCalculationTypesManager

 ChartOfCalculationTypesObject

 CalculationRegisterManager

 CalculationRegisterRecordSet

 RecalculationRecordSet

 COMSafeArray

 KeyAndValue

 Array

 FixedArray

 Map

 Structure

 ValueListItem

 ValueList

 ValueTable

 ValueTableRow

 ValueTree

 ValueTreeRow

Leaks are tracked between the begin point and the end check point in the source code. In the begin checkpoint data on leaks for the current user are cleared. In the end checkpoint the LEAKS event is generated and recorded in the technological log. In this event 1C:Enterprise script stack will be specified for every unreleased object instance at the moment of creation. The following can be used as checkpoints:

 Beginning and end of 1C:Enterprise script execution on the client or on the server;

 Calling 1C:Enterprise script procedure/function and return from the procedure/ function;

 Beginning of execution of one 1C:Enterprise script code string and end of execution of another 1C:Enterprise script code string.

The begin and end checkpoints are defined by <point> item. At that checkpoints can be nested into each other but will be ignored in this case as only external checkpoints are used for leaks tracking. For example, if the following checkpoints are passed in the configuration code execution:

 Begin1,

 Begin2,

 End1,  End2.

It means that leaks will only be tracked between the checkpoints Begin1 and End2.

The <point> item can be formatted in one of the following manners:

<point call="client"/>, <point call="server"/>

This item sets the checkpoints in the beginning / in the end of 1C:Enterprise script execution on the client or on the server, i.e. the begin point will be set in the beginning of 1C:Enterprise script execution on the server/client while the end point will be located in the end of 1C:Enterprise script execution on the server/client.

<point proc="<ModuleName>/<MethodName>"/>

It sets the checkpoints to the call and return of a specific 1C:Enterprise script method. <ModuleName> – contains full name of metadata object the module belongs to (without configuration name). Debugger displays module names formatted in the same manner. <MethodName> includes method name. If no <MethodName> argument is specified, the checkpoints will be located in the beginning/end of module body execution. Module names examples:

 SessionModule.Module – session module.

 ApplicationModule.Module – application module.

 ManagedApplicationModule.Module – managed application module.

 ExternalConnectionModule.Module – external connection module.

 CommonModule.Global.Module – shared Global module.

 Catalog.Contractors.ObjectModule – module of the Contractors Catalog item.

 DataProcessor.DataProcessor1.Form.Form1.FormForm1 module of the DataProcessor1 data processor.

 DataProcessor.DataProcessor2.Form.DefaultForm.FormDefaultForm form module of the DataProcessor2 data processor.

<point on="<ModuleName>/<LineNumber>" off=

"<ModuleName>/<LineNumber>"/>

In this case the begin and end checkpoints are defined via explicitly specified code strings. The begin checkpoint is the beginning of code execution of the string specified in the On attribute. The end checkpoint is the end of code execution of the string specified in the Off attribute. Strings numbering begins from 1. If the begin checkpoint is reached on the server, the end checkpoint should be reached on the server as well. The last string in the code of a procedure, function or module body cannot serve as the end checkpoint.

<leaks> item example:

<leaks collect="1">
<point  call="client"/>
<point  call="server"/>
<point  proc="ApplicationModule/"/>
<point  proc="CommonModule.ConnectionsDataProcessor.Module/AtServerNoLeak"/>
<point on="CommonModule.Services.Module/9"
off="CommonModule.Services.Module/11"/>
</leaks>

In this case leaks recording is enabled. The checkpoints are set at:

 the beginning and the end of 1C:Enterprise script execution on the client side,

 the beginning and the end of 1C:Enterprise script execution on the server side,

 at the beginning and completion of application module body execution;

 when calling the AtServerNoLeak() method and returning it from the

ConnectionsDataProcessor shared module;

 at the strings 9 and 11 of the Services shared module;

Let us assume that the procedure with the following code causes memory leak:

To identify the memory leak, you can enable leak tracking in the technological log using the following settings:



In this event upon server call or scheduled job execution the technological log portion without the leak occurring will look as follows:

 59:44.4562-2840,CALL,5,process=rphost,p:processName=t76346,t:clientID=428,t:applicationName= JobScheduler,Func=Execute,Module=CommonModule2,Meth=ScheduledJobNoLeak 59:49.4581-2700,CALL,5,process=rphost,p:processName=t76346,t:clientID=430,t:applicationName= JobScheduler,Func=Execute,Module=CommonModule2,Meth=ScheduledJobNoLeak

If the leak occurs, this portion will look like this:

59:48.4768-2885,CALL,5,process=rphost,p:processName=t76346,t:clientID=429,t:applicationName=
JobScheduler,Func=Execute,Module=CommonModule2,Meth=ScheduledJobWithLeak

59:48.4769-0,LEAKS,5,process=rphost,Descr='

Array:

CommonModule.CommonModule2:2:AtServerWithLeak();

Array:

CommonModule.CommonModule2:2:AtServerWithLeak();

CommonModule.CommonModule1:2:M=NewArray;

Array:

CommonModule.CommonModule2:2:AtServerWithLeak();

CommonModule.CommonModule1:3:M.Add(NewArray);

In the above code portion when the ScheduledJobWithLeak() method of the CommonModule2 module was executed as a scheduled job (t:applicationName=JobScheduler, Func=Execute), three Array objects were created and not released. At that 1C:Enterprise script call stacks are specified at the time every object is created.

## 3.17.1.6. <mem> Item

If <mem> item is present, the 1C:Enterprise server processes calculate the following:

 The number of allocated and not released memory fractions;

 The total volume of allocated and not released memory fractions.

If the number of the allocated and not released memory fractions increases since the moment when the server process did not execute any call or any scheduled job, the MEM event is recorded to the technological log with the following properties:

 sz – total volume of memory fractions allocated by the process and not released;

 szd – change in the volume since the previous MEM event recording;

cn – total number of memory fractions allocated by the process and not released;

 cnd – change in the number since the previous MEM event recording.

The MEM event duration is the period between the last moment when the server process did not execute any call or scheduled job and the next to the last moment like this. This is the time when the number of memory fractions taken by the process increased.

IMPORTANT!

Including the <mem> item in the technological log configuration file will somewhat damage the 1C:Enterprise performance, especially when multiple users work simultaneously.

For example, the following configuration is intended not to track the volume of distributed memory and not to record MEM events:

<config  xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\ProgramFiles\1cv8\logs"  history="24">
<event>
<eq property="name"  value="mem"/>
</event>
<property  name="all"/>
</log>
</config>

The following configuration of the technological log tracks the volume of distributed memory and records MEM events when it increases:

<config  xmlns="http://v8.1c.ru/v8/tech-log">
<log location="C:\ProgramFiles\1cv8\logs"  history="24">
<event>
<eq property="name"  value="mem"/>
</event>
<property  name="all"/>
</log>
<mem/>
</config>


## 3.17.1.7. <plansql> Item

If the <plansql> item is available, the system enables collection of the query plans that generate the DBMS while processing the 1C:Enterprise queries. The query plans themselves are stored in the <planSQLText> property of the events related to the specific DBMS query processing (see page 273).

TIP

The <SQL> property containing a query, the plan for which will be registered, will be included in a list of registered properties (together with the <planSQLText> property).

<?xml version="1.0"?>
<config  xmlns="http://v8.1c.ru/v8/tech-log">
<log location="c:\log" history="24">
<event>
<eq property="name"  value="dbmssql"/>
</event>
<property  name="sql"/>
<property  name="plansqltext"/>
</log>
<plansql  />
</config>

In the example above, collection of the query plans (the <plansql /> item) and their registry in the registration log (the <property name="plansqltext"/> expression) together with the queries themselves (the <property name="sql"/> expression) using the 1C:Enterprise query language is enabled for Microsoft SQL Server DBMS (the <eq property="name" value="dbmssql"/> expression).

IMPORTANT!

Receipt of the query plans may slow down DBMS query processing. For some DBMS such reduction in performance may be significant. Query plans will not be obtained in the regular 1C:Enterprise mode. Query plans will only be collected during query performance analysis.

NOTE

Query plans for external data sources (the <EDS> event) can be obtained only where the database management system of the external data source is IBM DB2, Microsoft SQL Server, Oracle Database, or PostgreSQL. Query plans cannot be obtained for other types of database management systems – only query text is recorded to the technological log.

### Information on DBMS Query Plans

Guidelines on the specific DBMS query plans are provided in the documentation for these DBMS.

 Microsoft SQL Server 2000:

Microsoft SQL Server 2005:

http://msdn.microsoft.com/en-us/library/ms187735(v=SQL.100).aspx  Microsoft SQL Server 2008 R2:

http://msdn.microsoft.com/en-us/library/ms187735(v=SQL.105).aspx  Microsoft SQL Server 2012:

http://msdn.microsoft.com/en-us/library/ms187735(v=SQL.11).aspx  PostgreSQL 8.1 Windows/Linux:

http://www.postgresql.org/docs/8.1/static/performance-tips.html  PostgreSQL 8.2 Windows/Linux:

http://www.postgresql.org/docs/8.2/static/using-explain.html  PostgreSQL 8.3 Windows/Linux:

http://www.postgresql.org/docs/8.3/static/using-explain.html  PostgreSQL 8.4 Windows/Linux:

http://www.postgresql.org/docs/8.4/static/using-explain.html  PostgreSQL 9.0 Windows/Linux:

 IBM DB2 9.1 Windows/Linux:

doc/doc/r0008441.htm

 IBM DB2 9.5 Windows/Linux:

doc/doc/r0008441.html

 IBM DB2 9.7 Windows/Linux:

doc/doc/r0008441.html

 Oracle DB2 10g R2:

For PostgreSQL and Oracle Database, the query plan format exactly matches the format described in the DBMS documentation. The format of the query plans for the Microsoft SQL Server and IBM BD2 has been simplified as compared with the original format. The original field names have been preserved, however. The data in these fields is interpreted in accordance with the information related to a specific DBMS. The changes are described in the sections below. The        MS       SQL     Server Query  Plan            Format

The planSQLText field for the Microsoft SQL Server DBMS consists of several entries (strings), each of which, in turn, consists of the following fields (in DBMS terms) in the order of description:

 Rows

 Executes

 EstimateRows

 EstimateIO

 EstimateCPU

 AvgRowSize

 TotalSubtreeCost

 EstimateExecutions

 StmtText

The fields are separated with commas. The last query plan description field (StmtText) will be read to the end of the string, ignoring any commas (","). The strings are separated with a line feed. The      IBM     DB2     Query  Plan    Format

The planSQLText field for IBM DB2 DBMS consists of several entries (strings), each of which, in turn, consists of the following fields in the order of description. The field names exactly match the fields from the explain tables, i.e., the IO_COST (EXPLAIN_OPERATOR) text means that the IO_COST field will be inserted in the query plan from the EXPLAIN_OPERATOR explain table:

 OPERATOR_TYPE (EXPLAIN_OPERATOR)

 TOTAL_COST (EXPLAIN_OPERATOR)

 STREAM_COUNT (EXPLAIN_STREAM)

 IO_COST (EXPLAIN_OPERATOR)

 CPU_COST (EXPLAIN_OPERATOR)

COMM_COST (EXPLAIN_OPERATOR)

 BUFFERS (EXPLAIN_OPERATOR)

 PREDICATE_TEXT (EXPLAIN_PREDICATE)

The fields are separated with commas. The last query plan description field (PREDICATE_TEXT) will be read to the end of the string, ignoring any commas (","). The strings are separated with a line feed.

The query plan description ends with a string that starts with the Optimized query: text and contains the text of the query created by the DBMS optimizer. The original query text is provided in the SQL property of the technological logevent. The query ends with the end of the string. Identifiers from an optimized query version are used in the data from the PREDICATE_TEXT column. The     File      mode  Query  Plan    Format

A file mode query plan has the following format:

### <Query plan>

[CONST <Conditions>]
<Fields  of the selection list>
[WITHOUT DUPLICATES]
[GROUPING]
[SORTING [CUTTING TOP]]
[UNION [ALL] <Query plan>]

In this description:

 WITHOUT DUPLICATES – specifies that data should be received without duplicates.

 GROUPING – specifies that the results should be grouped.

 SORTING – specifies that the results should be sorted.

 CUTTING TOP – specifies that not all entries will be received after sorting.

### <Conditions>

WHERE [(POST) | (END)] <Condition> [AND <Condition> […]]

In this description:

 (POST) – specifies that the conditions are verified after the connection is established.

 (END) – specifies that the conditions are verified after the connections between all tables are established.

<Fields of the selection list>

Fields:(<Expression from the selection list> [,<Expression from the selection list>])

### <Scanning description>

{{NOT  SCAN} | {FULL SCAN} | {DISTINCT SCAN} | {RANGE SCAN}} [UNTIL FIRST NOT NULL]
[USING  [REVERSE] INDEX (<Index name>)[(<Number of index fields used> fields)]]

In this description:

 NOT SCAN – specifies that the table contents will not be scanned.

 FULL SCAN – specifies that the table contents will be scanned in full.

 DISTINCT SCAN – specifies that different values will be tabbed by index.

 UNTIL FIRST NOT NULL – specifies that entries will be scanned until the first non-NULL entry is received.

 USING INDEX – specifies that the values will be tabbed by index.

 REVERSE – specifies that the index will be used in reverse order.

### <Source description>

{<Table  name> [(TWICE)] <Scan description>} |
{NESTED  SELECT <Scan description> (<Query plan>)}
<Conditions>

{{  NESTED [OUTER] LOOP <Table name> [(TWICE)] <Scan description>} |
{  NESTED [OUTER] LOOP BY SELECT <Scan description> (<Query plan>)}}
<Conditions> [<Conditions>]

In this description:

 (TWICE) – specifies that the table is used several times in the query.

 NESTED LOOP – specifies that a tabbing loop of the right-hand table entries will be performed for each left-hand table entry.

 OUTER – specifies that the whole entry will not be destroyed if no entry with the appropriate link condition is found in the right-hand table.

## 3.17.1.8. <defaultlog> item

The <defaultlog> item defines default technological log parameters. This log has a fixed event filter for the events defined by 1C:Enterprise. This filter cannot be changed and can be presented with the following settings file:

<log  location="C:\Users\<UserName>\AppData\Local\1C\1cv8\logs"  history="24" >
<event>
<eq property="name" value="system"/>
<eq property="level" value="error"/>
</event>
<property  name="all"/>
</log>

This log records the events that are critical for system operation. The essence of the events is not logged. The <system> item can be used to set up detailed recording of event creation. The attributes of an item:

Location attribute

The name of the directory where the default technological log will be stored. If the attribute is not set, the technological log is saved to the following directories by default:

 Windows OS:

Windows XP: %USERPROFILE%\Local Settings\1C\1cv8\logs.

Windows Vista (or later): %LOCALAPPDATA%\1C\1cv8\logs.

 Linux: \$HOME/.1cv8/logs.

### NOTE 1

Please note that a directory of any technological log is not intended for storing files that are not related to the technological log. So do not store dumps there and do not use a directory that can contain files that are not related to the 1C:Enterprise technological log. If there are any foreign files in the directory that is specified as a technological log directory, such specification is deemed invalid, and no technological log will be created.

### NOTE 2

The <log>, <dump> and <defaultlog> items must specify different directories in their location attributes.

History attribute

The number of hours after which information will be deleted from a technological log. If you set this attribute to 0, no technological log will be recorded by default.

The default value is 24.

Unlike other technological log files, the default technological log files are only created when a certain event occurs.

## 3.17.1.9. <system> item

The <system> item is used to control SYSTEM events creation in the technological log. A technological log settings file (logcfg.xml) may contain 0, 1 or several such elements.

If the <system> item is missing in the logcfg.xml file, then the technological log has the following default setup: the level on which system events are created for all system components is the Error level.

SYSTEM events will be recorded in all set technological logs (including the default one).

Attributes of an item:

The Level attribute

Sets the minimum value for the level of the events created by the system. Possible values (in the order of increasing importance):

 Trace – the level of maximum detail.

 Debug – the debug information level. This is set to record the events required for debugging platform mechanisms or investigating errors which are especially difficult to detect.

 Info – an information level. This records any events evidencing normal operation of a platform mechanism.

 Warning – a level of warning. This records any events that inform of unusual situations that are not, however, critical from the point of view of the platform mechanism.

 Error – is a level of error. This records any events that inform of the situations that are deemed erroneous from the point of view of the platform mechanism.

 None – system events are not recorded.

If you set this attribute, 1C:Enterprise will not create events that do not correspond to the level specified.

For instance, if you have a <system level="info" /> construction in the logcfg.xml file, that means that 1C:Enterprise will create events of the Info, Warning, and Error levels.

The Component attribute

Defines the name of the component for which the creation of system events is set up. The component name is case sensitive.

The Class attribute

Defines the name of the class for which the creation of system events is set up. The class name is case sensitive.

Let us review a sample situation when file logcfg.xml contains the following piece of code:

<system level="info"/>
<system  level="debug" class="core::FileSystem" />
<system  level="warning" component="core 83" />

This setting means the following:

 SYSTEM events with the Info level (or higher) should be created for all system objects.

 However, events of the Debug level should be created for the core::FileSystem class.

 Events of the Warning level (or higher) should be created for all core 83 component classes.

### 3.17.2. Recording Contexts of Exceptions

An exception context is a sequence of EXCPCNTX technological log events. Every EXCPCNTX event is one of the protracted events that were started at the moment of an exception in 1C:Enterprise operation but were not ended. At that the events are recorded in descending order of nesting levels. The type of the event that was the source of the EXCPCNTX event serves as a value of SrcName property of the EXCPCNTX event.

The exception context is recorded to the technological log if the technological log itself is enabled (at least one log item is available in logcfg.xml) and one of the following exceptions occurs:

 Operating system exception occurs during 1C:Enterprise operation, the process

(client or server) fails and crash dump is generated;

 Database exception occurs that results in displaying an error message and shutting 1C:Enterprise application down.

When any database error occurs, the EXCP event is recorded to the technological log if it meets the criteria specified in the technological log configuration file (logcfg.xml).

### 3.17.3. Recording Interlocks

Every time a query is sent to the database management system (DBMS) but once every 2 seconds at the most, another query is sent to the DBMS about the locked and locking streams. This query results in a table of pairs ("lock victim", "lock source") where:

 Lock victim – identifier of DBMS connection in waiting for being locked;  Lock source – identifier of DBMS connection that initiated the lock.

If multiple working processes exist in a cluster, the query is processed by one of such processes. The interlock queries are numbered.

The data from the resulting table are added to the context of every stream the resulting DBMS connection IDs comply with. These data will be recorded as the values of lock properties of the next technological log event. Once the next technological log event is completed in the stream with the lock information added to its context, this event will also have lock properties added to it. At that if the stream is a lock victim, the lock events will be cleared after recording. If the stream is a lock source, the events will only be cleared when the transaction is closed or rolled back.

The lock information is added to the streams in the following order:

 If the victim stream is not aware of the lock, query number and lock source stream ID are assigned to this stream;

 The lock source stream gets the query number only if it has unaware victims.

Locks information:

 Stream is a source, detection moment.

 Stream is a victim, detection moment.

 Query number (if the stream is a victim).

 Query numbers list (if the stream is a source).

 Source connection number (if the stream is a victim).

Lock properties of events:

 lka='1' – the stream is a lock source.  lkp='1' – the stream is a lock victim.

 lkpid – "who blocked whom" DBMS query number (only for the lock victim stream). Example: '423'.

 lkaid – The list of "who blocked whom" DBMS query numbers (only for the lock source stream). Example: '271,273,274'.

 lksrc – lock source connection number if the stream is a victim, e.g. '23'.

 lkpto – time in seconds elapsed since the moment it was detected the stream was a victim. Example: '15'.

 lkato – time in seconds elapsed since the moment it was detected the stream was a locks source. Example: '21'.

So in order to analyze the locks, you will need to find the first event with lka and lkp properties in the rphost processes technological logs, identify the values of the lkaid, lkpid properties and find all the events with these values of the properties in the logs of all the cluster working processes. Based on the group of the identified events you can define the events that were the sources and victims of locks, locks duration and the events behavior during the locks.

In addition, the Txt property of the TLOCK event in the technological log may record the namespace with a lock applied.

#### 3.18. LOGUI.TXT

logui.txt file contains the list of interactive user actions executed during the time of logging.

File location:

 For Windows: is located at %APPDATA%\1C\1cv8\<Unique infobase identifier>

 For Linux: ~/.1cv8/1C/1cv8/<Unique infobase identifier>

Every record describes one user action. In general, the string is formatted as follows:

 Date and time of the event,

 Event description (Event),

 Name of the object the event occurred to,

 Time (in milliseconds) elapsed since software was launched (t),

 beg or end prefix (similar to opening and closing brackets) that identifies an event beginning and end,  Details (Detail).

In order to collect statistics on actions duration, the protocol records action beginning and end. The action beginning is contained in the record identified by beg while the action end is identified by end (these attributes are located at the very end of the log string).

Action duration is also recorded: it is identified by t. The time is counted in milliseconds from the moment the software is launched.

The log strings containing beg and end may be separated by nested actions containing beg and end in turn as well as by the strings describing some actions that need to be recorded in the log.

Logging is applied to all the form controls and global command interface items available in the 1C:Enterprise mode.

The following actions are logged:

 Pressing a keyboard key. The data typed by the user are replaced by a star symbol in the log (Event Key_<key> or Event key_*),

 Left click (Event_LClick), right click (Event_RClick) and middle click (Event_ MBtnDn),

 Double click (Event_ LBtnDbl),

 Mouse wheel scrolling (Event_Wheel).

Some items have specific events that are not used for other items:

 Form:

Form window activation:

"Event FormActivate","Name <formname>"

 Subsystem panel (PartitionPanel):

Selecting a subsystem or the desktop with the mouse:

"Event LClick","Name PartitionPanel"

Activation using a keyboard shortcut:

"Event PanelActivate","Name SubsystemsPanel"

Command execution:

Command folder expanding/collapsing:

"Event LClick","Name FormNavigationPanel","Detail Close<command folder name>"

Activation using a keyboard shortcut:

 Window title (WindowCaptionText):

Clicking the title:

"Event LClick","Type WindowCaptionText","Detail Data Processor"

 Actions panel (ActionsPanel):

Command execution:

"Event LClick","Name ActionsPanel","Detail <command name>"

Activation using a keyboard shortcut:

"Event PanelActivate","Name ActionsPanel"

 Information panel area displaying the list of the latest notifications (NotificationHistoryPanel):

Command execution:

Activation using a keyboard shortcut:

 Status window (StatusWindow):

Closing:

"Event CloseWindow"

Moving:

"Event MoveWindow offset=<dx,dy> pos=<x,y,w,h>"

Closing:

"Event CloseWindow"

Moving:

"Event MoveWindow offset=<dx,dy> pos=<x,y,w,h>"

 Check window (entry errors prompt) (CheckWindow):

Clicking the Next message button:

"Event LClick","Name CheckWindow","Detail NextButton"

Clicking the Previous message button:

"Event LClick","Name CheckWindow","Detail PrevButton"

Clicking the Close button:

"Event LClick","Name CheckWindow","Detail CloseButton"

Log records example:

"17.12.200816:41:55","Event  Key_SPACE",
"Name HistoryPanel",  "t=465562", "beg"
"17.12.200816:41:55","Event  FormActivate",
"Name  Catalog.Articles.ListForm", "t=465562"
"17.12.200816:41:56","Event  Key_SPACE","Name HistoryPanel",
"Detail Bold","t=466281",  "end"
"17.12.200816:07:05","Event  PanelActivate",
"Name HistoryPanel",  "t=918188"

#### 3.19. NETHASP.INI

The nethasp.ini configuration file is used to customize the parameters of 1C:Enterprise interaction with the HASP License Manager.

The file is located in the 1C:Enterprise configuration files directory and it is optional. If the configuration file directory does not contain the given file, it will be searched for in the following directories:

 For Windows:

directory of executable files of the 1C:Enterprise version being run

current directory

%SYSTEMROOT%\Windows\System32 directory (for 32-bit Windows) or

%SYSTEMROOT%\Windows\SysWOW64 directory (for 64-bit Windows)

%SYSTEMROOT%\Windows\System directory

%SYSTEMROOT%\Windows directory

directories listed in the PATH environment variable  For Linux:

current directory

user’s home directory

/etc directory nethasp.ini contains four sections:

 [NH_COMMON], for common settings (see page 308)

 [NH_IPX], for IPX (see page 308)

 [NH_NETBIOS], for NetBIOS (see page 309)

 [NH_TCPIP], for TCP/IP (see page 309)

The [NH_COMMON] section contains global settings for all the sections of the configuration file. The remaining sections contain settings that affect operations with specific protocols.

In each section, you can use parameters specific to that section or those shared by all the sections. A parameter shared by all the sections specified in a section for one of the three protocols has higher priority than a setting in the [NH_COMMON] section (as applied to that protocol).

To specify extended settings for a particular protocol, use the parameters specific to the particular section.

The configuration file can contain comments. Comments begin with a semicolon (";") and continue to the end of the string.

Parameter names are not case sensitive.

In what follows you will find a list of parameters and their allowed values that can be used in various sections of nethasp.ini.

When you install 1C:Enterprise, a sample nethasp.ini file is copied to the 1C:Enterprise setup directory conf. This file actually consists entirely of commented-out strings and does not predefine default parameter values, but it does contain the most complete list of parameters that can be used to customize interaction of 1C:Enterprise with HASP License Manager.

Below we will describe in detail the parameters in every configuration file section.

### 3.19.1. [NH_COMMON] Section

NH_IPX

Available values: Enabled, Disabled. Defines if IPX should be used (respectively) for communication with HASP License Manager.

Default value: Enabled.

NH_NETBIOS

Available values: Enabled, Disabled. Defines if NetBIOS should be used (respectively) for communication with HASP License Manager.

Default value: Enabled.

NH_TCPIP

Available values: Enabled, Disabled. Defines if TCP/IP should be used (respectively) for communication with HASP License Manager.

Default value: Enabled.

NH_SESSION

Available values: <Number>. Specifies the period in seconds for the program to continue attempts to connect to HASP License Manager.

Default value: 2 seconds.

NH_SEND_RCV

Available values: <Number>. Specifies the period in seconds for the program to continue attempts to connect to HASP License Manager.

Default value: 1 second.

### 3.19.2. [NH_IPX] Section

NH_USE_SAP

Available values: Enabled, Disabled. Defines if SAP service should be used to search for HASP License Manager in the network.

Default value: Enabled.

Available values: Enabled, Disabled. Defines if Broadcast mechanism should only be used to search for HASP License Manager in the network. This option is useful when working with IPX in networks other than Novell NetWare. Default value: Enabled.

NH_BC_SOCKET_NUM

Available values: <Number>. Specifies the socket number for the broadcast mechanism. The number is specified in hex.

Default value: 7483Í.

NH_SERVER_NAME

Available values: localnet, Internet. Specifies whether the application exchanges data only with HASP LM in the local network or with any other HASP LM.

Default value: Internet.

NH_DATFILE_PATH

Available values: <Path>. The path where haspaddr.dat and newhaddr.dat files will be searched for. These files contain HASP License Manager network address. This parameter is mostly useful only with NH_USE_SAP=Disabled è NH_USE_BROADCAST=Disabled settings because otherwise the HASP License Manager address can be determined automatically.

NH_SESSION

Available values: <Number>. Specifies the period in seconds for the program to continue attempts to connect to HASP License Manager.

Default value: 2 seconds.

NH_SEND_RCV

Available values: <Number>. Specifies the maximum packet send or receive time for HASP License Manager.

Default value: 1 second.

### 3.19.3. [NH_NETBIOS] Section

NH_NBNAME

Available values: <Name>. Specifies HASP License Manager name (the name can contain a maximum of 8 characters).

NH_USELANANUM

Available values: <Number>. Specifies the port number that will be used as a communication channel.

NH_SESSION

Available values: <Number>. Specifies the period in seconds for the program to continue attempts to connect to HASP License Manager.

Default value: 2 seconds.

NH_SEND_RCV

Available values: <Number>. Specifies the maximum packet send or receive time for HASP License Manager.

Default value: 1 second.

### 3.19.4. [NH_TCPIP] Section

NH_SERVER_NAME

Available values: <name1>, <name2>. Exchanges data with a HASP LM with the specified name. Maximum of six names; every name may consist of up to seven characters.

NH_PORT_NUMBER

Available values: <Number>. Defines network port number.

Default value: 475.

NH_TCPIP_METHOD

Available values: TCP, UDP. You may use this to send a TCP or UDP packet.

Default value: UDP.

NOTE

Selecting TCP as the value for the parameter will be ignored. The license manager is always connected to via UDP.

Available values: Enabled, Disabled. Use the UDP broadcast mechanism.

Default value: Enabled.

NH_SESSION

Available values: <Number>. Specifies the period in seconds for the program to continue attempts to connect to HASP License Manager.

Default value: 2 seconds.

NH_SEND_RCV

Available values: <Number>. Specifies the maximum packet send or receive time for HASP License Manager.

Default value: 1 second.

#### 3.20. NHSRV.INI

Some HASP License Manager settings may be specified using nhsrv.ini configuration file.

File location:

 For Windows: this file is searched for in various directories in the following order:

The directory containing the HASP License Manager executable file.

 The  current Windows directory.

 Microsoft Windows system directory (%SystemRoot%\system32 for 32-bit version or %SystemRoot%\system for 64-bit version).

 Microsoft Windows directory (the %SystemRoot% directory).

 The directories listed in the PATH environment variable (only if the HASP License Manager is installed as a Microsoft Windows application).

For OS Windows we recommend placing nhsrv.ini, if you need it, in the directory where the HASP License Manager executable file is located. To verify that HASP License Manager has located and read the configuration file, you can use Event Viewer/Server Activity Log.

 For Linux: the location of nhsrv.ini configuration file is specified using the -c parameter. Location of configuration files is undefined by default.

Configure HASP License Manager by setting parameter values in the [NHS_ SERVER] section of nhsrv.ini:

NHS_IP_LIMIT

Defines the range of network workstations served by HASP LM. Example:

10.1.1.1, 10.1.1.*,10.1.1.1/32, 10.1.1.1/24.

Defines the IP address of one or more NICs that will be served by the HASP License Manager. Use when running HASP License Manager with Win32. Example: 10.1.1.111, 255.255.0.0.

NHS_USERLIST

Maximum number of users connected to the license manager at the same time. Default value: 250.

#### 3.21. SRV1CV83

Configuration file /etc/sysconfig/srv1cv83 (for RPM-system) is used to define startup options for 1C:Enterprise server agent using the script at /etc/init.d/srv1cv83. If installation was performed for DEB-system, then parameters listed below should be specified in /etc/init.d/srv1cv83 file.

IMPORTANT!

This configuration file is used when 1C:Enterprise server is run under Linux.

The configuration file configures the following parameters:

SRV1CV8_KEYTAB

Path to the Kerberos privacy key file.

SRV1CV8_DATA

The directory where server cluster service files will be located (including cluster list and cluster infobase list).

SRV1CV8_PORT

Number of cluster agent master port. This port is used by cluster agent to send a request to the central server. Agent cluster port is also specified as the network port of the Working server.

SRV1CV8_REGPORT

The cluster network port created by default when ragent is first run.

SRV1CV8_RANGE

Network port ranges for dynamic distribution. Cluster processes service ports are selected among them when they cannot be selected based on the settings of the corresponding Working server.

SRV1CV8_DEBUG

Run in the debugging mode:

  0 – no debugging mode (by default);  1 – in the debugging mode.

SRV1CV8_SECLEV

Connections security level;

  0 – disabled (by default);  1 – establishing connection;  2 – permanently.

#### 3.22. SWPUSER.INI

For the working process to be started under the user account other than the server agent was launched under, swpuser.ini can be located in the application data directory for the server agent user. The file has the following format:

user=<operating  system user name>
password=<operating  system user password>

Below is the sample content of swpuser.ini:

user=\\Server_comp\uuuu
password=1234567

In this case the working processes launched at this working server will be started under the user account of the specified operating system user (\\Server_comp\uuuu).

When specifying an account under which the cluster work process should be run on the specific working server in the swpuser.ini file, provide the privileges listed below for the account:

 Log on as a service

 Log on as a batch job

And to include that user in the following groups:

 Performance Log Users

In addition, the account under which the 1C:Enterprise server agent service is run should have the Replace a process level token privilege.

#### 3.23. TESTCFG.XML

The testcfg.xml file serves to set up the port range used in the automated testing of applied solutions operating in the web client.

The file is stored in the configuration file directory of the 1C:Enterprise systemg and is optional.

If the file is not found, ports in the standard range (1538-1539) are used for the interaction.

Example:

<config  xmlns="http://v8.1c.ru/v8/testcfg">
<testports range="1538:1539"/>
</config>

The testports item has the attributes described below.

range Attribute

Type: String. This contains a port range used by the web server to ensure interaction between the testing manager and the testing client.